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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.