Nasty IRQ conflict under OpenBSD
I’m trying to get three Edimax EW-7128g PCI wlan cards going under OpenBSD, since they work very poorly under Linux. OBSD detects them right away, but I’ve a problem: when I run kismet, my machine panics and has to be rebooted. A look at dmesg output offers a hint as to the problem:
uhci0 at pci0 dev 7 function 2 "Intel 82371AB USB" rev 0x01: apic 2 int 19 (irq 14)
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x02: SMBus disabled
em0 at pci0 dev 13 function 0 "Intel PRO/1000MT (82540EM)" rev 0x02: apic 2 int 17 (irq 11), address 00:07:e9:0f:4f:09
ral0 at pci0 dev 16 function 0 "Ralink RT2561S" rev 0x00: apic 2 int 19 (irq 14), address 00:0e:2e:b2:f1:23
ral0: MAC/BBP RT2561C, RF RT2527
ral1 at pci0 dev 17 function 0 "Ralink RT2561S" rev 0x00: apic 2 int 20 (irq 10), address 00:0e:2e:b2:f1:28
ral1: MAC/BBP RT2561C, RF RT2527
Notice anything? What IRQ is ral0 on? What IRQ is uhci0 on? Yeah. IRQ 14, both.
I learned about the OBSD vmstat command today. It says:
# vmstat -zi
interrupt total rate
irq0/clock 41574 200
irq0/ipi 46323 223
irq66/ahc0 25815 124
irq65/pciide0 0 0
irq67/uhci0 0 0
irq80/em0 504 2
irq67/ral0 0 0
irq81/ral1 0 0
irq112/pckbc0 0 0
irq176/pccom0 0 0
irq64/fdc0 0 0
Total 114216 551
Confirming my suspicions. I thought IRQs were assigned based on PCI slot, so I don’t see how there could be a conflict. I’ll shuffle the cards around in the hopes of getting a different assignment.
Hmm, I yanked one of the cards, and now vmstat doesn’t show any overlapping IRQs, and I’m still getting a panic when starting kismet. The error is page fault trap, code = 0 at rt2661_set_chan
Hmm, apparently OpenBSD kernel bug 5313 describes this exact problem. It looks like the patch has been committed. Obviously I want this fix, but it seems to be only in 4.0-CURRENT, which is the development branch. The errata don’t mention this bug, so it’s not in 4.0-STABLE. Shit.
Perhaps there’s a workaround. The bug suggests there’s a problem setting the channel of the device after placing it in monitor mode, if it’s not ‘running’ yet. The patch simply doesn’t attempt to set the channel unless the device is in the running state. Can I make the device be in the running state manually? Perhaps with ifconfig up?
Yeah, that took care of it. ifconfig up before starting kismet was all it took.
I’ll put back in the other two cards (which will reintroduce the IRQ conflict) and see if there are any other problems.
I’ve reproduced the IRQ conflict, but both cards seem to work fine with kismet, provided I remember to do an ifconfig up on each of them.
I can’t get the third card to be detected. I’m beginning to suspect the card is bad; no matter which slot I put it in, it doesn’t get detected by OBSD. It was working earlier today; I can’t imagine what happened.
I figured it out (sort of). Since my machine has dual PII 400MHz processors, I switched to the bsd.mp kernel. I switched back to the uniproc kernel, and all three cards are recognized. I don’t know why this would make a difference, but one reason that jumps out at me immediately is that the bsd.mp kernel uses APCI, while the plain bsd kernel does not.
While they are all three detected now, the IRQ conflict is back, this time with ral1 and uhci0. This is preventing my from bringing up ral1. Time for more card juggling.
That didn’t help. I disabled the FDD controller, PS/2 mouse, both serial ports, and the parallel port, and now we’re all green. Too easy.
However, I keep forgetting to bring up the ral* interfaces before running kismet. I’m putting the following in /etc/rc.local:
ifconfig ral0 up
ifconfig ral1 up
ifconfig ral2 up
Never again will I panic my system.