On Tue, May 22, 2007 at 04:31:22PM -0700, Jesse Barnes wrote:
> On Tuesday, May 22, 2007, Wayne Sherman wrote:
> > If so, the D-Link is not being mapped into the
> > right region, and the bridge it is behind does not have enough memory
> > assigned to it (ff500000-ff5fffff : PCI Bus #02).
>
> Sounds familiar. There are lots of cases where bridge windows aren't
> allocated properly so devices behind them are invisible or can't work.
> Check out the attached patch from Ivan, if you
> pass 'pci=assign-bus-resources' to your kernel at boot time, the code will
> try to reallocate bridge space for you if needed.
No, it won't help. The 1M range (ff500000-ff5fffff) is more than enough.
The reason why the D-Link resource is not getting assigned is rather
interesting: as Wayne wrote
> Here is the D-LINK NIC:
> # od -t x4 /sys/devices/pci0000:00/0000:00:14.4/0000:02:02.0/config
>
> 0000000 49011186 80b00117 00000011 00004010
^^^^^^
which means that the device class is 0 (not defined).
And in drivers/pci/setup-bus.c we have
/* Don't touch classless devices or host bridges or ioapics. */
if (class == PCI_CLASS_NOT_DEFINED ||
class == PCI_CLASS_BRIDGE_HOST)
continue;
The short term fix would be to assign proper device class to D-Link NIC
using pci quirk, but I believe a proper solution is to remove all sorts of
"if (class == PCI_xxx)" limitations (alpha, for example needs none of them)
from generic code and mark critical stuff with IORESOURCE_PCI_FIXED
in arch-specific way...
Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
