Prev: [PATCH 2.6.19.2] r8169: support RTL8169SC/8110SC
Next: find_exported_dentry: npd != pd -> stale NFS file handle
From: Manu Abraham on 6 Feb 2007 00:30
On 2/6/07, Grant Grundler <grundler(a)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(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: Andrew Morton on 6 Feb 2007 00:40
On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <grundler(a)parisc-linux.org> wrote:

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

Should we wait two seconds before declaring the device dead? To see whether
it will come back?
-
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 6 Feb 2007 01:30
On 2/6/07, Andrew Morton <akpm(a)linux-foundation.org> wrote:
> On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <grundler(a)parisc-linux.org> wrote:
>
> > 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.
>
> Should we wait two seconds before declaring the device dead? To see whether
> it will come back?
>


Wonders !

I was about to give the card it's last rites. I thought well let me
try under the other OS

I didn't have any drivers for the same, since the demodulator driver
doesn't exist in the other OS also, but the bridge device does have
the driver.

I plugged the card in, the OS searched for drivers, since i didn't
have any didn't load any..
So it went under a question mark.

Looking under Resources,

It showed the PCI information string like this ..

PCI\VEN_1822&DEV_4E35&SUBSYS_00311822&REV_01\4&2E98101C&0&10F0

then i thought try with the driver eventhough support for the
demodulator doesn't exist ..

Downloaded and installed drivers ..

Lo ..!

Memory Range: F87FF000 - F87FFFFF
IRQ : 17

it got assigned a memory region indeed.

So, to wrap it up, the device is not dead .. We have something wrong
in the PCI subsystem probably.


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: Greg KH on 6 Feb 2007 01:30
On Mon, Feb 05, 2007 at 10:03:31PM -0700, Grant Grundler wrote:
> 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?

Yes, that would be good.

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

Odds are there are probably _way_ too many devices, but it can't hurt to
at least flag them as a broken card so that they can be fixed in the
future...

thanks,

greg k-h
-
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 02:10
On Tue, Feb 06, 2007 at 10:28:56AM +0400, Manu Abraham wrote:
> On 2/6/07, Andrew Morton <akpm(a)linux-foundation.org> wrote:
> >On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler
> ><grundler(a)parisc-linux.org> wrote:
> >
> >> 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.
> >
> >Should we wait two seconds before declaring the device dead? To see
> >whether
> >it will come back?
> >
>
>
> Wonders !
>
> I was about to give the card it's last rites. I thought well let me
> try under the other OS

Could you be more specific? Which OS? FreeBSD? :)


> I didn't have any drivers for the same, since the demodulator driver
> doesn't exist in the other OS also, but the bridge device does have
> the driver.
>
> I plugged the card in, the OS searched for drivers, since i didn't
> have any didn't load any..
> So it went under a question mark.
>
> Looking under Resources,
>
> It showed the PCI information string like this ..
>
> PCI\VEN_1822&DEV_4E35&SUBSYS_00311822&REV_01\4&2E98101C&0&10F0
>
> then i thought try with the driver eventhough support for the
> demodulator doesn't exist ..
>
> Downloaded and installed drivers ..
>
> Lo ..!
>
> Memory Range: F87FF000 - F87FFFFF
> IRQ : 17
>
> it got assigned a memory region indeed.

Excellent.

> So, to wrap it up, the device is not dead .. We have something wrong
> in the PCI subsystem probably.

Hrm maybe but not likely. I'm more inclined to believe PCI subsystem
is missing hacks needed for that device and/or BIOS.

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/
First  |  Prev  |  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