Re: broadcom NetXtreme Gigabit

[Tom Sightler <ttsig tuxyturvy com>]

On Tue, 2006-04-04 at 13:11 -0700, Stephen Mah wrote:
> Tom,
> 
> I have an update, I tried what you suggested. acpi=off and it seemed to 
> have done the trick. It's now detected with lspci and using the tg3 
> driver. Can you explain how that fixes the problem?

The acpi=off is probably a big hammer, I suspect that pci=noacpi might
be enough and won't completely disable ACPI if that's important to you.

I actually attempted to explain what might be the issue in the original
note, but perhaps I was not completely clear so I'll attempt to explain
in more detail.  This description is probably not perfectly accurate,
but I think it is generally correct.

Obviously your issue is caused by the fact that Linux is not properly
determining all of the PCI busses available on your hardware.  If it
fails to find the PCI bus then it obviously can't find any hardware that
might be connected to that bus.

By default the Linux 2.6 kernel attempt to use the information provided
by the BIOS ACPI tables to determine the PCI bus configuration, as an
example, take a look at the following output from one of my RHEL4 U3
systems (notice how it finds each PCI bus via ACPI and then probes it to
see what hardware is attached):

ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:0f.1
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Root Bridge [PCI4] (00:04)
PCI: Probing PCI hardware (bus 04)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI4.ZION._PRT]
ACPI: PCI Root Bridge [PCI3] (00:03)
PCI: Probing PCI hardware (bus 03)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI3._PRT]
ACPI: PCI Root Bridge [PCI2] (00:02)
PCI: Probing PCI hardware (bus 02)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI2._PRT]
ACPI: PCI Root Bridge [PCI1] (00:01)
PCI: Probing PCI hardware (bus 01)

Unfortunately many BIOS's have numerous bugs in their ACPI
implementations that can make such probing fail.  Many fail to
completely describe their hierarchy and of course some there are
probably some bugs in the Linux ACPI code as well.  If it's a buggy BIOS
in many cases you can get an upgraded BIOS for the system.

Anyway, the acpi=off feature basically tells the Linux kernel that the
system does not have ACPI.  Since the kernel thinks the system does not
have ACPI it must use an alternate method to discover the PCI bus layout
and thus falls back to a more brute force, probe the hardware method
similar to what was used with previous kernels (like what RHEL3 uses).

Using pci=noacpi tell Linux that, while the system in question may
indeed have ACPI, it should not trust the PCI bus information provided
by ACPI but instead to use the old PCI probing code, that way other ACPI
functions should still work.  When using non-ACPI PCI bus probing the
output is very different:

PCI: PCI BIOS revision 2.10 entry at 0xfc7ee, last bus=4
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Discovered primary peer bus 01 [IRQ]
PCI: Discovered primary peer bus 02 [IRQ]
PCI: Discovered primary peer bus 03 [IRQ]
PCI: Discovered primary peer bus 04 [IRQ]

I hope that explains it and that there aren't too many errors in the
above description.  I'd be interested in corrections on any points that
are not completely accurate.

Later,
Tom