[lkml]   [2007]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PROBLEM: E6850 has an 8+ minute delay during boot
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 ?

 \ /
  Last update: 2007-12-14 15:41    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean