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
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
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 0000: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 0000: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
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 0000: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 0000: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
[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
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
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.
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 0000: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 0000: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. VT82xxxxx UHCI USB 1.1
Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx 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), via@pci:0000: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
Kind regards,
Udo
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
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 (root@recorder) (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: 0000000000000000 size: 000000000009f800 end:
000000000009f800 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000000009f800 size: 0000000000000800 end:
00000000000a0000 type: 2
copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end:
0000000000100000 type: 2
copy_e820_map() start: 0000000000100000 size: 000000003bef0000 end:
000000003bff0000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000003bff0000 size: 0000000000003000 end:
000000003bff3000 type: 4
copy_e820_map() start: 000000003bff3000 size: 000000000000d000 end:
000000003c000000 type: 3
copy_e820_map() start: 00000000fec00000 size: 0000000000001000 end:
00000000fec01000 type: 2
copy_e820_map() start: 00000000fee00000 size: 0000000000001000 end:
00000000fee01000 type: 2
copy_e820_map() start: 00000000ffff0000 size: 0000000000010000 end:
0000000100000000 type: 2
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003bff0000 (usable)
BIOS-e820: 000000003bff0000 - 000000003bff3000 (ACPI NVS)
BIOS-e820: 000000003bff3000 - 000000003c000000 (ACPI data)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (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 0x00000000) @ 0x3bff3040
ACPI: FADT (v001 P4M80P AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3bff30c0
ACPI: MADT (v001 P4M80P AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3bff7cc0
ACPI: DSDT (v001 P4M80P AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x00000000
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:10 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode: Flat. Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 40000000 (gap: 3c000000:c2c00000)
Detected 1197.000 MHz processor.
Built 1 zonelists. Total pages: 227584
Kernel command line: ro root=LABEL=/ rhgb quiet
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 904600k/917504k available (1961k kernel code, 12340k reserved,
724k data, 160k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xfffb7000 - 0xfffff000 ( 288 kB)
vmalloc : 0xf8800000 - 0xfffb5000 ( 119 MB)
lowmem : 0xc0000000 - 0xf8000000 ( 896 MB)
.init : 0xc03a2000 - 0xc03ca000 ( 160 kB)
.data : 0xc02ea7a3 - 0xc039f934 ( 724 kB)
.text : 0xc0100000 - 0xc02ea7a3 (1961 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 2396.88 BogoMIPS
(lpj=4793772)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: a7c9bbff 00000000 00000000 00000000
00000181 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 128K (64 bytes/line)
CPU: After all inits, caps: 27c9bbff 00000000 00000000 00000000 00000181
00003fcc 00000000
CPU: Centaur VIA Esther processor 1200MHz stepping 09
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf93b0, last bus=1
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is 0000:01:00.0
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.
SCSI subsystem initialized
libata version 2.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a
report
PCI: Bridge: 0000:00:01.0
IO window: b000-bfff
MEM window: fb000000-fcffffff
PREFETCH window: f4000000-f7ffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
checking if image is initramfs... it is
Freeing initrd memory: 1254k freed
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
JFS: nTxBlock = 7078, nTxLock = 56627
io scheduler noop registered
io scheduler cfq registered (default)
PCI: Bypassing VIA 8237 APIC De-Assert Message
Real Time Clock Driver v1.12ac
VIA RNG detected
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected VIA VT3314 chipset
agpgart: AGP aperture is 128M @ 0xe8000000
[drm] Initialized drm 1.1.0 20060810
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[drm] Initialized via 2.10.0 20060529 on minor 0
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
VIA Networking Velocity Family Gigabit Ethernet Adapter Driver Ver. 1.14
Copyright (c) 2002, 2003 VIA Networking Technologies, Inc.
Copyright (c) 2004 Red Hat Inc.
ACPI: PCI Interrupt 0000:00:0e.0[A] -> GSI 18 (level, low) -> IRQ 17
eth0: VIA Networking Velocity Family Gigabit Ethernet Adapter
eth0: Ethernet Address: 00:40:63:E6:D5:FA
Linux video capture interface: v2.00
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:0f.1
ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 20
ACPI: PCI Interrupt 0000:00:0f.1[A] -> Link [ALKA] -> GSI 20 (level,
low) -> IRQ 18
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
ide0: BM-DMA at 0xdc00-0xdc07, BIOS settings: hda:DMA, hdb:pio
Probing IDE interface ide0...
hda: MATSHITACD-RW CW-8124, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hda: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
sata_via 0000:00:0f.0: version 2.0
ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20 (level,
low) -> IRQ 18
sata_via 0000:00:0f.0: routed to hard irq line 11
ata1: SATA max UDMA/133 cmd 0xF400 ctl 0xF002 bmdma 0xE400 irq 18
ata2: SATA max UDMA/133 cmd 0xEC00 ctl 0xE802 bmdma 0xE408 irq 18
scsi0 : sata_via
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ATA: abnormal status 0x7F on port 0xF407
ATA: abnormal status 0x7F on port 0xF407
ata1.00: ATA-7, max UDMA/133, 976773168 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
scsi1 : sata_via
ata2: SATA link down 1.5 Gbps (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0xEC07
scsi 0:0:0:0: Direct-Access ATA WDC WD5000YS-01M 09.0 PQ: 0 ANSI: 5
SCSI device sda: 976773168 512-byte hdwr sectors (500108 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
SCSI device sda: 976773168 512-byte hdwr sectors (500108 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 sda10 >
sd 0:0:0:0: Attached scsi disk sda
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input0
input: PC Speaker as /class/input/input1
logips2pp: Detected unknown logitech mouse model 1
input: PS/2 Logitech Mouse as /class/input/input2
padlock: No VIA PadLock drivers have been loaded.
padlock: Using VIA PadLock ACE for AES algorithm.
padlock: Using VIA PadLock ACE for SHA1/SHA256 algorithms.
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
ACPI: (supports S0 S1 S4 S5)
Freeing unused kernel memory: 160k freed
Time: tsc clocksource has been installed.
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 21
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [ALKB] -> GSI 21 (level,
low) -> IRQ 19
uhci_hcd 0000:00:10.0: UHCI Host Controller
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:10.0: irq 19, io base 0x0000d800
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:10.1[A] -> Link [ALKB] -> GSI 21 (level,
low) -> IRQ 19
uhci_hcd 0000:00:10.1: UHCI Host Controller
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:10.1: irq 19, io base 0x0000d400
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:10.2[B] -> Link [ALKB] -> GSI 21 (level,
low) -> IRQ 19
uhci_hcd 0000:00:10.2: UHCI Host Controller
uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:10.2: irq 19, io base 0x0000d000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:10.4[C] -> Link [ALKB] -> GSI 21 (level,
low) -> IRQ 19
ehci_hcd 0000:00:10.4: EHCI Host Controller
ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 4
ehci_hcd 0000:00:10.4: irq 19, io mem 0xfdffd000
ehci_hcd 0000:00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 6 ports detected
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
ACPI: PCI Interrupt 0000:00:0d.0[A] -> GSI 17 (level, low) -> IRQ 20
saa7146: register extension 'budget_av'.
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[20]
MMIO=[fdfff000-fdfff7ff] Max Packet=[2048] IR/IT contexts=[4/8]
ACPI: PCI Interrupt 0000:00:13.0[A] -> GSI 16 (level, low) -> IRQ 16
saa7146: found saa7146 @ mem f8ce4000 (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
sd 0:0:0:0: Attached scsi generic sg0 type 0
DVB: registering frontend 0 (Philips TDA10046H DVB-T)...
budget-av: ci interface initialised.
ACPI: PCI Interrupt 0000:00:14.0[A] -> GSI 17 (level, low) -> IRQ 20
saa7146: found saa7146 @ mem f8e78000 (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
KNC1-1: MAC addr = 00:0a:ac:12:93:8d
ieee1394: Host added: ID:BUS[0-00:1023] GUID[004063500007b5e1]
DVB: registering frontend 1 (ST STV0299 DVB-S)...
budget-av: ci interface initialised.
ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [ALKC] -> GSI 22 (level,
low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:11.5 to 64
Non-volatile memory driver v1.2
lp: driver loaded but no devices found
input: Power Button (FF) as /class/input/input3
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input4
ACPI: Power Button (CM) [PWRB]
input: Sleep Button (CM) as /class/input/input5
ACPI: Sleep Button (CM) [SLPB]
ACPI: Fan [FAN] (on)
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
ACPI: Processor [CPU0] (supports 2 throttling states)
ACPI: Thermal Zone [THRM] (25 C)
Time: acpi_pm clocksource has been installed.
EXT3 FS on sda5, internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Adding 859436k swap on /dev/sda9. Priority:-1 extents:1 across:859436k
Velocity is AUTO mode
eth0: Link autonegation speed 100M bps full duplex
hwmon-vid: Unknown VRM version of your x86 CPU
tda1004x: setting up plls for 53MHz sampling clock
tda1004x: found firmware revision 20 -- ok
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. VT82xxxxx UHCI USB 1.1
> Controller (rev 81)
> 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 81)
> 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx 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), via@pci:0000: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
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 e8000000 (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: 0000b000-0000bfff
Memory behind bridge: fb000000-fcffffff
Prefetchable memory behind bridge: f4000000-f7ffffff
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 000001f0 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
[virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 00000370 (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. VT82xxxxx UHCI USB 1.1
Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xxxxx 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. VT82xxxxx UHCI USB 1.1
Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
Flags: bus master, medium devsel, latency 32, IRQ 19
I/O ports at d400 [size=32]
Capabilities: [80] Power Management version 2
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
Flags: bus master, medium devsel, latency 32, IRQ 19
I/O ports at d000 [size=32]
Capabilities: [80] Power Management version 2
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if
20 [EHCI])
Subsystem: VIA Technologies, Inc. USB 2.0
Flags: bus master, medium devsel, latency 32, IRQ 19
Memory at fdffd000 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge
[KT600/K8T800/K8T890 South]
Subsystem: VIA Technologies, Inc. Unknown device aa08
Flags: bus master, stepping, medium devsel, latency 0
Capabilities: [c0] Power Management version 2
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
Subsystem: VIA Technologies, Inc. Unknown device aa08
Flags: medium devsel, IRQ 21
I/O ports at c800 [size=256]
Capabilities: [c0] Power Management version 2
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 f4000000 (32-bit, prefetchable) [size=64M]
Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
[virtual] Expansion ROM at fc000000 [disabled] [size=64K]
Capabilities: [60] Power Management version 2
Capabilities: [70] AGP version 3.0
Kind regards,
Udo
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 e8000000 (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: 0000b000-0000bfff
> Memory behind bridge: fb000000-fcffffff
> Prefetchable memory behind bridge: f4000000-f7ffffff
> 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 000001f0 (32-bit, non-prefetchable) [size=8]
> [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
> [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
> [virtual] Memory at 00000370 (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. VT82xxxxx UHCI USB 1.1
> Controller (rev 81) (prog-if 00 [UHCI])
> Subsystem: VIA Technologies, Inc. VT82xxxxx 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. VT82xxxxx UHCI USB 1.1
> Controller (rev 81) (prog-if 00 [UHCI])
> Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
> Flags: bus master, medium devsel, latency 32, IRQ 19
> I/O ports at d400 [size=32]
> Capabilities: [80] Power Management version 2
>
> 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 81) (prog-if 00 [UHCI])
> Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
> Flags: bus master, medium devsel, latency 32, IRQ 19
> I/O ports at d000 [size=32]
> Capabilities: [80] Power Management version 2
>
> 00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if
> 20 [EHCI])
> Subsystem: VIA Technologies, Inc. USB 2.0
> Flags: bus master, medium devsel, latency 32, IRQ 19
> Memory at fdffd000 (32-bit, non-prefetchable) [size=256]
> Capabilities: [80] Power Management version 2
>
> 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge
> [KT600/K8T800/K8T890 South]
> Subsystem: VIA Technologies, Inc. Unknown device aa08
> Flags: bus master, stepping, medium devsel, latency 0
> Capabilities: [c0] Power Management version 2
>
> 00:11.5 Multimedia audio controller: VIA Technologies, Inc.
> VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
> Subsystem: VIA Technologies, Inc. Unknown device aa08
> Flags: medium devsel, IRQ 21
> I/O ports at c800 [size=256]
> Capabilities: [c0] Power Management version 2
>
> 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 f4000000 (32-bit, prefetchable) [size=64M]
> Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
> [virtual] Expansion ROM at fc000000 [disabled] [size=64K]
> Capabilities: [60] Power Management version 2
> Capabilities: [70] AGP version 3.0
0x14 = IRQ 20
0x13 = IRQ 16
0x10 = IRQ 19
0x0f = IRQ 18
0x0e = IRQ 17
0x0d = IRQ 20
Hmm, certainly the onboard devices are assigned in interesting order.
Is it possible that this board does simply not allow more pci slots?
After all if the BIOS knows that the only PCI slot in the system is
device 20 (0x14) then it has no reason to have any rule for how to
assign an interrupt to device 19 or anything else for that matter. If
that is the case you would have to find out what interrupt is used as
INTA, B, C and D on device 20, so you can calculate which one would end
up on the other device (assuming the riser card maps them correctly,
which it probably does), and assign that to the card. Of course it is
also possible that if you try other device numbers you could get lucky
and have the BIOS happen to assign the right value to your card for one
of them.
I see that VIA as their own 2 port riser card which is labeled as
working only with via boards, which may also mean that other riser cards
do not necesarily work with the via boards without some non standard
tweaking of the software.
--
Len Sorensen
[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
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
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
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
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.
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
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&threadid=41622&highlight_key=y&keyword1=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.
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
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
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)
0x08 A19 n/a
0x09 A20 n/a
0x0A A21 INT C
0x0B A22 n/a
0x0C A23 n/a
0x0D A24 IEEE1394 chip (INT A)
0x0E A25 n/a
0x0F A26 n/a
0x10 A27 USB (INT D, A, B, C)
0x11 A28 VT823x (11.5 uses INT B so it means INT A, B, C, D)
0x12 A29 onboard Ethernet (INT D)
0x13 A30 INT D
0x14 A31 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
[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
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
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
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
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 f4000000 (32-bit, prefetchable) [size=64M]
Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
[virtual] Expansion ROM at fc000000 [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?
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#
IEEE1394 INT 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 e8000000 (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: 0000b000-0000bfff
Memory behind bridge: fb000000-fcffffff
Prefetchable memory behind bridge: f4000000-f7ffffff
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 000001f0 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
[virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 00000370 (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. VT82xxxxx UHCI USB 1.1
Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xxxxx 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. VT82xxxxx UHCI USB 1.1
Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
Flags: bus master, medium devsel, latency 32, IRQ 19
I/O ports at d400 [size=32]
Capabilities: [80] Power Management version 2
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 81) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
Flags: bus master, medium devsel, latency 32, IRQ 19
I/O ports at d000 [size=32]
Capabilities: [80] Power Management version 2
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if
20 [EHCI])
Subsystem: VIA Technologies, Inc. USB 2.0
Flags: bus master, medium devsel, latency 32, IRQ 19
Memory at fdffd000 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge
[KT600/K8T800/K8T890 South]
Subsystem: VIA Technologies, Inc. Unknown device aa08
Flags: bus master, stepping, medium devsel, latency 0
Capabilities: [c0] Power Management version 2
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
Subsystem: VIA Technologies, Inc. Unknown device aa08
Flags: medium devsel, IRQ 21
I/O ports at c800 [size=256]
Capabilities: [c0] Power Management version 2
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 f4000000 (32-bit, prefetchable) [size=64M]
Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
[virtual] Expansion ROM at fc000000 [disabled] [size=64K]
Capabilities: [60] Power Management version 2
Capabilities: [70] AGP version 3.0
CPU0
0: 24611141 IO-APIC-edge timer
1: 34 IO-APIC-edge i8042
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-fasteoi acpi
12: 105 IO-APIC-edge i8042
14: 881823 IO-APIC-edge ide0
16: 4916467 IO-APIC-fasteoi saa7146 (0), via@pci:0000:01:00.0
17: 3522084 IO-APIC-fasteoi eth0
18: 820707 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: 4582389 IO-APIC-fasteoi VIA8237
NMI: 0
LOC: 24612000
ERR: 0
MIS: 0
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
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
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
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
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
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 f4000000 (32-bit, prefetchable) [size=64M]
> Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
> [virtual] Expansion ROM at fc000000 [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
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#
> > 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.
> Device# IDSEL INT (first)
> 0x08 A19 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
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 1 INT 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 M10000, 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.
[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)
>> 0x08 A19 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
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
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
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
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
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
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...
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?
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
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
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.
