From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57957 invoked by alias); 1 Dec 2016 16:11:08 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 56895 invoked by uid 48); 1 Dec 2016 16:10:54 -0000 From: "dsmith at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/20820] another "soft lockup" BUG on RHEL7 ppc64 Date: Thu, 01 Dec 2016 16:11:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: runtime X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dsmith at redhat dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2016-q4/txt/msg00104.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D20820 --- Comment #12 from David Smith --- (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 debugg= ing 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 gett= ing 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. --=20 You are receiving this mail because: You are the assignee for the bug.