Re: smp and irq conflict
On 2/2/07, Erik Mouw <[EMAIL PROTECTED]> wrote: On Fri, Feb 02, 2007 at 01:04:53AM +0100, Lapo TIN wrote: > I need to capture at 25 frame per second from each channel... > So 25 x 8 total frames per second on the pci. Each PAL frame takes about 800k, so that makes 20MB/s per channel. With 8 channels that makes 160 MB/s. That will most certainly overwhelm a normal 33 MHz 32 bit PCI bus which has a theoretical bandwidth of 132 MB/s (90MB/s max in practice). Modern PCs have faster PCI busses (66MHz, 64 bit, PCI-X, or PCI-e) so there's less chance on bus contention. On the other hand, I suppose you will store the video streams on disk. That will use another 20MB/s per channel on the bus so the total becomes 320 MB/s. You need some careful system design in order to get that right. Especially look carefully at bus contention, if the system has multiple busses, distribute the bttv cards over those busses. Also be sure to have enough bandwidth for the disk subsystem. > So do you think I have to change the motherboard ? > What is important ? the chipset ? is there specification I need ? Last time I had to record frame-synchronous video from 3 streams (8 years ago) PCs could hardly manage 2 streams over their bus and there was no way to guarantee frame sync. The only way out was to use an SGI Onyx2 with 3 digital video option cards and a large disk subsystem. That made the whole system much more expensive but at that time it was the only way to meet all requirements. I don't know about current PCs, bus speeds have improved. It is however still important how those busses are connected together and to the chipset. You have to figure out from your motherboard documentation if there is enough bandwidth available. If there isn't, get a faster motherboard, or consider using compressing grabber cards like the Hauppauge PVR 150 or PVR 500. such devices can do a max of one input or 2 inputs. There are cards that do 16/32 video inputs, do hardware MPEG4 compression and write to disk/ stream out through the network interface. But most such devices have proprietory drivers and have issues working properly. Got bitten by a bug similarly, recently. The vendor was pig headed to either fix the driver or to provide driver source. (http://dvr.neugent.net/ They talked too much of Linux, but really pathetic stuff overall, claimed their issue was Intellectual Property) They claimed the Linux kernel was buggy rather than stating that their driver was buggy. In the end, luckily got my money back for the hardware. Manu - 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/
Re: smp and irq conflict
Benny Amorsen wrote: "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. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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/
Re: smp and irq conflict
Lapo TIN 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/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. 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. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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/
Re: smp and irq conflict
On Fri, Feb 02, 2007 at 01:04:53AM +0100, Lapo TIN wrote: > I need to capture at 25 frame per second from each channel... > So 25 x 8 total frames per second on the pci. Each PAL frame takes about 800k, so that makes 20MB/s per channel. With 8 channels that makes 160 MB/s. That will most certainly overwhelm a normal 33 MHz 32 bit PCI bus which has a theoretical bandwidth of 132 MB/s (90MB/s max in practice). Modern PCs have faster PCI busses (66MHz, 64 bit, PCI-X, or PCI-e) so there's less chance on bus contention. On the other hand, I suppose you will store the video streams on disk. That will use another 20MB/s per channel on the bus so the total becomes 320 MB/s. You need some careful system design in order to get that right. Especially look carefully at bus contention, if the system has multiple busses, distribute the bttv cards over those busses. Also be sure to have enough bandwidth for the disk subsystem. > So do you think I have to change the motherboard ? > What is important ? the chipset ? is there specification I need ? Last time I had to record frame-synchronous video from 3 streams (8 years ago) PCs could hardly manage 2 streams over their bus and there was no way to guarantee frame sync. The only way out was to use an SGI Onyx2 with 3 digital video option cards and a large disk subsystem. That made the whole system much more expensive but at that time it was the only way to meet all requirements. I don't know about current PCs, bus speeds have improved. It is however still important how those busses are connected together and to the chipset. You have to figure out from your motherboard documentation if there is enough bandwidth available. If there isn't, get a faster motherboard, or consider using compressing grabber cards like the Hauppauge PVR 150 or PVR 500. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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/
Re: smp and irq conflict
On Thursday 01 February 2007 23:32, Andrew Morton wrote: > 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/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 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 > > 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 > > Should 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/ > - 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/
Re: smp and irq conflict
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/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 Should 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/
Re: smp and irq conflict
Lapo TIN wrote: I need to capture at 25 frame per second from each channel... So 25 x 8 total frames per second on the pci. So do you think I have to change the motherboard ? What is important ? the chipset ? is there specification I need ? What resolution are you using? 720x480 with 24 bits per pixel and 25fps will use about 25MB/sec on the PCI bus, there is no way you can keep up with 8 channels running on a standard 32-bit 33MHz PCI bus which can only transfer 133 MB/sec at most. If you need this much transfer rate, you likely need PCI Express or PCI-X capture cards or at least a motherboard which has multiple PCI buses (which most desktop boards don't typically have). You may be able to reduce the resolution and/or frame rate in order to allow the PCI bus to cope. Also, do you have enough CPU and disk speed in order to cope with all these streams? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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/
Re: smp and irq conflict
I need to capture at 25 frame per second from each channel... So 25 x 8 total frames per second on the pci. So do you think I have to change the motherboard ? What is important ? the chipset ? is there specification I need ? -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Per conto di Robert Hancock Inviato: venerdì 2 febbraio 2007 0.30 A: Lapo TIN Cc: linux-smp@vger.kernel.org; linux-kernel@vger.kernel.org Oggetto: Re: smp and irq conflict Lapo TIN 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/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. Usually the IRQ routing is hard-wired on the motherboard, so there's no way to avoid the devices sharing IRQs. Unless the driver is badly buggy this should not cause problems anyway. What kind of video bit rate are you capturing? 8 video capture chips is a pretty heavy load on the PCI bus, maybe something just gets overwhelmed? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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/ - 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/
Re: smp and irq conflict
Lapo TIN 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/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. Usually the IRQ routing is hard-wired on the motherboard, so there's no way to avoid the devices sharing IRQs. Unless the driver is badly buggy this should not cause problems anyway. What kind of video bit rate are you capturing? 8 video capture chips is a pretty heavy load on the PCI bus, maybe something just gets overwhelmed? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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/
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 - 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/