Hi
We are working closely with an x86-based hardware manufacturer for our
linux based application. In their hardware, it contains 4 x BT878
chips and 3 x USB controllers. The USB and BT878 share the same
hardware IRQ lines, which is causing us to notice random hard lockups.
Increasing the PCI latency of the BTTV drivers has helped the
situation (we have not noticed any lockups yet), but it would be nice
if we can separate the IRQs.
We asked the manufacturers if they can do a physical modication for
us, but unfortunately this is not possible. The engineer did mention
that under Windows XP in "IO APIC" mode, it is possible to assign
different IRQs to the USB and BTTV.
Is this possible in Linux? We have tried enabling IO APIC in the
kernel, but the IRQs are still shared.
Please advise if it is even possible in Linux to achieve what we want.
Kind Regards
Keith
Keith Chew wrote:
>
> We asked the manufacturers if they can do a physical modication for
> us, but unfortunately this is not possible. The engineer did mention
> that under Windows XP in "IO APIC" mode, it is possible to assign
> different IRQs to the USB and BTTV.
>
> Is this possible in Linux? We have tried enabling IO APIC in the
> kernel, but the IRQs are still shared.
>
> Please advise if it is even possible in Linux to achieve what we want.
>
You could try enabling "Bus Options" ->
[*] Message Signaled Interrupts (MSI and MSI-X)
or in .config
CONFIG_PCI_MSI=y
It only works for PCI devices.
>
> You could try enabling "Bus Options" ->
> [*] Message Signaled Interrupts (MSI and MSI-X)
>
> or in .config
> CONFIG_PCI_MSI=y
>
> It only works for PCI devices.
>
Yes, the 2 devices are PCI devices. We tried enabling CONFIG_PCI_MSI,
also tried pci=routeirq, but cat /proc/interrupts still show the
devices sharing the same IRQ. It is interesting how each of these
options (ie routeirq, CONFIG_PCI_MSI, noacpi, etc) causes the kernel
to assign a different IRQ each time, but the 2 devices are always
shared, eg
pci=noacpi -> 169: 5140 IO-APIC-level bttv0, uhci_hcd:usb1
pci=routeirq -> 153: 1253 IO-APIC-level bttv0, uhci_hcd:usb1
I guess there's no workaround for our problem. If there are any more
suggestions, please let me know, we hope the pci latency settings will
get us going for now.
Regards
Keith
On Wed, May 31, 2006 at 12:21:53AM +1200, Keith Chew wrote:
> We are working closely with an x86-based hardware manufacturer for our
> linux based application. In their hardware, it contains 4 x BT878
> chips and 3 x USB controllers.
That sounds like a nice MythTV box to me :)
> The USB and BT878 share the same
> hardware IRQ lines, which is causing us to notice random hard lockups.
> Increasing the PCI latency of the BTTV drivers has helped the
> situation (we have not noticed any lockups yet), but it would be nice
> if we can separate the IRQs.
>
> We asked the manufacturers if they can do a physical modication for
> us, but unfortunately this is not possible. The engineer did mention
> that under Windows XP in "IO APIC" mode, it is possible to assign
> different IRQs to the USB and BTTV.
Unless Windows XP IO APIC mode contains a soldering iron and rework
wire to physically change the way the hardware IRQ lines are connected,
this is nonsense.
Or the engineer means that in legacy PIC mode the IRQs are shared, but
in APIC mode they can be separated. That is a different thing, cause in
that case the IRQ lines are not physically connected, but put together
in PIC mode and can again be separated by using APIC mode.
> Is this possible in Linux? We have tried enabling IO APIC in the
> kernel, but the IRQs are still shared.
Depends on the hardware, but Linux does indeed support IO APIC.
Erik
--
+-- Erik Mouw -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
Hi Erik
> That sounds like a nice MythTV box to me :)
>
Yes it is! We are using the box as a video surveillance unit for the
automotive industry (eg trains, buses). We are using the USB for WIFI,
which is causing pain with the bttv drivers in IRQ sharing mode.
Increasing the PCI latency of the bttv allow it to not give up the IRQ
that often to the WIFI. The bttv FAQ did mention that the drivers
works "most of the time" in IRQ sharing, I guess we are seeing the
random freezes because our application is 24x7.
>
> Or the engineer means that in legacy PIC mode the IRQs are shared, but
> in APIC mode they can be separated. That is a different thing, cause in
> that case the IRQ lines are not physically connected, but put together
> in PIC mode and can again be separated by using APIC mode.
>
Ah, you could be right here. In the BIOS, there an option to
enable/disable APIC, which corresponds to what you are suggesting
above.
Unfortunately, we have tried all the options we know to separate the
IRQs in IO APIC mode, but to no avail. Next, we will be testing the
unit in Windows to verify the engineer's claims.
Thanks again for taking the time to respond to my post.
Regards
Keith
>>
>> Or the engineer means that in legacy PIC mode the IRQs are shared, but
>> in APIC mode they can be separated. That is a different thing, cause in
>> that case the IRQ lines are not physically connected, but put together
>> in PIC mode and can again be separated by using APIC mode.
>
> Ah, you could be right here. In the BIOS, there an option to
> enable/disable APIC, which corresponds to what you are suggesting
> above.
>
Plus
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
but I guess you already have these.
Jan Engelhardt
--
> >
> Plus
> CONFIG_X86_UP_APIC=y
> CONFIG_X86_UP_IOAPIC=y
> CONFIG_X86_LOCAL_APIC=y
> CONFIG_X86_IO_APIC=y
>
> but I guess you already have these.
>
Yes, I have these options enabled.
*sigh*
Keith