Prev: [PATCH 2.6.19.2] r8169: support RTL8169SC/8110SC
Next: find_exported_dentry: npd != pd -> stale NFS file handle
From: Luming Yu on 4 Feb 2007 22:10
On 2/5/07, Manu Abraham <abraham.manu(a)gmail.com> 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
Just did a search about this message around the kernel source tree.
The interesting thing is that I see the following comments at several
different arch/drivers files. Is it related to your problem?

* Known BIOS problems we have to work around:
* - I/O or memory regions not configured
* - regions configured, but not enabled in the command register
* - bogus I/O addresses above 64K used
* - expansion ROMs left enabled (this may sound harmless, but given
* the fact the PCI specs explicitly allow address decoders to be
* shared between expansion ROMs and other resource regions, it's
* at least dangerous)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 4 Feb 2007 23:20
Luming Yu wrote:
>
> * Known BIOS problems we have to work around:
> * - bogus I/O addresses above 64K used

On non-x86 architectures this might be just fine.

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Manu Abraham on 5 Feb 2007 12:30
On 2/5/07, Luming Yu <luming.yu(a)gmail.com> wrote:
> On 2/5/07, Manu Abraham <abraham.manu(a)gmail.com> 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
> Just did a search about this message around the kernel source tree.
> The interesting thing is that I see the following comments at several
> different arch/drivers files. Is it related to your problem?
>
> * Known BIOS problems we have to work around:
> * - I/O or memory regions not configured
> * - regions configured, but not enabled in the command register
> * - bogus I/O addresses above 64K used
> * - expansion ROMs left enabled (this may sound harmless, but given
> * the fact the PCI specs explicitly allow address decoders to be
> * shared between expansion ROMs and other resource regions, it's
> * at least dangerous)
>

The card supports I/O addresses above 64k, i think. It has a PCMCIA
slot as well on it, allowing access to the same

I have put my dmesg over here http://kromtek.com/dvb/dmesg.txt It
looks like lot of workarounds in my BIOS to me probably, couldn't
really make out much in there

The bridge features from the vendor are like this ..

PCI 2.2 Compatible
DVB Common Interface EN50221 Compliant
Philips I2C 2.0 Compliant
Master mode
UART � RS232
Receiver mode
Support PTC PT2225
TSMC 0.25um 5M1P CMOS Technology
PQFP 144 Package

2.5V Core / 3.3V IO
2660x2560 um2
100K Gate
4 Clock Domains
99.6% ATPG Test Coverage
32 scan chains

Implementation
Logical
Logic synthesis � Synopsys 2003.12-SP1
Test synthesis � Synopsys DFTC 2003.12-SP1
Physical
P&R � Synopsys Astro 2003.06-SP2

Verification
Logical
Simulation � Cadence NCsim 5.1
Physical
DRC/LVS � Synopsys Hercules 2003.12


DVB Common Interface EN50221 Compliant
Memory Mode
CIS
Support 8/16 bit
IO Mode
Indirect Read/Write
Issue address and data thru PCI local register
Pseudo GPIO Pins
A12/A13/A14

Common Access (CA)
Card reader � 7816 compliant
DVB CSA / B-CAS Multi2
PID/session filters

UART
Receiver mode only � 6 bits data
Configurable BAUD rate
9600 to 115.2K
16 Word FIFO
I2C
Master mode only
400k/s default



One of the things that really confused me was, on 2.6.17.7 in lspci it
always shows BIST is running. on 2.6.20, it is not there at all.

If this is a bug in the BIOS, i am wondering how the older revisions
of the same bridge works. The last two devices in that lspci output
are Rev 01 devices


Regards,
Manu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Grant Grundler on 6 Feb 2007 00:00
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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Grant Grundler on 6 Feb 2007 00:10
On Mon, Feb 05, 2007 at 09:55:28PM -0700, Grant Grundler wrote:
....
> > 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.

Gregkh,
I just realized linux-pci bus scan should ignore devices (print a warning)
which have BIST set. Want a patch for this?

Slight risk some previously "working" device which violates the
spec might get ignored...but I hope there aren't too many of those.

grant
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: [PATCH 2.6.19.2] r8169: support RTL8169SC/8110SC
Next: find_exported_dentry: npd != pd -> stale NFS file handle