Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1959

Summary: procinfo -d -n1 gets FP exceptions
Product: [Retired] Red Hat Raw Hide Reporter: Chris Siebenmann <cks-rhbugzilla>
Component: procinfoAssignee: Michael K. Johnson <johnsonm>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: 1.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-08-27 14:46:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Chris Siebenmann 1999-04-03 03:00:55 UTC
procinfo-16-3's procinfo gets FP exceptions sometimes
when run with '-d -n1' on a dual-CPU machine. What seems
to do it is running something with heavy CPU usage on
both CPUs (such as the distributed.net rc5des client).
If you run it for a while and wait, boom, there it goes.
I have not tested this behavior on a UP kernel.

 This is running with the latest Rawhide (although it
happened both under the Rawhide SMP kernel and under
stock 2.2.5-ac3).

Comment 1 Chris Siebenmann 1999-04-04 00:47:59 UTC
The root cause of this seems to be that raw idle time number
in /proc/stat occasionally blips backwards (!), with a ripple
through effect on procinfo, which assumes it always goes forward.

 I'm not sure how this is possible, but the idle number is not
a kstat variable but is instead worked out by subtracting all
the other time ticks (kernel, user, nice) from elapsed jiffies
(times the number of cpus). Possibly there is some update ordering
issues there, especially with multiple cpus and IRQs coming in at
just the wrong time on the 'other' cpu.

 I will be asking the gurus. In the mean time, there is an obvious
patch that can be made to the code in procinfo that reads /proc/stat
(just check if new.cpu_idle < old.cpu_idle and make them equal if
so).

Comment 2 Preston Brown 1999-08-27 14:46:59 UTC
fixed in procinfo-17-1, available in the next release.  However, as
this seems to be a kernel bug, I also certainly hope that it has been
corrected in a later release of the kernel as well.