On Sun, May 28, 2006 at 05:48:33PM +0200, Michael Buesch wrote:
> Oh, yes. That's really an interresting oops.
> I guess the interrupt, which is used for bcm, is used by another
> device, too. Is that right? Could you show us your /proc/interrupts
> please?
> In the "interrupt-shared" case it is indeed possible to deadlock.
> I will do an updated patch, which tries to solve this.
hmm, i don't think so. This is from my UP kernel, but iirc it's the same
for the smp one:
CPU0
0: 4855137 IO-APIC-edge timer
1: 51628 IO-APIC-edge i8042
7: 3 IO-APIC-edge parport0
8: 0 IO-APIC-edge rtc
9: 9283 IO-APIC-level acpi
12: 23101 IO-APIC-edge i8042
14: 21526 IO-APIC-edge ide0
15: 172237 IO-APIC-edge ide1
16: 4 IO-APIC-level yenta, ohci1394
17: 1 IO-APIC-level yenta, rtk
18: 0 IO-APIC-level ohci_hcd:usb1, NVidia nForce3 Modem
19: 0 IO-APIC-level ohci_hcd:usb2, NVidia nForce3
20: 0 IO-APIC-level ehci_hcd:usb3
21: 459980 IO-APIC-level bcm43xx
NMI: 681
LOC: 4855420
ERR: 1
MIS: 0
Maybe you're seeing the effect of the nmi watchdog?
afaict, the nmi oopser is used to diagnose deadlocks. and we're assuming
a deadlock is the problem here? I confess i've been too lazy to actually
read the code and the patch -- i'm just acting as a tester for now.
anyway, what you might be seeing is the effect of bcm43xx deadlocking
somehow, then several seconds later the nmi interrupt handler runs,
notices the deadlock, and triggers the oops. Which is a "shared
interrupt" in a sense, but not the way you mean.
iow, the way i read it, the nmi stuff at the top of the call stack is
only there as an artifact of the way the nmi watchdog works.
Jason
_______________________________________________
Bcm43xx-dev mailing list
[email protected]
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
