Messages in this thread | | | Date | Tue, 6 Feb 2007 13:06:17 +0400 | From | "Manu Abraham" <> | Subject | Re: 2.6.20 PCI Cannot allocate resource region 2 |
| |
On 2/6/07, Grant Grundler <grundler@parisc-linux.org> wrote: > On Mon, Feb 05, 2007 at 09:33:39PM -0800, Andrew Morton wrote: > > On Mon, 5 Feb 2007 22:03:31 -0700 Grant Grundler <grundler@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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |