From: Wu Fengguang <fengguang.wu@intel.com>
To: "Zhang, Rui" <rui.zhang@intel.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
Andrew Morton <akpm@linux-foundation.org>,
Martin Michlmayr <tbm@cyrius.com>,
"elendil@planet.nl" <elendil@planet.nl>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"intel-gfx@lists.freedesktop..."
<intel-gfx@lists.freedesktop.org>
Subject: Re: [2.6.28] Kernel panic after closing lid on HP 2510p
Date: Thu, 15 Jan 2009 12:20:58 +0800 [thread overview]
Message-ID: <20090115042058.GA4073@localhost> (raw)
In-Reply-To: <1231988103.20746.149.camel@rzhang-dt>
On Thu, Jan 15, 2009 at 04:55:03AM +0200, Zhang, Rui wrote:
> 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@srcf.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.
I found it not easy given the required sequence of operations:
For this specific bug, opregion DIDL entry must be set before the
*first* _DOD invocation, i.e. the ACPI video module loading time.
This means
- opregion module must be loaded before ACPI video module
- the opregion DIDL setting code must run in module init time,
instead of the current implemented startx time.
However, how can the opregion module get the right DIDL data
without the help of Xorg and intel driver? Maybe kernel mode
setting?
So the module dependencies could be:
ACPI video => i915 opregion => kernel mode setting
The latter dependency should be a reasonable one, but does the first
one make sense in general?
Or is it possible to delay the first _DOD invocation in ACPI video?
Thanks,
Fengguang
next prev parent reply other threads:[~2009-01-15 4:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-12 12:56 [2.6.28] Kernel panic after closing lid on HP 2510p Frans Pop
2009-01-13 12:30 ` Martin Michlmayr
2009-01-13 17:45 ` Git as of 13-Jan-2009 build fail on OMAP3 david.hagood
2009-01-14 15:55 ` Tony Lindgren
2009-01-13 19:31 ` [2.6.28] Kernel panic after closing lid on HP 2510p Frans Pop
2009-01-15 0:26 ` Andrew Morton
2009-01-15 2:03 ` Matthew Garrett
2009-01-15 2:15 ` Andrew Morton
2009-01-15 2:21 ` Matthew Garrett
2009-01-15 2:55 ` Zhang Rui
2009-01-15 2:59 ` Matthew Garrett
2009-01-15 4:20 ` Wu Fengguang [this message]
2009-01-15 7:41 ` Martin Michlmayr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090115042058.GA4073@localhost \
--to=fengguang.wu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=elendil@planet.nl \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=rui.zhang@intel.com \
--cc=tbm@cyrius.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).