linux-kernel - Re: [Bug 41722] Clevo M5X0JE hangs in ACPI init

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: <CADdbW+Eq=5U2smt=QgYiEKf2amy=xd_ZdpBZ9oLD3au7KfHgNg@mail.gmail.com>
Date:	Tue, 10 Jan 2012 04:25:12 -0500
From:	Edward Donovan <ed@...ble.net>
To:	Rogério Brito <rbrito@....usp.br>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	linux-kernel@...r.kernel.org,
	Márcia Coutinho de Brito <mcbrito@...il.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Ram Pai <linuxram@...ibm.com>
Subject: Re: [Bug 41722] Clevo M5X0JE hangs in ACPI init

Hi Rogério -

I'm glad to see you're getting help from a lot of skilled people, here.

On Sun, Jan 8, 2012 at 5:13 PM, Rogério Brito <rbrito@....usp.br> wrote:
> On Jan 06 2012, Linus Torvalds wrote:
>> 2012/1/6 Rogério Brito <rbrito@....usp.br>:
>> >
>> > For the record, *some* description of the problem is at:
>> >
>> > * https://bugzilla.kernel.org/show_bug.cgi?id=41132
>>
>> This one looks very much like the thing that Edward Donovan fixed
>> fairly recently in commit 52553ddffad7 ("genirq: fix regression in
>> irqfixup, irqpoll")
>
> It does look similar, but not quite the same. And, yes, my main desktop (the
> one that I'm using right now) was affected by Edward's commit, which, BTW,
> has my Reported-and-tested-by.


The one area I have experience with is the IRQ regression you cite in
41132.  I was bitten by the regressions in spurious IRQ handling, like
you, and this has been my first trip inside the kernel.  The patches I
sent are the sum of my kernel wisdom to date, and I don't want to
impersonate an experienced developer, even by accident. :)

At any rate: I can't tell, yet, what IRQ trouble is happening on this
notebook.  I couldn't pick any out from the description below.  And so
I can't tell, either :) , how it is similar to the bug above, but not
quite the same.

Is there an IRQ disabled, "nobody cared", problem, even with the
newest kernels?

If you have info on IRQ problems, I can look at it, hopefully soon.
Right now, it might make sense to let this PCI effort roll forward,
before opening a second front, but I can't say that for sure.  I
certainly hope we can make your mom's notebook a happy Linux box.

Thanks,

Ed


> This one is different. Here is a brief summary of the situation:
>
> # Computer description
>
> * Rebranded Clevo M5X0JE
> * nForce2 chipset
> * AMD Sempron CPU
> * NIC with driver forcedeth
> * wifi rtl8187
>
> # Booting options
>
> The current working options passed to the kernel are: `acpi=off pnpbios=off noapic`
>
> It doesn't boot with a vanilla kernel. It only boots when I pass the options
> above *and* compile the kernel with the following patch applied:
>
> ,----[ do_not_size_subtractive_decoding_transparent_pci_to_pci_bridges.patch ]
> | diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> | index 86b69f85..84543f5 100644
> | --- a/drivers/pci/setup-bus.c
> | +++ b/drivers/pci/setup-bus.c
> | @@ -849,6 +849,10 @@ void __ref __pci_bus_size_bridges(struct pci_bus *bus,
> |               break;
> |
> |       case PCI_CLASS_BRIDGE_PCI:
> | +             /* don't size subtractive decoding (transparent)
> | +              * PCI-to-PCI bridges */
> | +             if (bus->self->transparent)
> | +                     break;
> |               pci_bridge_check_ranges(bus);
> |               if (bus->self->is_hotplug_bridge) {
> |                       additional_io_size  = pci_hotplug_io_size;
> `----
>
> Otherwise, it hangs right when trying to configure PCI, which, according to
> the dmesg log when it boots occurs approximately 0.12 seconds after the
> kernel shows its first message.
>
--
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/