From: "Andrew Scott" <A.J.Scott@casdn.neu.edu>
To: Greg Boyce <gboyce@rakis.net>, linux-kernel@vger.kernel.org
Subject: Re: Machines misreporting Bogomips
Date: Fri, 8 Feb 2002 12:13:23 -0500 [thread overview]
Message-ID: <3C63C0E3.17319.A2A062@localhost> (raw)
In-Reply-To: <Pine.LNX.4.42.0201311747560.24180-100000@egg>
On 31 Jan 2002 at 17:55, Greg Boyce wrote:
> kernel folk,
>
> I've got a strange issue that I've been struggling to find the solution to
> for some time now.
>
> I work in a group that assists in the managing of large numbers of
> deployed linux boxes running variants of the 2.2 kernel on them. The
> machines themselves are all pretty standard. There are slight variances
> on vendors, cpu speeds, etc., but they're all running from the same
> motherboards.
>
> Every once in a while we come across single machines which are running a
> lot slower than they should be, and are misreporting their speed in
> bogomips under /proc/cpuinfo. Reinstalling the OS and changing versions
> of the kernel don't appear to affect the machines themselves at all.
>
> I was wondering if anyone would be able to provide me with a starting
> point to hunt this down. The only solution we had found in the past was
> to replace the machines, but some of them are located out of the country
> and that would be expensive.
It seems to me that there was an issue with timers not being set up
properly, or changing their settings during startup, which could cause a
machine to behave like it was running slow. On more recent 2.2.x kernels
you would see a line like 'timer configuration lost' in dmesg, which meant
that the computer had the problem, and a workaround was being implimented.
On kernels that didn't detect the timer problem you could sometimes boot
with no problem, but other times you'd get a kernel that seemed to run very
slowly.
I don't remember if it affected the bogomips reporting, but I would think
that it could.
BTW, I think that the kernels I had the problems with were pre 2.2.17,
though I'm not positive. 2.2.20 and 2.2.19 do not exhibit the problem. i.e.
they detect the problem and work around it.
_
/ \ / ascott@casdn.neu.edu
/ \ \ /
/ \_/
next prev parent reply other threads:[~2002-02-08 17:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-31 22:55 Machines misreporting Bogomips Greg Boyce
2002-01-31 23:21 ` Matthew Dharm
2002-01-31 23:30 ` Roger Larsson
2002-02-01 0:11 ` Greg Boyce
2002-02-01 9:59 ` Horst von Brand
2002-02-01 17:11 ` Greg Boyce
2002-02-01 12:59 ` gmack
2002-02-01 20:53 ` Greg Boyce
2002-02-01 23:41 ` Alan Cox
2002-02-01 23:34 ` Greg Boyce
2002-02-01 23:59 ` Alan Cox
2002-02-03 22:05 ` Juhan Ernits
2002-02-03 7:39 ` watermodem
2002-02-08 17:13 ` Andrew Scott [this message]
[not found] <no.id>
2002-02-03 21:40 ` Barry K. Nathan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C63C0E3.17319.A2A062@localhost \
--to=a.j.scott@casdn.neu.edu \
--cc=gboyce@rakis.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).