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
--
Sean O'Connell
Office of Engineering Computing oconnell@xxxxxxxxxxxx
Jacobs School of Engineering, UCSD 858.534.9716 (49716)
