linux-kernel - Re: PCI: Fix boot-time hang on G31/G33 PC

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: <20070927231344.GD869@kroah.com>
Date:	Thu, 27 Sep 2007 16:13:44 -0700
From:	Greg KH <greg@...ah.com>
To:	"Kok, Auke" <auke-jan.h.kok@...el.com>
Cc:	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Jesse Barnes <jesse.barnes@...el.com>,
	linux-pci@...ey.karlin.mff.cuni.cz,
	Matthew Wilcox <matthew@....cx>, linux-kernel@...r.kernel.org,
	Robert Hancock <hancockr@...w.ca>,
	"Li, Shaohua" <shaohua.li@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: PCI: Fix boot-time hang on G31/G33 PC

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/