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)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux