Messages in this thread | | | Subject | Re: 2.6.17-mm5 + pcmcia/hostap/8139too patches -- inconsistent {hardirq-on-W} -> {in-hardirq-W} usage | From | Alan Cox <> | Date | Mon, 03 Jul 2006 23:25:57 +0100 |
| |
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.
Alan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |