> While digging into SMP stability (I have a stable Abit BP6, but
> worried), I ran across the following kernel code:
>
> Ingo Molnar coded in kernel/irq.c from Linux 2.1.76 to 2.3.28:
> > /*
> > * I had a lockup scenario where a tight loop doing
> > * spin_unlock()/spin_lock() on CPU#1 was racing with
> > * spin_lock() on CPU#0. CPU#0 should have noticed spin_unlock(), but
note that this is old-old code and a very old comment, from the early days
of finegrained SMP. We've fixed many many lockups since then. We also have
the NMI oopser running on all SMP boxes unconditionally, which should
debug the above lockup just fine.
i've disabled the above workaround in smp-2.3.29-B2 (attached, against
vanilla 2.3.29), we will see wether anyone sees any lockup + NMI assert.
[Will remove that code altogether after some timeout.]
the patch also updates some other SMP things:
- adds the 'movb $0, %0' spin_unlock() variant, now that Intel has
clarified the P6 core's cache-coherency behavior.
- fixed the annoying 'APIC error ...' messages on reboot
- cleaned up the reboot path, clean APIC/IOAPIC state after reboot
- the error codes in 'APIC error ...' messages are now analyzed and
printed out in plaintext as well, this should help people determining
why the kernel is complaining:
APIC error interrupt on CPU#0, should never happen.
... APIC ESR0: 00000004
... APIC ESR1: 00000004
... bit 2: APIC Send Accept Error.
- focus CPU disabled again, still causes problems.
it works just fine on my box.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/