Bug 591614 - Boot fails after update to kernel BUG in quirk_xio2000a+0x45/0x99
Summary: Boot fails after update to kernel BUG in quirk_xio2000a+0x...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 12
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-12 17:28 UTC by CrystalCowboy
Modified: 2010-12-03 14:46 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-12-03 14:46:17 UTC
Type: ---

Attachments (Terms of Use)
Boot session from serial port (28.44 KB, text/plain)
2010-05-17 19:38 UTC, CrystalCowboy
no flags Details

Description CrystalCowboy 2010-05-12 17:28:24 UTC
Description of problem: Tyan Thunder K8WE (S2895) motherboard with two Opteron 246 CPUs. Running OK with Fedora 12 under kernel Did a yum update to kernel-, followed by a reboot. Reboot process fails very soon with a kernel panic. Affects 3 of 4 machines with this motherboard. Does not affect several other (newer) platforms we have in house.

Version-Release number of selected component (if applicable):

How reproducible: For 3 of the 4 machines we have with this hardware, it is very repeatable. Happens on the reboot command. Happens when the RESET button is pressed. Happens after a power-down restart. Does not seem to affect any other hardware we have.

Steps to Reproduce:
1. Update the kernel
2. Reboot
3. Scream
Actual results: Reboot fails with kernel panic very soon (within a few seconds) after BIOS hands off to the Linux boot procedure. So soon that no logs, etc. are saved.

Expected results: Boot into OS.

Additional info: Booting under an old kernel, until I can figure this out.

Comment 1 Eric Sandeen 2010-05-14 15:48:25 UTC
any characterization of the failure would be helpful - oops?  BUG()?  Backgrace? can't find root fs?  Even a cell-phone-camera snapshot of the screen after failure might help.

Comment 2 CrystalCowboy 2010-05-17 19:38:45 UTC
Created attachment 414644 [details]
Boot session from serial port

Comment 3 CrystalCowboy 2010-05-17 19:49:37 UTC
Today I got help from someone more experienced, and we managed to get more information. We hooked up a serial console and so managed to capture the output during the boot sequence (See attachment id=414644).

It starts to go south about here:

pci 0000:ff:00.0: TI XIO2000a quirk detected; secondary bus fast back-to-back td
BUG: unable to handle kernel NULL pointer dereference at 0000000000000028       
IP: [<ffffffff814444f4>] quirk_xio2000a+0x45/0x99                               
PGD 0                                                                           
Oops: 0000 [#1] SMP                                                             

This was identified as coming from a PCI-express x1 serial port card (brand Rosewill) with a Texas Instruments XIO2000A chip on it. I am told this is a PCI-express=>PCI bridge chip. I.e. the card is not native PCI-express. Probably this is causing a conflict with a similar bridged chip on the motherboard. (This is a server board with a mix of PCI-express, PCI and PCI-X slots)

When the serial port card is removed, the machine boots up just fine with kernel This is repeatable on the other two machines which had this problem. We can get by without these cards and so are back in business.

Comment 4 Eric Sandeen 2010-05-17 20:16:52 UTC
static void __devinit quirk_xio2000a(struct pci_dev *dev)
        struct pci_dev *pdev;
        u16 command;

        dev_warn(&dev->dev, "TI XIO2000a quirk detected; "
                "secondary bus fast back-to-back transfers disabled\n");
        list_for_each_entry(pdev, &dev->subordinate->devices, bus_list) {
                pci_read_config_word(pdev, PCI_COMMAND, &command);
                if (command & PCI_COMMAND_FAST_BACK)
                        pci_write_config_word(pdev, PCI_COMMAND, command & ~PCI_COMMAND_FAST_BACK);

I think you oopsed in the list_for_each_entry, guessing dev->subordinate was null but this is well outside my realm of expertise, you might want to put it on LKML and/or contact the author of the commit that added it:

commit 1f56f4a2b4d12c1c348cab23024024396ec7cddc
Author: Gabe Black <gabe.black@ni.com>
Date:   Tue Oct 6 09:19:45 2009 -0500

    PCI quirk: TI XIO200a erroneously reports support for fast b2b transfers
    This quirk will disable fast back to back transfer on the secondary bus
    segment of the TI Bridge.
    Signed-off-by: Gabe Black <gabe.black@ni.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

Comment 5 Bug Zapper 2010-11-03 15:00:15 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 6 Bug Zapper 2010-12-03 14:46:17 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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