Re: broadcom NetXtreme Gigabit

[Matthias Saou <thias spam spam spam spam spam spam spam egg and spam freshrpms net>]

Tom Sightler wrote :

> 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.

Thanks for the pci=noacpi trick. I lost two days not long ago, trying to
install Fedora Core 5 on a brand new Asus motherboard where the
installation didn't see either of the IDE or SATA buses. Fedora Core 3 ran
fine (I suspect it still defaulted to APM), and the problem was indeed
ACPI... the "big hammer" acpi=off did the trick, and oh so naive me
understood for the first time that "broken ACPI in the BIOS" hell wasn't
only present in the laptop world...

It did bother me a little to completely turn off ACPI, so I'll be trying
only for the PCI probing when I get a chance ;-)

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.16-1.2080_FC5
Load : 0.57 0.66 0.69