[Bug runtime/20820] another "soft lockup" BUG on RHEL7 ppc64

["dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20820

--- Comment #12 from David Smith <dsmith at redhat dot com> ---
(In reply to Martin Cermak from comment #11)
> Hi David, attached test results show the effect of the above patch on my
> test boxes.  Actually, I have 12 more ppc64 test boxes not reported there,
> but showing similar results.  No division by zero observed at any of them
> yet (although especially one of them looks very close to yours).  I wonder
> whether there is some difference in how we test.

There is probably a difference in our source code. I'm running with a patch to
the time initialization code that you don't have. As part of my work debugging
bug #20735, I updated/improved the __stp_get_freq() runtime C function (in
runtime/time.c).

Currently, what it does it get the cpu frequency in an arch-specific way. If
there isn't arch-specific support for a particular architecture, it tries to
estimate the cpu frequency. On ppc64, that estimated cpu frequency is used.

While looking at that code, I decided to add some arch-specific ppc64 code that
grabs the cpu frequency. Later, I then found a arch-independent way of getting
the cpu frequency on kernels that have CONFIG_CPU_FREQ.

I've been running with that patch for about a month now, but just haven't
checked it in yet. I'd guess the more accurate cpu frequency returned by the
new code is changing the values returned by the gettimeofday_us() tapset
function.

-- 
You are receiving this mail because:
You are the assignee for the bug.