lkml.org 
[lkml]   [2011]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [Bug 41622] [REGRESSION][BISECTED] Notebook crashes upon detecting the PCI subsystem with kernels >= 2.6.24-rc7
On Thu, Aug 25, 2011 at 8:49 AM, Rogério Brito <rbrito@ime.usp.br> wrote:
> 2011/8/24 Bjorn Helgaas <bhelgaas@google.com>:
>> I'd still like to see a dmesg log with no arguments (remove the
>> "acpi=off pnpbios=off noapic nolapic" arguments).  Your machine is new
>> enough that we'll use PCI _CRS by default, and I'd like to make sure
>> we're doing the right thing.
>
> OK. I put them there one by one, but let me report what I get with
> those disabled, but *with* that small patch applied:
>
> * "acpi=off pnpbios=off noapic": it works well, no problems with
> dropping the nolapic.
> * "acpi=off noapic": it works well, with no problems dropping
> "pnpbios=off, aside from the "[Firmware Bug]: powernow-k8: No PSB or
> ACPI _PSS objects" message.
> * "acpi=off": does not work well---it books OK, but some accesses to
> disk get very long and I get the following in the dmesg log:
> ...
> * without any boot options: without "acpi=off", the machine just hangs
> at (hand copied, but photographed, if you want it):
>
> (...)
> CPU: Mobile AMD Sempron (tm) Processor 3400+ stepping 02
> ACPI: Core revision 20110623
>
> And nothing else happens.

This is a serious problem, and while we probably need to fix both this
and the PCI bridge issue, this is the first thing you hit, so I'd like
to look at it first. Users should never have to use "acpi=off" except
for debugging purposes.

I opened a separate bug report for it:
https://bugzilla.kernel.org/show_bug.cgi?id=41722

Would you build your kernel with "CONFIG_ACPI_DEBUG=y" and boot with
the kernel options "ignore loglevel acpi.debug_layer=0xffffffff
acpi.debug_level=0xffffffff" and see if we can learn anything? If
that's too much output, try acpi.debug_layer=0x59f instead.

>> I don't really like that change because in __pci_bus_size_bridges(),
>> it's not obvious why sizing transparent bridges should be a problem.
>> If growing transparent bridge windows makes us run out of space, let's
>> put the smarts ("this bridge is transparent, we can take advantage of
>> subtractive decode so we may not need to grow the positive decode
>> windows") at the point where we grow, not at the point where we size.
>> If we do have enough space, growing the positive decode windows is
>> better because they're faster than subtractive decode.
>
> I'm afraid that I have understood almost nothing of what you just said
> :-), but I will try to read some of the code.

That's all right; that was intended for the PCI people who might care
about how this is implemented.

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

\
 
 \ /
  Last update: 2011-08-25 18:55    [W:0.056 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site