linux-kernel - Re: 2.6.20 PCI Cannot allocate resource region 2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1a297b360702060129n54f73e66qc753a2ccb35cb3cd@mail.gmail.com>
Date:	Tue, 6 Feb 2007 13:29:04 +0400
From:	"Manu Abraham" <abraham.manu@...il.com>
To:	"Grant Grundler" <grundler@...isc-linux.org>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-pci@...ey.karlin.mff.cuni.cz,
	greg@...ah.com
Subject: Re: 2.6.20 PCI Cannot allocate resource region 2

On 2/6/07, Manu Abraham <abraham.manu@...il.com> wrote:
> On 2/6/07, Grant Grundler <grundler@...isc-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@...isc-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.



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

View attachment "lspci_working.txt" of type "text/plain" (9220 bytes)