Pavel Machek wrote:
How can hlt check break? It is hlt;hlt;hlt, IIRC, that looks fairly
innocent to me.
Not if you use tickless timers that don't generate interrupts to unhalt
you, or if you delay ticks until the next scheduled timeout and you
haven't yet scheduled any timeout. Both are likely in a hypervisor.
Well.. but you are working around problem, instead of fixing it.
Tickless kernels are possible on normal machines, too.
Please fix it properly... probably by requesting timer 10msec in
advance or something.
Pavel
Well, I agree in spirit, but there is something to be said for keeping
the code less complicated by removing these workarounds for broken
processors. Preferably, we could remove the hlt check entirely, but
then those people with these broken processors would not get the
expected behavior of stalling during boot - that is the expected
behavior of failure, correct? In any case, I added this workaround for
the case when running under Xen. I would rather not add a dependence on
timer scheduling to legacy bug checking code when the number of timer
sources and tickless variations available is proliferating and the
number of legacy processors that would even need this check is rapidly
approaching zero.
Zach
-
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]