Re: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: > Udo van den Heuvel <[EMAIL PROTECTED]> writes: > >> I have DN19 and DN20 now and it doesn't work. >> Only because the INT mapping on the riser is not right? > > Yes. I assume DN20 works, only DN19 has problems. Well, today I tried the same VIA motherboard (EN12000) with a Morex 2788 case and their dual PCI riser card does have a working interrupt on the upper slot. lspci is below. I can use the lower slot later, when the harddisk is not blocking the space for the PCI-card there. I use a 2.6.20.1 kernel with SAA7146_USE_I2C_IRQ for budget-av.c. In the old situation I was forced to use SAA7146_I2C_SHORT_DELAY even though the upper slot had the same DN and same IRQ given by Linux. Thanks a lot for all the comments and feedback! Thanks to Morex for having a working PCI riser card! # lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Subsystem: VIA Technologies, Inc. Unknown device aa08 Flags: bus master, 66MHz, medium devsel, latency 8 Memory at e800 (32-bit, prefetchable) [size=128M] Capabilities: [80] AGP version 3.5 Capabilities: [50] Power Management version 2 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge Flags: bus master, medium devsel, latency 0 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: b000-bfff Memory behind bridge: fb00-fcff Prefetchable memory behind bridge: f400-f7ff Capabilities: [70] Power Management version 2 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller ( rev 80) (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. IEEE 1394 Host Controller Flags: bus master, stepping, medium devsel, latency 32, IRQ 20 Memory at fdfff000 (32-bit, non-prefetchable) [size=2K] I/O ports at fc00 [size=128] Capabilities: [50] Power Management version 2 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) Subsystem: VIA Technologies, Inc. Unknown device 0110 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 17 I/O ports at f800 [size=256] Memory at fdffe000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (r ev 80) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller Flags: bus master, medium devsel, latency 32, IRQ 18 I/O ports at f400 [size=8] I/O ports at f000 [size=4] I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=16] I/O ports at e000 [size=256] Capabilities: [c0] Power Management version 2 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/ C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8 235 PIPC Bus Master IDE Flags: bus master, medium devsel, latency 32, IRQ 18 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [size=1] I/O ports at dc00 [size=16] Capabilities: [c0] Power Management version 2 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at d800 [size=32] Capabilities: [80] Power Management version 2 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1
Re: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: Udo van den Heuvel [EMAIL PROTECTED] writes: I have DN19 and DN20 now and it doesn't work. Only because the INT mapping on the riser is not right? Yes. I assume DN20 works, only DN19 has problems. Well, today I tried the same VIA motherboard (EN12000) with a Morex 2788 case and their dual PCI riser card does have a working interrupt on the upper slot. lspci is below. I can use the lower slot later, when the harddisk is not blocking the space for the PCI-card there. I use a 2.6.20.1 kernel with SAA7146_USE_I2C_IRQ for budget-av.c. In the old situation I was forced to use SAA7146_I2C_SHORT_DELAY even though the upper slot had the same DN and same IRQ given by Linux. Thanks a lot for all the comments and feedback! Thanks to Morex for having a working PCI riser card! # lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Subsystem: VIA Technologies, Inc. Unknown device aa08 Flags: bus master, 66MHz, medium devsel, latency 8 Memory at e800 (32-bit, prefetchable) [size=128M] Capabilities: [80] AGP version 3.5 Capabilities: [50] Power Management version 2 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge Flags: bus master, medium devsel, latency 0 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: b000-bfff Memory behind bridge: fb00-fcff Prefetchable memory behind bridge: f400-f7ff Capabilities: [70] Power Management version 2 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller ( rev 80) (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. IEEE 1394 Host Controller Flags: bus master, stepping, medium devsel, latency 32, IRQ 20 Memory at fdfff000 (32-bit, non-prefetchable) [size=2K] I/O ports at fc00 [size=128] Capabilities: [50] Power Management version 2 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) Subsystem: VIA Technologies, Inc. Unknown device 0110 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 17 I/O ports at f800 [size=256] Memory at fdffe000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (r ev 80) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller Flags: bus master, medium devsel, latency 32, IRQ 18 I/O ports at f400 [size=8] I/O ports at f000 [size=4] I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=16] I/O ports at e000 [size=256] Capabilities: [c0] Power Management version 2 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/ C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8 235 PIPC Bus Master IDE Flags: bus master, medium devsel, latency 32, IRQ 18 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [size=1] I/O ports at dc00 [size=16] Capabilities: [c0] Power Management version 2 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at d800 [size=32] Capabilities: [80] Power Management version 2 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller
Re: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: > Udo van den Heuvel <[EMAIL PROTECTED]> writes: > >> I will try a different case with a different dual PCI riser card soon. >> This Morex riser has DN20-31 or so, so more options. > > OTOH I wonder how do they use DN 21-31? The board uses lines AD11 to AD31 > (21 lines) for selecting devices #0 - #20. 32-bit PCI bus has only 32 > address/data lines :-) > > Perhaps they mean AD20-AD31 lines = device #9 - #0x14=20? If that is > the case, you can try: > - their "DN30" = device 0x13 = 19, which is apparently what the VIA riser > card does, Got the Morex stuff here today. Surprise: the (current) default jumper location is ID30. - 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: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: Udo van den Heuvel [EMAIL PROTECTED] writes: I will try a different case with a different dual PCI riser card soon. This Morex riser has DN20-31 or so, so more options. OTOH I wonder how do they use DN 21-31? The board uses lines AD11 to AD31 (21 lines) for selecting devices #0 - #20. 32-bit PCI bus has only 32 address/data lines :-) Perhaps they mean AD20-AD31 lines = device #9 - #0x14=20? If that is the case, you can try: - their DN30 = device 0x13 = 19, which is apparently what the VIA riser card does, Got the Morex stuff here today. Surprise: the (current) default jumper location is ID30. - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel <[EMAIL PROTECTED]> writes: > Description VIA Dual PCI Riser > The EXT-PCI is a PCI riser card which expands a PCI slot into two PCI slots. > EXT-PCI slot 1 (lower slot) uses the system resources (Device ID, INT) > of the PCI slot of the motherboard. Yep. ID 20, INT D (chipset POV). > EXT-PCI slot 2 (Upper slot) uses device 19 and INT_A. Right. > Upper slot has the problems. TranquilPC does not even respond anymore. > The lower slot is a copy of the normal (single) PCI slot w.r.t. devcie > and irq, it has DN20 and irq 20. Ok. > dmesg links ALNKA to IRQ 20. So if ALNKA is INTA both PCI cards should > share IRQ 20? No. I don't exactly know what these ACPI messages show. Probably they list some power-up state, before devices are configured. If lspci says DN20 uses IRQ 20 and DN19 "uses" IRQ16 then that's exactly what they should use - two different INT/IRQ signals. If the lspci shows that DN20 uses the same IRQ as IEEE1394 controller and that DN19 uses the same IRQ as on-board Ethernet and VGA then that means just that: they share INTs/IRQs (this is especially true when running in IO-APIC mode). If lspci shows no IRQ for the device then that DN is not supported by the BIOS. I'd try this "aluminum film" trick. Just be careful, shorting wrong traces can destroy the hardware. As I wrote, shorting the good ones can make the system (temporarily) unusable. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel <[EMAIL PROTECTED]> writes: > I have DN19 and DN20 now and it doesn't work. > Only because the INT mapping on the riser is not right? Yes. I assume DN20 works, only DN19 has problems. > http://www.morex.com.tw/drawing/MAR122-J%20Drawing.pdf shows some IDSEL > jumper with ADxx numbers. What could these be? > Photo at http://www.morex.com.tw/products/imgproduct/100-1.jpg. > > Still DN's? The second file shows some 28-pin IC but it's not a PCI-PCI bridge. Jumpers marked AD20-31 are for selecting IDSEL - AD20 = DN9, AD31 is DN20 (DNx = ADx - 11). Perhaps they could say how the INTs are wired. It's possible the IC plays some role there. If the riser card is for specific motherboard(s) only (and it must be) then they can read the IDSEL jumper position with this IC and rotate INTs appropriately (thus it could work, with that particular motherboard(s), in any IDSEL jumper position). -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: > Udo van den Heuvel <[EMAIL PROTECTED]> writes: > >> I will try a different case with a different dual PCI riser card soon. >> This Morex riser has DN20-31 or so, so more options. > > OTOH I wonder how do they use DN 21-31? The board uses lines AD11 to AD31 > (21 lines) for selecting devices #0 - #20. 32-bit PCI bus has only 32 > address/data lines :-) > > Perhaps they mean AD20-AD31 lines = device #9 - #0x14=20? If that is > the case, you can try: > - their "DN30" = device 0x13 = 19, which is apparently what the VIA riser > card does, > - their "DN21" = device 0xA = 10, which could work as well. > > I'm afraid both would require (different) soldering. My dmesg says: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 10 11 12) *5 ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 6 7 10 *11 12) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 *10 11 12) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 6 7 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 6 7 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [ALKA] (IRQs *20) ACPI: PCI Interrupt Link [ALKB] (IRQs *21) ACPI: PCI Interrupt Link [ALKC] (IRQs *22) ACPI: PCI Interrupt Link [ALKD] (IRQs *23), disabled. lspci -v says: 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1157 Flags: bus master, medium devsel, latency 32, IRQ 16 Memory at fdffc000 (32-bit, non-prefetchable) [size=512] 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1155 Flags: bus master, medium devsel, latency 32, IRQ 20 Memory at fdffb000 (32-bit, non-prefetchable) [size=512] Does this provide additional info to you? http://www.itx-warehouse.co.uk/Product.aspx?ProductID=410 says: Description VIA Dual PCI Riser The EXT-PCI is a PCI riser card which expands a PCI slot into two PCI slots. EXT-PCI slot 1 (lower slot) uses the system resources (Device ID, INT) of the PCI slot of the motherboard. EXT-PCI slot 2 (Upper slot) uses device 19 and INT_A. Upper slot has the problems. TranquilPC does not even respond anymore. The lower slot is a copy of the normal (single) PCI slot w.r.t. devcie and irq, it has DN20 and irq 20. dmesg links ALNKA to IRQ 20. So if ALNKA is INTA both PCI cards should share IRQ 20? - 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: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: > Udo van den Heuvel <[EMAIL PROTECTED]> writes: > >> I will try a different case with a different dual PCI riser card soon. >> This Morex riser has DN20-31 or so, so more options. >> Could this help solve my irq issue? (try 4 consecutive DNs until I have >> the right mapping?) > > I don't think so. Unless you can configure INT connections on the riser > card, of course. > > You need DN19 for the second slot (and perhaps 10 would work with > double INTx rotation), that's fixed in the BIOS. I have DN19 and DN20 now and it doesn't work. Only because the INT mapping on the riser is not right? http://www.morex.com.tw/drawing/MAR122-J%20Drawing.pdf shows some IDSEL jumper with ADxx numbers. What could these be? Photo at http://www.morex.com.tw/products/imgproduct/100-1.jpg. Still DN's? >> This Morex riser has DN20-31 or so, so more options. > > OTOH I wonder how do they use DN 21-31? The board uses lines AD11 to AD31 > (21 lines) for selecting devices #0 - #20. 32-bit PCI bus has only 32 > address/data lines :-) > > Perhaps they mean AD20-AD31 lines = device #9 - #0x14=20? If that is > the case, you can try: > - their "DN30" = device 0x13 = 19, which is apparently what the VIA riser > card does, > - their "DN21" = device 0xA = 10, which could work as well. > > I'm afraid both would require (different) soldering. So at least try the different jumper settings (without additional info, I hope Morex responds to my emails). Else do a little soldering. > It's possible that the riser card includes a bridge, though. A bridge > chip can select devices differently and thus it can handle 32 devices. Looking at the photo I don't think I see a bridge... - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel <[EMAIL PROTECTED]> writes: > I will try a different case with a different dual PCI riser card soon. > This Morex riser has DN20-31 or so, so more options. OTOH I wonder how do they use DN 21-31? The board uses lines AD11 to AD31 (21 lines) for selecting devices #0 - #20. 32-bit PCI bus has only 32 address/data lines :-) Perhaps they mean AD20-AD31 lines = device #9 - #0x14=20? If that is the case, you can try: - their "DN30" = device 0x13 = 19, which is apparently what the VIA riser card does, - their "DN21" = device 0xA = 10, which could work as well. I'm afraid both would require (different) soldering. It's possible that the riser card includes a bridge, though. A bridge chip can select devices differently and thus it can handle 32 devices. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Hello, Udo van den Heuvel <[EMAIL PROTECTED]> writes: > I will try a different case with a different dual PCI riser card soon. > This Morex riser has DN20-31 or so, so more options. > Could this help solve my irq issue? (try 4 consecutive DNs until I have > the right mapping?) I don't think so. Unless you can configure INT connections on the riser card, of course. You need DN19 for the second slot (and perhaps 10 would work with double INTx rotation), that's fixed in the BIOS. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
On Fri, Feb 23, 2007 at 04:45:45PM +0100, Udo van den Heuvel wrote: > Small update: > > I will try a different case with a different dual PCI riser card soon. > This Morex riser has DN20-31 or so, so more options. > Could this help solve my irq issue? (try 4 consecutive DNs until I have > the right mapping?) It all depends on the BIOS. If the bios doesn't assign interrupts to a given DN, then there is nothing to do about it really. You could hack the kernel or boot loader to do the job that the bios didn't do, but that's about it. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
Hello, Small update: I will try a different case with a different dual PCI riser card soon. This Morex riser has DN20-31 or so, so more options. Could this help solve my irq issue? (try 4 consecutive DNs until I have the right mapping?) Kind regrads, Udo - 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: PCI riser cards and PCI irq routing, etc
Hello, Small update: I will try a different case with a different dual PCI riser card soon. This Morex riser has DN20-31 or so, so more options. Could this help solve my irq issue? (try 4 consecutive DNs until I have the right mapping?) Kind regrads, Udo - 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: PCI riser cards and PCI irq routing, etc
On Fri, Feb 23, 2007 at 04:45:45PM +0100, Udo van den Heuvel wrote: Small update: I will try a different case with a different dual PCI riser card soon. This Morex riser has DN20-31 or so, so more options. Could this help solve my irq issue? (try 4 consecutive DNs until I have the right mapping?) It all depends on the BIOS. If the bios doesn't assign interrupts to a given DN, then there is nothing to do about it really. You could hack the kernel or boot loader to do the job that the bios didn't do, but that's about it. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
Hello, Udo van den Heuvel [EMAIL PROTECTED] writes: I will try a different case with a different dual PCI riser card soon. This Morex riser has DN20-31 or so, so more options. Could this help solve my irq issue? (try 4 consecutive DNs until I have the right mapping?) I don't think so. Unless you can configure INT connections on the riser card, of course. You need DN19 for the second slot (and perhaps 10 would work with double INTx rotation), that's fixed in the BIOS. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel [EMAIL PROTECTED] writes: I will try a different case with a different dual PCI riser card soon. This Morex riser has DN20-31 or so, so more options. OTOH I wonder how do they use DN 21-31? The board uses lines AD11 to AD31 (21 lines) for selecting devices #0 - #20. 32-bit PCI bus has only 32 address/data lines :-) Perhaps they mean AD20-AD31 lines = device #9 - #0x14=20? If that is the case, you can try: - their DN30 = device 0x13 = 19, which is apparently what the VIA riser card does, - their DN21 = device 0xA = 10, which could work as well. I'm afraid both would require (different) soldering. It's possible that the riser card includes a bridge, though. A bridge chip can select devices differently and thus it can handle 32 devices. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: Udo van den Heuvel [EMAIL PROTECTED] writes: I will try a different case with a different dual PCI riser card soon. This Morex riser has DN20-31 or so, so more options. Could this help solve my irq issue? (try 4 consecutive DNs until I have the right mapping?) I don't think so. Unless you can configure INT connections on the riser card, of course. You need DN19 for the second slot (and perhaps 10 would work with double INTx rotation), that's fixed in the BIOS. I have DN19 and DN20 now and it doesn't work. Only because the INT mapping on the riser is not right? http://www.morex.com.tw/drawing/MAR122-J%20Drawing.pdf shows some IDSEL jumper with ADxx numbers. What could these be? Photo at http://www.morex.com.tw/products/imgproduct/100-1.jpg. Still DN's? This Morex riser has DN20-31 or so, so more options. OTOH I wonder how do they use DN 21-31? The board uses lines AD11 to AD31 (21 lines) for selecting devices #0 - #20. 32-bit PCI bus has only 32 address/data lines :-) Perhaps they mean AD20-AD31 lines = device #9 - #0x14=20? If that is the case, you can try: - their DN30 = device 0x13 = 19, which is apparently what the VIA riser card does, - their DN21 = device 0xA = 10, which could work as well. I'm afraid both would require (different) soldering. So at least try the different jumper settings (without additional info, I hope Morex responds to my emails). Else do a little soldering. It's possible that the riser card includes a bridge, though. A bridge chip can select devices differently and thus it can handle 32 devices. Looking at the photo I don't think I see a bridge... - 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: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: Udo van den Heuvel [EMAIL PROTECTED] writes: I will try a different case with a different dual PCI riser card soon. This Morex riser has DN20-31 or so, so more options. OTOH I wonder how do they use DN 21-31? The board uses lines AD11 to AD31 (21 lines) for selecting devices #0 - #20. 32-bit PCI bus has only 32 address/data lines :-) Perhaps they mean AD20-AD31 lines = device #9 - #0x14=20? If that is the case, you can try: - their DN30 = device 0x13 = 19, which is apparently what the VIA riser card does, - their DN21 = device 0xA = 10, which could work as well. I'm afraid both would require (different) soldering. My dmesg says: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 10 11 12) *5 ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 6 7 10 *11 12) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 *10 11 12) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 6 7 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 6 7 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 6 7 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [ALKA] (IRQs *20) ACPI: PCI Interrupt Link [ALKB] (IRQs *21) ACPI: PCI Interrupt Link [ALKC] (IRQs *22) ACPI: PCI Interrupt Link [ALKD] (IRQs *23), disabled. lspci -v says: 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1157 Flags: bus master, medium devsel, latency 32, IRQ 16 Memory at fdffc000 (32-bit, non-prefetchable) [size=512] 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1155 Flags: bus master, medium devsel, latency 32, IRQ 20 Memory at fdffb000 (32-bit, non-prefetchable) [size=512] Does this provide additional info to you? http://www.itx-warehouse.co.uk/Product.aspx?ProductID=410 says: Description VIA Dual PCI Riser The EXT-PCI is a PCI riser card which expands a PCI slot into two PCI slots. EXT-PCI slot 1 (lower slot) uses the system resources (Device ID, INT) of the PCI slot of the motherboard. EXT-PCI slot 2 (Upper slot) uses device 19 and INT_A. Upper slot has the problems. TranquilPC does not even respond anymore. The lower slot is a copy of the normal (single) PCI slot w.r.t. devcie and irq, it has DN20 and irq 20. dmesg links ALNKA to IRQ 20. So if ALNKA is INTA both PCI cards should share IRQ 20? - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel [EMAIL PROTECTED] writes: I have DN19 and DN20 now and it doesn't work. Only because the INT mapping on the riser is not right? Yes. I assume DN20 works, only DN19 has problems. http://www.morex.com.tw/drawing/MAR122-J%20Drawing.pdf shows some IDSEL jumper with ADxx numbers. What could these be? Photo at http://www.morex.com.tw/products/imgproduct/100-1.jpg. Still DN's? The second file shows some 28-pin IC but it's not a PCI-PCI bridge. Jumpers marked AD20-31 are for selecting IDSEL - AD20 = DN9, AD31 is DN20 (DNx = ADx - 11). Perhaps they could say how the INTs are wired. It's possible the IC plays some role there. If the riser card is for specific motherboard(s) only (and it must be) then they can read the IDSEL jumper position with this IC and rotate INTs appropriately (thus it could work, with that particular motherboard(s), in any IDSEL jumper position). -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel [EMAIL PROTECTED] writes: Description VIA Dual PCI Riser The EXT-PCI is a PCI riser card which expands a PCI slot into two PCI slots. EXT-PCI slot 1 (lower slot) uses the system resources (Device ID, INT) of the PCI slot of the motherboard. Yep. ID 20, INT D (chipset POV). EXT-PCI slot 2 (Upper slot) uses device 19 and INT_A. Right. Upper slot has the problems. TranquilPC does not even respond anymore. The lower slot is a copy of the normal (single) PCI slot w.r.t. devcie and irq, it has DN20 and irq 20. Ok. dmesg links ALNKA to IRQ 20. So if ALNKA is INTA both PCI cards should share IRQ 20? No. I don't exactly know what these ACPI messages show. Probably they list some power-up state, before devices are configured. If lspci says DN20 uses IRQ 20 and DN19 uses IRQ16 then that's exactly what they should use - two different INT/IRQ signals. If the lspci shows that DN20 uses the same IRQ as IEEE1394 controller and that DN19 uses the same IRQ as on-board Ethernet and VGA then that means just that: they share INTs/IRQs (this is especially true when running in IO-APIC mode). If lspci shows no IRQ for the device then that DN is not supported by the BIOS. I'd try this aluminum film trick. Just be careful, shorting wrong traces can destroy the hardware. As I wrote, shorting the good ones can make the system (temporarily) unusable. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Alistair John Strachan <[EMAIL PROTECTED]> writes: > One warning to you though, I found the riser to be pretty flaky, causing > bizarre lockups and periodic crashes of Linux. Maybe this is a Linux > bug, but > it really didn't seem like it. I don't know how it could be a Linux bug. Perhaps mechanical problems with edge connector - PCI slot connections? -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
[EMAIL PROTECTED] (Lennart Sorensen) writes:
> Well someone said the VIA uses INTA for the DN19 on their riser card,
> although is that INTA from the CPUs point of view or INTA from the slot
> the riser card is plugged into?
CPU/chipset it seems.
>> Device# IDSEL INT (first)
>> 0x08A19 n/a
>> 0x09 A20 n/a
>> 0x0A A21 INT D (and A, B, C)
>> 0x0B A22 n/a
>> 0x0C A23 n/a
>> 0x0D A24 IEEE1394 chip (INT B (single function), unused C, D, A)
>> 0x0E A25 n/a
>> 0x0F A26 n/a
>> 0x10 A27 USB (INT A, B, C, D - 3 UHCI and 1 OHCI = 4 functions)
>> 0x11 A28 VT823x (11.5 uses INT C so it means INT B, C, D, A)
>> 0x12 A29 onboard Ethernet (INT A, unused B, C, D)
>> 0x13 A30 INT A (and B, C, D of course)
>> 0x14 A31 INT B (the MB PCI slot is wired this way, and C, D, A of
>> course as there are 4 usable interrupt lines here)
>>
>> The on-board VGA is INT A (shares with Ethernet, and it's device #0
>> behind a bridge so it has to use INT A).
>
> Which bridge? Interrupts on the mainboard can do anything they want
> (and do).
Anyway, this is consistent with their manual, and it really doesn't
matter (what matters is "what you have to do with INTx signals on
device 0x14 to connect them to device 0x13).
> This would be true, if the bios assigned interrupts to devices that way
> all the time, but this is bus 0 and there are no rules.
That's a function of the PCB, the BIOS can alter IRQx-INTx assignments
(and does it) but can't alter PCB traces, so the INTx-deviceX
assignments are constant.
> After all if
> slot 0, 4, 8, 12, 16, and 20 all used INTA->INTA then that would make
> sense, but slot 20 (0x14) is using INTB->INTA so that isn't the case.
As you wrote, no rules.
> And why would slot 18 (0x12) and slot 19 (0x13) both use INTA?
Who knows? They made it this way, we have to use what we got.
> If the
> bios doesn't expect a device in slot 19 then it won't assing an irq
> correctly, and it will only be correct if the bios knows how it was
> wired.
Sure, but the BIOS expects a device here and expects it to use said
INT A (as seen by the chipset).
Look, I just got that EPIA-M board, connected it to PSU, put a strip
of schotch tape over IDSEL connector (MB PCI slot), tried connecting
IDSEL going to the device to different PCI ADxx lines and noted what
the BIOS thought after RESET. The table just shows that :-)
I initially mapped the MB slot INTs with a 4-port Ethernet card
(with DEC 21152 bridge chip) and then tested device/INT mapping
with a small, simple 1-function card.
I haven't tested devices 1-7 (can test, 0 is used by the chipset),
and I haven't investigated IO-APIC connections, that's right. But
it's almost certain both slots on original VIA riser card share
that set of 4 INTs (rotated) so it doesn't matter.
> Are there any bios options for enabling support for slot 19 devices on
> riser cards?
No, if the BIOS shows the device and (any valid) IRQ number at
startup ("Show summary" = yes in BIOS setup) then the card is
detected and supported, even if the riser card isn't the correct one
(= the card wouldn't work but it shows up).
You just have to connect that card's INT A to whatever the BIOS
wants and expects. That's it.
--
Krzysztof Halasa
-
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: PCI riser cards and PCI irq routing, etc
On Wednesday 21 February 2007 22:40, Lennart Sorensen wrote: > On Wed, Feb 21, 2007 at 10:35:05PM +0100, Krzysztof Halasa wrote: > > Do you mean both slots on the riser card? No, they have to be rotated. > > > > Given the table from the manual: > > > The IRQ (interrupt request line) are hardware lines over which devices > > > can send interrupt signals to the microprocessor. The ??PCI & LAN?? IRQ > > > pins are typically connected to the PCI bus INT A# ~ INT D# pins as > > > follows: Order 1 Order 2 Order 3 Order 4 > > > PCI Slot 1INT B# INT C# INT D# INT A# > > > IEEE1394 INT B# > > > > (I assume Order 1 is device's INT A and so on) > > the chipset-centric view is: > > Well someone said the VIA uses INTA for the DN19 on their riser card, > although is that INTA from the CPUs point of view or INTA from the slot > the riser card is plugged into? There was also mention of a BIOS update > needed on some boards to even support the riser card at all. Maybe that > applies. It applies on the M1, I'm sure the newer EN series boards have always supported the feature. One warning to you though, I found the riser to be pretty flaky, causing bizarre lockups and periodic crashes of Linux. Maybe this is a Linux bug, but it really didn't seem like it. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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: PCI riser cards and PCI irq routing, etc
On Wed, Feb 21, 2007 at 10:35:05PM +0100, Krzysztof Halasa wrote: > Do you mean both slots on the riser card? No, they have to be rotated. > > Given the table from the manual: > > > The IRQ (interrupt request line) are hardware lines over which devices > > can send interrupt signals to the microprocessor. The ??PCI & LAN?? IRQ > > pins are typically connected to the PCI bus INT A# ~ INT D# pins as follows: > > Order 1 Order 2 Order 3 Order 4 > > PCI Slot 1 INT B# INT C# INT D# INT A# > > IEEE1394INT B# > > (I assume Order 1 is device's INT A and so on) > the chipset-centric view is: Well someone said the VIA uses INTA for the DN19 on their riser card, although is that INTA from the CPUs point of view or INTA from the slot the riser card is plugged into? There was also mention of a BIOS update needed on some boards to even support the riser card at all. Maybe that applies. > Device# IDSEL INT (first) > 0x08A19 n/a > 0x09 A20 n/a > 0x0A A21 INT D (and A, B, C) > 0x0B A22 n/a > 0x0C A23 n/a > 0x0D A24 IEEE1394 chip (INT B (single function), unused C, D, A) > 0x0E A25 n/a > 0x0F A26 n/a > 0x10 A27 USB (INT A, B, C, D - 3 UHCI and 1 OHCI = 4 functions) > 0x11 A28 VT823x (11.5 uses INT C so it means INT B, C, D, A) > 0x12 A29 onboard Ethernet (INT A, unused B, C, D) > 0x13 A30 INT A (and B, C, D of course) > 0x14 A31 INT B (the MB PCI slot is wired this way, and C, D, A of > course as there are 4 usable interrupt lines here) > > The on-board VGA is INT A (shares with Ethernet, and it's device #0 > behind a bridge so it has to use INT A). Which bridge? Interrupts on the mainboard can do anything they want (and do). > Device 0x14 (the original PCI slot) ABCD = chipset DABC (as above) > (equal to BCDA = chipset ABCD). > This is a "backward" rotation because the "new" device number is 1 less > than the original one (0x13 vs. 0x14), and the riser card probably uses > "normal" rotation as it assumes the device numer increases. > Device 0x13 is the additional slot on the riser card, 0x14 is the > "original" slot on the riser card (uses 1:1 INT mapping and IDSEL > from the motherboard slot). > > Device 0x0A would need a double rotation, ABCD => CDAB (not sure > if it could work but there was a photo with 3-card riser somewhere > and it seems it's the only possibility, short of PCI-PCI bridge). This would be true, if the bios assigned interrupts to devices that way all the time, but this is bus 0 and there are no rules. After all if slot 0, 4, 8, 12, 16, and 20 all used INTA->INTA then that would make sense, but slot 20 (0x14) is using INTB->INTA so that isn't the case. And why would slot 18 (0x12) and slot 19 (0x13) both use INTA? If the bios doesn't expect a device in slot 19 then it won't assing an irq correctly, and it will only be correct if the bios knows how it was wired. > The BIOS just doesn't give an IRQ to other devices (that's what > "n/a" above means). > > This is for EPIA-M but since they all can use the same riser card... Are there any bios options for enabling support for slot 19 devices on riser cards? -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
On Wed, Feb 21, 2007 at 07:11:06PM +0100, Udo van den Heuvel wrote: > BTW: > > Is the situation, with default DN setting of 19 as displayed below, > `normal` w.r.t. interrupts? > I mean: Both the DVB card with DN19 and the Unichrome Pro video adapter > have the same irq although they are on different busses. Unfortunately, on bus 0, which is always the main bus of a system, there is no such thing as normal. The BIOS knows how the mainboard is wired and hence knows how to assign IRQs. It is only ones you get past bus 0 and onto secondary busses behind bridges that fixed rules apply since that is when things have to work universally. So in your case, via can do whatever they want with IRQs for each DN, since they know the layout of the mainboard. The problem with riser cards without a pci bridge chip, is that they try to modify bus 0 without the knowledge of the board maker, which means the bios won't have a clue how it is wired. Use of any riser card not explicitly supported by the board is hence unsupported and really not recommended. > (...) > 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) > Subsystem: TERRATEC Electronic GmbH Unknown device 1157 > Flags: bus master, medium devsel, latency 32, IRQ 16 > Memory at fdffc000 (32-bit, non-prefetchable) [size=512] > > 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) > Subsystem: TERRATEC Electronic GmbH Unknown device 1155 > Flags: bus master, medium devsel, latency 32, IRQ 20 > Memory at fdffb000 (32-bit, non-prefetchable) [size=512] > > 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro > IGP (rev > 01) (prog-if 00 [VGA]) > Subsystem: VIA Technologies, Inc. UniChrome Pro IGP > Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 > Memory at f400 (32-bit, prefetchable) [size=64M] > Memory at fb00 (32-bit, non-prefetchable) [size=16M] > [virtual] Expansion ROM at fc00 [disabled] [size=64K] > Capabilities: [60] Power Management version 2 > Capabilities: [70] AGP version 3.0 > > How can I find out what INT_A/B/C/D line is mapped to what irq? Read the manual/developer guide. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
On Wed, Feb 21, 2007 at 01:11:12AM +0100, Krzysztof Halasa wrote: > [EMAIL PROTECTED] (Lennart Sorensen) writes: > > > Via has a dual pci-ext card. See EXT-PCI at > > http://www.via.com.tw/en/products/mainboards/accessories.jsp > > Right, and they say it's compatible with "EPIA mini-ITX family". > That means the mappings I just outlined should apply to all of them. > > BTW: any "universal" dual+ PCI riser card have to use a PCI bridge > chip, and a bridge isn't a small 20 pin IC (I'd expect 144 pins or > so). "Active" or "passive" - doesn't matter. > -- Certainly. The system I work with (which is not via based) has a PCI to PCI bridge, which is 208pins (it supports 10 bus master loads behind it). A cheap riser card that just does device number tricks will only work on boards designed to use a riser card done that particular way. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
On Wed, Feb 21, 2007 at 10:24:28AM +0100, Udo van den Heuvel wrote: > Udo van den Heuvel wrote: > > Any ideas about how to proceed? > > What to test? > > I found some info on the VIA dual PCI extender card at > http://www.itx-warehouse.co.uk/Product.aspx?ProductID=410. > The text says: > > The EXT-PCI is a PCI riser card which expands a PCI slot into two PCI slots. > > EXT-PCI slot 1 (lower slot) uses the system resources (Device ID, INT) > of the PCI slot of the motherboard. > > EXT-PCI slot 2 (Upper slot) uses device 19 and INT_A. > > > > So if my non-VIA riser card can use DN 19 and also INT_A things should work? > (assuming that VIA Epia EN BIOS 1.07 is enough to use this card) > > So, if not (as in my situation) how can I find out what is wrong? > Or find out if the BIOS works OK with the card? > How can I verify that the correct routing for the IRQ is in place? > The DN is the only variable so INT lines are hardwired on the riser card? > Then same for the motherboard. It is quite likely that the interrupts are set based on the DN. Now if they use whatever the parent slot uses as INTD as INTA for the second slot (since it is set to 19 which is 1 below 20 of the main slot), then that probably isn't what the BIOS is likely to assign. It really sounds like via decided to do things their own way and only riser cards done their way, or riser cards with a pci to pci bridge are going to work with it. > I.o.w.: how can I find the root cause? Does the documentation say which interrupts are INTA, B, C and D on the main board? I would expect slot 20 to have INTA mapped to INTA but then again being a weird main board it doesn't have to be that way. It is certainly possible via decided to just support DN19 and 20 and assign them both INTA, which would certainly make for a very simple riser card. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel <[EMAIL PROTECTED]> writes: > Is the situation, with default DN setting of 19 as displayed below, > `normal` w.r.t. interrupts? > I mean: Both the DVB card with DN19 and the Unichrome Pro video adapter > have the same irq although they are on different busses. It's normal (and consistent with EPIA-M). The first UHCI USB (#0) could get it, too (but it may be connected differently with IO-APIC, I haven't checked). > How can I find out what INT_A/B/C/D line is mapped to what irq? That "INT_A/B/C/D" stuff depends on the point of view. In the BIOS setup you can select some IRQs (which Linux could change anyway) but it's a chipset-centric view (not very useful here). Every PCI card have INT_A/B/C/D signals and they are (may be) remapped on the riser card and on the motherboard. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel <[EMAIL PROTECTED]> writes: > But the IRQ for the DVB-T card doesn't work. That's because the card drives incorrect INT line. The system (BIOS, Linux) thinks the card would drive INT_D (as seen at the MB PCI slot) and and card drives (its INT_A) INT_B. > I would need to test the DVB-T card alone to be sure it has working IRQ. > If so, what would be the conclusion? I'd expect it to work. Anyway, you'd need to change the mapping. Of course, you have to select device # = 19 (0x13). > What IRQ rerouting would I need to try? 1 of 3 choices? > Or one best bet? You can test if it works first by connecting lines INT B and INT D on the motherboard (or on the device 0x14 slot). That's pins B7 and B8 (you may want to google PCI slot pinout, "B" is the "component side"). I think a small piece of conductive film (aluminum or so) placed carefully with the card would do. Make sure not to damage the connector pins and not to short any additional connectors. It can a) work, b) not work, c) give you "interrupt stuck -> disabled" messages (and perhaps make the system unusable until the film is removed). I'd verify my speculation WRT the riser card is correct and the lines are indeed connected as follows: (device 0x13=19) ABCD -> BCDA (MB slot = device 0x14=20). That means pin A6 on device 0x13 connected to B7 on device 0x14 and on edge connector going to MB slot, pin B7 on 0x13 to A7 on 0x14/MB, pin A7 on 0x13 to B8 on 0x14/MB, pin B8 on 0x13 to pin A6 on 0x14/MB. If that is the case and the alu film works, then (assuming you only need a single IRQ for 0x13) you have to cut connection between A6 on 0x13 and B7 on 0x14 (B7 on 0x14 and B7 on edge connector should stay), then connect that A6 on 0x13 to B8 on 0x14/MB. I think the modification should rather be done by someone who knows how to solder electronics. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
On Wed, Feb 21, 2007 at 03:59:51PM +0100, Udo van den Heuvel wrote: > But the IRQ for the DVB-T card doesn't work. > I would need to test the DVB-T card alone to be sure it has working IRQ. > If so, what would be the conclusion? Well the BIOS makes an assumption about the irq routing on the board, and assigns the IRQ based on that assumption. Via's assumptions are different than the assumptions of the maker of your riser board. That certainly makes sense given how the via ext-pci riser is explicitly labeled as only compatible with via mini-itx boards, which really also implies that no other riser card would be compabitle with a via mini-itx board unless it is a universal card with a proper pci bridge chip (And I have seen embedded boards that don't work correctly with those either, but those are simpler to deal with in software, which is actually what I had to do). > What IRQ rerouting would I need to try? 1 of 3 choices? > Or one best bet? Well best bet is to find out if INTA on the PCI controller matches INTA on the PCI slot. If it does then you want the interrupts on both slots to match. If it doesn't then you want to undo whatever the mapping to the slot is to make it match INTA on the slot to INTA on the bus (assuming that is what Via means by DN19 uses INTA). -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
Lennart Sorensen wrote: > On Wed, Feb 21, 2007 at 10:24:28AM +0100, Udo van den Heuvel wrote: >> Udo van den Heuvel wrote: >> So, if not (as in my situation) how can I find out what is wrong? >> Or find out if the BIOS works OK with the card? >> How can I verify that the correct routing for the IRQ is in place? >> The DN is the only variable so INT lines are hardwired on the riser card? >> Then same for the motherboard. > > It is quite likely that the interrupts are set based on the DN. Now if > they use whatever the parent slot uses as INTD as INTA for the second > slot (since it is set to 19 which is 1 below 20 of the main slot), then > that probably isn't what the BIOS is likely to assign. It really sounds > like via decided to do things their own way and only riser cards done > their way, or riser cards with a pci to pci bridge are going to work > with it. > >> I.o.w.: how can I find the root cause? > > Does the documentation say which interrupts are INTA, B, C and D on the > main board? I would expect slot 20 to have INTA mapped to INTA but then > again being a weird main board it doesn't have to be that way. It is > certainly possible via decided to just support DN19 and 20 and assign > them both INTA, which would certainly make for a very simple riser card. I found something: EPIA-EN User's Manual v.1.10.pdf, chapter 2, Slots (page 26): PCI Interrupt Request Routing The IRQ (interrupt request line) are hardware lines over which devices can send interrupt signals to the microprocessor. The “PCI & LAN” IRQ pins are typically connected to the PCI bus INT A# ~ INT D# pins as follows: Order 1 Order 2 Order 3 Order 4 PCI Slot 1 INT B# INT C# INT D# INT A# IEEE1394INT B# `The slot` and IEEE1394 are indeed on the same IRQ 20 when I use the default setting of DN19 for the extra slot. 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Subsystem: VIA Technologies, Inc. Unknown device aa08 Flags: bus master, 66MHz, medium devsel, latency 8 Memory at e800 (32-bit, prefetchable) [size=128M] Capabilities: [80] AGP version 3.5 Capabilities: [50] Power Management version 2 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge Flags: bus master, medium devsel, latency 0 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: b000-bfff Memory behind bridge: fb00-fcff Prefetchable memory behind bridge: f400-f7ff Capabilities: [70] Power Management version 2 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. IEEE 1394 Host Controller Flags: bus master, stepping, medium devsel, latency 32, IRQ 20 Memory at fdfff000 (32-bit, non-prefetchable) [size=2K] I/O ports at fc00 [size=128] Capabilities: [50] Power Management version 2 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) Subsystem: VIA Technologies, Inc. Unknown device 0110 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 17 I/O ports at f800 [size=256] Memory at fdffe000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller Flags: bus master, medium devsel, latency 32, IRQ 18 I/O ports at f400 [size=8] I/O ports at f000 [size=4] I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=16] I/O ports at e000 [size=256] Capabilities: [c0] Power Management version 2 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE Flags: bus master, medium devsel, latency 32, IRQ 18
Re: PCI riser cards and PCI irq routing, etc
BTW: Is the situation, with default DN setting of 19 as displayed below, `normal` w.r.t. interrupts? I mean: Both the DVB card with DN19 and the Unichrome Pro video adapter have the same irq although they are on different busses. (...) 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1157 Flags: bus master, medium devsel, latency 32, IRQ 16 Memory at fdffc000 (32-bit, non-prefetchable) [size=512] 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1155 Flags: bus master, medium devsel, latency 32, IRQ 20 Memory at fdffb000 (32-bit, non-prefetchable) [size=512] 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01) (prog-if 00 [VGA]) Subsystem: VIA Technologies, Inc. UniChrome Pro IGP Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at f400 (32-bit, prefetchable) [size=64M] Memory at fb00 (32-bit, non-prefetchable) [size=16M] [virtual] Expansion ROM at fc00 [disabled] [size=64K] Capabilities: [60] Power Management version 2 Capabilities: [70] AGP version 3.0 How can I find out what INT_A/B/C/D line is mapped to what irq? - 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: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: > Udo van den Heuvel <[EMAIL PROTECTED]> writes: > >> So if my non-VIA riser card can use DN 19 and also INT_A things should work? > > That INT_A may be INT_A from their (motherboard) point of view, but > the riser card doesn't know about that, it only knows INTs as seen > at its PCI edge connector (so this INT_A here is meaningless). > > Device numbers aren't rotated but rather derived from address lines > (address/data). AD0-31 lines are the same across the whole PCI bus. > That means device numbers are independent of POV. > >> (assuming that VIA Epia EN BIOS 1.07 is enough to use this card) > > My VIA EPIA-M 600 is probably older than your one, so I'd assume > it should work as well. > When you configure 0x13 and 0x14, both devices get IRQs - that means > the BIOS can see both of them. But the IRQ for the DVB-T card doesn't work. I would need to test the DVB-T card alone to be sure it has working IRQ. If so, what would be the conclusion? >> The DN is the only variable so INT lines are hardwired on the riser card? > > Yep. You just need a bit of soldering. What IRQ rerouting would I need to try? 1 of 3 choices? Or one best bet? Udo - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel <[EMAIL PROTECTED]> writes: > So if my non-VIA riser card can use DN 19 and also INT_A things should work? That INT_A may be INT_A from their (motherboard) point of view, but the riser card doesn't know about that, it only knows INTs as seen at its PCI edge connector (so this INT_A here is meaningless). Device numbers aren't rotated but rather derived from address lines (address/data). AD0-31 lines are the same across the whole PCI bus. That means device numbers are independent of POV. > (assuming that VIA Epia EN BIOS 1.07 is enough to use this card) My VIA EPIA-M 600 is probably older than your one, so I'd assume it should work as well. When you configure 0x13 and 0x14, both devices get IRQs - that means the BIOS can see both of them. > The DN is the only variable so INT lines are hardwired on the riser card? Yep. You just need a bit of soldering. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel wrote: > Any ideas about how to proceed? > What to test? I found some info on the VIA dual PCI extender card at http://www.itx-warehouse.co.uk/Product.aspx?ProductID=410. The text says: The EXT-PCI is a PCI riser card which expands a PCI slot into two PCI slots. EXT-PCI slot 1 (lower slot) uses the system resources (Device ID, INT) of the PCI slot of the motherboard. EXT-PCI slot 2 (Upper slot) uses device 19 and INT_A. So if my non-VIA riser card can use DN 19 and also INT_A things should work? (assuming that VIA Epia EN BIOS 1.07 is enough to use this card) So, if not (as in my situation) how can I find out what is wrong? Or find out if the BIOS works OK with the card? How can I verify that the correct routing for the IRQ is in place? The DN is the only variable so INT lines are hardwired on the riser card? Then same for the motherboard. I.o.w.: how can I find the root cause? Kind regards, Udo - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel wrote: Any ideas about how to proceed? What to test? I found some info on the VIA dual PCI extender card at http://www.itx-warehouse.co.uk/Product.aspx?ProductID=410. The text says: The EXT-PCI is a PCI riser card which expands a PCI slot into two PCI slots. EXT-PCI slot 1 (lower slot) uses the system resources (Device ID, INT) of the PCI slot of the motherboard. EXT-PCI slot 2 (Upper slot) uses device 19 and INT_A. So if my non-VIA riser card can use DN 19 and also INT_A things should work? (assuming that VIA Epia EN BIOS 1.07 is enough to use this card) So, if not (as in my situation) how can I find out what is wrong? Or find out if the BIOS works OK with the card? How can I verify that the correct routing for the IRQ is in place? The DN is the only variable so INT lines are hardwired on the riser card? Then same for the motherboard. I.o.w.: how can I find the root cause? Kind regards, Udo - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel [EMAIL PROTECTED] writes: So if my non-VIA riser card can use DN 19 and also INT_A things should work? That INT_A may be INT_A from their (motherboard) point of view, but the riser card doesn't know about that, it only knows INTs as seen at its PCI edge connector (so this INT_A here is meaningless). Device numbers aren't rotated but rather derived from address lines (address/data). AD0-31 lines are the same across the whole PCI bus. That means device numbers are independent of POV. (assuming that VIA Epia EN BIOS 1.07 is enough to use this card) My VIA EPIA-M 600 is probably older than your one, so I'd assume it should work as well. When you configure 0x13 and 0x14, both devices get IRQs - that means the BIOS can see both of them. The DN is the only variable so INT lines are hardwired on the riser card? Yep. You just need a bit of soldering. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: Udo van den Heuvel [EMAIL PROTECTED] writes: So if my non-VIA riser card can use DN 19 and also INT_A things should work? That INT_A may be INT_A from their (motherboard) point of view, but the riser card doesn't know about that, it only knows INTs as seen at its PCI edge connector (so this INT_A here is meaningless). Device numbers aren't rotated but rather derived from address lines (address/data). AD0-31 lines are the same across the whole PCI bus. That means device numbers are independent of POV. (assuming that VIA Epia EN BIOS 1.07 is enough to use this card) My VIA EPIA-M 600 is probably older than your one, so I'd assume it should work as well. When you configure 0x13 and 0x14, both devices get IRQs - that means the BIOS can see both of them. But the IRQ for the DVB-T card doesn't work. I would need to test the DVB-T card alone to be sure it has working IRQ. If so, what would be the conclusion? The DN is the only variable so INT lines are hardwired on the riser card? Yep. You just need a bit of soldering. What IRQ rerouting would I need to try? 1 of 3 choices? Or one best bet? Udo - 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: PCI riser cards and PCI irq routing, etc
BTW: Is the situation, with default DN setting of 19 as displayed below, `normal` w.r.t. interrupts? I mean: Both the DVB card with DN19 and the Unichrome Pro video adapter have the same irq although they are on different busses. (...) 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1157 Flags: bus master, medium devsel, latency 32, IRQ 16 Memory at fdffc000 (32-bit, non-prefetchable) [size=512] 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1155 Flags: bus master, medium devsel, latency 32, IRQ 20 Memory at fdffb000 (32-bit, non-prefetchable) [size=512] 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01) (prog-if 00 [VGA]) Subsystem: VIA Technologies, Inc. UniChrome Pro IGP Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at f400 (32-bit, prefetchable) [size=64M] Memory at fb00 (32-bit, non-prefetchable) [size=16M] [virtual] Expansion ROM at fc00 [disabled] [size=64K] Capabilities: [60] Power Management version 2 Capabilities: [70] AGP version 3.0 How can I find out what INT_A/B/C/D line is mapped to what irq? - 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: PCI riser cards and PCI irq routing, etc
Lennart Sorensen wrote: On Wed, Feb 21, 2007 at 10:24:28AM +0100, Udo van den Heuvel wrote: Udo van den Heuvel wrote: So, if not (as in my situation) how can I find out what is wrong? Or find out if the BIOS works OK with the card? How can I verify that the correct routing for the IRQ is in place? The DN is the only variable so INT lines are hardwired on the riser card? Then same for the motherboard. It is quite likely that the interrupts are set based on the DN. Now if they use whatever the parent slot uses as INTD as INTA for the second slot (since it is set to 19 which is 1 below 20 of the main slot), then that probably isn't what the BIOS is likely to assign. It really sounds like via decided to do things their own way and only riser cards done their way, or riser cards with a pci to pci bridge are going to work with it. I.o.w.: how can I find the root cause? Does the documentation say which interrupts are INTA, B, C and D on the main board? I would expect slot 20 to have INTA mapped to INTA but then again being a weird main board it doesn't have to be that way. It is certainly possible via decided to just support DN19 and 20 and assign them both INTA, which would certainly make for a very simple riser card. I found something: EPIA-EN User's Manual v.1.10.pdf, chapter 2, Slots (page 26): PCI Interrupt Request Routing The IRQ (interrupt request line) are hardware lines over which devices can send interrupt signals to the microprocessor. The “PCI LAN” IRQ pins are typically connected to the PCI bus INT A# ~ INT D# pins as follows: Order 1 Order 2 Order 3 Order 4 PCI Slot 1 INT B# INT C# INT D# INT A# IEEE1394INT B# `The slot` and IEEE1394 are indeed on the same IRQ 20 when I use the default setting of DN19 for the extra slot. 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Subsystem: VIA Technologies, Inc. Unknown device aa08 Flags: bus master, 66MHz, medium devsel, latency 8 Memory at e800 (32-bit, prefetchable) [size=128M] Capabilities: [80] AGP version 3.5 Capabilities: [50] Power Management version 2 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge Flags: bus master, medium devsel, latency 0 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: b000-bfff Memory behind bridge: fb00-fcff Prefetchable memory behind bridge: f400-f7ff Capabilities: [70] Power Management version 2 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. IEEE 1394 Host Controller Flags: bus master, stepping, medium devsel, latency 32, IRQ 20 Memory at fdfff000 (32-bit, non-prefetchable) [size=2K] I/O ports at fc00 [size=128] Capabilities: [50] Power Management version 2 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) Subsystem: VIA Technologies, Inc. Unknown device 0110 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 17 I/O ports at f800 [size=256] Memory at fdffe000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller Flags: bus master, medium devsel, latency 32, IRQ 18 I/O ports at f400 [size=8] I/O ports at f000 [size=4] I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=16] I/O ports at e000 [size=256] Capabilities: [c0] Power Management version 2 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE Flags: bus master, medium devsel, latency 32, IRQ 18 [virtual] Memory at 01f0
Re: PCI riser cards and PCI irq routing, etc
On Wed, Feb 21, 2007 at 03:59:51PM +0100, Udo van den Heuvel wrote: But the IRQ for the DVB-T card doesn't work. I would need to test the DVB-T card alone to be sure it has working IRQ. If so, what would be the conclusion? Well the BIOS makes an assumption about the irq routing on the board, and assigns the IRQ based on that assumption. Via's assumptions are different than the assumptions of the maker of your riser board. That certainly makes sense given how the via ext-pci riser is explicitly labeled as only compatible with via mini-itx boards, which really also implies that no other riser card would be compabitle with a via mini-itx board unless it is a universal card with a proper pci bridge chip (And I have seen embedded boards that don't work correctly with those either, but those are simpler to deal with in software, which is actually what I had to do). What IRQ rerouting would I need to try? 1 of 3 choices? Or one best bet? Well best bet is to find out if INTA on the PCI controller matches INTA on the PCI slot. If it does then you want the interrupts on both slots to match. If it doesn't then you want to undo whatever the mapping to the slot is to make it match INTA on the slot to INTA on the bus (assuming that is what Via means by DN19 uses INTA). -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel [EMAIL PROTECTED] writes: But the IRQ for the DVB-T card doesn't work. That's because the card drives incorrect INT line. The system (BIOS, Linux) thinks the card would drive INT_D (as seen at the MB PCI slot) and and card drives (its INT_A) INT_B. I would need to test the DVB-T card alone to be sure it has working IRQ. If so, what would be the conclusion? I'd expect it to work. Anyway, you'd need to change the mapping. Of course, you have to select device # = 19 (0x13). What IRQ rerouting would I need to try? 1 of 3 choices? Or one best bet? You can test if it works first by connecting lines INT B and INT D on the motherboard (or on the device 0x14 slot). That's pins B7 and B8 (you may want to google PCI slot pinout, B is the component side). I think a small piece of conductive film (aluminum or so) placed carefully with the card would do. Make sure not to damage the connector pins and not to short any additional connectors. It can a) work, b) not work, c) give you interrupt stuck - disabled messages (and perhaps make the system unusable until the film is removed). I'd verify my speculation WRT the riser card is correct and the lines are indeed connected as follows: (device 0x13=19) ABCD - BCDA (MB slot = device 0x14=20). That means pin A6 on device 0x13 connected to B7 on device 0x14 and on edge connector going to MB slot, pin B7 on 0x13 to A7 on 0x14/MB, pin A7 on 0x13 to B8 on 0x14/MB, pin B8 on 0x13 to pin A6 on 0x14/MB. If that is the case and the alu film works, then (assuming you only need a single IRQ for 0x13) you have to cut connection between A6 on 0x13 and B7 on 0x14 (B7 on 0x14 and B7 on edge connector should stay), then connect that A6 on 0x13 to B8 on 0x14/MB. I think the modification should rather be done by someone who knows how to solder electronics. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel [EMAIL PROTECTED] writes: Is the situation, with default DN setting of 19 as displayed below, `normal` w.r.t. interrupts? I mean: Both the DVB card with DN19 and the Unichrome Pro video adapter have the same irq although they are on different busses. It's normal (and consistent with EPIA-M). The first UHCI USB (#0) could get it, too (but it may be connected differently with IO-APIC, I haven't checked). How can I find out what INT_A/B/C/D line is mapped to what irq? That INT_A/B/C/D stuff depends on the point of view. In the BIOS setup you can select some IRQs (which Linux could change anyway) but it's a chipset-centric view (not very useful here). Every PCI card have INT_A/B/C/D signals and they are (may be) remapped on the riser card and on the motherboard. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
On Wed, Feb 21, 2007 at 01:11:12AM +0100, Krzysztof Halasa wrote: [EMAIL PROTECTED] (Lennart Sorensen) writes: Via has a dual pci-ext card. See EXT-PCI at http://www.via.com.tw/en/products/mainboards/accessories.jsp Right, and they say it's compatible with EPIA mini-ITX family. That means the mappings I just outlined should apply to all of them. BTW: any universal dual+ PCI riser card have to use a PCI bridge chip, and a bridge isn't a small 20 pin IC (I'd expect 144 pins or so). Active or passive - doesn't matter. -- Certainly. The system I work with (which is not via based) has a PCI to PCI bridge, which is 208pins (it supports 10 bus master loads behind it). A cheap riser card that just does device number tricks will only work on boards designed to use a riser card done that particular way. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
On Wed, Feb 21, 2007 at 10:24:28AM +0100, Udo van den Heuvel wrote: Udo van den Heuvel wrote: Any ideas about how to proceed? What to test? I found some info on the VIA dual PCI extender card at http://www.itx-warehouse.co.uk/Product.aspx?ProductID=410. The text says: The EXT-PCI is a PCI riser card which expands a PCI slot into two PCI slots. EXT-PCI slot 1 (lower slot) uses the system resources (Device ID, INT) of the PCI slot of the motherboard. EXT-PCI slot 2 (Upper slot) uses device 19 and INT_A. So if my non-VIA riser card can use DN 19 and also INT_A things should work? (assuming that VIA Epia EN BIOS 1.07 is enough to use this card) So, if not (as in my situation) how can I find out what is wrong? Or find out if the BIOS works OK with the card? How can I verify that the correct routing for the IRQ is in place? The DN is the only variable so INT lines are hardwired on the riser card? Then same for the motherboard. It is quite likely that the interrupts are set based on the DN. Now if they use whatever the parent slot uses as INTD as INTA for the second slot (since it is set to 19 which is 1 below 20 of the main slot), then that probably isn't what the BIOS is likely to assign. It really sounds like via decided to do things their own way and only riser cards done their way, or riser cards with a pci to pci bridge are going to work with it. I.o.w.: how can I find the root cause? Does the documentation say which interrupts are INTA, B, C and D on the main board? I would expect slot 20 to have INTA mapped to INTA but then again being a weird main board it doesn't have to be that way. It is certainly possible via decided to just support DN19 and 20 and assign them both INTA, which would certainly make for a very simple riser card. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
On Wed, Feb 21, 2007 at 07:11:06PM +0100, Udo van den Heuvel wrote: BTW: Is the situation, with default DN setting of 19 as displayed below, `normal` w.r.t. interrupts? I mean: Both the DVB card with DN19 and the Unichrome Pro video adapter have the same irq although they are on different busses. Unfortunately, on bus 0, which is always the main bus of a system, there is no such thing as normal. The BIOS knows how the mainboard is wired and hence knows how to assign IRQs. It is only ones you get past bus 0 and onto secondary busses behind bridges that fixed rules apply since that is when things have to work universally. So in your case, via can do whatever they want with IRQs for each DN, since they know the layout of the mainboard. The problem with riser cards without a pci bridge chip, is that they try to modify bus 0 without the knowledge of the board maker, which means the bios won't have a clue how it is wired. Use of any riser card not explicitly supported by the board is hence unsupported and really not recommended. (...) 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1157 Flags: bus master, medium devsel, latency 32, IRQ 16 Memory at fdffc000 (32-bit, non-prefetchable) [size=512] 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1155 Flags: bus master, medium devsel, latency 32, IRQ 20 Memory at fdffb000 (32-bit, non-prefetchable) [size=512] 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01) (prog-if 00 [VGA]) Subsystem: VIA Technologies, Inc. UniChrome Pro IGP Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at f400 (32-bit, prefetchable) [size=64M] Memory at fb00 (32-bit, non-prefetchable) [size=16M] [virtual] Expansion ROM at fc00 [disabled] [size=64K] Capabilities: [60] Power Management version 2 Capabilities: [70] AGP version 3.0 How can I find out what INT_A/B/C/D line is mapped to what irq? Read the manual/developer guide. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
On Wed, Feb 21, 2007 at 10:35:05PM +0100, Krzysztof Halasa wrote: Do you mean both slots on the riser card? No, they have to be rotated. Given the table from the manual: The IRQ (interrupt request line) are hardware lines over which devices can send interrupt signals to the microprocessor. The ??PCI LAN?? IRQ pins are typically connected to the PCI bus INT A# ~ INT D# pins as follows: Order 1 Order 2 Order 3 Order 4 PCI Slot 1 INT B# INT C# INT D# INT A# IEEE1394INT B# (I assume Order 1 is device's INT A and so on) the chipset-centric view is: Well someone said the VIA uses INTA for the DN19 on their riser card, although is that INTA from the CPUs point of view or INTA from the slot the riser card is plugged into? There was also mention of a BIOS update needed on some boards to even support the riser card at all. Maybe that applies. Device# IDSEL INT (first) 0x08A19 n/a 0x09 A20 n/a 0x0A A21 INT D (and A, B, C) 0x0B A22 n/a 0x0C A23 n/a 0x0D A24 IEEE1394 chip (INT B (single function), unused C, D, A) 0x0E A25 n/a 0x0F A26 n/a 0x10 A27 USB (INT A, B, C, D - 3 UHCI and 1 OHCI = 4 functions) 0x11 A28 VT823x (11.5 uses INT C so it means INT B, C, D, A) 0x12 A29 onboard Ethernet (INT A, unused B, C, D) 0x13 A30 INT A (and B, C, D of course) 0x14 A31 INT B (the MB PCI slot is wired this way, and C, D, A of course as there are 4 usable interrupt lines here) The on-board VGA is INT A (shares with Ethernet, and it's device #0 behind a bridge so it has to use INT A). Which bridge? Interrupts on the mainboard can do anything they want (and do). Device 0x14 (the original PCI slot) ABCD = chipset DABC (as above) (equal to BCDA = chipset ABCD). This is a backward rotation because the new device number is 1 less than the original one (0x13 vs. 0x14), and the riser card probably uses normal rotation as it assumes the device numer increases. Device 0x13 is the additional slot on the riser card, 0x14 is the original slot on the riser card (uses 1:1 INT mapping and IDSEL from the motherboard slot). Device 0x0A would need a double rotation, ABCD = CDAB (not sure if it could work but there was a photo with 3-card riser somewhere and it seems it's the only possibility, short of PCI-PCI bridge). This would be true, if the bios assigned interrupts to devices that way all the time, but this is bus 0 and there are no rules. After all if slot 0, 4, 8, 12, 16, and 20 all used INTA-INTA then that would make sense, but slot 20 (0x14) is using INTB-INTA so that isn't the case. And why would slot 18 (0x12) and slot 19 (0x13) both use INTA? If the bios doesn't expect a device in slot 19 then it won't assing an irq correctly, and it will only be correct if the bios knows how it was wired. The BIOS just doesn't give an IRQ to other devices (that's what n/a above means). This is for EPIA-M but since they all can use the same riser card... Are there any bios options for enabling support for slot 19 devices on riser cards? -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
On Wednesday 21 February 2007 22:40, Lennart Sorensen wrote: On Wed, Feb 21, 2007 at 10:35:05PM +0100, Krzysztof Halasa wrote: Do you mean both slots on the riser card? No, they have to be rotated. Given the table from the manual: The IRQ (interrupt request line) are hardware lines over which devices can send interrupt signals to the microprocessor. The ??PCI LAN?? IRQ pins are typically connected to the PCI bus INT A# ~ INT D# pins as follows: Order 1 Order 2 Order 3 Order 4 PCI Slot 1INT B# INT C# INT D# INT A# IEEE1394 INT B# (I assume Order 1 is device's INT A and so on) the chipset-centric view is: Well someone said the VIA uses INTA for the DN19 on their riser card, although is that INTA from the CPUs point of view or INTA from the slot the riser card is plugged into? There was also mention of a BIOS update needed on some boards to even support the riser card at all. Maybe that applies. It applies on the M1, I'm sure the newer EN series boards have always supported the feature. One warning to you though, I found the riser to be pretty flaky, causing bizarre lockups and periodic crashes of Linux. Maybe this is a Linux bug, but it really didn't seem like it. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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: PCI riser cards and PCI irq routing, etc
[EMAIL PROTECTED] (Lennart Sorensen) writes: Well someone said the VIA uses INTA for the DN19 on their riser card, although is that INTA from the CPUs point of view or INTA from the slot the riser card is plugged into? CPU/chipset it seems. Device# IDSEL INT (first) 0x08A19 n/a 0x09 A20 n/a 0x0A A21 INT D (and A, B, C) 0x0B A22 n/a 0x0C A23 n/a 0x0D A24 IEEE1394 chip (INT B (single function), unused C, D, A) 0x0E A25 n/a 0x0F A26 n/a 0x10 A27 USB (INT A, B, C, D - 3 UHCI and 1 OHCI = 4 functions) 0x11 A28 VT823x (11.5 uses INT C so it means INT B, C, D, A) 0x12 A29 onboard Ethernet (INT A, unused B, C, D) 0x13 A30 INT A (and B, C, D of course) 0x14 A31 INT B (the MB PCI slot is wired this way, and C, D, A of course as there are 4 usable interrupt lines here) The on-board VGA is INT A (shares with Ethernet, and it's device #0 behind a bridge so it has to use INT A). Which bridge? Interrupts on the mainboard can do anything they want (and do). Anyway, this is consistent with their manual, and it really doesn't matter (what matters is what you have to do with INTx signals on device 0x14 to connect them to device 0x13). This would be true, if the bios assigned interrupts to devices that way all the time, but this is bus 0 and there are no rules. That's a function of the PCB, the BIOS can alter IRQx-INTx assignments (and does it) but can't alter PCB traces, so the INTx-deviceX assignments are constant. After all if slot 0, 4, 8, 12, 16, and 20 all used INTA-INTA then that would make sense, but slot 20 (0x14) is using INTB-INTA so that isn't the case. As you wrote, no rules. And why would slot 18 (0x12) and slot 19 (0x13) both use INTA? Who knows? They made it this way, we have to use what we got. If the bios doesn't expect a device in slot 19 then it won't assing an irq correctly, and it will only be correct if the bios knows how it was wired. Sure, but the BIOS expects a device here and expects it to use said INT A (as seen by the chipset). Look, I just got that EPIA-M board, connected it to PSU, put a strip of schotch tape over IDSEL connector (MB PCI slot), tried connecting IDSEL going to the device to different PCI ADxx lines and noted what the BIOS thought after RESET. The table just shows that :-) I initially mapped the MB slot INTs with a 4-port Ethernet card (with DEC 21152 bridge chip) and then tested device/INT mapping with a small, simple 1-function card. I haven't tested devices 1-7 (can test, 0 is used by the chipset), and I haven't investigated IO-APIC connections, that's right. But it's almost certain both slots on original VIA riser card share that set of 4 INTs (rotated) so it doesn't matter. Are there any bios options for enabling support for slot 19 devices on riser cards? No, if the BIOS shows the device and (any valid) IRQ number at startup (Show summary = yes in BIOS setup) then the card is detected and supported, even if the riser card isn't the correct one (= the card wouldn't work but it shows up). You just have to connect that card's INT A to whatever the BIOS wants and expects. That's it. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Alistair John Strachan [EMAIL PROTECTED] writes: One warning to you though, I found the riser to be pretty flaky, causing bizarre lockups and periodic crashes of Linux. Maybe this is a Linux bug, but it really didn't seem like it. I don't know how it could be a Linux bug. Perhaps mechanical problems with edge connector - PCI slot connections? -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
[EMAIL PROTECTED] (Lennart Sorensen) writes: > Via has a dual pci-ext card. See EXT-PCI at > http://www.via.com.tw/en/products/mainboards/accessories.jsp Right, and they say it's compatible with "EPIA mini-ITX family". That means the mappings I just outlined should apply to all of them. BTW: any "universal" dual+ PCI riser card have to use a PCI bridge chip, and a bridge isn't a small 20 pin IC (I'd expect 144 pins or so). "Active" or "passive" - doesn't matter. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel <[EMAIL PROTECTED]> writes: > saa7146: found saa7146 @ mem f896a000 (revision 1, irq 145) (0x153b,0x1157). > saa7146: found saa7146 @ mem f89e6000 (revision 1, irq 153) (0x153b,0x1155). IO-APICs can do such things... Ok, I have experimented a bit with my old unused EPIA-M 600 MHz MB. INT A, B, C, D - as seen at the MB PCI connector (using PCI-PCI bridge or 4-function device). Device# IDSEL INT (first) 0x08A19 n/a 0x09A20 n/a 0x0AA21 INT C 0x0BA22 n/a 0x0CA23 n/a 0x0DA24 IEEE1394 chip (INT A) 0x0EA25 n/a 0x0FA26 n/a 0x10A27 USB (INT D, A, B, C) 0x11A28 VT823x (11.5 uses INT B so it means INT A, B, C, D) 0x12A29 onboard Ethernet (INT D) 0x13A30 INT D 0x14A31 INT A (the MB PCI slot is wired this way) That's from BIOS summary screen, I haven't bothered to run Linux and check IO-APIC stuff (there may be more than 1 set of 4 INTs). I haven't tested devices 1-7, you can't probably use them anyway. It means that (assuming your MB can use the same riser card as this one), you need the following mapping on the riser: - first slot, device 0x14 (=20), INT lines 1:1 (the same INT and IDSEL wiring as at the motherboard PCI slot) - second slot, device 0x13 (=19), INT lines rotated (device) ABCD -> DABC (MB) (i.e., line INT A as seen at the MB PCI slot becomes INT B at the device on the riser card and INT A as seen at the riser slot becomes INT D at the motherboard). Chances are that you could probably use device 0x0A (=10) as well, but it would require another INT rotation (= double rotation). I bet your riser card have the following mapping: device X INTs 1:1 device X+1 INTs (device X+1) ABCD -> BCDA (MB = device X) (INT A at the device slot becomes INT B at the MB connector and so on). That means (unless INT rotations are configurable) you have to make some (quite simple, in fact) modifications to the riser card :-( -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
On Tue, Feb 20, 2007 at 09:47:48PM +0100, Krzysztof Halasa wrote: > Udo van den Heuvel <[EMAIL PROTECTED]> writes: > > > Yes, VIA Epia EN12000. > > Interesting to check the riser card. > > Unfortunately it turns out it's single slot only. Via has a dual pci-ext card. See EXT-PCI at http://www.via.com.tw/en/products/mainboards/accessories.jsp -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel <[EMAIL PROTECTED]> writes: > Yes, VIA Epia EN12000. > Interesting to check the riser card. Unfortunately it turns out it's single slot only. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
On Tuesday 20 February 2007 15:44, you wrote: > Alistair John Strachan wrote: > > On Tuesday 20 February 2007 04:17, Udo van den Heuvel wrote: > >> Krzysztof Halasa wrote: > >>> Is it a VIA ITX board? I think I have VIA's riser card somewhere, > >>> could check what it does. > >> > >> Yes, VIA Epia EN12000. > >> Interesting to check the riser card. > > > > Just be aware that there are two types of PCI riser -- risers that work > > in any board, and Via Epia-specific risers. The latter requires a BIOS > > update on some Epias and presumably has some advantages, possible the > > ones you're looking for. > > This card is sold by TranquilPC for their T2e case which holds Mini-ITX > boards. My EN12000 has the latest BIOS I could find on the VIA site: > http://www.via.com.tw/en/products/mainboards/downloads.jsp?motherboard_id=3 >99#BIOS The riser I have here is called "ext-pci rev b" and is marked "Via Tech Inc". My understanding is that this is not an "active riser" and requires explicit BIOS support. A quick googling for the device revealed this: http://forums.viaarena.com/messageview.aspx?catid=32=41622_key=y=riser A poster here seems to suggest the following: "As far as I know the only dual riser card that is supported by the EPIA BIOS is the one from VIA (that faces out). That one has some logic on it to get both slots working. The upper slot uses device 19 and INT_A, allocated through the EPIA BIOS." This may perhaps describe the issue you are having, and from the PDF you linked I do not believe you have a riser that is the same as mine. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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: PCI riser cards and PCI irq routing, etc
Alistair John Strachan wrote: > On Tuesday 20 February 2007 04:17, Udo van den Heuvel wrote: >> Krzysztof Halasa wrote: >>> Is it a VIA ITX board? I think I have VIA's riser card somewhere, >>> could check what it does. >> Yes, VIA Epia EN12000. >> Interesting to check the riser card. > > Just be aware that there are two types of PCI riser -- risers that work in > any > board, and Via Epia-specific risers. The latter requires a BIOS update on > some Epias and presumably has some advantages, possible the ones you're > looking for. This card is sold by TranquilPC for their T2e case which holds Mini-ITX boards. My EN12000 has the latest BIOS I could find on the VIA site: http://www.via.com.tw/en/products/mainboards/downloads.jsp?motherboard_id=399#BIOS I just tested with Device Number 12 and DN 18 (the only free locations to try besides the DN 19 default, if I am correct on this). DN 12 gave me this: 00:0c.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1157 Flags: medium devsel, IRQ 255 Memory at fdfff000 (32-bit, non-prefetchable) [size=512] No irq! The other card remained at DN20 and irq 20. So no visible i2c at all (!) for the DVB-T card. DN 18 gave me: 00:12.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1157 Flags: bus master, medium devsel, latency 32, IRQ 20 Memory at fdffc000 (32-bit, non-prefetchable) [size=512] 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1155 Flags: bus master, medium devsel, latency 32, IRQ 21 Memory at fdffb000 (32-bit, non-prefetchable) [size=512] The DVB-T card had the same problems as with DN19 in irq mode. Visible i2c bus but not usable i2c. Any ideas about how to proceed? What to test? BTW: Another case I am considering has this drawing for the riser: http://www.morex.com.tw/drawing/MAR122-J%20Drawing.pdf DN ranges from 20 to 31. Would this improve the situation? Kind regards, Udo - 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: PCI riser cards and PCI irq routing, etc
On Tuesday 20 February 2007 04:17, Udo van den Heuvel wrote: > Krzysztof Halasa wrote: > > Udo van den Heuvel <[EMAIL PROTECTED]> writes: > >> At the bottom I added a dmesg output of the kernel after boot. > >> I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is > >> 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for > >> i2c although the card does work perfectly for DVB-T reception (picture, > >> low CPU load, etc) with only reception as the bottleneck. > > > > BTW: Can you check which device # and IRQ does the card get if plugged > > directly into the PCI slot on board (without the riser)? > > DN is 20 I believe (from the tranquilPC doc). > irq I'd have to check. > > > Is it a VIA ITX board? I think I have VIA's riser card somewhere, > > could check what it does. > > Yes, VIA Epia EN12000. > Interesting to check the riser card. Just be aware that there are two types of PCI riser -- risers that work in any board, and Via Epia-specific risers. The latter requires a BIOS update on some Epias and presumably has some advantages, possible the ones you're looking for. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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: PCI riser cards and PCI irq routing, etc
On Tuesday 20 February 2007 04:17, Udo van den Heuvel wrote: Krzysztof Halasa wrote: Udo van den Heuvel [EMAIL PROTECTED] writes: At the bottom I added a dmesg output of the kernel after boot. I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for i2c although the card does work perfectly for DVB-T reception (picture, low CPU load, etc) with only reception as the bottleneck. BTW: Can you check which device # and IRQ does the card get if plugged directly into the PCI slot on board (without the riser)? DN is 20 I believe (from the tranquilPC doc). irq I'd have to check. Is it a VIA ITX board? I think I have VIA's riser card somewhere, could check what it does. Yes, VIA Epia EN12000. Interesting to check the riser card. Just be aware that there are two types of PCI riser -- risers that work in any board, and Via Epia-specific risers. The latter requires a BIOS update on some Epias and presumably has some advantages, possible the ones you're looking for. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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: PCI riser cards and PCI irq routing, etc
Alistair John Strachan wrote: On Tuesday 20 February 2007 04:17, Udo van den Heuvel wrote: Krzysztof Halasa wrote: Is it a VIA ITX board? I think I have VIA's riser card somewhere, could check what it does. Yes, VIA Epia EN12000. Interesting to check the riser card. Just be aware that there are two types of PCI riser -- risers that work in any board, and Via Epia-specific risers. The latter requires a BIOS update on some Epias and presumably has some advantages, possible the ones you're looking for. This card is sold by TranquilPC for their T2e case which holds Mini-ITX boards. My EN12000 has the latest BIOS I could find on the VIA site: http://www.via.com.tw/en/products/mainboards/downloads.jsp?motherboard_id=399#BIOS I just tested with Device Number 12 and DN 18 (the only free locations to try besides the DN 19 default, if I am correct on this). DN 12 gave me this: 00:0c.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1157 Flags: medium devsel, IRQ 255 Memory at fdfff000 (32-bit, non-prefetchable) [size=512] No irq! The other card remained at DN20 and irq 20. So no visible i2c at all (!) for the DVB-T card. DN 18 gave me: 00:12.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1157 Flags: bus master, medium devsel, latency 32, IRQ 20 Memory at fdffc000 (32-bit, non-prefetchable) [size=512] 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Unknown device 1155 Flags: bus master, medium devsel, latency 32, IRQ 21 Memory at fdffb000 (32-bit, non-prefetchable) [size=512] The DVB-T card had the same problems as with DN19 in irq mode. Visible i2c bus but not usable i2c. Any ideas about how to proceed? What to test? BTW: Another case I am considering has this drawing for the riser: http://www.morex.com.tw/drawing/MAR122-J%20Drawing.pdf DN ranges from 20 to 31. Would this improve the situation? Kind regards, Udo - 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: PCI riser cards and PCI irq routing, etc
On Tuesday 20 February 2007 15:44, you wrote: Alistair John Strachan wrote: On Tuesday 20 February 2007 04:17, Udo van den Heuvel wrote: Krzysztof Halasa wrote: Is it a VIA ITX board? I think I have VIA's riser card somewhere, could check what it does. Yes, VIA Epia EN12000. Interesting to check the riser card. Just be aware that there are two types of PCI riser -- risers that work in any board, and Via Epia-specific risers. The latter requires a BIOS update on some Epias and presumably has some advantages, possible the ones you're looking for. This card is sold by TranquilPC for their T2e case which holds Mini-ITX boards. My EN12000 has the latest BIOS I could find on the VIA site: http://www.via.com.tw/en/products/mainboards/downloads.jsp?motherboard_id=3 99#BIOS The riser I have here is called ext-pci rev b and is marked Via Tech Inc. My understanding is that this is not an active riser and requires explicit BIOS support. A quick googling for the device revealed this: http://forums.viaarena.com/messageview.aspx?catid=32threadid=41622highlight_key=ykeyword1=riser A poster here seems to suggest the following: As far as I know the only dual riser card that is supported by the EPIA BIOS is the one from VIA (that faces out). That one has some logic on it to get both slots working. The upper slot uses device 19 and INT_A, allocated through the EPIA BIOS. This may perhaps describe the issue you are having, and from the PDF you linked I do not believe you have a riser that is the same as mine. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel [EMAIL PROTECTED] writes: Yes, VIA Epia EN12000. Interesting to check the riser card. Unfortunately it turns out it's single slot only. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
On Tue, Feb 20, 2007 at 09:47:48PM +0100, Krzysztof Halasa wrote: Udo van den Heuvel [EMAIL PROTECTED] writes: Yes, VIA Epia EN12000. Interesting to check the riser card. Unfortunately it turns out it's single slot only. Via has a dual pci-ext card. See EXT-PCI at http://www.via.com.tw/en/products/mainboards/accessories.jsp -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel [EMAIL PROTECTED] writes: saa7146: found saa7146 @ mem f896a000 (revision 1, irq 145) (0x153b,0x1157). saa7146: found saa7146 @ mem f89e6000 (revision 1, irq 153) (0x153b,0x1155). IO-APICs can do such things... Ok, I have experimented a bit with my old unused EPIA-M 600 MHz MB. INT A, B, C, D - as seen at the MB PCI connector (using PCI-PCI bridge or 4-function device). Device# IDSEL INT (first) 0x08A19 n/a 0x09A20 n/a 0x0AA21 INT C 0x0BA22 n/a 0x0CA23 n/a 0x0DA24 IEEE1394 chip (INT A) 0x0EA25 n/a 0x0FA26 n/a 0x10A27 USB (INT D, A, B, C) 0x11A28 VT823x (11.5 uses INT B so it means INT A, B, C, D) 0x12A29 onboard Ethernet (INT D) 0x13A30 INT D 0x14A31 INT A (the MB PCI slot is wired this way) That's from BIOS summary screen, I haven't bothered to run Linux and check IO-APIC stuff (there may be more than 1 set of 4 INTs). I haven't tested devices 1-7, you can't probably use them anyway. It means that (assuming your MB can use the same riser card as this one), you need the following mapping on the riser: - first slot, device 0x14 (=20), INT lines 1:1 (the same INT and IDSEL wiring as at the motherboard PCI slot) - second slot, device 0x13 (=19), INT lines rotated (device) ABCD - DABC (MB) (i.e., line INT A as seen at the MB PCI slot becomes INT B at the device on the riser card and INT A as seen at the riser slot becomes INT D at the motherboard). Chances are that you could probably use device 0x0A (=10) as well, but it would require another INT rotation (= double rotation). I bet your riser card have the following mapping: device X INTs 1:1 device X+1 INTs (device X+1) ABCD - BCDA (MB = device X) (INT A at the device slot becomes INT B at the MB connector and so on). That means (unless INT rotations are configurable) you have to make some (quite simple, in fact) modifications to the riser card :-( -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
[EMAIL PROTECTED] (Lennart Sorensen) writes: Via has a dual pci-ext card. See EXT-PCI at http://www.via.com.tw/en/products/mainboards/accessories.jsp Right, and they say it's compatible with EPIA mini-ITX family. That means the mappings I just outlined should apply to all of them. BTW: any universal dual+ PCI riser card have to use a PCI bridge chip, and a bridge isn't a small 20 pin IC (I'd expect 144 pins or so). Active or passive - doesn't matter. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: > Udo van den Heuvel <[EMAIL PROTECTED]> writes: > >> At the bottom I added a dmesg output of the kernel after boot. >> I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is >> 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for >> i2c although the card does work perfectly for DVB-T reception (picture, >> low CPU load, etc) with only reception as the bottleneck. > > BTW: Can you check which device # and IRQ does the card get if plugged > directly into the PCI slot on board (without the riser)? BTW: 2.6.18-1.2798.fc6 (Fedora kernel) gave me in dmesg: Linux video capture interface: v2.00 saa7146: register extension 'budget_av'. saa7146: found saa7146 @ mem f896a000 (revision 1, irq 145) (0x153b,0x1157). saa7146 (0): dma buffer size 192512 DVB: registering new adapter (Terratec Cinergy 1200 DVB-T). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff input: PC Speaker as /class/input/input2 KNC1-0: MAC addr = 00:0a:ac:01:d6:87 DVB: registering frontend 0 (Philips TDA10046H DVB-T)... budget-av: ci interface initialised. saa7146: found saa7146 @ mem f89e6000 (revision 1, irq 153) (0x153b,0x1155). saa7146 (1): dma buffer size 192512 DVB: registering new adapter (TerraTec Cinergy 1200 DVB-S). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff KNC1-1: MAC addr = 00:0a:ac:12:93:8d DVB: registering frontend 1 (ST STV0299 DVB-S)... budget-av: ci interface initialised. (irq 145 and 153!?) I think I can do some testing this afternoon. Kind regards, Udo - 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: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: > Udo van den Heuvel <[EMAIL PROTECTED]> writes: > >> At the bottom I added a dmesg output of the kernel after boot. >> I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is >> 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for >> i2c although the card does work perfectly for DVB-T reception (picture, >> low CPU load, etc) with only reception as the bottleneck. > > BTW: Can you check which device # and IRQ does the card get if plugged > directly into the PCI slot on board (without the riser)? DN is 20 I believe (from the tranquilPC doc). irq I'd have to check. > Is it a VIA ITX board? I think I have VIA's riser card somewhere, > could check what it does. Yes, VIA Epia EN12000. Interesting to check the riser card. Udo - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel <[EMAIL PROTECTED]> writes: > At the bottom I added a dmesg output of the kernel after boot. > I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is > 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for > i2c although the card does work perfectly for DVB-T reception (picture, > low CPU load, etc) with only reception as the bottleneck. BTW: Can you check which device # and IRQ does the card get if plugged directly into the PCI slot on board (without the riser)? Is it a VIA ITX board? I think I have VIA's riser card somewhere, could check what it does. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
[EMAIL PROTECTED] (Lennart Sorensen) writes: > The PCI spec doesn't require 4 seperate interrupts. They certainly can > all be the same. I do believe it does require the rotation method on > anything using PCI bridges Correct, PCI-PCI bridges have to rotate their INT lines (used ones only, of course). The BIOS and OS would have no way to know the topology otherwise (especially if the bridge is on a add-on card). > If you > make a mainboard on the other hand you can do whatever you want since > you get to design the firmware that assigns the interrupts. Precisely. > Depends if the riser card is specific to that system, or if it is > supposed to be a generic PCI card. I think a generic card would require a bridge - how would you produce IDSEL signals without a bridge, and without knowledge about the motherboard? If you know the motherboard you know, for example, that is uses A(D)25-31 as IDSELs for on-board devices and A24 for PCI slot. Then you can use, say, A23 for card #1 and reuse A24 (or IDSEL from the mb connector) as IDSEL for card #0. And you know your BIOS will support this. If you don't know the motherboard you don't even know if IDSELs are derived from AD 0->31 or if they are made differently. The BIOS may just support only one device connected directly to the PCI slot. I have never seen a riser card with a bridge, though of course it doesn't mean there aren't any. > It may. But using just INTB and INTD on a card is not allowed by the > spec as far as I understand it. Yep, single function -> INTA, two functions -> INT A+B and so on. > Sure. But if you have a PCI to PCI bridge on a card, then you only get > 4 interrupt lines into the card, and you have to distribute them by the > spec to the chips behind the bridge if you want the system to know how > the interrupts should be used Right. > (although I guess a driver could do its > own thing if it really wanted to). Well, that would be against PCI bridge specs but it probably could. Normally, a special driver for PCI-PCI bridge is not needed. > It does help make sure that if you have 8 devices, each IRQ is used by > only two devices, so the interrupt handler doesn't have too many devices > to check when an interrupt occours. Right. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
On Mon, Feb 19, 2007 at 04:43:55PM +0100, Udo van den Heuvel wrote: > Lennart Sorensen wrote: > > On Mon, Feb 19, 2007 at 05:04:48AM +0100, Udo van den Heuvel wrote: > >> lspci and interrupts at the bottom. yes, we have apic. > > > > Well you could always try to just change the setting > > You mean the Device Number of the riser card? > Or? Yeah the device number. > > to see if you find > > one where the interrupts are happy. If you change the setting by one at > > a time, you should only have to try 4 positions to get one that works > > since that is how many interrupts PCI has. > > So there could (or is) be a relation between interrupt and DN? Well certainly the usual way to layout a PCI bus the interrupt does have to do with the device number. > # lspci > 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro > Host Bridge > (...) > 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) > 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) > 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro > IGP (rev 01) > > Device Numbers can be configured from 12 to 19 but some numbers are > already in use (the number after the initial 00:). That is OK? Just don't use one that is already in use. The link you sent seemed to indicate 20 and 19 were the defaults. That matches with 0x13 and 0x14 so I guess it is. If 00:10 isn't in use you could try that one (device 16). If nothing else uses them, 16, 17, 18, 19 would be worth trying since that should (normally at least) try all the interrupt possibilities. > # lspci -v > 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro > Host Bridge > Subsystem: VIA Technologies, Inc. Unknown device aa08 > Flags: bus master, 66MHz, medium devsel, latency 8 > Memory at e800 (32-bit, prefetchable) [size=128M] > Capabilities: [80] AGP version 3.5 > Capabilities: [50] Power Management version 2 > > 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro > Host Bridge > Flags: bus master, medium devsel, latency 0 > > 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro > Host Bridge > Flags: bus master, medium devsel, latency 0 > > 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge > Flags: bus master, medium devsel, latency 0 > > 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro > Host Bridge > Flags: bus master, medium devsel, latency 0 > > 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro > Host Bridge > Flags: bus master, medium devsel, latency 0 > > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 > [Normal decode]) > Flags: bus master, 66MHz, medium devsel, latency 0 > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 > I/O behind bridge: b000-bfff > Memory behind bridge: fb00-fcff > Prefetchable memory behind bridge: f400-f7ff > Capabilities: [70] Power Management version 2 > > 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host > Controller (rev 80) (prog-if 10 [OHCI]) > Subsystem: VIA Technologies, Inc. IEEE 1394 Host Controller > Flags: bus master, stepping, medium devsel, latency 32, IRQ 20 > Memory at fdfff000 (32-bit, non-prefetchable) [size=2K] > I/O ports at fc00 [size=128] > Capabilities: [50] Power Management version 2 > > 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 > Gigabit Ethernet Adapter (rev 11) > Subsystem: VIA Technologies, Inc. Unknown device 0110 > Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 17 > I/O ports at f800 [size=256] > Memory at fdffe000 (32-bit, non-prefetchable) [size=256] > Capabilities: [50] Power Management version 2 > > 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID > Controller (rev 80) (prog-if 8f [Master SecP SecO PriP PriO]) > Subsystem: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller > Flags: bus master, medium devsel, latency 32, IRQ 18 > I/O ports at f400 [size=8] > I/O ports at f000 [size=4] > I/O ports at ec00 [size=8] > I/O ports at e800 [size=4] > I/O ports at e400 [size=16] > I/O ports at e000 [size=256] > Capabilities: [c0] Power Management version 2 > > 00:0f.1 IDE interface: VIA Technologies, Inc. > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) > (prog-if 8a [Master SecP PriP]) > Subsystem: VIA Technologies, Inc. > VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE > Flags: bus master, medium devsel, latency 32, IRQ 18 > [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8] > [virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1] >
Re: PCI riser cards and PCI irq routing, etc
Lennart Sorensen wrote: > On Mon, Feb 19, 2007 at 05:04:48AM +0100, Udo van den Heuvel wrote: >> lspci and interrupts at the bottom. yes, we have apic. > > Well you could always try to just change the setting You mean the Device Number of the riser card? Or? > to see if you find > one where the interrupts are happy. If you change the setting by one at > a time, you should only have to try 4 positions to get one that works > since that is how many interrupts PCI has. So there could (or is) be a relation between interrupt and DN? # lspci 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge (...) 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01) Device Numbers can be configured from 12 to 19 but some numbers are already in use (the number after the initial 00:). That is OK? >> The info: >> >> 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro >> Host Bridge (...) > You need lspci -v to get interrupt information. # lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Subsystem: VIA Technologies, Inc. Unknown device aa08 Flags: bus master, 66MHz, medium devsel, latency 8 Memory at e800 (32-bit, prefetchable) [size=128M] Capabilities: [80] AGP version 3.5 Capabilities: [50] Power Management version 2 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge Flags: bus master, medium devsel, latency 0 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: b000-bfff Memory behind bridge: fb00-fcff Prefetchable memory behind bridge: f400-f7ff Capabilities: [70] Power Management version 2 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. IEEE 1394 Host Controller Flags: bus master, stepping, medium devsel, latency 32, IRQ 20 Memory at fdfff000 (32-bit, non-prefetchable) [size=2K] I/O ports at fc00 [size=128] Capabilities: [50] Power Management version 2 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) Subsystem: VIA Technologies, Inc. Unknown device 0110 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 17 I/O ports at f800 [size=256] Memory at fdffe000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller Flags: bus master, medium devsel, latency 32, IRQ 18 I/O ports at f400 [size=8] I/O ports at f000 [size=4] I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=16] I/O ports at e000 [size=256] Capabilities: [c0] Power Management version 2 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE Flags: bus master, medium devsel, latency 32, IRQ 18 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [size=1] I/O ports at dc00 [size=16] Capabilities: [c0] Power Management version 2 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at d800 [size=32] Capabilities: [80] Power Management version 2 00:10.1 USB Controller: VIA
Re: PCI riser cards and PCI irq routing, etc
On Mon, Feb 19, 2007 at 05:04:48AM +0100, Udo van den Heuvel wrote: > lspci and interrupts at the bottom. yes, we have apic. Well you could always try to just change the setting to see if you find one where the interrupts are happy. If you change the setting by one at a time, you should only have to try 4 positions to get one that works since that is how many interrupts PCI has. > The EN12000 is equipped with a PCI riser like the one here: > http://www.tranquilpc-shop.co.uk/acatalog/info%5f2%2ehtml > Please also see > http://www.tranquilpc-shop.co.uk/acatalog/PCI_Risers.html and > http://www.tranquilpc.co.uk/support/Files/TPC014/Tranquil%20Riser.pdf > for info about how the riser works. > > > I guess it is possible the card does something weird and the IRQs for > > both cards have to actually be the same. If that is the case you could > > make the kernel change the IRQ assigned to the second card before > > loading the driver. Or you could do it from the boot loader or > > something (The system I work with has a stupid bios that doesn't have a > > clue about bridges, so we added IRQ fixup code to grub to deal with all > > PCI bridges before booting the system). > > Ah, this sounds interesting. > Any pointers about hwo to do this? Well reasonably you shouldn't have to. > I will give the change a try. > > The info: > > 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro > Host Bridge > 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro > Host Bridge > 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro > Host Bridge > 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge > 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro > Host Bridge > 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro > Host Bridge > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge > 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host > Controller (rev 80) > 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 > Gigabit Ethernet Adapter (rev 11) > 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID > Controller (rev 80) > 00:0f.1 IDE interface: VIA Technologies, Inc. > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) > 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 > Controller (rev 81) > 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 > Controller (rev 81) > 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 > Controller (rev 81) > 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) > 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge > [KT600/K8T800/K8T890 South] > 00:11.5 Multimedia audio controller: VIA Technologies, Inc. > VT8233/A/8235/8237 AC97 Audio Controller (rev 60) > 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) > 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) > 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro > IGP (rev 01) You need lspci -v to get interrupt information. > CPU0 > 0: 15939569 IO-APIC-edge timer > 1: 36 IO-APIC-edge i8042 > 8: 1 IO-APIC-edge rtc > 9: 0 IO-APIC-fasteoi acpi > 12:222 IO-APIC-edge i8042 > 14: 570999 IO-APIC-edge ide0 > 16:3166202 IO-APIC-fasteoi saa7146 (0), [EMAIL > PROTECTED]::01:00.0 > 17:2619374 IO-APIC-fasteoi eth0 > 18: 402194 IO-APIC-fasteoi libata > 19: 0 IO-APIC-fasteoi uhci_hcd:usb1, uhci_hcd:usb2, > uhci_hcd:usb3, ehci_hcd:usb4 > 20: 2 IO-APIC-fasteoi saa7146 (1), ohci1394 > 21:2768193 IO-APIC-fasteoi VIA8237 > NMI: 0 > LOC: 15938827 > ERR: 0 > MIS: 0 That unfortunately only shows interrupts in use by active drivers. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
Lennart Sorensen wrote: >> So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no >> communication with the DVB-T card (the frontend), so there is no >> /dev/dvb/* entry. This points to an IRQ problem. > > Any documentation on that riser card? > > I guess it is possible the card does something weird and the IRQs for > both cards have to actually be the same. If that is the case you could > make the kernel change the IRQ assigned to the second card before > loading the driver. Or you could do it from the boot loader or > something (The system I work with has a stupid bios that doesn't have a > clue about bridges, so we added IRQ fixup code to grub to deal with all > PCI bridges before booting the system). Example patches or other ways to handle such situations are welcome. I hope there is a 'standard' way to deal with this. I asked TranquilPC about the card. I am waiting for an answer. Can I do some tests to find out the real irq's myself? >> If it is different from what Linux thinks: how do I tell Linux? > > Linux doesn't think anything. It goes by the IRQ assigned to the > device, which is in one of the PCI registers on each device. You can > change those registers though, and then it should use the new value > (although you may have to change it from the kernel before it enumerates > the pci devices). I.e.: patching. >> I set the BIOS for 'PnP OS installed'. Should I change that? > > I would NEVER do that. That actually disables the BIOS from doing Changing teh setting did not change the irq assignment: # cat /proc/interrupts CPU0 0: 97145 IO-APIC-edge timer 1: 8 IO-APIC-edge i8042 8: 1 IO-APIC-edge rtc 9: 0 IO-APIC-fasteoi acpi 12:105 IO-APIC-edge i8042 14: 3063 IO-APIC-edge ide0 16: 0 IO-APIC-fasteoi saa7146 (0) 17: 1337 IO-APIC-fasteoi eth0 18: 9993 IO-APIC-fasteoi libata 19: 0 IO-APIC-fasteoi uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, ehci_hcd:usb4 20: 2 IO-APIC-fasteoi ohci1394, saa7146 (1) 21: 0 IO-APIC-fasteoi VIA8237 NMI: 0 LOC: 97086 ERR: 0 MIS: 0 At the bottom I added a dmesg output of the kernel after boot. I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for i2c although the card does work perfectly for DVB-T reception (picture, low CPU load, etc) with only reception as the bottleneck. How can I proceed to test for the right irq for card saa7146 (0)? Any ideas? Kind regards, Udo Linux version 2.6.20i2c ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 PREEMPT Fri Feb 16 17:39:51 CET 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009f800 end: 0009f800 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009f800 size: 0800 end: 000a type: 2 copy_e820_map() start: 000f size: 0001 end: 0010 type: 2 copy_e820_map() start: 0010 size: 3bef end: 3bff type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 3bff size: 3000 end: 3bff3000 type: 4 copy_e820_map() start: 3bff3000 size: d000 end: 3c00 type: 3 copy_e820_map() start: fec0 size: 1000 end: fec01000 type: 2 copy_e820_map() start: fee0 size: 1000 end: fee01000 type: 2 copy_e820_map() start: size: 0001 end: 0001 type: 2 BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3bff (usable) BIOS-e820: 3bff - 3bff3000 (ACPI NVS) BIOS-e820: 3bff3000 - 3c00 (ACPI data) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) Warning only 896MB will be used. Use a HIGHMEM enabled kernel. 896MB LOWMEM available. found SMP MP-table at 000f3800 Entering add_active_range(0, 0, 229376) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 early_node_map[1] active PFN ranges 0:0 -> 229376 On node 0 totalpages: 229376 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 P4M80P) @ 0x000f7970 ACPI: RSDT (v001 P4M80P AWRDACPI 0x42302e31 AWRD 0x) @
Re: PCI riser cards and PCI irq routing, etc
On Sun, Feb 18, 2007 at 09:42:26PM +0100, Krzysztof Halasa wrote: > [EMAIL PROTECTED] (Lennart Sorensen) writes: > > > My understanding (which is better of verified against the specs) is: > > > > PCI interrupts (PCI INTA to INTD) are rotated for every slot by one. So > > slot 0, 4, 8, etc see INTA->realINTA, INTB->realINTB. INTC->realINTC, > > INTD->realINTD > > slot 1, 5, 9, etc see INTA->realINTB, INTB->realINTC. INTC->realINTD, > > INTD->realINTA > > slot 2, 6, 10, etc see INTA->realINTC, INTB->realINTD. INTC->realINTA, > > INTD->realINTB > > slot 3, 7, 11, etc see INTA->realINTD, INTB->realINTA. INTC->realINTB, > > INTD->realINTC > > This is common and suggested practice but the PCI specs don't require > it. There is no rule - you can, for example, have all INT lines > connected to a single CPU IRQ input. The PCI spec doesn't require 4 seperate interrupts. They certainly can all be the same. I do believe it does require the rotation method on anything using PCI bridges and such if you want your card to work in PCI compliant systems since that is how they will assume the lines are routed and hence will assume that is how to set the interrupts. If you make a mainboard on the other hand you can do whatever you want since you get to design the firmware that assigns the interrupts. > Anyway, something has to know how the IRQs are routed. BIOS, other > firmware, Linux. > > Actually it has to be wired consistently with the BIOS (which is > probably consistent with chipset manufacturer's instructions). Depends if the riser card is specific to that system, or if it is supposed to be a generic PCI card. > Usually they are just bus splitters, they route IRQs and IDSELs > (and maybe JTAG) as required by the BIOS, all others pins are > connected 1:1. > > I.e., they are completely transparent, generally comply to PCI specs > and are dedicated to a specific motherboard(s). Well dedicated hardware would be different. Of course if it is dedicated the BIOS better do the right thing when configuring it. > Actually I think (would have to check the specs for sure) every > subdevice (function) may use just one interrupt line. It may. But using just INTB and INTD on a card is not allowed by the spec as far as I understand it. > This rotating INTx scheme is common because it's cheap. There are > systems which support more than 4 shared INTs per bus, for example > you can have different sets of 4 INTx lines for every PCI slot, even > if all slots are on the same PCI bus. Sure. But if you have a PCI to PCI bridge on a card, then you only get 4 interrupt lines into the card, and you have to distribute them by the spec to the chips behind the bridge if you want the system to know how the interrupts should be used (although I guess a driver could do its own thing if it really wanted to). > Correct. This scheme assumes at most 4 single-function devices > on the bus, otherwise INTs are shared. It does help make sure that if you have 8 devices, each IRQ is used by only two devices, so the interrupt handler doesn't have too many devices to check when an interrupt occours. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
On Sun, Feb 18, 2007 at 09:42:26PM +0100, Krzysztof Halasa wrote: [EMAIL PROTECTED] (Lennart Sorensen) writes: My understanding (which is better of verified against the specs) is: PCI interrupts (PCI INTA to INTD) are rotated for every slot by one. So slot 0, 4, 8, etc see INTA-realINTA, INTB-realINTB. INTC-realINTC, INTD-realINTD slot 1, 5, 9, etc see INTA-realINTB, INTB-realINTC. INTC-realINTD, INTD-realINTA slot 2, 6, 10, etc see INTA-realINTC, INTB-realINTD. INTC-realINTA, INTD-realINTB slot 3, 7, 11, etc see INTA-realINTD, INTB-realINTA. INTC-realINTB, INTD-realINTC This is common and suggested practice but the PCI specs don't require it. There is no rule - you can, for example, have all INT lines connected to a single CPU IRQ input. The PCI spec doesn't require 4 seperate interrupts. They certainly can all be the same. I do believe it does require the rotation method on anything using PCI bridges and such if you want your card to work in PCI compliant systems since that is how they will assume the lines are routed and hence will assume that is how to set the interrupts. If you make a mainboard on the other hand you can do whatever you want since you get to design the firmware that assigns the interrupts. Anyway, something has to know how the IRQs are routed. BIOS, other firmware, Linux. Actually it has to be wired consistently with the BIOS (which is probably consistent with chipset manufacturer's instructions). Depends if the riser card is specific to that system, or if it is supposed to be a generic PCI card. Usually they are just bus splitters, they route IRQs and IDSELs (and maybe JTAG) as required by the BIOS, all others pins are connected 1:1. I.e., they are completely transparent, generally comply to PCI specs and are dedicated to a specific motherboard(s). Well dedicated hardware would be different. Of course if it is dedicated the BIOS better do the right thing when configuring it. Actually I think (would have to check the specs for sure) every subdevice (function) may use just one interrupt line. It may. But using just INTB and INTD on a card is not allowed by the spec as far as I understand it. This rotating INTx scheme is common because it's cheap. There are systems which support more than 4 shared INTs per bus, for example you can have different sets of 4 INTx lines for every PCI slot, even if all slots are on the same PCI bus. Sure. But if you have a PCI to PCI bridge on a card, then you only get 4 interrupt lines into the card, and you have to distribute them by the spec to the chips behind the bridge if you want the system to know how the interrupts should be used (although I guess a driver could do its own thing if it really wanted to). Correct. This scheme assumes at most 4 single-function devices on the bus, otherwise INTs are shared. It does help make sure that if you have 8 devices, each IRQ is used by only two devices, so the interrupt handler doesn't have too many devices to check when an interrupt occours. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
Lennart Sorensen wrote: So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no communication with the DVB-T card (the frontend), so there is no /dev/dvb/* entry. This points to an IRQ problem. Any documentation on that riser card? I guess it is possible the card does something weird and the IRQs for both cards have to actually be the same. If that is the case you could make the kernel change the IRQ assigned to the second card before loading the driver. Or you could do it from the boot loader or something (The system I work with has a stupid bios that doesn't have a clue about bridges, so we added IRQ fixup code to grub to deal with all PCI bridges before booting the system). Example patches or other ways to handle such situations are welcome. I hope there is a 'standard' way to deal with this. I asked TranquilPC about the card. I am waiting for an answer. Can I do some tests to find out the real irq's myself? If it is different from what Linux thinks: how do I tell Linux? Linux doesn't think anything. It goes by the IRQ assigned to the device, which is in one of the PCI registers on each device. You can change those registers though, and then it should use the new value (although you may have to change it from the kernel before it enumerates the pci devices). I.e.: patching. I set the BIOS for 'PnP OS installed'. Should I change that? I would NEVER do that. That actually disables the BIOS from doing Changing teh setting did not change the irq assignment: # cat /proc/interrupts CPU0 0: 97145 IO-APIC-edge timer 1: 8 IO-APIC-edge i8042 8: 1 IO-APIC-edge rtc 9: 0 IO-APIC-fasteoi acpi 12:105 IO-APIC-edge i8042 14: 3063 IO-APIC-edge ide0 16: 0 IO-APIC-fasteoi saa7146 (0) 17: 1337 IO-APIC-fasteoi eth0 18: 9993 IO-APIC-fasteoi libata 19: 0 IO-APIC-fasteoi uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, ehci_hcd:usb4 20: 2 IO-APIC-fasteoi ohci1394, saa7146 (1) 21: 0 IO-APIC-fasteoi VIA8237 NMI: 0 LOC: 97086 ERR: 0 MIS: 0 At the bottom I added a dmesg output of the kernel after boot. I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for i2c although the card does work perfectly for DVB-T reception (picture, low CPU load, etc) with only reception as the bottleneck. How can I proceed to test for the right irq for card saa7146 (0)? Any ideas? Kind regards, Udo Linux version 2.6.20i2c ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 PREEMPT Fri Feb 16 17:39:51 CET 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009f800 end: 0009f800 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009f800 size: 0800 end: 000a type: 2 copy_e820_map() start: 000f size: 0001 end: 0010 type: 2 copy_e820_map() start: 0010 size: 3bef end: 3bff type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 3bff size: 3000 end: 3bff3000 type: 4 copy_e820_map() start: 3bff3000 size: d000 end: 3c00 type: 3 copy_e820_map() start: fec0 size: 1000 end: fec01000 type: 2 copy_e820_map() start: fee0 size: 1000 end: fee01000 type: 2 copy_e820_map() start: size: 0001 end: 0001 type: 2 BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3bff (usable) BIOS-e820: 3bff - 3bff3000 (ACPI NVS) BIOS-e820: 3bff3000 - 3c00 (ACPI data) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) Warning only 896MB will be used. Use a HIGHMEM enabled kernel. 896MB LOWMEM available. found SMP MP-table at 000f3800 Entering add_active_range(0, 0, 229376) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 229376 early_node_map[1] active PFN ranges 0:0 - 229376 On node 0 totalpages: 229376 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 P4M80P) @ 0x000f7970 ACPI: RSDT (v001 P4M80P AWRDACPI 0x42302e31 AWRD 0x) @ 0x3bff3040 ACPI: FADT (v001 P4M80P
Re: PCI riser cards and PCI irq routing, etc
On Mon, Feb 19, 2007 at 05:04:48AM +0100, Udo van den Heuvel wrote: lspci and interrupts at the bottom. yes, we have apic. Well you could always try to just change the setting to see if you find one where the interrupts are happy. If you change the setting by one at a time, you should only have to try 4 positions to get one that works since that is how many interrupts PCI has. The EN12000 is equipped with a PCI riser like the one here: http://www.tranquilpc-shop.co.uk/acatalog/info%5f2%2ehtml Please also see http://www.tranquilpc-shop.co.uk/acatalog/PCI_Risers.html and http://www.tranquilpc.co.uk/support/Files/TPC014/Tranquil%20Riser.pdf for info about how the riser works. I guess it is possible the card does something weird and the IRQs for both cards have to actually be the same. If that is the case you could make the kernel change the IRQ assigned to the second card before loading the driver. Or you could do it from the boot loader or something (The system I work with has a stupid bios that doesn't have a clue about bridges, so we added IRQ fixup code to grub to deal with all PCI bridges before booting the system). Ah, this sounds interesting. Any pointers about hwo to do this? Well reasonably you shouldn't have to. I will give the change a try. The info: 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01) You need lspci -v to get interrupt information. CPU0 0: 15939569 IO-APIC-edge timer 1: 36 IO-APIC-edge i8042 8: 1 IO-APIC-edge rtc 9: 0 IO-APIC-fasteoi acpi 12:222 IO-APIC-edge i8042 14: 570999 IO-APIC-edge ide0 16:3166202 IO-APIC-fasteoi saa7146 (0), [EMAIL PROTECTED]::01:00.0 17:2619374 IO-APIC-fasteoi eth0 18: 402194 IO-APIC-fasteoi libata 19: 0 IO-APIC-fasteoi uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, ehci_hcd:usb4 20: 2 IO-APIC-fasteoi saa7146 (1), ohci1394 21:2768193 IO-APIC-fasteoi VIA8237 NMI: 0 LOC: 15938827 ERR: 0 MIS: 0 That unfortunately only shows interrupts in use by active drivers. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
Lennart Sorensen wrote: On Mon, Feb 19, 2007 at 05:04:48AM +0100, Udo van den Heuvel wrote: lspci and interrupts at the bottom. yes, we have apic. Well you could always try to just change the setting You mean the Device Number of the riser card? Or? to see if you find one where the interrupts are happy. If you change the setting by one at a time, you should only have to try 4 positions to get one that works since that is how many interrupts PCI has. So there could (or is) be a relation between interrupt and DN? # lspci 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge (...) 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01) Device Numbers can be configured from 12 to 19 but some numbers are already in use (the number after the initial 00:). That is OK? The info: 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge (...) You need lspci -v to get interrupt information. # lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Subsystem: VIA Technologies, Inc. Unknown device aa08 Flags: bus master, 66MHz, medium devsel, latency 8 Memory at e800 (32-bit, prefetchable) [size=128M] Capabilities: [80] AGP version 3.5 Capabilities: [50] Power Management version 2 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge Flags: bus master, medium devsel, latency 0 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: b000-bfff Memory behind bridge: fb00-fcff Prefetchable memory behind bridge: f400-f7ff Capabilities: [70] Power Management version 2 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. IEEE 1394 Host Controller Flags: bus master, stepping, medium devsel, latency 32, IRQ 20 Memory at fdfff000 (32-bit, non-prefetchable) [size=2K] I/O ports at fc00 [size=128] Capabilities: [50] Power Management version 2 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) Subsystem: VIA Technologies, Inc. Unknown device 0110 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 17 I/O ports at f800 [size=256] Memory at fdffe000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller Flags: bus master, medium devsel, latency 32, IRQ 18 I/O ports at f400 [size=8] I/O ports at f000 [size=4] I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=16] I/O ports at e000 [size=256] Capabilities: [c0] Power Management version 2 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE Flags: bus master, medium devsel, latency 32, IRQ 18 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [size=1] I/O ports at dc00 [size=16] Capabilities: [c0] Power Management version 2 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller Flags: bus master, medium devsel, latency 32, IRQ 19 I/O ports at d800 [size=32] Capabilities: [80] Power Management version 2 00:10.1 USB Controller: VIA Technologies, Inc.
Re: PCI riser cards and PCI irq routing, etc
On Mon, Feb 19, 2007 at 04:43:55PM +0100, Udo van den Heuvel wrote: Lennart Sorensen wrote: On Mon, Feb 19, 2007 at 05:04:48AM +0100, Udo van den Heuvel wrote: lspci and interrupts at the bottom. yes, we have apic. Well you could always try to just change the setting You mean the Device Number of the riser card? Or? Yeah the device number. to see if you find one where the interrupts are happy. If you change the setting by one at a time, you should only have to try 4 positions to get one that works since that is how many interrupts PCI has. So there could (or is) be a relation between interrupt and DN? Well certainly the usual way to layout a PCI bus the interrupt does have to do with the device number. # lspci 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge (...) 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01) Device Numbers can be configured from 12 to 19 but some numbers are already in use (the number after the initial 00:). That is OK? Just don't use one that is already in use. The link you sent seemed to indicate 20 and 19 were the defaults. That matches with 0x13 and 0x14 so I guess it is. If 00:10 isn't in use you could try that one (device 16). If nothing else uses them, 16, 17, 18, 19 would be worth trying since that should (normally at least) try all the interrupt possibilities. # lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Subsystem: VIA Technologies, Inc. Unknown device aa08 Flags: bus master, 66MHz, medium devsel, latency 8 Memory at e800 (32-bit, prefetchable) [size=128M] Capabilities: [80] AGP version 3.5 Capabilities: [50] Power Management version 2 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge Flags: bus master, medium devsel, latency 0 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge Flags: bus master, medium devsel, latency 0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: b000-bfff Memory behind bridge: fb00-fcff Prefetchable memory behind bridge: f400-f7ff Capabilities: [70] Power Management version 2 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. IEEE 1394 Host Controller Flags: bus master, stepping, medium devsel, latency 32, IRQ 20 Memory at fdfff000 (32-bit, non-prefetchable) [size=2K] I/O ports at fc00 [size=128] Capabilities: [50] Power Management version 2 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) Subsystem: VIA Technologies, Inc. Unknown device 0110 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 17 I/O ports at f800 [size=256] Memory at fdffe000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller Flags: bus master, medium devsel, latency 32, IRQ 18 I/O ports at f400 [size=8] I/O ports at f000 [size=4] I/O ports at ec00 [size=8] I/O ports at e800 [size=4] I/O ports at e400 [size=16] I/O ports at e000 [size=256] Capabilities: [c0] Power Management version 2 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc. VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE Flags: bus master, medium devsel, latency 32, IRQ 18 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 0370 (type 3,
Re: PCI riser cards and PCI irq routing, etc
[EMAIL PROTECTED] (Lennart Sorensen) writes: The PCI spec doesn't require 4 seperate interrupts. They certainly can all be the same. I do believe it does require the rotation method on anything using PCI bridges Correct, PCI-PCI bridges have to rotate their INT lines (used ones only, of course). The BIOS and OS would have no way to know the topology otherwise (especially if the bridge is on a add-on card). If you make a mainboard on the other hand you can do whatever you want since you get to design the firmware that assigns the interrupts. Precisely. Depends if the riser card is specific to that system, or if it is supposed to be a generic PCI card. I think a generic card would require a bridge - how would you produce IDSEL signals without a bridge, and without knowledge about the motherboard? If you know the motherboard you know, for example, that is uses A(D)25-31 as IDSELs for on-board devices and A24 for PCI slot. Then you can use, say, A23 for card #1 and reuse A24 (or IDSEL from the mb connector) as IDSEL for card #0. And you know your BIOS will support this. If you don't know the motherboard you don't even know if IDSELs are derived from AD 0-31 or if they are made differently. The BIOS may just support only one device connected directly to the PCI slot. I have never seen a riser card with a bridge, though of course it doesn't mean there aren't any. It may. But using just INTB and INTD on a card is not allowed by the spec as far as I understand it. Yep, single function - INTA, two functions - INT A+B and so on. Sure. But if you have a PCI to PCI bridge on a card, then you only get 4 interrupt lines into the card, and you have to distribute them by the spec to the chips behind the bridge if you want the system to know how the interrupts should be used Right. (although I guess a driver could do its own thing if it really wanted to). Well, that would be against PCI bridge specs but it probably could. Normally, a special driver for PCI-PCI bridge is not needed. It does help make sure that if you have 8 devices, each IRQ is used by only two devices, so the interrupt handler doesn't have too many devices to check when an interrupt occours. Right. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel [EMAIL PROTECTED] writes: At the bottom I added a dmesg output of the kernel after boot. I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for i2c although the card does work perfectly for DVB-T reception (picture, low CPU load, etc) with only reception as the bottleneck. BTW: Can you check which device # and IRQ does the card get if plugged directly into the PCI slot on board (without the riser)? Is it a VIA ITX board? I think I have VIA's riser card somewhere, could check what it does. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: Udo van den Heuvel [EMAIL PROTECTED] writes: At the bottom I added a dmesg output of the kernel after boot. I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for i2c although the card does work perfectly for DVB-T reception (picture, low CPU load, etc) with only reception as the bottleneck. BTW: Can you check which device # and IRQ does the card get if plugged directly into the PCI slot on board (without the riser)? DN is 20 I believe (from the tranquilPC doc). irq I'd have to check. Is it a VIA ITX board? I think I have VIA's riser card somewhere, could check what it does. Yes, VIA Epia EN12000. Interesting to check the riser card. Udo - 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: PCI riser cards and PCI irq routing, etc
Krzysztof Halasa wrote: Udo van den Heuvel [EMAIL PROTECTED] writes: At the bottom I added a dmesg output of the kernel after boot. I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for i2c although the card does work perfectly for DVB-T reception (picture, low CPU load, etc) with only reception as the bottleneck. BTW: Can you check which device # and IRQ does the card get if plugged directly into the PCI slot on board (without the riser)? BTW: 2.6.18-1.2798.fc6 (Fedora kernel) gave me in dmesg: Linux video capture interface: v2.00 saa7146: register extension 'budget_av'. saa7146: found saa7146 @ mem f896a000 (revision 1, irq 145) (0x153b,0x1157). saa7146 (0): dma buffer size 192512 DVB: registering new adapter (Terratec Cinergy 1200 DVB-T). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff input: PC Speaker as /class/input/input2 KNC1-0: MAC addr = 00:0a:ac:01:d6:87 DVB: registering frontend 0 (Philips TDA10046H DVB-T)... budget-av: ci interface initialised. saa7146: found saa7146 @ mem f89e6000 (revision 1, irq 153) (0x153b,0x1155). saa7146 (1): dma buffer size 192512 DVB: registering new adapter (TerraTec Cinergy 1200 DVB-S). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff KNC1-1: MAC addr = 00:0a:ac:12:93:8d DVB: registering frontend 1 (ST STV0299 DVB-S)... budget-av: ci interface initialised. (irq 145 and 153!?) I think I can do some testing this afternoon. Kind regards, Udo - 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: PCI riser cards and PCI irq routing, etc
Lennart Sorensen wrote: > On Sun, Feb 18, 2007 at 05:15:30PM +0100, Udo van den Heuvel wrote: >> FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser >> where only the Device Number can be changed. >> The kernel sees the two DVB cards in there as: >> >> saa7146: register extension 'budget_av'. >> ACPI: PCI Interrupt :00:13.0[A] -> GSI 16 (level, low) -> IRQ 16 >> saa7146: found saa7146 @ mem f8c3e000 (revision 1, irq 16) (0x153b,0x1157). >> saa7146 (0): dma buffer size 192512 >> DVB: registering new adapter (Terratec Cinergy 1200 DVB-T). >> adapter failed MAC signature check >> encoded MAC from EEPROM was >> ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff >> KNC1-0: MAC addr = 00:0a:ac:01:d6:87 >> DVB: registering frontend 0 (Philips TDA10046H DVB-T)... >> budget-av: ci interface initialised. >> ACPI: PCI Interrupt :00:14.0[A] -> GSI 17 (level, low) -> IRQ 20 >> saa7146: found saa7146 @ mem f8cb2000 (revision 1, irq 20) (0x153b,0x1155). >> saa7146 (1): dma buffer size 192512 >> DVB: registering new adapter (TerraTec Cinergy 1200 DVB-S). >> adapter failed MAC signature check >> encoded MAC from EEPROM was >> ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff >> sd 0:0:0:0: Attached scsi generic sg0 type 0 >> KNC1-1: MAC addr = 00:0a:ac:12:93:8d >> DVB: registering frontend 1 (ST STV0299 DVB-S)... >> budget-av: ci interface initialised. > > Well it says they are slot 13 and 14. What other pci devices are > present in the system and what irq's are they using? lspci and interrupts at the bottom. yes, we have apic. >> So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no >> communication with the DVB-T card (the frontend), so there is no >> /dev/dvb/* entry. This points to an IRQ problem. > > Any documentation on that riser card? The EN12000 is equipped with a PCI riser like the one here: http://www.tranquilpc-shop.co.uk/acatalog/info%5f2%2ehtml Please also see http://www.tranquilpc-shop.co.uk/acatalog/PCI_Risers.html and http://www.tranquilpc.co.uk/support/Files/TPC014/Tranquil%20Riser.pdf for info about how the riser works. > I guess it is possible the card does something weird and the IRQs for > both cards have to actually be the same. If that is the case you could > make the kernel change the IRQ assigned to the second card before > loading the driver. Or you could do it from the boot loader or > something (The system I work with has a stupid bios that doesn't have a > clue about bridges, so we added IRQ fixup code to grub to deal with all > PCI bridges before booting the system). Ah, this sounds interesting. Any pointers about hwo to do this? >> I set the BIOS for 'PnP OS installed'. Should I change that? () > It might actually work better if you change that, although it may also > just make no difference. I will give the change a try. The info: 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01) CPU0 0: 15939569 IO-APIC-edge timer 1: 36 IO-APIC-edge i8042 8: 1 IO-APIC-edge rtc 9: 0 IO-APIC-fasteoi acpi 12:222 IO-APIC-edge i8042 14: 570999 IO-APIC-edge ide0 16:3166202 IO-APIC-fasteoi saa7146 (0), [EMAIL PROTECTED]::01:00.0 17:2619374 IO-APIC-fasteoi eth0 18: 402194 IO-APIC-fasteoi libata 19:
Re: PCI riser cards and PCI irq routing, etc
On Sunday 18 February 2007 19:39, Lennart Sorensen wrote: [snip] > > > On a PC, the BIOS is supposed to assign interrupts to devices based on > > > those rules, since that is how the hardware must be done according to > > > the PCI specifications. > > > > I set the BIOS for 'PnP OS installed'. Should I change that? > > I would NEVER do that. That actually disables the BIOS from doing > configuration of most hardware since it really means "Microsoft wants to > do configuration themselves and asked us to put in a setting to make the > bios only configure drive controllers and sound cards". I know some > people have worked towards making linux a "PnP OS" by microsoft > standards, but whether it is entirely there or not by now I am not sure. > Fortunately most motherboards I have ever bought come preset at 'pnp os > installed' off, which is how I like it. I have had a number of > problems on systems with that setting on, which went away when the > setting was set back to off. I think this option actually _used_ to mean whether the BIOS would _provide_ PNP services to the host OS, allowing it to detect peripherals like parallel ports, etc. In reality, very few devices on modern PCs use or require BIOS PNP support, and in some situations it's just annoying (for example, disabling the parallel port on my Thinkpad has no effect because Linux just uses PNP to redetect it). > It might actually work better if you change that, although it may also > just make no difference. In my experience it just makes no difference. I strongly doubt the option has _anything_ to do with this problem. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel <[EMAIL PROTECTED]> writes: > FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser > where only the Device Number can be changed. With jumpers? > So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no > communication with the DVB-T card (the frontend), so there is no > /dev/dvb/* entry. This points to an IRQ problem. > > How can I find out the actual IRQ that the card is using? I would remove the PCI cards and then the riser card and check INT routing with a multimeter. Perhaps a task for someone used to stuff like that. > I set the BIOS for 'PnP OS installed'. Should I change that? Most drivers already enable devices so it probably doesn't matter. I would check it, though. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
[EMAIL PROTECTED] (Lennart Sorensen) writes: > My understanding (which is better of verified against the specs) is: > > PCI interrupts (PCI INTA to INTD) are rotated for every slot by one. So > slot 0, 4, 8, etc see INTA->realINTA, INTB->realINTB. INTC->realINTC, > INTD->realINTD > slot 1, 5, 9, etc see INTA->realINTB, INTB->realINTC. INTC->realINTD, > INTD->realINTA > slot 2, 6, 10, etc see INTA->realINTC, INTB->realINTD. INTC->realINTA, > INTD->realINTB > slot 3, 7, 11, etc see INTA->realINTD, INTB->realINTA. INTC->realINTB, > INTD->realINTC This is common and suggested practice but the PCI specs don't require it. There is no rule - you can, for example, have all INT lines connected to a single CPU IRQ input. > On a PC, the BIOS is supposed to assign interrupts to devices based on > those rules, since that is how the hardware must be done according to > the PCI specifications. On other platforms the firmware may or may not > handle it. Anyway, something has to know how the IRQs are routed. BIOS, other firmware, Linux. > So as long as the riser board is wired according to the PCI bridge > rules, Actually it has to be wired consistently with the BIOS (which is probably consistent with chipset manufacturer's instructions). > Of course if the > riser card is NOT a proper pci bridge, but rather some weird device, > well then it probably isn't even PCI complient and who knows how it > shold be handled. Usually they are just bus splitters, they route IRQs and IDSELs (and maybe JTAG) as required by the BIOS, all others pins are connected 1:1. I.e., they are completely transparent, generally comply to PCI specs and are dedicated to a specific motherboard(s). > Interrupts for PCI are assigned based on the 4 shared interrupts line on > PCI, not really per device. A PCI device may use up to 4 interrupts if > it wants to, and is supposed to always use interrupt A (as seen from > it's slot) as the first interrupt. Actually I think (would have to check the specs for sure) every subdevice (function) may use just one interrupt line. This rotating INTx scheme is common because it's cheap. There are systems which support more than 4 shared INTs per bus, for example you can have different sets of 4 INTx lines for every PCI slot, even if all slots are on the same PCI bus. > The rotating assignment of the 4 > interrupts to the slots are supposed to help balance the distribution of > the interrupts between devices in the system, so that although they are > shared interrupts, as few devices as possible get assigned to each > interrupt. Correct. This scheme assumes at most 4 single-function devices on the bus, otherwise INTs are shared. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
On Sun, Feb 18, 2007 at 05:15:30PM +0100, Udo van den Heuvel wrote: > FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser > where only the Device Number can be changed. > The kernel sees the two DVB cards in there as: > > saa7146: register extension 'budget_av'. > ACPI: PCI Interrupt :00:13.0[A] -> GSI 16 (level, low) -> IRQ 16 > saa7146: found saa7146 @ mem f8c3e000 (revision 1, irq 16) (0x153b,0x1157). > saa7146 (0): dma buffer size 192512 > DVB: registering new adapter (Terratec Cinergy 1200 DVB-T). > adapter failed MAC signature check > encoded MAC from EEPROM was > ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff > KNC1-0: MAC addr = 00:0a:ac:01:d6:87 > DVB: registering frontend 0 (Philips TDA10046H DVB-T)... > budget-av: ci interface initialised. > ACPI: PCI Interrupt :00:14.0[A] -> GSI 17 (level, low) -> IRQ 20 > saa7146: found saa7146 @ mem f8cb2000 (revision 1, irq 20) (0x153b,0x1155). > saa7146 (1): dma buffer size 192512 > DVB: registering new adapter (TerraTec Cinergy 1200 DVB-S). > adapter failed MAC signature check > encoded MAC from EEPROM was > ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff > sd 0:0:0:0: Attached scsi generic sg0 type 0 > KNC1-1: MAC addr = 00:0a:ac:12:93:8d > DVB: registering frontend 1 (ST STV0299 DVB-S)... > budget-av: ci interface initialised. Well it says they are slot 13 and 14. What other pci devices are present in the system and what irq's are they using? Now it appears you have acpi, and probably an apic on that board, which would explain having IRQs higher than the 15 a plain old PC had. > So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no > communication with the DVB-T card (the frontend), so there is no > /dev/dvb/* entry. This points to an IRQ problem. Any documentation on that riser card? I guess it is possible the card does something weird and the IRQs for both cards have to actually be the same. If that is the case you could make the kernel change the IRQ assigned to the second card before loading the driver. Or you could do it from the boot loader or something (The system I work with has a stupid bios that doesn't have a clue about bridges, so we added IRQ fixup code to grub to deal with all PCI bridges before booting the system). > How can I find out the actual IRQ that the card is using? > If it is different from what Linux thinks: how do I tell Linux? Linux doesn't think anything. It goes by the IRQ assigned to the device, which is in one of the PCI registers on each device. You can change those registers though, and then it should use the new value (although you may have to change it from the kernel before it enumerates the pci devices). > > On a PC, the BIOS is supposed to assign interrupts to devices based on > > those rules, since that is how the hardware must be done according to > > the PCI specifications. > > I set the BIOS for 'PnP OS installed'. Should I change that? I would NEVER do that. That actually disables the BIOS from doing configuration of most hardware since it really means "Microsoft wants to do configuration themselves and asked us to put in a setting to make the bios only configure drive controllers and sound cards". I know some people have worked towards making linux a "PnP OS" by microsoft standards, but whether it is entirely there or not by now I am not sure. Fortunately most motherboards I have ever bought come preset at 'pnp os installed' off, which is how I like it. I have had a number of problems on systems with that setting on, which went away when the setting was set back to off. It might actually work better if you change that, although it may also just make no difference. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
Lennart Sorensen wrote: > On Sun, Feb 18, 2007 at 03:07:29PM +0100, Udo van den Heuvel wrote: >> How, based on what information, does Linux assign an IRQ to each card, >> plugged into the riser? >> How can one tweak/influence the irq routing? >> How can I make a dual riser card work so that both cards have a working >> interrupt? >> Or if stuff should work all by itself, what could be wrong? > > The PCI specifications cover how pci to pci bridges should work. > > My understanding (which is better of verified against the specs) is: [] > The same rules apply behind a PCI bridge, so whatever INTA is on the > slot with the pci bridge chip, should make to INTA on slots 0, 4, 8, etc > behind the bridge, while INTB is seen as INTA on slots 1, 5, 9, etc. FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser where only the Device Number can be changed. The kernel sees the two DVB cards in there as: saa7146: register extension 'budget_av'. ACPI: PCI Interrupt :00:13.0[A] -> GSI 16 (level, low) -> IRQ 16 saa7146: found saa7146 @ mem f8c3e000 (revision 1, irq 16) (0x153b,0x1157). saa7146 (0): dma buffer size 192512 DVB: registering new adapter (Terratec Cinergy 1200 DVB-T). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff KNC1-0: MAC addr = 00:0a:ac:01:d6:87 DVB: registering frontend 0 (Philips TDA10046H DVB-T)... budget-av: ci interface initialised. ACPI: PCI Interrupt :00:14.0[A] -> GSI 17 (level, low) -> IRQ 20 saa7146: found saa7146 @ mem f8cb2000 (revision 1, irq 20) (0x153b,0x1155). saa7146 (1): dma buffer size 192512 DVB: registering new adapter (TerraTec Cinergy 1200 DVB-S). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff sd 0:0:0:0: Attached scsi generic sg0 type 0 KNC1-1: MAC addr = 00:0a:ac:12:93:8d DVB: registering frontend 1 (ST STV0299 DVB-S)... budget-av: ci interface initialised. So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no communication with the DVB-T card (the frontend), so there is no /dev/dvb/* entry. This points to an IRQ problem. How can I find out the actual IRQ that the card is using? If it is different from what Linux thinks: how do I tell Linux? > On a PC, the BIOS is supposed to assign interrupts to devices based on > those rules, since that is how the hardware must be done according to > the PCI specifications. I set the BIOS for 'PnP OS installed'. Should I change that? > () Thanks for your response! Kind regards, Udo - 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: PCI riser cards and PCI irq routing, etc
On Sun, Feb 18, 2007 at 03:07:29PM +0100, Udo van den Heuvel wrote: > Is there some howto information available about using PCI riser cards > (with multiple PCI slots) under Linux? > Several incarnations exist of PCI riser cards with two PCI slots where > the Device Number of one slot can be changed. > How, based on what information, does Linux assign an IRQ to each card, > plugged into the riser? > How can one tweak/influence the irq routing? > How can I make a dual riser card work so that both cards have a working > interrupt? > Or if stuff should work all by itself, what could be wrong? The PCI specifications cover how pci to pci bridges should work. My understanding (which is better of verified against the specs) is: PCI interrupts (PCI INTA to INTD) are rotated for every slot by one. So slot 0, 4, 8, etc see INTA->realINTA, INTB->realINTB. INTC->realINTC, INTD->realINTD slot 1, 5, 9, etc see INTA->realINTB, INTB->realINTC. INTC->realINTD, INTD->realINTA slot 2, 6, 10, etc see INTA->realINTC, INTB->realINTD. INTC->realINTA, INTD->realINTB slot 3, 7, 11, etc see INTA->realINTD, INTB->realINTA. INTC->realINTB, INTD->realINTC The same rules apply behind a PCI bridge, so whatever INTA is on the slot with the pci bridge chip, should make to INTA on slots 0, 4, 8, etc behind the bridge, while INTB is seen as INTA on slots 1, 5, 9, etc. On a PC, the BIOS is supposed to assign interrupts to devices based on those rules, since that is how the hardware must be done according to the PCI specifications. On other platforms the firmware may or may not handle it. On ARM for example, the kernel takes care of assigning this (or it least it should). I have seen pci interrupt swizzle routines in the kernel code for an arm system which went through, looking for devices, and assigning IRQs based on their slot number, and when it found a bridge it would do a mapping past the bridge and continue assigning interrupts to devices behind the bridge. So as long as the riser board is wired according to the PCI bridge rules, then interrupts assignment should simply work. Of course if the riser card is NOT a proper pci bridge, but rather some weird device, well then it probably isn't even PCI complient and who knows how it shold be handled. Interrupts for PCI are assigned based on the 4 shared interrupts line on PCI, not really per device. A PCI device may use up to 4 interrupts if it wants to, and is supposed to always use interrupt A (as seen from it's slot) as the first interrupt. The rotating assignment of the 4 interrupts to the slots are supposed to help balance the distribution of the interrupts between devices in the system, so that although they are shared interrupts, as few devices as possible get assigned to each interrupt. On some systems some of the 4 PCI interrupts may in fact get mapped to the same interrupts if not enough are available (for example a system I work with only has two PCI interrupts available, so PCI INTA and C are the same interrupt line, and INTB and D are the same, but the system is still wired as if there were 4 interrupts, and the BIOS assigns the interrupts properly based on that, but using IRQ 11 for A and C and IRQ 10 for B and D.) -- Len Sorensen - 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/
PCI riser cards and PCI irq routing, etc
Hello, Is there some howto information available about using PCI riser cards (with multiple PCI slots) under Linux? Several incarnations exist of PCI riser cards with two PCI slots where the Device Number of one slot can be changed. How, based on what information, does Linux assign an IRQ to each card, plugged into the riser? How can one tweak/influence the irq routing? How can I make a dual riser card work so that both cards have a working interrupt? Or if stuff should work all by itself, what could be wrong? Kind regards, Udo - 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/
PCI riser cards and PCI irq routing, etc
Hello, Is there some howto information available about using PCI riser cards (with multiple PCI slots) under Linux? Several incarnations exist of PCI riser cards with two PCI slots where the Device Number of one slot can be changed. How, based on what information, does Linux assign an IRQ to each card, plugged into the riser? How can one tweak/influence the irq routing? How can I make a dual riser card work so that both cards have a working interrupt? Or if stuff should work all by itself, what could be wrong? Kind regards, Udo - 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: PCI riser cards and PCI irq routing, etc
On Sun, Feb 18, 2007 at 03:07:29PM +0100, Udo van den Heuvel wrote: Is there some howto information available about using PCI riser cards (with multiple PCI slots) under Linux? Several incarnations exist of PCI riser cards with two PCI slots where the Device Number of one slot can be changed. How, based on what information, does Linux assign an IRQ to each card, plugged into the riser? How can one tweak/influence the irq routing? How can I make a dual riser card work so that both cards have a working interrupt? Or if stuff should work all by itself, what could be wrong? The PCI specifications cover how pci to pci bridges should work. My understanding (which is better of verified against the specs) is: PCI interrupts (PCI INTA to INTD) are rotated for every slot by one. So slot 0, 4, 8, etc see INTA-realINTA, INTB-realINTB. INTC-realINTC, INTD-realINTD slot 1, 5, 9, etc see INTA-realINTB, INTB-realINTC. INTC-realINTD, INTD-realINTA slot 2, 6, 10, etc see INTA-realINTC, INTB-realINTD. INTC-realINTA, INTD-realINTB slot 3, 7, 11, etc see INTA-realINTD, INTB-realINTA. INTC-realINTB, INTD-realINTC The same rules apply behind a PCI bridge, so whatever INTA is on the slot with the pci bridge chip, should make to INTA on slots 0, 4, 8, etc behind the bridge, while INTB is seen as INTA on slots 1, 5, 9, etc. On a PC, the BIOS is supposed to assign interrupts to devices based on those rules, since that is how the hardware must be done according to the PCI specifications. On other platforms the firmware may or may not handle it. On ARM for example, the kernel takes care of assigning this (or it least it should). I have seen pci interrupt swizzle routines in the kernel code for an arm system which went through, looking for devices, and assigning IRQs based on their slot number, and when it found a bridge it would do a mapping past the bridge and continue assigning interrupts to devices behind the bridge. So as long as the riser board is wired according to the PCI bridge rules, then interrupts assignment should simply work. Of course if the riser card is NOT a proper pci bridge, but rather some weird device, well then it probably isn't even PCI complient and who knows how it shold be handled. Interrupts for PCI are assigned based on the 4 shared interrupts line on PCI, not really per device. A PCI device may use up to 4 interrupts if it wants to, and is supposed to always use interrupt A (as seen from it's slot) as the first interrupt. The rotating assignment of the 4 interrupts to the slots are supposed to help balance the distribution of the interrupts between devices in the system, so that although they are shared interrupts, as few devices as possible get assigned to each interrupt. On some systems some of the 4 PCI interrupts may in fact get mapped to the same interrupts if not enough are available (for example a system I work with only has two PCI interrupts available, so PCI INTA and C are the same interrupt line, and INTB and D are the same, but the system is still wired as if there were 4 interrupts, and the BIOS assigns the interrupts properly based on that, but using IRQ 11 for A and C and IRQ 10 for B and D.) -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
Lennart Sorensen wrote: On Sun, Feb 18, 2007 at 03:07:29PM +0100, Udo van den Heuvel wrote: How, based on what information, does Linux assign an IRQ to each card, plugged into the riser? How can one tweak/influence the irq routing? How can I make a dual riser card work so that both cards have a working interrupt? Or if stuff should work all by itself, what could be wrong? The PCI specifications cover how pci to pci bridges should work. My understanding (which is better of verified against the specs) is: [] The same rules apply behind a PCI bridge, so whatever INTA is on the slot with the pci bridge chip, should make to INTA on slots 0, 4, 8, etc behind the bridge, while INTB is seen as INTA on slots 1, 5, 9, etc. FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser where only the Device Number can be changed. The kernel sees the two DVB cards in there as: saa7146: register extension 'budget_av'. ACPI: PCI Interrupt :00:13.0[A] - GSI 16 (level, low) - IRQ 16 saa7146: found saa7146 @ mem f8c3e000 (revision 1, irq 16) (0x153b,0x1157). saa7146 (0): dma buffer size 192512 DVB: registering new adapter (Terratec Cinergy 1200 DVB-T). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff KNC1-0: MAC addr = 00:0a:ac:01:d6:87 DVB: registering frontend 0 (Philips TDA10046H DVB-T)... budget-av: ci interface initialised. ACPI: PCI Interrupt :00:14.0[A] - GSI 17 (level, low) - IRQ 20 saa7146: found saa7146 @ mem f8cb2000 (revision 1, irq 20) (0x153b,0x1155). saa7146 (1): dma buffer size 192512 DVB: registering new adapter (TerraTec Cinergy 1200 DVB-S). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff sd 0:0:0:0: Attached scsi generic sg0 type 0 KNC1-1: MAC addr = 00:0a:ac:12:93:8d DVB: registering frontend 1 (ST STV0299 DVB-S)... budget-av: ci interface initialised. So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no communication with the DVB-T card (the frontend), so there is no /dev/dvb/* entry. This points to an IRQ problem. How can I find out the actual IRQ that the card is using? If it is different from what Linux thinks: how do I tell Linux? On a PC, the BIOS is supposed to assign interrupts to devices based on those rules, since that is how the hardware must be done according to the PCI specifications. I set the BIOS for 'PnP OS installed'. Should I change that? () Thanks for your response! Kind regards, Udo - 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: PCI riser cards and PCI irq routing, etc
On Sun, Feb 18, 2007 at 05:15:30PM +0100, Udo van den Heuvel wrote: FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser where only the Device Number can be changed. The kernel sees the two DVB cards in there as: saa7146: register extension 'budget_av'. ACPI: PCI Interrupt :00:13.0[A] - GSI 16 (level, low) - IRQ 16 saa7146: found saa7146 @ mem f8c3e000 (revision 1, irq 16) (0x153b,0x1157). saa7146 (0): dma buffer size 192512 DVB: registering new adapter (Terratec Cinergy 1200 DVB-T). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff KNC1-0: MAC addr = 00:0a:ac:01:d6:87 DVB: registering frontend 0 (Philips TDA10046H DVB-T)... budget-av: ci interface initialised. ACPI: PCI Interrupt :00:14.0[A] - GSI 17 (level, low) - IRQ 20 saa7146: found saa7146 @ mem f8cb2000 (revision 1, irq 20) (0x153b,0x1155). saa7146 (1): dma buffer size 192512 DVB: registering new adapter (TerraTec Cinergy 1200 DVB-S). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff sd 0:0:0:0: Attached scsi generic sg0 type 0 KNC1-1: MAC addr = 00:0a:ac:12:93:8d DVB: registering frontend 1 (ST STV0299 DVB-S)... budget-av: ci interface initialised. Well it says they are slot 13 and 14. What other pci devices are present in the system and what irq's are they using? Now it appears you have acpi, and probably an apic on that board, which would explain having IRQs higher than the 15 a plain old PC had. So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no communication with the DVB-T card (the frontend), so there is no /dev/dvb/* entry. This points to an IRQ problem. Any documentation on that riser card? I guess it is possible the card does something weird and the IRQs for both cards have to actually be the same. If that is the case you could make the kernel change the IRQ assigned to the second card before loading the driver. Or you could do it from the boot loader or something (The system I work with has a stupid bios that doesn't have a clue about bridges, so we added IRQ fixup code to grub to deal with all PCI bridges before booting the system). How can I find out the actual IRQ that the card is using? If it is different from what Linux thinks: how do I tell Linux? Linux doesn't think anything. It goes by the IRQ assigned to the device, which is in one of the PCI registers on each device. You can change those registers though, and then it should use the new value (although you may have to change it from the kernel before it enumerates the pci devices). On a PC, the BIOS is supposed to assign interrupts to devices based on those rules, since that is how the hardware must be done according to the PCI specifications. I set the BIOS for 'PnP OS installed'. Should I change that? I would NEVER do that. That actually disables the BIOS from doing configuration of most hardware since it really means Microsoft wants to do configuration themselves and asked us to put in a setting to make the bios only configure drive controllers and sound cards. I know some people have worked towards making linux a PnP OS by microsoft standards, but whether it is entirely there or not by now I am not sure. Fortunately most motherboards I have ever bought come preset at 'pnp os installed' off, which is how I like it. I have had a number of problems on systems with that setting on, which went away when the setting was set back to off. It might actually work better if you change that, although it may also just make no difference. -- Len Sorensen - 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: PCI riser cards and PCI irq routing, etc
[EMAIL PROTECTED] (Lennart Sorensen) writes: My understanding (which is better of verified against the specs) is: PCI interrupts (PCI INTA to INTD) are rotated for every slot by one. So slot 0, 4, 8, etc see INTA-realINTA, INTB-realINTB. INTC-realINTC, INTD-realINTD slot 1, 5, 9, etc see INTA-realINTB, INTB-realINTC. INTC-realINTD, INTD-realINTA slot 2, 6, 10, etc see INTA-realINTC, INTB-realINTD. INTC-realINTA, INTD-realINTB slot 3, 7, 11, etc see INTA-realINTD, INTB-realINTA. INTC-realINTB, INTD-realINTC This is common and suggested practice but the PCI specs don't require it. There is no rule - you can, for example, have all INT lines connected to a single CPU IRQ input. On a PC, the BIOS is supposed to assign interrupts to devices based on those rules, since that is how the hardware must be done according to the PCI specifications. On other platforms the firmware may or may not handle it. Anyway, something has to know how the IRQs are routed. BIOS, other firmware, Linux. So as long as the riser board is wired according to the PCI bridge rules, Actually it has to be wired consistently with the BIOS (which is probably consistent with chipset manufacturer's instructions). Of course if the riser card is NOT a proper pci bridge, but rather some weird device, well then it probably isn't even PCI complient and who knows how it shold be handled. Usually they are just bus splitters, they route IRQs and IDSELs (and maybe JTAG) as required by the BIOS, all others pins are connected 1:1. I.e., they are completely transparent, generally comply to PCI specs and are dedicated to a specific motherboard(s). Interrupts for PCI are assigned based on the 4 shared interrupts line on PCI, not really per device. A PCI device may use up to 4 interrupts if it wants to, and is supposed to always use interrupt A (as seen from it's slot) as the first interrupt. Actually I think (would have to check the specs for sure) every subdevice (function) may use just one interrupt line. This rotating INTx scheme is common because it's cheap. There are systems which support more than 4 shared INTs per bus, for example you can have different sets of 4 INTx lines for every PCI slot, even if all slots are on the same PCI bus. The rotating assignment of the 4 interrupts to the slots are supposed to help balance the distribution of the interrupts between devices in the system, so that although they are shared interrupts, as few devices as possible get assigned to each interrupt. Correct. This scheme assumes at most 4 single-function devices on the bus, otherwise INTs are shared. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
Udo van den Heuvel [EMAIL PROTECTED] writes: FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser where only the Device Number can be changed. With jumpers? So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no communication with the DVB-T card (the frontend), so there is no /dev/dvb/* entry. This points to an IRQ problem. How can I find out the actual IRQ that the card is using? I would remove the PCI cards and then the riser card and check INT routing with a multimeter. Perhaps a task for someone used to stuff like that. I set the BIOS for 'PnP OS installed'. Should I change that? Most drivers already enable devices so it probably doesn't matter. I would check it, though. -- Krzysztof Halasa - 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: PCI riser cards and PCI irq routing, etc
On Sunday 18 February 2007 19:39, Lennart Sorensen wrote: [snip] On a PC, the BIOS is supposed to assign interrupts to devices based on those rules, since that is how the hardware must be done according to the PCI specifications. I set the BIOS for 'PnP OS installed'. Should I change that? I would NEVER do that. That actually disables the BIOS from doing configuration of most hardware since it really means Microsoft wants to do configuration themselves and asked us to put in a setting to make the bios only configure drive controllers and sound cards. I know some people have worked towards making linux a PnP OS by microsoft standards, but whether it is entirely there or not by now I am not sure. Fortunately most motherboards I have ever bought come preset at 'pnp os installed' off, which is how I like it. I have had a number of problems on systems with that setting on, which went away when the setting was set back to off. I think this option actually _used_ to mean whether the BIOS would _provide_ PNP services to the host OS, allowing it to detect peripherals like parallel ports, etc. In reality, very few devices on modern PCs use or require BIOS PNP support, and in some situations it's just annoying (for example, disabling the parallel port on my Thinkpad has no effect because Linux just uses PNP to redetect it). It might actually work better if you change that, although it may also just make no difference. In my experience it just makes no difference. I strongly doubt the option has _anything_ to do with this problem. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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: PCI riser cards and PCI irq routing, etc
Lennart Sorensen wrote: On Sun, Feb 18, 2007 at 05:15:30PM +0100, Udo van den Heuvel wrote: FYI: My situation is a VIA Epia EN12000 with a TranquilPC dual PCI riser where only the Device Number can be changed. The kernel sees the two DVB cards in there as: saa7146: register extension 'budget_av'. ACPI: PCI Interrupt :00:13.0[A] - GSI 16 (level, low) - IRQ 16 saa7146: found saa7146 @ mem f8c3e000 (revision 1, irq 16) (0x153b,0x1157). saa7146 (0): dma buffer size 192512 DVB: registering new adapter (Terratec Cinergy 1200 DVB-T). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff KNC1-0: MAC addr = 00:0a:ac:01:d6:87 DVB: registering frontend 0 (Philips TDA10046H DVB-T)... budget-av: ci interface initialised. ACPI: PCI Interrupt :00:14.0[A] - GSI 17 (level, low) - IRQ 20 saa7146: found saa7146 @ mem f8cb2000 (revision 1, irq 20) (0x153b,0x1155). saa7146 (1): dma buffer size 192512 DVB: registering new adapter (TerraTec Cinergy 1200 DVB-S). adapter failed MAC signature check encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff sd 0:0:0:0: Attached scsi generic sg0 type 0 KNC1-1: MAC addr = 00:0a:ac:12:93:8d DVB: registering frontend 1 (ST STV0299 DVB-S)... budget-av: ci interface initialised. Well it says they are slot 13 and 14. What other pci devices are present in the system and what irq's are they using? lspci and interrupts at the bottom. yes, we have apic. So IRQ 16 and 20. But when using the stock 2.6.20 kernel there is no communication with the DVB-T card (the frontend), so there is no /dev/dvb/* entry. This points to an IRQ problem. Any documentation on that riser card? The EN12000 is equipped with a PCI riser like the one here: http://www.tranquilpc-shop.co.uk/acatalog/info%5f2%2ehtml Please also see http://www.tranquilpc-shop.co.uk/acatalog/PCI_Risers.html and http://www.tranquilpc.co.uk/support/Files/TPC014/Tranquil%20Riser.pdf for info about how the riser works. I guess it is possible the card does something weird and the IRQs for both cards have to actually be the same. If that is the case you could make the kernel change the IRQ assigned to the second card before loading the driver. Or you could do it from the boot loader or something (The system I work with has a stupid bios that doesn't have a clue about bridges, so we added IRQ fixup code to grub to deal with all PCI bridges before booting the system). Ah, this sounds interesting. Any pointers about hwo to do this? I set the BIOS for 'PnP OS installed'. Should I change that? () It might actually work better if you change that, although it may also just make no difference. I will give the change a try. The info: 00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11) 00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro IGP (rev 01) CPU0 0: 15939569 IO-APIC-edge timer 1: 36 IO-APIC-edge i8042 8: 1 IO-APIC-edge rtc 9: 0 IO-APIC-fasteoi acpi 12:222 IO-APIC-edge i8042 14: 570999 IO-APIC-edge ide0 16:3166202 IO-APIC-fasteoi saa7146 (0), [EMAIL PROTECTED]::01:00.0 17:2619374 IO-APIC-fasteoi eth0 18: 402194 IO-APIC-fasteoi libata 19: 0 IO-APIC-fasteoi uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3,
