LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Manu Abraham" <abraham.manu@gmail.com>
To: "Grant Grundler" <grundler@parisc-linux.org>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
	greg@kroah.com
Subject: Re: 2.6.20 PCI Cannot allocate resource region 2
Date: Tue, 6 Feb 2007 13:06:17 +0400	[thread overview]
Message-ID: <1a297b360702060106x321bfb8dw918d15df76952576@mail.gmail.com> (raw)
In-Reply-To: <20070206084638.GB20752@colo.lackof.org>

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

  reply	other threads:[~2007-02-06  9:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-05  1:09 Manu Abraham
2007-02-05  3:04 ` Luming Yu
2007-02-05  4:16   ` H. Peter Anvin
2007-02-05 17:20   ` Manu Abraham
2007-02-06  4:55 ` Grant Grundler
2007-02-06  5:03   ` Grant Grundler
2007-02-06  5:33     ` Andrew Morton
2007-02-06  6:28       ` Manu Abraham
2007-02-06  7:04         ` Grant Grundler
2007-02-06  7:13           ` Manu Abraham
2007-02-06  8:46       ` Grant Grundler
2007-02-06  9:06         ` Manu Abraham [this message]
2007-02-06  9:29           ` Manu Abraham
2007-02-06 12:21             ` Luming Yu
2007-02-06 12:24               ` Manu Abraham
2007-02-06 12:56                 ` Manu Abraham
2007-02-06 12:56                   ` Manu Abraham
2007-02-07  4:19                 ` Luming Yu
2007-02-07  5:25                   ` Manu Abraham
2007-02-06 11:13         ` Manu Abraham
2007-02-06 11:52           ` Manu Abraham
2007-02-07  6:58             ` Grant Grundler
2007-02-08  5:26               ` Manu Abraham
2007-02-08  5:46               ` Manu Abraham
2007-02-06  6:24     ` Greg KH
2007-02-06  5:20   ` Manu Abraham
2007-02-06  8:25     ` Grant Grundler
2007-02-06  8:48       ` Manu Abraham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a297b360702060106x321bfb8dw918d15df76952576@mail.gmail.com \
    --to=abraham.manu@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=grundler@parisc-linux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --subject='Re: 2.6.20 PCI Cannot allocate resource region 2' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).