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: <1231988103.20746.149.camel@rzhang-dt>
Date:	Thu, 15 Jan 2009 10:55:03 +0800
From:	Zhang Rui <rui.zhang@...el.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Martin Michlmayr <tbm@...ius.com>,
	"elendil@...net.nl" <elendil@...net.nl>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	fengguang.wu@...el.com
Subject: Re: [2.6.28] Kernel panic after closing lid on HP 2510p

On Thu, 2009-01-15 at 10:21 +0800, Matthew Garrett wrote:
> On Wed, Jan 14, 2009 at 06:15:42PM -0800, Andrew Morton wrote:
> > On Thu, 15 Jan 2009 02:03:11 +0000 Matthew Garrett <mjg59@...f.ucam.org> wrote:
> > > Lid actions typically trigger SMI code, so it's entirely capable of 
> > > destroying CPU state in such a way that the kernel falls over (and 
> > > probably even in ways that cause the kernel to turn green, emit pleasing 
> > > warbling noises or invade neighbouring pieces of hardware). In this case 
> > > it seems to be SMP specific - the system's entirely stable in UP mode. 
> > > It's greatly vexing.
> > 
> > Does it always crash in the same way?
> 
> Not in my experience. Sometimes it falls over in the ACPI parsing code, 
> but sometimes the backtrace is nonsense and the IP is in the middle of 
> nowhere. I've now got a working 2510p again, so maybe I'll have time to 
> look at this on the way to LCA.
> 
please check if this is a duplicate of bug #11259.
http://bugzilla.kernel.org/show_bug.cgi?id=11259


We (Wu, fengguang and me) reproduced this bug on a HP 6910p.
and we found that windows run a different AML code path when closing Lid
on this laptop and the SMI is not invoked...
And I have verified how to make Linux run the same code path by changing
the IGD OpRegion code.

DIDL is an IGD OpRegion field, as the Supported Display Devices ID List.
it's evaluated by the _DOD method when ACPI video driver is loaded.
And according to the spec, "The graphics driver writes to this field
once during its initialization"
if DIDL is not empty, a flag is set and the SMI will not be invoked when
closing the lid.
In our tests, this field (DIDL) is set in windows when _DOD is invoked
while it's not in Linux.
I can workaround this bug by setting the DIDL manually in AML code.

So a patch setting the DIDL in i915_opregion.c should be a proper fix
for this problem. Fengguang will cook up a patch later.

But there is still one mystery left.
Windows doesn't break even if the SMI is invoked...

thanks,
rui




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

Powered by Openwall GNU/*/Linux Powered by OpenVZ