On Mon, 1 Dec 2003, Niki Waibel wrote:
i think we need a new thread for the ``intel dual netwokcard problem on epia-m'' topic.
OK, I'm now looking at this for real :)
facts (correct me if i am wrong!): * intel dual eth nic is not working with linuxbios (2003-10-24). * it can be plugged into the pci slot (00:14.0) of the epia-m. * the dual nic has a pci-to-pci bridge on the card. * that bridge assignes pci bus 2 (0=internal, 1=vga/agp?) * the 2 nics on the card assign: 02:04.0 and 02:05.0 * linuxbios detects the bus/bridge and also sees the 2 nic. !!* linuxbios does not assign irqs to the nics. * default (2003-10-24) linuxbios src/mainboard/via/epia-m/irq_tables.c:
ok so far.
{0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0},
That's 0:14.0, or Bus 0, devfn 0xa0.
{0,0xa0, {{0x2, 0xdeb8}, {0x3, 0xdeb8}, {0x4, 0xdeb8}, {0x1, 0xdeb8}}, 0x1, 0},
Note that linuxbios and the standard bios agree.
* it does not help using the new irq_tables.c.
which makes sense as the one in there is already correct. My mistake. The issue is that the card you're using has a bridge on it. I've never dealt with this before.
* i had to modify src/mainboard/via/epia-m/mainboard.c in addition to get it running.
--> basically add: ``pci_assign_irqs(2, 0x4, dualenetaIrq);pci_assign_irqs(2, 0x5, dualenetbIrq);'' in addition i had to play with the irq lists.
eek. You know that this is exactly the wrong way to do this and why, I assume. But it works, so keep it for now. But this will never go into the CVS.
questions: * what do the strange numbers in my new irq_table.c mean?
doesn't matter, the old one was probably ok.
* if everything is hardcoded in mainboard.c -- what is irq_table.c for?
irq_table.c is for linux, it tells linux how the irqs are wired up. In an ideal world, linuxbios would hand the irq table to linux or plan9 or *bsd and those OSes would do everything correctly. In our world, each of these OSes get it wrong often enough that we have to now assign it directly. I had hoped to avoid IRQ assignment in linuxbios but it seems that we have no choice -- too many busted hardware/OS bits out there.
* is it possible that all this is hardcoded in mainboard.c forepia/epia-m only, but not for other boards?
yes.
other boards use irq_table.c to assign interrupts?
yes. And, *most of the time*, it works fine.
* if you plug a card to the pci slot linuxbios seems to detect everything
(devices/bridges/devices behind bridges). why cannot we say: ok there is irq 5, 10, 11 and 12. assign that 4 irqs to all devices which were detected in the previous stage. this must be the way the regular bios does it...
Yes. We need more complex irq management in linuxbios. Obviously linux doesn't know what to do here either.
* when booting the epia-m with the std (award) bios and using the getpir prg -> the resulting irq_table.c does not work either. is itjust ignored by the epia-m setup, or what is it actually for?
I don't know what the award bios is doing. It's clear that linux is not able to handle the interrupt assignmnet in this case, so linuxbios will have to do more. Oh well. Another thing to add.
ron