[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAErSpo5T7kuAvh0YNNsOiCZ3s8sAmqGxpyq2BFmQPD1AVOcKSQ@mail.gmail.com>
Date: Fri, 22 Jun 2012 13:52:45 -0600
From: Bjorn Helgaas <bhelgaas@...gle.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: bugzilla-daemon@...zilla.kernel.org,
Yinghai Lu <yinghai@...nel.org>, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [Bug 41622] [REGRESSION][BISECTED] Notebook crashes upon
detecting the PCI subsystem with kernels >= 2.6.24-rc7
> Maybe we should just try that patch in
>
> https://bugzilla.kernel.org/show_bug.cgi?id=41622#c17
>
> but it really needs to happen early in a merge window. We didn't do
> that for 3.2, maybe we can do it for 3.6?
The first problem is still that this machine doesn't get anywhere at
all with ACPI enabled
(https://bugzilla.kernel.org/show_bug.cgi?id=41722), so we only get to
this transparent bridge issue with "acpi=off".
I really think that it would be better to solve the ACPI issue first
because it's too difficult to support an "acpi=off" config -- nobody
else tests that and very few users will be sophisticated enough to
even try it. Unfortunately, I don't have any good ideas about the
ACPI issue other than the MTRR possibility Len suggested.
If we just fiddle with transparent bridge sizing, we're making the
problem go away, but we don't really know why, so I'm afraid of
breaking some other machine or tripping over this somewhere else. My
guess is that we hang because we moved a device on top of something
else, and if we skip transparent bridge sizing, we avoid that device
move. I do think it might be reasonable to avoid bridge sizing on the
grounds that we shouldn't move things unless we have to. But right
now, we don't even know the real effect of skipping the bridge sizing.
Rogério, we might be able to at least identify a relevant difference
if you collect the dmesg from the "working" case ("acpi=off" with the
comment #17 patch), a video of the hanging case ("acpi=off" without
the patch, possibly with "boot_delay=1000" to slow things down) that
we can transcribe by hand, and the AIDA64 info from Windows that I
mentioned in bug 41722.
--
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/
Powered by blists - more mailing lists