lkml.org 
[lkml]   [2007]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [REGRESSION from 2.6.23-rc8] (was: Re: 2.6.23-rc4-mm1 and -rc6-mm1: boot failure on HP nx6325, related to clockevents)
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/

\
 
 \ /
  Last update: 2007-09-30 16:41    [W:0.113 / U:0.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site