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)
lspci shows me a bit weird status BIST is running (on 2.6.17.7)
on 2.6.20, the line which says BIST is running, does not exist.
I have attached the lspci outputs on both 2.6.17.7 and 2.6.20
The device is a PCI 2.2 compliant device a multimedia bridge device
called Mantis.
The card is a plain 32 bit PCI card in a 32 bit PCI slot on an Asus
P4C800 motherboard.
looking at lspci output, the last 3 PCI devices are using the same chip.
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 ?
Thanks,
Manu
On 2/5/07, Manu Abraham <[email protected]> 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)
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
On 2/5/07, Luming Yu <[email protected]> wrote:
> On 2/5/07, Manu Abraham <[email protected]> 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
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
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
On 2/6/07, Grant Grundler <[email protected]> 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
On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[email protected]> 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?
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
On 2/6/07, Andrew Morton <[email protected]> wrote:
> On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[email protected]> 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
On Tue, Feb 06, 2007 at 10:28:56AM +0400, Manu Abraham wrote:
> On 2/6/07, Andrew Morton <[email protected]> wrote:
> >On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler
> ><[email protected]> 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
On 2/6/07, Grant Grundler <[email protected]> wrote:
> On Tue, Feb 06, 2007 at 10:28:56AM +0400, Manu Abraham wrote:
> > On 2/6/07, Andrew Morton <[email protected]> wrote:
> > >On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler
> > ><[email protected]> 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? :)
>
Hehe, we don't get question marks and stuff like that for those OS 's .. ;-)
M$ XP SP2
>
> > 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.
>
I have access to the source there, but there are no PCI specific
stuff, i think the NT HAL just handles all the PCI stuff over there.
It would be great , if we could have the missing hacks under Linux as well.
> grant
>
regards,
manu
On Tue, Feb 06, 2007 at 09:20:15AM +0400, Manu Abraham wrote:
...
> >BIST is required to complete in 2 seconds. Either with success or failure.
> >I expect BIOS to have complained before launching grub/lilo.
...
> BIST is supposed to terminate before, say the OS kernel is loaded?
Yes - that's what I was trying to imply above.
> or does it mean that it can keep running still ?
Don't know. Either it's still running (for much longer that 2 seconds),
linux is causing it run _again_, or linux is has terribly confused the
device somehow. More on this in an email I'm still working on...will
send that out in a bit.
> >> 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.
64-bit BAR is seperate from 64-bit Device (data path).
PCI has three different 32 vs 64-bit areas:
o BARs
o DMA
o HW/data path width.
"32-bit device" generally only refers to the latter.
The three attributes are generally all "32-bit" for "32-bit device".
That's less likely to be true for "64-bit devices". Several "64-bit
devices" can only DMA to 32-bit host memory and at least a few only
support 32-bit BARs (even if the device claims it has a 64-bit BAR).
hth,
grant
>
> >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
On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote:
> On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[email protected]> 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?
Hrm...my thought was BIOS should already be doing that...but I just
realised 2 seconds have elapsed if Manu can collect "lspci" output showing
"BIST is running". I think the fact that BIST is not "running" in the
2.6.20-rc7 lspci output is just coincidental. The config space for that
device is full of similar garbage in both cases regardless how long
it took.
Maybe BIOS is clobbering BIST when writing latency timer or cacheline size
register and BIOS is not being careful to clear or disable the other
bytes in that same 32-bit word?
PCI is by nature a 32-bit wide config space and "byte enables"
are used to mask off bytes we want to ignore. If the chipset
or BIOS config access routines aren't careful, they could accidentally
modify other values in the same 32-bit word when only one byte was
intended to be changed.
The code in pci_set_cacheline_size() uses byte enables but is only
called by pci_set_mwi(). 82 different .c files (124 instances) access
PCI_LATENCY_TIMER. Of those, 68 are pci_write_config_byte() calls.
But I really only care about the calls what would apply get invoked
for 1822:4e35. My guess is this one always gets invoked:
./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]".
(http://pci-ids.ucw.cz/iii/?i=1822)
pci_enable_bridges() -> pci_set_master() -> pcibios_set_master().
Manu, can you add code to pci_enable_bridges() to dump information about
which bridges are getting enabled _before_ pci_set_master() is called?
I'm interested in a hex dump of the first 8 32-bit words of
PCI config space for each device.
BTW, I wasn't planning declaring the device as dead. I just wanted to
pretend it didn't exist and then let something else (user space? timeout?)
trigger a rescan of that bus/"slot". That trigger could come in a successive
patch which also removes the 2 second polling loop.
grant
On 2/6/07, Grant Grundler <[email protected]> wrote:
> On Tue, Feb 06, 2007 at 09:20:15AM +0400, Manu Abraham wrote:
> ...
> > >BIST is required to complete in 2 seconds. Either with success or failure.
> > >I expect BIOS to have complained before launching grub/lilo.
> ...
> > BIST is supposed to terminate before, say the OS kernel is loaded?
>
> Yes - that's what I was trying to imply above.
>
> > or does it mean that it can keep running still ?
>
> Don't know. Either it's still running (for much longer that 2 seconds),
> linux is causing it run _again_, or linux is has terribly confused the
> device somehow. More on this in an email I'm still working on...will
> send that out in a bit.
i think probably, Linux is causing it to run again .. ?
> > >> 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.
>
> 64-bit BAR is seperate from 64-bit Device (data path).
>
> PCI has three different 32 vs 64-bit areas:
> o BARs
> o DMA
> o HW/data path width.
>
> "32-bit device" generally only refers to the latter.
> The three attributes are generally all "32-bit" for "32-bit device".
According to the information i have on this device ..
Configuration Register 00H : Device_ID / Vendor_ID Register
Bit [31:16] R Device_ID Device ID = 16'h4e35
Bit [15:0] R Vendor_ID Vendor ID = 16'h1822
Configuration Register 04H : Status / Command Register
Bit 31 R Detpar_rpt Detect Parity Report
Bit 30 W/R System_err Indicate System Error
Bit 29 R Master_abort Indicate Master Abort
Bit 28 R Target_abort Indicate Target Abort
Bit [27:25] Default = 3'b001
Bit 24 R Datapar_rpt Data Parity Report
Bit [23:20] Default = 4'b0000
Bit [19:16] Default = 4'b0000
Bit [15:9] Default = 7'h0
Bit 8 W/R Pci_serr_en PCI system error enable
Bit 7 Default = 1'b0
Bit 6 W/R Pci_perr_en PCI parity error enable
Bit [5:3] Default = 3'h0
Bit 2 W/R Pci_master_en PCI master mode enable
Bit 1 W/R Pci_target_en PCI target mode enable
Bit 0 Default = 1'b0
Configuration Register 08H : Class_Code / Revision_ID Register
Bit [31:8] R Class_Code Class_Code = 24'h048000
Bit [7:0] R Revision_ID Revision_ID = 8'h01
Configuration Register 0CH : Latency Timer Register
Bit [31:16] Default = 16'h0
Bit [15:11] W/R Pci_lat_timer Indicate PCI latency timer
Bit [10:8] Default = 3'h0
Bit [7:0] Default = 8'b0
Configuration Register 10H : Base_Address / Memory&Prep Register
Bit [31:12] W/R Pci_base_addr Indicate PCI Base Address
Bit [31:0] R Default = 12'h008
Configuration Register 2CH : I2C Subsystem_ID / Subsystem_Vendor_ID Register
Bit [31:0] W/R I2c_ssid_ssvid Indicate I2C subsystem_ID / subsystem_vendor_ID
Configuration Register 38H : Test PCI Connection Register
Bit [31:0] W/R Test_pci_conn Indicate to test PCI connection
Configuration Register 3CH : Max_Latency / Min_Gnt / Int_Pin / Int_Line Register
Bit [31:24] W Max_lat Default = 8'hFF
Bit [23:16] W Min_gnt Default = 8'h08
Bit [15:8] W Int_pin Default = 8'h01
Bit [7:0] W/R Int_line Indicate interrupt line
> That's less likely to be true for "64-bit devices". Several "64-bit
> devices" can only DMA to 32-bit host memory and at least a few only
> support 32-bit BARs (even if the device claims it has a 64-bit BAR).
>
AFAIK, the device does 32 bit DMA, but it is not completely hardware driven DMA.
it just uses a RISC core which just jumps to the pointer allocated in software.
The other devices using the same chip, works that way.
> hth,
> grant
thanks,
manu
On 2/6/07, Grant Grundler <[email protected]> wrote:
> On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote:
> > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[email protected]> 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?
>
> Hrm...my thought was BIOS should already be doing that...but I just
> realised 2 seconds have elapsed if Manu can collect "lspci" output showing
> "BIST is running". I think the fact that BIST is not "running" in the
> 2.6.20-rc7 lspci output is just coincidental. The config space for that
> device is full of similar garbage in both cases regardless how long
> it took.
>
waited for more than 30 mins as well, well almost the entire night,
BIST didn't stop
> Maybe BIOS is clobbering BIST when writing latency timer or cacheline size
> register and BIOS is not being careful to clear or disable the other
> bytes in that same 32-bit word?
>
If the BIOS is clobbering the BIST, then the same should happen in the
other OS as well ?
Just plugging in the card, without any drivers, got me the PCI vendor info.
> PCI is by nature a 32-bit wide config space and "byte enables"
> are used to mask off bytes we want to ignore. If the chipset
> or BIOS config access routines aren't careful, they could accidentally
> modify other values in the same 32-bit word when only one byte was
> intended to be changed.
>
> The code in pci_set_cacheline_size() uses byte enables but is only
> called by pci_set_mwi(). 82 different .c files (124 instances) access
> PCI_LATENCY_TIMER. Of those, 68 are pci_write_config_byte() calls.
> But I really only care about the calls what would apply get invoked
> for 1822:4e35. My guess is this one always gets invoked:
> ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
>
> since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]".
> (http://pci-ids.ucw.cz/iii/?i=1822)
> pci_enable_bridges() -> pci_set_master() -> pcibios_set_master().
>
> Manu, can you add code to pci_enable_bridges() to dump information about
> which bridges are getting enabled _before_ pci_set_master() is called?
> I'm interested in a hex dump of the first 8 32-bit words of
> PCI config space for each device.
>
let me give it a shot.
> BTW, I wasn't planning declaring the device as dead. I just wanted to
> pretend it didn't exist and then let something else (user space? timeout?)
> trigger a rescan of that bus/"slot". That trigger could come in a successive
> patch which also removes the 2 second polling loop.
maybe the driver can do a rescan ?
>
> grant
>
thanks,
manu
On 2/6/07, Manu Abraham <[email protected]> wrote:
> On 2/6/07, Grant Grundler <[email protected]> wrote:
> > On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote:
> > > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[email protected]> 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?
> >
> > Hrm...my thought was BIOS should already be doing that...but I just
> > realised 2 seconds have elapsed if Manu can collect "lspci" output showing
> > "BIST is running". I think the fact that BIST is not "running" in the
> > 2.6.20-rc7 lspci output is just coincidental. The config space for that
> > device is full of similar garbage in both cases regardless how long
> > it took.
> >
>
> waited for more than 30 mins as well, well almost the entire night,
> BIST didn't stop
>
>
> > Maybe BIOS is clobbering BIST when writing latency timer or cacheline size
> > register and BIOS is not being careful to clear or disable the other
> > bytes in that same 32-bit word?
> >
>
>
> If the BIOS is clobbering the BIST, then the same should happen in the
> other OS as well ?
> Just plugging in the card, without any drivers, got me the PCI vendor info.
>
>
> > PCI is by nature a 32-bit wide config space and "byte enables"
> > are used to mask off bytes we want to ignore. If the chipset
> > or BIOS config access routines aren't careful, they could accidentally
> > modify other values in the same 32-bit word when only one byte was
> > intended to be changed.
> >
> > The code in pci_set_cacheline_size() uses byte enables but is only
> > called by pci_set_mwi(). 82 different .c files (124 instances) access
> > PCI_LATENCY_TIMER. Of those, 68 are pci_write_config_byte() calls.
> > But I really only care about the calls what would apply get invoked
> > for 1822:4e35. My guess is this one always gets invoked:
> > ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
> >
> > since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]".
> > (http://pci-ids.ucw.cz/iii/?i=1822)
> > pci_enable_bridges() -> pci_set_master() -> pcibios_set_master().
> >
> > Manu, can you add code to pci_enable_bridges() to dump information about
> > which bridges are getting enabled _before_ pci_set_master() is called?
> > I'm interested in a hex dump of the first 8 32-bit words of
> > PCI config space for each device.
> >
>
> let me give it a shot.
dang !
rebooted it into 2.6.17.7
no errors, during a bootup, BIST isn't running anymore
running M$ did change the status from dead to alive ??? shocked !!
attached lspci output in the very same setup as earlier, no difference
in anything, except that it was rebooted into windows.
the PCI config dump would help ?
regards,
manu
On 2/6/07, Grant Grundler <[email protected]> wrote:
> On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote:
> > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[email protected]> 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?
>
> Hrm...my thought was BIOS should already be doing that...but I just
> realised 2 seconds have elapsed if Manu can collect "lspci" output showing
> "BIST is running". I think the fact that BIST is not "running" in the
> 2.6.20-rc7 lspci output is just coincidental. The config space for that
> device is full of similar garbage in both cases regardless how long
> it took.
>
> Maybe BIOS is clobbering BIST when writing latency timer or cacheline size
> register and BIOS is not being careful to clear or disable the other
> bytes in that same 32-bit word?
>
> PCI is by nature a 32-bit wide config space and "byte enables"
> are used to mask off bytes we want to ignore. If the chipset
> or BIOS config access routines aren't careful, they could accidentally
> modify other values in the same 32-bit word when only one byte was
> intended to be changed.
>
> The code in pci_set_cacheline_size() uses byte enables but is only
> called by pci_set_mwi(). 82 different .c files (124 instances) access
> PCI_LATENCY_TIMER. Of those, 68 are pci_write_config_byte() calls.
> But I really only care about the calls what would apply get invoked
> for 1822:4e35. My guess is this one always gets invoked:
> ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
>
> since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]".
> (http://pci-ids.ucw.cz/iii/?i=1822)
> pci_enable_bridges() -> pci_set_master() -> pcibios_set_master().
>
> Manu, can you add code to pci_enable_bridges() to dump information about
> which bridges are getting enabled _before_ pci_set_master() is called?
>
> I'm interested in a hex dump of the first 8 32-bit words of
> PCI config space for each device.
>
attaching a dump of the regs (on 2.6.17.7) as well as the diff
regards,
manu
On 2/6/07, Manu Abraham <[email protected]> wrote:
> On 2/6/07, Grant Grundler <[email protected]> wrote:
> > On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote:
> > > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <[email protected]> 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?
> >
> > Hrm...my thought was BIOS should already be doing that...but I just
> > realised 2 seconds have elapsed if Manu can collect "lspci" output showing
> > "BIST is running". I think the fact that BIST is not "running" in the
> > 2.6.20-rc7 lspci output is just coincidental. The config space for that
> > device is full of similar garbage in both cases regardless how long
> > it took.
> >
> > Maybe BIOS is clobbering BIST when writing latency timer or cacheline size
> > register and BIOS is not being careful to clear or disable the other
> > bytes in that same 32-bit word?
> >
> > PCI is by nature a 32-bit wide config space and "byte enables"
> > are used to mask off bytes we want to ignore. If the chipset
> > or BIOS config access routines aren't careful, they could accidentally
> > modify other values in the same 32-bit word when only one byte was
> > intended to be changed.
> >
> > The code in pci_set_cacheline_size() uses byte enables but is only
> > called by pci_set_mwi(). 82 different .c files (124 instances) access
> > PCI_LATENCY_TIMER. Of those, 68 are pci_write_config_byte() calls.
> > But I really only care about the calls what would apply get invoked
> > for 1822:4e35. My guess is this one always gets invoked:
> > ./arch/i386/pci/i386.c: pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
> >
> > since the offending device is "Mantis DTV PCI Bridge Controller [Ver 1.0]".
> > (http://pci-ids.ucw.cz/iii/?i=1822)
> > pci_enable_bridges() -> pci_set_master() -> pcibios_set_master().
> >
> > Manu, can you add code to pci_enable_bridges() to dump information about
> > which bridges are getting enabled _before_ pci_set_master() is called?
> >
> > I'm interested in a hex dump of the first 8 32-bit words of
> > PCI config space for each device.
> >
>
> attaching a dump of the regs (on 2.6.17.7) as well as the diff
>
The device now works, used the demodulator driver alongwith the bridge driver.
inlined the log
regards,
manu
[17181623.040000] gpif status: 6000 irqcfg: 0000
[17181623.040000] irq: 18, latency: 64
[17181623.040000] memory: 0xefeff000, mmio: 0xe18f4000
[17181623.040000] found a UNKNOWN PCI UNKNOWN device on (02:0a.0),
[17181623.040000] Mantis Rev 1 [1822:0031], irq: 18, latency: 64
[17181623.040000] memory: 0xefeff000, mmio: 0xe18f4000
[17181623.040000] mantis_i2c_write: Address=[0x50] <W>[ 08 ]
[17181623.040000] mantis_i2c_read: Address=[0x50] <R>[ 00 00
00 00 00 00 ]
[17181623.044000] MAC Address=[00:00:00:00:00:00]
[17181623.044000] mantis_alloc_buffers (0): DMA=0x186b0000
cpu=0xd86b0000 size=65536
[17181623.044000] mantis_alloc_buffers (0): RISC=0x1c3af000
cpu=0xdc3af000 size=1000
[17181623.044000] DVB: registering new adapter (Mantis dvb adapter).
[17181623.564000] mantis_frontend_init (0): Probing for STB0899
(DVB-S/DSS/DVB-S2)
[17181623.564000] stb0899_write_regs [0xf1b6]: 02
[17181623.564000] mantis_i2c_write: Address=[0x68] <W>[ f1 b6 02 ]
[17181623.564000] stb0899_write_regs [0xf1c2]: 00
[17181623.564000] mantis_i2c_write: Address=[0x68] <W>[ f1 c2 00 ]
[17181623.568000] stb0899_write_regs [0xf1c3]: 00
[17181623.568000] mantis_i2c_write: Address=[0x68] <W>[ f1 c3 00 ]
[17181623.568000] mantis_i2c_write: Address=[0x68] <W>[ f0 00 ]
[17181623.568000] mantis_i2c_read: Address=[0x68] <R>[ 82 ]
[17181623.568000] stb0899_read_reg: Reg=[0xf000], data=82
[17181623.568000] stb0899_get_dev_id: Device ID=[8], Release=[2]
[17181623.568000] mantis_i2c_write: Address=[0x68] <W>[ f3 fc
00 04 00 00 ]
[17181623.572000] mantis_i2c_write: Address=[0x68] <W>[ f3 34 ]
[17181623.572000] mantis_i2c_read: Address=[0x68] <R>[ 31 44 4d 44 ]
[17181623.572000] mantis_i2c_write: Address=[0x68] <W>[ f3 34 ]
[17181623.572000] mantis_i2c_read: Address=[0x68] <R>[ 31 44 4d 44 ]
[17181623.576000] stb0899_read_s2reg Device=[0xf3fc], Base
address=[0x00000400], Offset=[0xf334], Data=[0x444d4431]
[17181623.576000] mantis_i2c_write: Address=[0x68] <W>[ f3 fc
00 04 00 00 ]
[17181623.576000] mantis_i2c_write: Address=[0x68] <W>[ f3 00 ]
[17181623.576000] mantis_i2c_read: Address=[0x68] <R>[ 01 00 00 00 ]
[17181623.580000] mantis_i2c_write: Address=[0x68] <W>[ f3 3c ]
[17181623.580000] mantis_i2c_read: Address=[0x68] <R>[ 01 00 00 00 ]
[17181623.580000] stb0899_read_s2reg Device=[0xf3fc], Base
address=[0x00000400], Offset=[0xf33c], Data=[0x00000001]
[17181623.580000] stb0899_get_dev_id: Demodulator Core ID=[DMD1], Version=[1]
[17181623.580000] mantis_i2c_write: Address=[0x68] <W>[ fa fc
00 08 00 00 ]
[17181623.584000] mantis_i2c_write: Address=[0x68] <W>[ fa 00 ]
[17181623.584000] mantis_i2c_read: Address=[0x68] <R>[ 4c 00 00 00 ]
[17181623.588000] mantis_i2c_write: Address=[0x68] <W>[ fa 2c ]
[17181623.588000] mantis_i2c_read: Address=[0x68] <R>[ 31 43 45 46 ]
[17181623.588000] stb0899_read_s2reg Device=[0xfafc], Base
address=[0x00000800], Offset=[0xfa2c], Data=[0x46454331]
[17181623.588000] mantis_i2c_write: Address=[0x68] <W>[ fa fc
00 08 00 00 ]
[17181623.592000] mantis_i2c_write: Address=[0x68] <W>[ fa 34 ]
[17181623.592000] mantis_i2c_read: Address=[0x68] <R>[ 01 00 00 00 ]
[17181623.592000] mantis_i2c_write: Address=[0x68] <W>[ fa 34 ]
[17181623.592000] mantis_i2c_read: Address=[0x68] <R>[ 01 00 00 00 ]
[17181623.596000] stb0899_read_s2reg Device=[0xfafc], Base
address=[0x00000800], Offset=[0xfa34], Data=[0x00000001]
[17181623.596000] stb0899_get_dev_id: FEC Core ID=[FEC1], Version=[1]
[17181623.596000] stb0899_attach: Attaching STB0899
[17181623.596000] mantis_frontend_init (0): found STB0899
DVB-S/DSS/DVB-S2 frontend @0x68
[17181623.596000] mantis_frontend_init (0): Probing for STB6100 tuner
[17181623.596000] stb6100_attach: Attaching
[17181623.596000] mantis_frontend_init (0): found STB6100 tuner @0x60
[17181623.596000] mantis_frontend_init (0): Probing for LNBP21 SEC
[17181623.596000] mantis_i2c_write: Address=[0x08] <W>[ 40 ]
[17181623.596000] DVB: registering frontend 0 (STB0899 Multistandard)...
> dang !
>
> rebooted it into 2.6.17.7
>
> no errors, during a bootup, BIST isn't running anymore
> running M$ did change the status from dead to alive ??? shocked !!
Interesting! does windows driver fixes the broken firmware/flash on this card?
>
> attached lspci output in the very same setup as earlier, no difference
> in anything, except that it was rebooted into windows.
>
> the PCI config dump would help ?
>
I guess you would never reproduce this issue again unless you can
restore the broken firmware/flash on this card. :-)
On 2/6/07, Luming Yu <[email protected]> wrote:
> > dang !
> >
> > rebooted it into 2.6.17.7
> >
> > no errors, during a bootup, BIST isn't running anymore
> > running M$ did change the status from dead to alive ??? shocked !!
>
> Interesting! does windows driver fixes the broken firmware/flash on this card?
No firmware/flash on the card.
>
> >
> > attached lspci output in the very same setup as earlier, no difference
> > in anything, except that it was rebooted into windows.
> >
> > the PCI config dump would help ?
> >
>
> I guess you would never reproduce this issue again unless you can
> restore the broken firmware/flash on this card. :-)
>
none on the card, a flash or a firmware .. it has a 24c02 EEPROM for
vendor information, that's all
regards,
manu
On 2/6/07, Manu Abraham <[email protected]> wrote:
> On 2/6/07, Luming Yu <[email protected]> wrote:
> > > dang !
> > >
> > > rebooted it into 2.6.17.7
> > >
> > > no errors, during a bootup, BIST isn't running anymore
> > > running M$ did change the status from dead to alive ??? shocked !!
> >
> > Interesting! does windows driver fixes the broken firmware/flash on this card?
>
>
> No firmware/flash on the card.
>
>
> >
> > >
> > > attached lspci output in the very same setup as earlier, no difference
> > > in anything, except that it was rebooted into windows.
> > >
> > > the PCI config dump would help ?
> > >
> >
> > I guess you would never reproduce this issue again unless you can
> > restore the broken firmware/flash on this card. :-)
> >
>
> none on the card, a flash or a firmware .. it has a 24c02 EEPROM for
> vendor information, that's all
>
You can see the same from this picture
regards,
manu
On 2/6/07, Manu Abraham <[email protected]> wrote:
> On 2/6/07, Manu Abraham <[email protected]> wrote:
> > On 2/6/07, Luming Yu <[email protected]> wrote:
> > > > dang !
> > > >
> > > > rebooted it into 2.6.17.7
> > > >
> > > > no errors, during a bootup, BIST isn't running anymore
> > > > running M$ did change the status from dead to alive ??? shocked !!
> > >
> > > Interesting! does windows driver fixes the broken firmware/flash on this card?
> >
> >
> > No firmware/flash on the card.
> >
> >
> > >
> > > >
> > > > attached lspci output in the very same setup as earlier, no difference
> > > > in anything, except that it was rebooted into windows.
> > > >
> > > > the PCI config dump would help ?
> > > >
> > >
> > > I guess you would never reproduce this issue again unless you can
> > > restore the broken firmware/flash on this card. :-)
> > >
> >
> > none on the card, a flash or a firmware .. it has a 24c02 EEPROM for
> > vendor information, that's all
> >
>
> You can see the same from this picture
http://abraham.manu.googlepages.com/p3130016.jpg
>
> regards,
> manu
>
> none on the card, a flash or a firmware .. it has a 24c02 EEPROM for
> vendor information, that's all
Ok, sounds like windows driver can fix the broken EEPROM on you card.
Otherwise, I can not explain how windows driver can fix the problem for linux.
Anyway, this issue is NOT linux problem. right?
On 2/7/07, Luming Yu <[email protected]> wrote:
> > none on the card, a flash or a firmware .. it has a 24c02 EEPROM for
> > vendor information, that's all
>
> Ok, sounds like windows driver can fix the broken EEPROM on you card.
> Otherwise, I can not explain how windows driver can fix the problem for linux.
I have the windows driver sources for the device, it does _not_ write
anything to the EEPROM under any circumstance.
moreover the EEPROM is write protected in hardware by a jumper. So no
application can write to it, AFAICS
> Anyway, this issue is NOT linux problem. right?
>
I am not very sure about that.
really i am thinking this way .. On booting up windows, it could have
changed some BIOS stuff (written something to NVRAM or something like
that ?).. that's the only possibility that i can see here.
really lost on this one.
regards,
manu
On Tue, Feb 06, 2007 at 03:52:47PM +0400, Manu Abraham wrote:
> >attaching a dump of the regs (on 2.6.17.7) as well as the diff
>
> The device now works, used the demodulator driver alongwith the bridge
> driver.
Ok - thanks for the dmesg output and log. I suspect you've already
tried cycling power on the machine (If not, please do).
I have no idea what M$ XP was doing that might "fix" the problem.
I was just suspicious of our byte accesses to the same dword.
To answer you previous question, it's possible that M$ only
uses dword accesses. I don't know.
> inlined the log
excellent - sounds like you are making forward progress even
if we can not reproduce the problem...worst case other users
(or customers) have a "work around" :^/
thanks,
grant
ps. I'll be unavailable until this weekend when I want to look at
the old and new logs a bit more.
>
> regards,
> manu
>
>
> [17181623.040000] gpif status: 6000 irqcfg: 0000
> [17181623.040000] irq: 18, latency: 64
> [17181623.040000] memory: 0xefeff000, mmio: 0xe18f4000
> [17181623.040000] found a UNKNOWN PCI UNKNOWN device on (02:0a.0),
> [17181623.040000] Mantis Rev 1 [1822:0031], irq: 18, latency: 64
> [17181623.040000] memory: 0xefeff000, mmio: 0xe18f4000
> [17181623.040000] mantis_i2c_write: Address=[0x50] <W>[ 08 ]
> [17181623.040000] mantis_i2c_read: Address=[0x50] <R>[ 00 00
> 00 00 00 00 ]
> [17181623.044000] MAC Address=[00:00:00:00:00:00]
> [17181623.044000] mantis_alloc_buffers (0): DMA=0x186b0000
> cpu=0xd86b0000 size=65536
> [17181623.044000] mantis_alloc_buffers (0): RISC=0x1c3af000
> cpu=0xdc3af000 size=1000
> [17181623.044000] DVB: registering new adapter (Mantis dvb adapter).
> [17181623.564000] mantis_frontend_init (0): Probing for STB0899
> (DVB-S/DSS/DVB-S2)
> [17181623.564000] stb0899_write_regs [0xf1b6]: 02
> [17181623.564000] mantis_i2c_write: Address=[0x68] <W>[ f1 b6 02 ]
> [17181623.564000] stb0899_write_regs [0xf1c2]: 00
> [17181623.564000] mantis_i2c_write: Address=[0x68] <W>[ f1 c2 00 ]
> [17181623.568000] stb0899_write_regs [0xf1c3]: 00
> [17181623.568000] mantis_i2c_write: Address=[0x68] <W>[ f1 c3 00 ]
> [17181623.568000] mantis_i2c_write: Address=[0x68] <W>[ f0 00 ]
> [17181623.568000] mantis_i2c_read: Address=[0x68] <R>[ 82 ]
> [17181623.568000] stb0899_read_reg: Reg=[0xf000], data=82
> [17181623.568000] stb0899_get_dev_id: Device ID=[8], Release=[2]
> [17181623.568000] mantis_i2c_write: Address=[0x68] <W>[ f3 fc
> 00 04 00 00 ]
> [17181623.572000] mantis_i2c_write: Address=[0x68] <W>[ f3 34 ]
> [17181623.572000] mantis_i2c_read: Address=[0x68] <R>[ 31 44 4d 44
> ]
> [17181623.572000] mantis_i2c_write: Address=[0x68] <W>[ f3 34 ]
> [17181623.572000] mantis_i2c_read: Address=[0x68] <R>[ 31 44 4d 44
> ]
> [17181623.576000] stb0899_read_s2reg Device=[0xf3fc], Base
> address=[0x00000400], Offset=[0xf334], Data=[0x444d4431]
> [17181623.576000] mantis_i2c_write: Address=[0x68] <W>[ f3 fc
> 00 04 00 00 ]
> [17181623.576000] mantis_i2c_write: Address=[0x68] <W>[ f3 00 ]
> [17181623.576000] mantis_i2c_read: Address=[0x68] <R>[ 01 00 00 00
> ]
> [17181623.580000] mantis_i2c_write: Address=[0x68] <W>[ f3 3c ]
> [17181623.580000] mantis_i2c_read: Address=[0x68] <R>[ 01 00 00 00
> ]
> [17181623.580000] stb0899_read_s2reg Device=[0xf3fc], Base
> address=[0x00000400], Offset=[0xf33c], Data=[0x00000001]
> [17181623.580000] stb0899_get_dev_id: Demodulator Core ID=[DMD1],
> Version=[1]
> [17181623.580000] mantis_i2c_write: Address=[0x68] <W>[ fa fc
> 00 08 00 00 ]
> [17181623.584000] mantis_i2c_write: Address=[0x68] <W>[ fa 00 ]
> [17181623.584000] mantis_i2c_read: Address=[0x68] <R>[ 4c 00 00 00
> ]
> [17181623.588000] mantis_i2c_write: Address=[0x68] <W>[ fa 2c ]
> [17181623.588000] mantis_i2c_read: Address=[0x68] <R>[ 31 43 45 46
> ]
> [17181623.588000] stb0899_read_s2reg Device=[0xfafc], Base
> address=[0x00000800], Offset=[0xfa2c], Data=[0x46454331]
> [17181623.588000] mantis_i2c_write: Address=[0x68] <W>[ fa fc
> 00 08 00 00 ]
> [17181623.592000] mantis_i2c_write: Address=[0x68] <W>[ fa 34 ]
> [17181623.592000] mantis_i2c_read: Address=[0x68] <R>[ 01 00 00 00
> ]
> [17181623.592000] mantis_i2c_write: Address=[0x68] <W>[ fa 34 ]
> [17181623.592000] mantis_i2c_read: Address=[0x68] <R>[ 01 00 00 00
> ]
> [17181623.596000] stb0899_read_s2reg Device=[0xfafc], Base
> address=[0x00000800], Offset=[0xfa34], Data=[0x00000001]
> [17181623.596000] stb0899_get_dev_id: FEC Core ID=[FEC1], Version=[1]
> [17181623.596000] stb0899_attach: Attaching STB0899
> [17181623.596000] mantis_frontend_init (0): found STB0899
> DVB-S/DSS/DVB-S2 frontend @0x68
> [17181623.596000] mantis_frontend_init (0): Probing for STB6100 tuner
> [17181623.596000] stb6100_attach: Attaching
> [17181623.596000] mantis_frontend_init (0): found STB6100 tuner @0x60
> [17181623.596000] mantis_frontend_init (0): Probing for LNBP21 SEC
> [17181623.596000] mantis_i2c_write: Address=[0x08] <W>[ 40 ]
> [17181623.596000] DVB: registering frontend 0 (STB0899 Multistandard)...
On 2/7/07, Grant Grundler <[email protected]> wrote:
> On Tue, Feb 06, 2007 at 03:52:47PM +0400, Manu Abraham wrote:
> > >attaching a dump of the regs (on 2.6.17.7) as well as the diff
> >
> > The device now works, used the demodulator driver alongwith the bridge
> > driver.
>
> Ok - thanks for the dmesg output and log. I suspect you've already
> tried cycling power on the machine (If not, please do).
I did power cycling on the machine .. did try pulling out the power
cord out for a while as well, to check whether it is some "fix that
just evaporated"
> I have no idea what M$ XP was doing that might "fix" the problem.
>
> I was just suspicious of our byte accesses to the same dword.
> To answer you previous question, it's possible that M$ only
> uses dword accesses. I don't know.
>
someone who has access to NT HAL inside ideas (maybe a too far deam) ,
could probably explain ?
> > inlined the log
>
> excellent - sounds like you are making forward progress even
> if we can not reproduce the problem...worst case other users
> (or customers) have a "work around" :^/
Sounds like a horrible workaround . :-)
I am thinking more in the direction of something wrong in the BIOS, as
that is the only dark area, where i can't see/understand anything.
regards,
manu
On 2/7/07, Grant Grundler <[email protected]> wrote:
> On Tue, Feb 06, 2007 at 03:52:47PM +0400, Manu Abraham wrote:
> > >attaching a dump of the regs (on 2.6.17.7) as well as the diff
> >
> > The device now works, used the demodulator driver alongwith the bridge
> > driver.
>
> Ok - thanks for the dmesg output and log. I suspect you've already
> tried cycling power on the machine (If not, please do).
> I have no idea what M$ XP was doing that might "fix" the problem.
>
> I was just suspicious of our byte accesses to the same dword.
> To answer you previous question, it's possible that M$ only
> uses dword accesses. I don't know.
Does it sound too weird, if our PCI accesses could accidentally
overwrite EEPROM contents on cards that have the EEPROM, R/W ?
we came across with lot of issues on the same unfortunately under
Linux only this issues comes up, we used to sling mud at each other,
probably for bad I2C communications on a BT878 based chip.
Recently, somebody came across a strange case where, booting into
Windows , fixed his EEPROM contents. Since i have the driver sources
for the described card from the vendor for windows, i don't see how
any way in which the Windows driver does rewriting the EEPROM.
http://thread.gmane.org/gmane.linux.drivers.dvb/23911/focus=31185
Does this have any relation to the current situation ?
regards,
manu
