From: Jim Paris <jim@jtan.com>
To: Len Brown <len.brown@intel.com>
Cc: linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Bjorn Helgaas <bjorn.helgaas@hp.com>
Subject: Re: PCI IRQ problems: "nobody cared!"
Date: Sat, 16 Oct 2004 20:12:16 -0400 [thread overview]
Message-ID: <20041017001216.GA29461@jim.sh> (raw)
In-Reply-To: <1097906133.14149.37.camel@d845pe>
Hi Len,
Thanks for the tips. I tried your suggestions (a bit out of order).
Here are the results.
> Before doing anything else, please verify that you're running the latest
> BIOS for this box.
The BIOS and EC are both the latest version available.
> You might find that using "noirqdebug" gets you through the boot
> sequence and that after the drivers are loaded the system runs
> normally. This may be preferable to the irqpoll workaround.
> Of course both are workarounds and neither actually help us
> identify the root cause.
"noirqdebug" results in a freeze where it would previously have given
the "irq 9: nobody cared!" error.
> Note that PNPBIOS shouldn't run on an ACPI-enabled system -- probably no
> harm, but use a CONFIG_PNPBIOS=n kernel to verify there is no change in
> your ACPI enabled result.
That was on the Debian kernel. On my own 2.6.8.1 build, I have
CONFIG_PNP=n, and the result (without irqpoll) is the same.
My full config:
https://jim.sh/svn/jim/devl/toughbook/log/current.config
> The failure in the acpioff case is a clue I think. Several devices
> get enabled on IRQ9 with no issues, but the system dies when yenta
> gets enabled, so perhaps the devices behind that bridge are at
> fault.
It doesn't seem specific to a particular device.
With my 2.6.8.1 and acpi=off, it dies when uhci_hcd is loaded, before yenta.
https://jim.sh/svn/jim/devl/toughbook/log/uhcidie.txt
(fyi, I've also added some ram since the last logs I posted)
In order to get Debian installed with their kernel, I needed to have
IDE working, as well as one of either wireless net, wired net, or usb.
I tried a ton of configurations, until I finally found that the only
thing that worked was using acpi=off, and then only loading modules
8139too for net, and generic for IDE. If I used piix for IDE, it
would cause the same irq9 problem on load and break the other devices
(but the IDE would still work).
[ I should have mentioned and tested PIIX earlier. See the end of
this mail for what I found out. ]
> It would be interesting to look at your
> BIOS setup to see if there are some parameters you can use to allow the
> BIOS to give us more freedom.
..
> As a start, go to your BIOS SETUP
> and disable all devices that it allows you to disable.
BIOS lets me enable or disable the following:
serial ports, touch screen, parallel port,
touch pad, LAN, modem, wireless LAN.
For the devices on the first line, I can also choose their port/IRQ
manually, but the BIOS (Phoenix) doesn't give me any more control than
that. The motherboard has six DIP switches, but they are undocumented.
Setting all of them to "disable" doesn't change anything for acpi=on
or acpi=off.
> Also, it would be a good idea to identify the device at the root cause.
> Looks like you have a couple of NICs behind a cardbus bridge.
> If they are physically removable, then take them out.
I physically removed both the NIC/modem combo and the wireless card.
Both the acpi=on and acpi=off cases failed the same way as when the
cards are present:
https://jim.sh/svn/jim/devl/toughbook/log/removed.txt
https://jim.sh/svn/jim/devl/toughbook/log/removed-acpioff.txt
> If you supply the output from lspci -vv
> and acpidmp, then we can find out exactly
> what devices are attached to which interrupt link
> and that will probably tell us which device is being bad.
Sure. With acpi and irqpoll:
https://jim.sh/svn/jim/devl/toughbook/log/lspcivv.txt
https://jim.sh/svn/jim/devl/toughbook/log/acpidmp.txt
> One thing that might help is if you try Bjorn's patch
> to delay enabling the PCI Interrupt Links until the
> actual drivers request that their interrupt be enabled:
> http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc4/2.6.9-rc4-mm1/broken-out/remove-unconditional-pci-acpi-irq-routing.patch
First, 2.6.9-final has the same problems:
https://jim.sh/svn/jim/devl/toughbook/log/269.txt
2.6.9-final-routeirq (with Bjorne's patches) breaks at IDE initialization:
https://jim.sh/svn/jim/devl/toughbook/log/269bjorn.txt
But! 2.6.9-final-routeirq, _without_ CONFIG_BLK_DEV_PIIX (just
CONFIG_BLK_DEV_GENERIC), works!
https://jim.sh/svn/jim/devl/toughbook/log/nopiix.txt
And 2.6.9-final-routeirq with neither ACPI nor PIIX also works:
https://jim.sh/svn/jim/devl/toughbook/log/noacpi-nopiix.txt
For completeness, 2.6.9-final-routeirq with pci=routeirq and no PIIX breaks:
https://jim.sh/svn/jim/devl/toughbook/log/routeirq-nopiix.txt
So it appears that the problem is very much related to the IDE
controller. That's a little bit surprising, because IDE was the only
thing that consistently worked when everything else broke.
-jim
prev parent reply other threads:[~2004-10-17 0:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-15 8:37 PCI IRQ problems: "nobody cared!" Jim Paris
2004-10-15 13:19 ` Alan Cox
2004-10-15 18:51 ` Jim Paris
2004-10-16 5:55 ` Len Brown
2004-10-17 0:12 ` Jim Paris [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041017001216.GA29461@jim.sh \
--to=jim@jtan.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bjorn.helgaas@hp.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox