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 02:20
On 2/6/07, Grant Grundler <grundler(a)parisc-linux.org> wrote:
> 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? :)
>


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
-
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 03:30
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
-
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 03:50
On 2/6/07, Grant Grundler <grundler(a)parisc-linux.org> 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
-
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 03:50
On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton 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?

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
-
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 04:10
On 2/6/07, Grant Grundler <grundler(a)parisc-linux.org> 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 <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?
>
> 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
-
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