http://landley.net/notes.html#16-03-2013
Let's jump back to the 3.6 kernel release, where I was reverting all the irq routing stuff back to what it looked like in 3.3 or so, and both scsi and the ethernet controller worked. In that context, we got the following boot messages:
PCI: enabling device 0000:00:0d.0 (0100 -> 0103) sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 27 sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking sym0: SCSI BUS has been reset. ... 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) PCI: enabling device 0000:00:0c.0 (0100 -> 0103) 8139cp 0000:00:0c.0 eth0: RTL-8139C+ at 0xc8874400, 52:54:00:12:34:56, IRQ 27
So both the scsi and ethernet were sharing IRQ 27.
After they moved the IRQ controller start from 0 to 32 (for not obvious reason), this means the corresponding IRQ is now 27+32=59. And this is the one that works.
Here are the new boot messages after the fix I checked in yesterday:
PCI: enabling device 0000:00:0d.0 (0100 -> 0103) sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 59 sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking sym0: SCSI BUS has been reset. ... 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) PCI: enabling device 0000:00:0c.0 (0100 -> 0103) 8139cp 0000:00:0c.0 eth0: RTL-8139C+ at 0xd0874400, 52:54:00:12:34:56, IRQ 62
Spot anything? Like the fact that 62 != 59? And thus, when I run the nativel linux from scratch build and it tries to distribute compilation over distcc, we get:
=== zlib(2 of 48) Checking for gcc... irq 59: nobody cared (try booting with the "irqpoll" option) Backtrace: [<c00113e8>] (dump_backtrace+0x0/0x110) from [<c001152c>] (dump_stack+0x18/0x1c) r6:00000000 r5:c02eabdc r4:c02eabdc [<c0011514>] (dump_stack+0x0/0x1c) from [<c004d384>] (__report_bad_irq+0x28/0xb0) ... (mondo useless stack dump that just says the IRQ came from hardware) Disabling IRQ #59 ... (more stack dump) 8139cp 0000:00:0c.0 eth0: Transmit timeout, status d 2b 5 80ff 8139cp 0000:00:0c.0 eth0: Transmit timeout, status d 2b 5 80ff 8139cp 0000:00:0c.0 eth0: Transmit timeout, status d 2b 5 80ff
Oddly, QEMU's scsi device still seems to be usable so at a guess they didn't actually disable IRQ 59? Dunno...
So let's annotate and see:
slot=12 pin=1 irq=62 slot=13 pin=1 irq=59