Bug 245048 - PCI Express devices behind a PCI-Express to PCI bridge are not reassigned to new IRQ's by the OS.
Summary: PCI Express devices behind a PCI-Express to PCI bridge are not reassigned to ...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 7
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-20 18:15 UTC by Derrek Sypert
Modified: 2015-01-04 22:29 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2008-01-09 14:58:09 UTC

Attachments (Terms of Use)
BIOS assigned IRQ's, dmesg and messages files, lspci output(verbose) (19.78 KB, application/x-zip-compressed)
2007-06-20 18:17 UTC, Derrek Sypert
no flags Details

Description Derrek Sypert 2007-06-20 18:15:06 UTC
Description of problem: Communication devices behind a PCI-Express to PCI 
bridge are not assigned new IRQ's by Fedora Core 7.  You can see in the 
attached BIOS log that the BIOS assigned 2 Simple COMM. Cntrlr devices to IRQ 
10.  These should have been reassigned 2 new separate IRQ's by the OS. If you 
review the attached dmesg and messages file, the devices are left on IRQ 10.  
The IO addresses of the 2 boards can be read in the LSPCI log.  If you review 
the messages file, those IO ranges are assigned IRQ's only to the PCI bus.  Our 
PCI-Express multi-port serial boards do not work as a result.  We can get one 
board to work by itself if we add only 1 board, and use the 'noapic' boot 
option in the grub.conf file.  I am not sure if this is a problem with the OS 
PCI assignment, or an issue with pciutils.  This problem does not happen in 
Windows XP/Server 2003, etc.  We don't have any problems with the PCI-X,PCI 
version of the same board.

Version-Release number of selected component (if applicable): PCIUTILS version 
2.2.5 (dated 5/4/07)
Fedora 7.0.1 (dated 5/31/07)
Kernel: 2.6.21-1.3194.fc7
Motherboard:  Gigabyte GA-965G-DS3
Bios: 965G-DS3  Version F9 (dated 5/28/07)

How reproducible:  100% reproducable.  None of our PCI-Express Multi-modem 
cards work without the noapic boot option.  We can get one PCI-Express board to 
work using IRQ 10 if we use the 'noapic' kernel boot option. The PCI/PCI-X 
version works fine, and each board is assigned a different IRQ.

Steps to Reproduce:
1. Physically install 1 or more PCI-Express multi-port serial com devices in a 
system with a motherboard with a PCI-Express to PCI bridge.
2. Boot the machine
3. Use lspci to view the resources assigned to the device.
Actual results: Each board is left on IRQ 10 by the OS.  Even though lspci 
showed that the board was assigned to IRQ 10, one board was able to be used 
using IRQ 16, even though lspci said the device was using IRQ 10.

Expected results:  Each board should have been assigned a new separate IRQ by 
the OS.  Also, Fedora should also be able to automatically configure all the 
serial ports of each port on each card automatically as it does with our 
PCI/PCI-X version of our board. Each serial port of our standard PCI version is 
assigned a ttyS# .

Additional Info:  We are the primary multi-port fax board device in the 
HylaFax/Linux community, so it is very important that our PCI-Express boards 
are supported.  Fedora is a good starting point as it is what we use on our 
test systems at our Engineering facility.

Comment 1 Derrek Sypert 2007-06-20 18:17:01 UTC
Created attachment 157485 [details]
BIOS assigned IRQ's, dmesg and messages files, lspci output(verbose)

Comment 2 Christopher Brown 2007-09-17 11:30:03 UTC
Hello Derrek,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.


I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.


Comment 3 Christopher Brown 2008-01-09 14:58:09 UTC
As indicated previously there has been no update on the progress of this bug
therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue
still occurs for you and I will try to assist in its resolution. Thank you for
taking the time to report the initial bug.

Note You need to log in before you can comment on or make changes to this bug.