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]
Date:	Mon, 5 Feb 2007 21:55:28 -0700
From:	Grant Grundler <grundler@...isc-linux.org>
To:	Manu Abraham <abraham.manu@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-pci@...ey.karlin.mff.cuni.cz,
	greg@...ah.com, Andrew Morton <akpm@...l.org>
Subject: Re: 2.6.20 PCI Cannot allocate resource region 2

On Mon, Feb 05, 2007 at 05:09:01AM +0400, Manu Abraham wrote:
> Hi,
> 
> I get this error on booting up 2.6.20 (Similar error on 2.6.17.7 also,
> the message is slightly different in 2.6.17.7)
> 
> PCI Cannot allocate resource region 2 of device 0000:02:0a.0
> PCI Error while updating region 000:02:0a.0/5 (f3e00004 != 0200)
> PCI Error while updating region 000:02:0a.0/5 (high 00000000 != 4e351)

...
> The last 2 devices are Rev 1 chips, whereas the one which is acting a
> bit strange is a newer version from the same vendor.

> Any ideas as to why it could not allocate the region ?

Looks like the HW is broken.


This bridge:

> 00:1e.0 0604: 8086:244e (rev c2)
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> 	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> 	Latency: 0
> 	Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
> 	I/O behind bridge: 0000d000-0000dfff
> 	Memory behind bridge: f3e00000-f7efffff
> 	Prefetchable memory behind bridge: e9b00000-e9bfffff
> 	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR+
> 	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

will only route 0xf3e... to 0xf7efff... 
The attempt to assign f3e00004 is just trying to put a valid value in the BAR.
So I think linux is _trying_ to DTRT.

> 02:0a.0 4e35: 1800:4e35 (rev 08) (prog-if 18)
> 	Subsystem: 002c:c200
> 	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> 	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR+ <PERR+
> 	Latency: 0, Cache Line Size 0c
> 	BIST is running

BIST is required to complete in 2 seconds. Either with success or failure.
I expect BIOS to have complained before launching grub/lilo.
You might look for that on the next reboot and if possible use a
serial console to log all output or look for BIOS warnings or
logged "events".

But all bets are off regarding programming the device as
long as BIST is running. The only PCI requirement is the device
not interfere with "operation of other devices on the bus".


> 	Region 0: Memory at f7ee0000 (32-bit, non-prefetchable) [disabled] [size=4K]
> 	Region 2: Memory at e9b00000 (32-bit, prefetchable) [disabled] [size=4K]
> 	Region 3: Memory at <unassigned> (32-bit, prefetchable) [disabled]
> 	Region 4: Memory at <ignored> (32-bit, non-prefetchable) [disabled]
> 	Region 5: Memory at <invalid-64bit-slot> (64-bit, non-prefetchable) [disabled]

This is obviously garbage. 64-bit registers can only be represented with
two consecutive "BAR" and region 5 is the last one.
There is no way this can be a 64-bit BAR.
Generally, 64-bit BARs start on an "even" numbered BAR (but I've forgotten
again if that's just convention or a requirement)

hth,
grant
-
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/

Powered by blists - more mailing lists