On the 28 September 2007 03:13 Greg KH, wrote: > 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. >
No, it still doesn't work even with a latest BIOS verstion. I have a computer with Intel DQ35MP motherboard. I upgraded BIOS to rev. 0696, released Oct 1. But kernel (2.6.22.5) still hangs up. Kernel with this fix patch boots and works fine. > 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 [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Thanks, Vitaliy Gusev - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/