Re: [REGRESSION from 2.6.23-rc8] (was: Re: 2.6.23-rc4-mm1 and-rc6-mm1: boot failure on HP nx6325, related to clockevents)
From: Thomas Gleixner
Date: Sun Sep 30 2007 - 10:39:32 EST
On Sun, 30 Sep 2007, Andi Kleen wrote:
OK, this explains 2) and 3). I just looked into the code and the logic
vs. noapictimer on SMP is completely broken.
noapictimer really doesn't make any sense on non SMP imho with the old
timer architecture. That is why I never bothered to implement it.
It's purely a UP hack.
It does not matter whether it makes sense to you or not. It is a command
line option which bricks systems. There is neither an explanation in
Dokumentation/kernel-parameters.txt nor a check in the code, which
disables this completely.
It makes a lot of sense even with the existing architecture. Trouble
shooting a box, where the local apic timer does not work correctly is not
an UP only requirement.
Yes, it is a hack, a _bad_ hack.
..and thanks for the explanation.
Thanks for finding it so quickly guys. Sounds like this will be fixed
properly in 2.6.24 with the x86 merge (which hopefully brings in the hrt
There is nothing really to fix currently. Clockevents changes behaviour
majorly (always using APIC timers without irq 0 backups) and that causes
problems that need new workarounds and new fixes (surprise surprise!)
That merge would probably fix a few more such "Thomas doesn't understand
the code" bugs I guess because he hacks much more on i386 than x86-64;
but if the overall result will be really better is a totally different
I understand the code quite well. I'm just surprised from time to time by
interesting hacks in the so clean x8664 tree.
 Or let's call it "I trust all my time to the CPU" and no more southrbridge
aka put all eggs in one basket. Given the trends in CPU power saving that
is a quite dangerous strategy.
No, it's not dangerous. We spent quite some time to make the clock events
layer flexible enough to handle the current problems and the design allows
to add more infrastructure when necessary. The maybe new (mis)features of
upcoming CPUs need to be addressed with or without clock events and they
need to be done careful and not by random hacks.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/