Jonathan Sturges wrote:
Jonathan,
You can use lspci to get that information. "lspci -xxxv" or "lspci -s 00:12.0 -xxxv" for just device 0x12
Marc
Marc, Well the steering bits are actually being set, and it does seem to work! What threw me off (and I apologize for not testing this more) was the fact that with a normal kernel (2.6.20 plus PCI debugging), you get messages like this at bootup:
IRQ for 0000:00:15.0[A] -> PIRQ 02, mask 0800, excl 0000 -> newirq=11 ... failed PCI: Guessed IRQ 11 for device 0000:00:15.0 natsemi eth0: NatSemi DP8381[56] at 0xfebf2000 (0000:00:15.0), 00:50:f6:22:91:4e, IRQ 11, port TP.
The "failed" messages concerned me. However, in reality, the devices work, and you can verify that the interrupts are routed properly via /proc/interrupts. With the same kernel, but patched to know the CS5530 IRQ router, you don't get the "failed" messages.
So since things work, I'm about ready to claim success. Are the "failed" messages an acceptable artifact of the kernel not knowing the CS5530 router, or something I should be concerned about?
thanks, Jonathan
Glad it worked. I don't know enough about the kernel to know if the failed message is important. It seems to have a fallback mechanism. I also haven't followed the 5530 kernel patch debate. Maybe someone else here has the knowledge?
Marc