Re: 2.6.17-mm5 + pcmcia/hostap/8139too patches -- inconsistent {hardirq-on-W} -> {in-hardirq-W} usage

From: Miles Lane
Date: Mon Jul 03 2006 - 19:13:28 EST


On 7/3/06, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
Ar Llu, 2006-07-03 am 23:43 +0200, ysgrifennodd Arjan van de Ven:
> The ne2000 drivers use disable_irq as a poor mans locking construct;
> make sure lockdep knows about these.

Actually they use it as a locking construct because the kernel lacks the
constructs it needs (or did when the work was done). We don't have a

spin_lock_disable_irq(lock, n)

construct which some other OS's do. There are also good reasons for not
having one given so few drivers realy need it.

The underlying problem is that the NE2K chips are slow, especially some
of the ones nailed to PCI with FPGA glue. So slow that worst case taking
a spinlock and uploading a packet drops characters at 9600 baud serial.

The driver disables the on chip IRQ, which for 99.9% of cases then
ensures we don't get further interrupts, then takes the lock. An IRQ
running in parallel on another CPU also holds the lock so that much is
fine.

However: the people at Intel designed the original APIC bus to be
somewhat slow, asynchronous and also without a guaranteed "one message
send, one message receive" sematic of any kind.

That means we have a corner case where we also have to
disable_irq_nosync to ensure that an IRQ that left the 8390 but has not
yet arrived at the processor doesn't race with us and lock up the box.
PCI posting is not the issue here, the IRQ bus is itself even more async
than that.

Doing that work means our tx path doesn't totally trash the machine in
these cases.

Well, I get this:
pcmcia: request for exclusive IRQ could not be fulfilled.
pcmcia: the driver needs updating to supported shared IRQ lines.
eth2: NE2000 (DL10022 rev 30): io 0x300, irq 11, hw_addr 00:50:BA:73:92:3D
Which seems to indicate I need to tweak the PCMCIA settings to get this card
working. I wonder if anyone is going to follow up on enabling shared IRQ
support.

Arjan, the patch you sent does cause the lockdep message to disappear,
but the card doesn't work. When I plug an ethernet cable into the card,
neither the 10 or 100 LED lights up. I tried running
"modprobe <modname> debug=1" on 8390 and pcnet_cs, but neither seem
to support modprobe options. I am recompiling with debugging enabled by
tweaking the debugging values in the files. I'll send you any useful debug
info I gather.

Miles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/