Re: [LinuxBIOS] Two more CS5530 IRQ steering questions

[Jonathan Sturges]

> 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

____________________________________________________________________________________
Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.
http://autos.yahoo.com/index.html

[LinuxBIOS] Two more CS5530 IRQ steering questions

[Marc Jones]

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

[LinuxBIOS] Two more CS5530 IRQ steering questions

[Juergen Beisert]

Marc,

On Wednesday 03 October 2007 18:46, Marc Jones wrote:
> 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?

The kernel found the IRQ routing table and now it tries to route this IRQ. As 
it does not know the 5530 IRQ router it would switch to BIOS32 services to do 
so. But there is no BIOS32 service, so it fails. But also it does not touch 
the steering registers. So your solution works.

Juergen

[LinuxBIOS] Two more CS5530 IRQ steering questions

[ron minnich]

On 10/2/07, Jonathan Sturges  wrote:
> 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?

yes, if it does not know the router it can get pretty mixed up. I
think you're ok.

ron