LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Manu Abraham" <abraham.manu@gmail.com>
To: "Grant Grundler" <grundler@parisc-linux.org>
Cc: linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
	greg@kroah.com, "Andrew Morton" <akpm@osdl.org>
Subject: Re: 2.6.20 PCI Cannot allocate resource region 2
Date: Tue, 6 Feb 2007 09:20:15 +0400	[thread overview]
Message-ID: <1a297b360702052120x10f15b4cicaa867573d0210b9@mail.gmail.com> (raw)
In-Reply-To: <20070206045528.GA4228@colo.lackof.org>

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

  parent reply	other threads:[~2007-02-06  5:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-05  1:09 Manu Abraham
2007-02-05  3:04 ` Luming Yu
2007-02-05  4:16   ` H. Peter Anvin
2007-02-05 17:20   ` Manu Abraham
2007-02-06  4:55 ` Grant Grundler
2007-02-06  5:03   ` Grant Grundler
2007-02-06  5:33     ` Andrew Morton
2007-02-06  6:28       ` Manu Abraham
2007-02-06  7:04         ` Grant Grundler
2007-02-06  7:13           ` Manu Abraham
2007-02-06  8:46       ` Grant Grundler
2007-02-06  9:06         ` Manu Abraham
2007-02-06  9:29           ` Manu Abraham
2007-02-06 12:21             ` Luming Yu
2007-02-06 12:24               ` Manu Abraham
2007-02-06 12:56                 ` Manu Abraham
2007-02-06 12:56                   ` Manu Abraham
2007-02-07  4:19                 ` Luming Yu
2007-02-07  5:25                   ` Manu Abraham
2007-02-06 11:13         ` Manu Abraham
2007-02-06 11:52           ` Manu Abraham
2007-02-07  6:58             ` Grant Grundler
2007-02-08  5:26               ` Manu Abraham
2007-02-08  5:46               ` Manu Abraham
2007-02-06  6:24     ` Greg KH
2007-02-06  5:20   ` Manu Abraham [this message]
2007-02-06  8:25     ` Grant Grundler
2007-02-06  8:48       ` Manu Abraham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a297b360702052120x10f15b4cicaa867573d0210b9@mail.gmail.com \
    --to=abraham.manu@gmail.com \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --cc=grundler@parisc-linux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --subject='Re: 2.6.20 PCI Cannot allocate resource region 2' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).