public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Lord <lkml@rtr.ca>
To: Arun Thomas <arun.thomas@gmail.com>
Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	jirislaby@gmail.com
Subject: Re: PROBLEM: E6850 has an 8+ minute delay during boot
Date: Fri, 14 Dec 2007 09:38:32 -0500	[thread overview]
Message-ID: <47629568.6050901@rtr.ca> (raw)
In-Reply-To: <9a8cbed90712140110l156a34e3x38533b7710544cf8@mail.gmail.com>

Arun Thomas wrote:
...
> [   31.670148] TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
> [   31.670351] TCP: Hash tables configured (established 131072 bind 65536)
> [   31.670391] TCP reno registered
> [   31.681591] checking if image is initramfs...<7>Switched to high
> resolution mode on CPU 0
> [  540.133678] Clocksource tsc unstable (delta = 299978139535 ns)
> [  540.137708] Time: hpet clocksource has been installed.
> [  540.432798]  it is
> [  541.570364] Freeing initrd memory: 44428k freed
> [  541.570748] audit: initializing netlink socket (disabled)
...

Ahh... BINGO!

This is very likely the same problem that I first reported back in 2.6.21(20?),
when NOHZ and HPET first came in!

It never occurred to me to wait a full 8-minutes though,
so I just rebooted again after a 1-2 minute wait each time.

Seen on Core2Duo T7400 and Core2Quad E6600 systems, with kernels 2.6.21/22
at various points.  Not consistent -- sometimes it would boot after a few
attempts, sometimes not.

It always hung around the "Switched to high resolution mode" messages.

Thomas Gleixner wrote:
> The problem is caused by an SMI during the calibration routine. We
> really need to come up with a solid solution which does not rely on
> the periodic timer coming in, when there is something else (HPET,
> pm_timer) available.
...

Oh good, an explanation!

Now we just need a creative fix.

One thing that *might* be sufficient, would be to do the
delay loop calibration twice, and compare the results to
see if they're within 10% (pick a number) of each other.

Is there a flag or something that SMI sets that we could poll
before/after the calibration?  That could be used to tell us
that it needs redoing ?

  parent reply	other threads:[~2007-12-14 14:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-14  9:10 PROBLEM: E6850 has an 8+ minute delay during boot Arun Thomas
2007-12-14  9:53 ` Andrew Morton
2007-12-14 10:01   ` Arun Thomas
2007-12-14 10:18     ` Jiri Slaby
2007-12-14 10:43       ` Thomas Gleixner
2007-12-14 11:15         ` Arun Thomas
2007-12-14 14:44         ` Mark Lord
2007-12-14 19:01         ` H. Peter Anvin
2007-12-15  0:00           ` Arun Thomas
2007-12-15  0:38             ` H. Peter Anvin
2007-12-14 14:38 ` Mark Lord [this message]
2007-12-15  6:07 ` Len Brown
2007-12-16  5:38   ` Arun Thomas

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=47629568.6050901@rtr.ca \
    --to=lkml@rtr.ca \
    --cc=akpm@linux-foundation.org \
    --cc=arun.thomas@gmail.com \
    --cc=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /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