smp and irq conflict
Dear all,
I have a problem with IRQs.
My pc has a CPU PentiumD945 (dual core) and a 2.6.19smp kernel. I have two video acquisition board (four bt8t8 each) in the only two pci slots of my motherboard. Thus I have a total of 8 bttv modules that are working together, and the /proc/interrupts is as follows:
# cat /proc/interrupts
CPU0 CPU1
0: 13575 0 IO-APIC-edge timer
1: 2 0 IO-APIC-edge i8042
4: 11 0 IO-APIC-edge serial
8: 1 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
12: 4 0 IO-APIC-edge i8042
14: 22286 0 IO-APIC-edge ide0
17: 7073 2097 IO-APIC-fasteoi uhci_hcd:usb5, eth0
18: 2525 0 IO-APIC-fasteoi bttv0, bttv7
19: 2829 0 IO-APIC-fasteoi bttv1, bttv4
20: 2526 0 IO-APIC-fasteoi bttv2, bttv5
21: 2226 0 IO-APIC-fasteoi bttv3, bttv6
22: 2 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb4
23: 86 0 IO-APIC-fasteoi uhci_hcd:usb2
24: 0 0 IO-APIC-fasteoi uhci_hcd:usb3
NMI: 0 0
LOC: 13484 13502
ERR: 0
MIS: 0
You can see that IRQ18 is shared between bttv0 and bttv7, IRQ19 between
bttv1 and bttv4 and so on.Sometimes it crashes. It seems a matter of conflict in IRQ. With only one video board everything is ok, but with two, they shared irq and something goes wrong...
How can I tell to the kernel to not to share the IRQ for these boards ? I think (I don't know if I'm right) that this could be the problem.
I even tried with another motherboard, and doing cat /proc/interrupts the situation was the same, except for 'eth0' that was together with bttv0 and bttv7... so it was even worst ! it crashes after few minutes.
I tried to read IO-APIC.txt in Documentation/i386/ folder, but I didn't understand how to avoid the coupling of IRQ.
Thanks
Lapo
Quoted 37 lines · On Thu, 1 Feb 2007 18:46:00 +0100 "Lapo TIN" <[email protected]> wrote:
Dear all,
I have a problem with IRQs.My pc has a CPU PentiumD945 (dual core) and a 2.6.19smp kernel. I have two video acquisition board (four bt8t8 each) in the only two pci slots of my motherboard. Thus I have a total of 8 bttv modules that are working together, and the
/proc/interruptsis as follows:# cat /proc/interrupts CPU0 CPU1 0: 13575 0 IO-APIC-edge timer 1: 2 0 IO-APIC-edge i8042 4: 11 0 IO-APIC-edge serial 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12: 4 0 IO-APIC-edge i8042 14: 22286 0 IO-APIC-edge ide0 17: 7073 2097 IO-APIC-fasteoi uhci_hcd:usb5, eth0 18: 2525 0 IO-APIC-fasteoi bttv0, bttv7 19: 2829 0 IO-APIC-fasteoi bttv1, bttv4 20: 2526 0 IO-APIC-fasteoi bttv2, bttv5 21: 2226 0 IO-APIC-fasteoi bttv3, bttv6 22: 2 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb4 23: 86 0 IO-APIC-fasteoi uhci_hcd:usb2 24: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 NMI: 0 0 LOC: 13484 13502 ERR: 0 MIS: 0 You can see that IRQ18 is shared between bttv0 and bttv7, IRQ19 between bttv1 and bttv4 and so on.Sometimes it crashes. It seems a matter of conflict in IRQ. With only one video board everything is ok, but with two, they shared irq and something goes wrong...
How can I tell to the kernel to not to share the IRQ for these boards ? I think (I don't know if I'm right) that this could be the problem.
Quoted 7 lines
I even tried with another motherboard, and doing cat
/proc/interruptsthe situation was the same, except for 'eth0' that was together with bttv0 and bttv7... so it was even worst ! it crashes after few minutes.I tried to read IO-APIC.txt in
Documentation/i386/folder, but I didn't understand how to avoid the coupling of IRQ.
Thanks
Should be OK. Can you provide us with any kernel output from these crashes?
Quoted 15 lines · Andrew Morton
Quoted 13 lines · On Thu, 1 Feb 2007 18:46:00 +0100 "Lapo TIN" <[email protected]> wrote:
Dear all,
I have a problem with IRQs.My pc has a CPU PentiumD945 (dual core) and a 2.6.19smp kernel. I have two video acquisition board (four bt8t8 each) in the only two pci slots of my motherboard. Thus I have a total of 8 bttv modules that are working together, and the
/proc/interruptsis as follows:# cat /proc/interrupts CPU0 CPU1 0: 13575 0 IO-APIC-edge timer 1: 2 0 IO-APIC-edge i8042 4: 11 0 IO-APIC-edge serial 8: 1 0 IO-APIC-edge rtc
Quoted 8 lines
Quoted 8 lines
9: 0 0 IO-APIC-fasteoi acpi 12: 4 0 IO-APIC-edge i8042 14: 22286 0 IO-APIC-edge ide0 17: 7073 2097 IO-APIC-fasteoi uhci_hcd:usb5, eth0 18: 2525 0 IO-APIC-fasteoi bttv0, bttv7 19: 2829 0 IO-APIC-fasteoi bttv1, bttv4 20: 2526 0 IO-APIC-fasteoi bttv2, bttv5 21: 2226 0 IO-APIC-fasteoi bttv3, bttv6
The assignment of the interrupt pins from the bttv cards is dictated by how the motherboard routed the physical wires from the PCI slots to the IO APIC pins.
Sometimes these can be re-routed by an interrupt router on the board controlled by PIRQ tables or ACPI PCI Interrupt Link devices -- but in the case of a dekstop board with an IOAPIC they are usually just hard coded in a "barber poll" fashion like above, and you will not be able to change them
except by moving cards between slots.
The complete output from dmesg -s64000 will tell us.
-Len
Quoted 32 lines
Quoted 16 lines
22: 2 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb4 23: 86 0 IO-APIC-fasteoi uhci_hcd:usb2 24: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 NMI: 0 0 LOC: 13484 13502 ERR: 0 MIS: 0You can see that IRQ18 is shared between bttv0 and bttv7, IRQ19 between bttv1 and bttv4 and so on.
Sometimes it crashes. It seems a matter of conflict in IRQ. With only one video board everything is ok, but with two, they shared irq and something goes wrong...
How can I tell to the kernel to not to share the IRQ for these boards ? I think (I don't know if I'm right) that this could be the problem.Quoted 7 lines
I even tried with another motherboard, and doing cat
/proc/interruptsthe situation was the same, except for 'eth0' that was together with bttv0 and bttv7... so it was even worst ! it crashes after few minutes.I tried to read IO-APIC.txt in
Documentation/i386/folder, but I didn't understand how to avoid the coupling of IRQ.
ThanksShould be OK. Can you provide us with any kernel output from these crashes?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 36 lines · Lapo TIN
Dear all,
I have a problem with IRQs.My pc has a CPU PentiumD945 (dual core) and a 2.6.19smp kernel. I have two video acquisition board (four bt8t8 each) in the only two pci slots of my motherboard. Thus I have a total of 8 bttv modules that are working together, and the
/proc/interruptsis as follows:# cat /proc/interrupts CPU0 CPU1 0: 13575 0 IO-APIC-edge timer 1: 2 0 IO-APIC-edge i8042 4: 11 0 IO-APIC-edge serial 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12: 4 0 IO-APIC-edge i8042 14: 22286 0 IO-APIC-edge ide0 17: 7073 2097 IO-APIC-fasteoi uhci_hcd:usb5, eth0 18: 2525 0 IO-APIC-fasteoi bttv0, bttv7 19: 2829 0 IO-APIC-fasteoi bttv1, bttv4 20: 2526 0 IO-APIC-fasteoi bttv2, bttv5 21: 2226 0 IO-APIC-fasteoi bttv3, bttv6 22: 2 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb4 23: 86 0 IO-APIC-fasteoi uhci_hcd:usb2 24: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 NMI: 0 0 LOC: 13484 13502 ERR: 0 MIS: 0 You can see that IRQ18 is shared between bttv0 and bttv7, IRQ19 between bttv1 and bttv4 and so on.Sometimes it crashes. It seems a matter of conflict in IRQ.
With only one video board everything is ok, but with two, they shared irq
and something goes wrong... How can I tell to the kernel to not to share the IRQ for these boards ? I think (I don't know if I'm right) that this could be the problem.
Quoted 6 lines
I even tried with another motherboard, and doing cat
/proc/interruptsthe situation was the same, except for 'eth0' that was together with bttv0 and bttv7... so it was even worst ! it crashes after few minutes.I tried to read IO-APIC.txt in
Documentation/i386/folder, but I didn't understand how to avoid the coupling of IRQ.
You may be able to move one board to another slot, but looking at the bandwidth I suspect you may need a server motherboard with multiple busses, preferably running at 66MHz 64bit. I don't think this is a interrupt problem, but you can just try capture on two channels which share an interrupt, like bttv0 and bttv7 to verify that.
I think you are just running out of bus.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"BD" == Bill Davidsen <[email protected]> writes:
BD> You may be able to move one board to another slot, but looking at BD> the bandwidth I suspect you may need a server motherboard with BD> multiple busses, preferably running at 66MHz 64bit. I don't think BD> this is a interrupt problem, but you can just try capture on two BD> channels which share an interrupt, like bttv0 and bttv7 to verify BD> that.
66MHz 64bit isn't much fun when the capture cards are 33MHz 32bit.
/Benny
Quoted 13 lines · Benny Amorsen
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"BD" == Bill Davidsen <[email protected]> writes:
BD> You may be able to move one board to another slot, but looking at BD> the bandwidth I suspect you may need a server motherboard with BD> multiple busses, preferably running at 66MHz 64bit. I don't think BD> this is a interrupt problem, but you can just try capture on two BD> channels which share an interrupt, like bttv0 and bttv7 to verify BD> that.
66MHz 64bit isn't much fun when the capture cards are 33MHz 32bit.
It doesn't help the video to bus, but multiple busses to give a bus per card would help, and assuming the data are being saved to disk using a decent disk controller which can use the additional bandwidth, at least some conflict is avoided or reduced.
This is really a case of using general hardware to the utmost, I suspect more m/b bandwidth will be needed somewhere.
Signature · 3 lines
bill davidsen <[email protected]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979