LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Grant Grundler <grundler@parisc-linux.org>,
	Manu Abraham <abraham.manu@gmail.com>,
	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 01:46:38 -0700	[thread overview]
Message-ID: <20070206084638.GB20752@colo.lackof.org> (raw)
In-Reply-To: <20070205213339.80239a22.akpm@linux-foundation.org>

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.

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

  parent reply	other threads:[~2007-02-06  8:46 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 [this message]
2007-02-06  9:06         ` Manu Abraham
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=20070206084638.GB20752@colo.lackof.org \
    --to=grundler@parisc-linux.org \
    --cc=abraham.manu@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --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).