Hmmm... on closer inspection, bogomips shouldn't change unless
cpuinfo[].loops_per_jiffy changes, and *that* is typically set at system startup
and should only change if the cpufreq driver messes with CPU frequencies. Since
the cpufreq driver isn't even enabled for RHEL3 x86_64 at this time, I'm puzzled...

OK, since I only have my memory to depend upon when I state that the
bogomips values changed while the computer was running, maybe its just
isn't so...
However I just rebooted it, and now it came up with the values 6710.88
and 3578.26 for the two CPU:s, so there certainly still is a problem.

Hi, David. I'm reopening this bug because nothing changed in the -20.0.1.EL
security errata that could possibly affect the problem. Jim is busy at the
moment with different bugs, but he'll get back to this someday. The RHEL3
U4 kernel (-27.EL) is scheduled for release in a couple of weeks (on 12/15).

Thanks for the update, David. For now, since we've never been able
to reproduce this problem and now you can't either, I'm going to
tentatively close this bug. If the problem reappears, please reopen.
Thanks. -ernie

Just discovered that for the moment 23 of our 35 dual opteron servers
have a slight differens in the bogomips value reported for the two cpu:s
To be precise, on all of them, the second CPU reports 13.11 bogomips
more then the first one.

Small deviations like this are considered acceptable. I've noticed
that on 4P systems the bogomips for CPU 0 is sometimes slightly
different than that for CPUs 1, 2, & 3. This is because CPU 0 is
initialized through a different code path than the others. Since
"bogomips" begins with "bogo-", we don't consider this a major issue
since it's not intended for high-precision timing calculations or
anything like that.
Please let us know if you see any runtime drift between the values.

right now, we see a 81.92 bogomips deviation on all our machines. Anyway, since
we've stoped using Platform LSF, we no longer have any applicatoin that depends
on this figure, so I'll close this issue.

Hi SEG,
This appears to be BZ 138336. I'm bumping this to internal priority
"2" to match the customer's elevated severity.
Some notes and questions from the customer (this ticket is quickly getting
really, really long and hard to read):
==========
Looks like the same issue in that BZ...
The reason this is a problem for us is that Platform LSF uses the largest
bogomips value to determine CPU speed, and if we can't count on the
bogomips value to be a) reasonably predictable for a given CPU frequency,
and b) the same for all CPUs in a system, then the LSF software reports
incorrect values for the CPU speed, causing our customers' jobs to land
on the wrong systems.
I'm elevating this issue to "high" since it's obviously not an
isolated case, is affecting our customers' jobs, and has been reported by
other people but not gotten enough attention.
We don't have enough 3U9 systems installed yet to have any idea whether
it fixes this problem. It will be several months before U9 has enough
penetration in our environment.
This problem appears to affect roughly 44% of our systems, i.e. at least
one bogomips entry differs from the others. Should we expect for a system
with 2-8 identical CPUs to have identical bogomips entries for all cores?
Or should we expect some small degree of variance?
=========
Issue escalated to Support Engineering Group by: pvn.
Internal Status set to 'Waiting on SEG'
Priority set to: 2
This event sent from IssueTracker by streeter
issue 124968

This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

Note

You need to
log in
before you can comment on or make changes to this bug.