From: Greg KH <greg@kroah.com>
To: "Kok, Auke" <auke-jan.h.kok@intel.com>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Jesse Barnes <jesse.barnes@intel.com>,
linux-pci@atrey.karlin.mff.cuni.cz,
Matthew Wilcox <matthew@wil.cx>,
linux-kernel@vger.kernel.org, Robert Hancock <hancockr@shaw.ca>,
"Li, Shaohua" <shaohua.li@intel.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: PCI: Fix boot-time hang on G31/G33 PC
Date: Thu, 27 Sep 2007 16:13:44 -0700 [thread overview]
Message-ID: <20070927231344.GD869@kroah.com> (raw)
In-Reply-To: <46FBF830.9000704@intel.com>
On Thu, Sep 27, 2007 at 11:36:32AM -0700, Kok, Auke wrote:
> Ivan Kokshaysky wrote:
> > On Wed, Sep 26, 2007 at 03:20:40PM -0700, Jesse Barnes wrote:
> >> Ivan, your concern is about disabling things like interrupt controllers
> >> and power management chips during probe right? You're right that doing
> >> that could cause problems if we get and interrupt or PMU event at just
> >> the wrong time, but that could just as easily happen if decode was
> >> still enabled but the BAR had a bogus address programmed (as it would
> >> during probing).
> >
> > Yes, nobody is arguing that moving the BAR around is unsafe, but generally
> > it's the less of two evils.
> >
> > The major problem here is that with IO and MEM bits cleared in the command
> > register you disable *all* address decoders on the device, not just ranges
> > that have respective BARs. At least this behaviour is required by PCI spec.
> > Examples:
> > - legacy VGA IO and memory (no corresponding BARs);
> > - base/limit registers of P2P bridge;
> > - PMU and SMBus registers (sort of normal BARs, but hidden elsewhere
> > in the config space);
> > - IDE legacy mode registers;
> > - IO-APIC registers (typically sort of read-only BAR).
> >
> > For all of these address ranges our current BAR probe is effectively
> > a no-op, but disable/re-enable clearly isn't.
> >
> >> Ultimately, I don't care much one way or another as long as we can get
> >> the desktop platforms fixed somehow. I think disabling decode is the
> >> most correct way of doing this, but I'm open to other solutions (this
> >> is the only patch I've seen though that's been tested to solve the
> >> problem).
> >
> > There are two other solutions: one is to disable decode selectively,
> > only on devices or systems where it's necessary and known to be safe.
> > I've posted a patch which introduces "disable_while_probe" pci_dev field
> > for that purpose.
> > Another one is to delay mmconfig probe until after the PCI probe is done,
> > as Matthew suggested, and Robert confirmed that it's feasible.
>
>
> for everyone who's using this quirk or has the same boot issue: I just confirmed
> that the new dg33tl bios update v0287 (released 9/20) fixes the boot issue for my
> systems. I encourage everyone to update their BIOS image and see if this works.
Thanks for letting us know. So, another reason to drop this patch :)
thanks,
greg k-h
next prev parent reply other threads:[~2007-09-28 17:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-26 1:55 [PATCH] Fix boot-time hang on G31/G33 PC Matthew Wilcox
2007-08-26 4:24 ` Robert Hancock
2007-08-26 12:55 ` Matthew Wilcox
2007-08-26 14:07 ` Matthew Wilcox
2007-08-26 17:59 ` Robert Hancock
2007-08-28 17:22 ` Jesse Barnes
2007-08-28 17:59 ` Grant Grundler
2007-08-28 18:28 ` Grant Grundler
2007-09-26 21:18 ` PCI: " Greg KH
2007-09-26 21:55 ` Jesse Barnes
2007-09-26 21:56 ` Greg KH
2007-09-26 22:20 ` Jesse Barnes
2007-09-26 23:04 ` Robert Hancock
2007-09-27 14:31 ` Ivan Kokshaysky
2007-09-27 18:36 ` Kok, Auke
2007-09-27 23:13 ` Greg KH [this message]
2007-10-12 14:26 ` Vitaliy Gusev
2007-10-12 17:07 ` Kok, Auke
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=20070927231344.GD869@kroah.com \
--to=greg@kroah.com \
--cc=akpm@linux-foundation.org \
--cc=auke-jan.h.kok@intel.com \
--cc=hancockr@shaw.ca \
--cc=ink@jurassic.park.msu.ru \
--cc=jesse.barnes@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=matthew@wil.cx \
--cc=shaohua.li@intel.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox