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)

[Thomas Gleixner <tglx@linutronix.de>]

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
> > patch too)
>
> There is nothing really to fix currently.  Clockevents changes behaviour
> majorly (always using APIC timers without irq 0 backups[1]) 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
> question.

I understand the code quite well. I'm just surprised from time to time by 
interesting hacks in the so clean x8664 tree.

> [1]  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.

      tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/