linux-kernel - Re: PCI device problem - MMCONFIG, cannot allocate resource region, resource collisions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070523132634.A16545@jurassic.park.msu.ru>
Date:	Wed, 23 May 2007 13:26:34 +0400
From:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Wayne Sherman <wsherman@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: PCI device problem - MMCONFIG, cannot allocate resource region, resource collisions

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/