lkml.org 
[lkml]   [2007]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.20 PCI Cannot allocate resource region 2
    On 2/6/07, Grant Grundler <grundler@parisc-linux.org> wrote:
    > 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.


    ah, was thinking about this. :-)


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


    BIOS didn't say anything at all.


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

    BIST is supposed to terminate before, say the OS kernel is loaded ? or
    does it mean that it can keep running still ?

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

    was just wondering how it could be a 64 bit device.

    > hth,
    > grant
    >


    Thanks a lot for the valuable info. I had not ruled out the option
    that it could be broken.
    I will try the device in the other OS also, to confirm this. Will post
    the status after that.
    But most probably as you said, could be broken.

    Thanks,
    Manu
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-02-06 06:23    [W:0.027 / U:124.420 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site