On Tue, 2005-07-26 at 17:49 -0500, Bryan J. Smith wrote:
There's the AMD8131 dual PCI-X HyperTransport Tunnel. The kernel was not seeing it at all before, which is why your PCI-X channels were useless.
Makes sense.
Why the kernel is not seeing it is beyond me. When you first posted, I didn't think a kernel flag would help because you were saying the BIOS didn't see it. You later then said it was, so I should have agreed with your prior assertion that a kernel flag might help.
I may not have mentioned that it was POSTing, but I guess it didn't strike me as significant (I wouldn't have expected to see it if it hadn't POSTed :).
Now here comes the biggie ... I typically use pci=nobios on a few mainboards when necessary. That's because pci=bios is (or was?) the default. So I didn't even think of it. The Boot Prompt HOWTO seems to collaborate this: http://www.tldp.org/HOWTO/BootPrompt-HOWTO-4.html#ss4.2
Now maybe I'm outta-date, since when did the default change to pci=nobios? Or maybe pci=bios now explicitly forces it to read the _entire_ BIOS configuration information, including extra PCI busses? This really disturbs me that the Linux kernel is not doing a good job of reading the entire PCI configuration from the BIOS -- unless there is a reason (stability?) for not doing so.
Of course, the nForce Pro 2200 + nForce Pro 2050 + AMD 8131 combination is new. Maybe the APIC settings aren't perfected. But then again, I'm still bothered that the kernel is supposed to read the BIOS by default, and your issue was solved by pci=bios which is supposed to be the default.
I believe the kernels use ACPI to enumerate PCI buses. Maybe a kernel guru could chime in? :) As one of the potential kernel parameters is pci=noacpi
noacpi [IA-32] Do not use ACPI for IRQ routing or for PCI scanning.
For S&G, I did try booting the machine with acpi=off and it panicd :)
[ BTW, where did you find this suggestion? ]
I was re-reading the various boot flag options in kernel-paramaters.txt (yum install kernel-doc), and I found a few that looked promising (see below). I tried pci=biosirq first (you can see why :), but then tried pci=bios
bios [IA-32] force use of PCI BIOS, don't access the hardware directly. Use this if your machine has a non-standard PCI host bridge.
biosirq [IA-32] Use PCI BIOS calls to get the interrupt routing table. These calls are known to be buggy on several machines and they hang the machine when used, but on other computers it's the only way to get the interrupt routing table. Try this option if the kernel is unable to allocate IRQs or discover secondary PCI buses on your motherboard.
I was also pondering the use of (but wasn't really sure how to go about the value of N).
lastbus=N [IA-32] Scan all buses till bus #N. Can be useful if the kernel is unable to find your secondary buses and you want to tell it explicitly which ones they are.
Also, as a further test, I reset the BIOS to their default settings and the machine works just fine. It looks a combination of updated BIOS and of course the kernel flags results in a functional machine.
I would venture to say it was just "pci=bios".
I'm fairly sure, but the newer BIOS seemed to have a few more options and reorganizes things a bit more nicely.
I would really like to know the "root cause" of this. Especially since there are literally a half-dozen PCI busses on that mainboard.
If someone has an RHEL account/entitlement (I don't), they could file a bug against the upstream kernel.
Sean