Messages in this thread |  | | | Date | Wed, 24 Nov 1999 11:38:32 +0100 (CET) | | From | Ingo Molnar <> | | Subject | [patch] smp-2.3.29-B2, spinlocks, reboot |
| |
On Tue, 23 Nov 1999, Robert Redelmeier wrote:
> 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/
|  |