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: <CAErSpo7imA4X+5F3_QKO7Nhm2cZAXC2ben+VmM7FhHzz9WrXjg@mail.gmail.com>
Date:	Tue, 24 Jan 2012 15:53:03 -0700
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Rogério Brito <rbrito@....usp.br>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Edward Donovan <edward.donovan@...ble.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org,
	Márcia Coutinho de Brito <mcbrito@...il.com>,
	Ram Pai <linuxram@...ibm.com>, rui.zhang@...el.com
Subject: Re: [Bug 41722] Clevo M5X0JE hangs in ACPI init

On Tue, Jan 24, 2012 at 3:18 PM, Rogério Brito <rbrito@....usp.br> wrote:
> The only change is the `nopat` option, as suggested by Yinghai.

I like this idea.  Last August, when we first looked at the hang when
enabling ACPI, Len Brown suggested that the outb() that does the
transition triggers SMM, and the hang is likely in SMM (which is
basically invisible and undebuggable from Linux).  And he said "we've
had problems in the past with SMM relying on something that Windows
just happened to do -- such as different MTRRs."

I couldn't see any MTRR info in your video (probably goes by too fast
as it's very early).  You might be able to get that info by adding
another call to print_mtrr_state() later in boot.  Then it would be
interesting to try to get the corresponding info from Windows.

>    ACPI Exception: AE_BAD_PARAMETER, Thread 9340 could not acquire
> Mutex [0x1] (20120111/utmutex-276)
>
> which seems strange, particularly as I passed the option `acpi=off` to
> my kernel.

Definitely odd.  I don't think that should happen.  I see a couple
places where we might be able to get there even with ACPI disabled,
e.g., eeepc_wmi_check_atkd() -> acpi_get_devices() ->
acpi_ut_acquire_mutex().  You could find out by adding a dump_stack()
where that error is printed.  It'd be nice to fix it, but I don't
think it's related to the real problems on your box.

Bjorn
--
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/