All of lore.kernel.org
 help / color / mirror / Atom feed
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
                    / \ \ /
                   /   \_/


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.