lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m3irds63vd.fsf@maximus.localdomain>
Date:	Fri, 23 Feb 2007 21:00:38 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Udo van den Heuvel <udovdh@...all.nl>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: PCI riser cards and PCI irq routing, etc

Udo van den Heuvel <udovdh@...all.nl> writes:

> Description VIA Dual PCI Riser
> The EXT-PCI is a PCI riser card which expands a PCI slot into two PCI slots.
> EXT-PCI slot 1 (lower slot) uses the system resources (Device ID, INT)
> of the PCI slot of the motherboard.

Yep. ID 20, INT D (chipset POV).

> EXT-PCI slot 2 (Upper slot) uses device 19 and INT_A.

Right.

> Upper slot has the problems. TranquilPC does not even respond anymore.
> The lower slot is a copy of the normal (single) PCI slot w.r.t. devcie
> and irq, it has DN20 and irq 20.

Ok.

> dmesg links ALNKA to IRQ 20. So if ALNKA is INTA both PCI cards should
> share IRQ 20?

No. I don't exactly know what these ACPI messages show. Probably they
list some power-up state, before devices are configured. If lspci says
DN20 uses IRQ 20 and DN19 "uses" IRQ16 then that's exactly what they
should use - two different INT/IRQ signals.

If the lspci shows that DN20 uses the same IRQ as IEEE1394 controller
and that DN19 uses the same IRQ as on-board Ethernet and VGA then
that means just that: they share INTs/IRQs (this is especially true
when running in IO-APIC mode).

If lspci shows no IRQ for the device then that DN is not supported
by the BIOS.

I'd try this "aluminum film" trick. Just be careful, shorting wrong
traces can destroy the hardware. As I wrote, shorting the good ones
can make the system (temporarily) unusable.
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ