Vitaliy Gusev wrote:
> 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.
please note that your BIOS is completely different than the one posted above. This
may be a clue.
interestingly enough I can attest (somewhat) to this. After the BIOS upgrade
2.6.22 booted just fine without pci=nommconf, but I've had several boot lockups
with 2.6.23-rc8.
So, the issue is still open and Matthew/Jesse's suggested fix becomes much more
attractive to me now.
Greg, I suggest putting this patch back in the "grey" zone
Auke
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
