From: Peter Clifton <pcjc2@cam.ac.uk>
To: "Raúl Sánchez Siles" <rasasi78@gmail.com>
Cc: linux-acpi@vger.kernel.org
Subject: Re: System hard lock when closing lid(2nd try)
Date: Sun, 28 Oct 2007 13:18:39 +0000 [thread overview]
Message-ID: <1193577519.6402.9.camel@pcjc2lap> (raw)
In-Reply-To: <ffvaf8$99k$1@ger.gmane.org>
On Sat, 2007-10-27 at 14:20 +0200, Raúl Sánchez Siles wrote:
> Hello:
>
> Peter Clifton wrote:
>
> >
> > On Fri, 2007-10-26 at 17:41 +0200, Raúl Sánchez Siles wrote:
> >> Hello All:
> >>
> >> Some time ago(2007/09/17) I wrote this e-mail:
> >>
> >> Raúl Sánchez Siles wrote:
> >>
> >> > Hello all:
> >> >
> >> > I've searched for a more user related ML, but this is the closest
> >> > I've
> >> > found. I own a Dell inspiron 510m laptop which include the HW listed at
> >> > [1]
> >> >
> > > As you can see there the graphics card is an intel 855GM. The newer
> xorg
> > > intel driver tries to save power by disabling one of the video output
> > > pipes of the card, the one that could drive an external VGA monitor. As
> a
> > > result, someone told me that the system enters in SMM (System Management
> > > Mode), leaves the system in such a state that the system ends up locking
> > > totally: no ssh connection or sys-rq combination works, just hard power
> > > off. More details at https://bugs.freedesktop.org/show_bug.cgi?id=11432
> >>
> >> The lid problem stills exist on a current Xorg version, even with intel
> >> video driver git version. I'm not surprised since I suspect heavily on a
> >> BIOS problem. I'm coming back with more attached info:
> >
> Thanks a lot for your reply, Peter. :)
>
> > There is probably a BIOS issue (from reports I've seen on this issue),
> > however the git version of the xserver-xorg-video-intel driver does not
> > address a couple of crashes with 855 hardware which are caused by the X
> > driver writing registers in the card.
> >
> >
> http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2.2.diff.gz
>
> >
> > Shows the diff applied to a (yet unreleased) Ubuntu package for the
> > drivers. (Applies against 2.1.1 release version). You should be able to
> > find the patches in the debian/patches/ dir which the diff creates.
> >
> I've been following this thread on the xorg-devel ML, and I have those
> patches queued for testing ;)
>
> > It might be worth looking at these, and revisiting the BIOS issue if (as
> > is unfortunately likely) if there remains an issue.
> >
>
> If you pay attention to https://bugs.freedesktop.org/show_bug.cgi?id=11432 I
> had published there a patch (comment #23) there that has been happily
> working for me since I post it (yet it works). But what it does is ugly and
> has drawbacks as explained there so I still consider it a workaround and
> not a final solution.
>
> That's the reason I came here, to check out wether the Linux kernel could
> address the issue.
I guess this depends on whether it turns out to be ACPI code which is
poking the video chip when you close / open the lid. Please try the
above patches without the patch from comment #23, as there is a chance
it will still improve things. (It'd be good to identify which cases it
does help in).
There might of course be a similar test required in the display
detection code which enables PipeA temporarily, as in the Video overlay
enable code. If it still crashes with the patches I wrote, it would be
good to find out exactly what line in the driver locks the system up in
your case. I guess it might be a register access to PIPEACONF somewhere.
For the patches I made, I added lots of driver print messages, before
and after suspect register accesses, added a sync(); call after each
message, and got my tester to work with hard-drive write-caching
switched off. (This got the log entries previous to the hang to disk.)
Please let us know on the xorg mailing-list if you discover anything
interesting!
Regards,
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2007-10-28 13:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-26 15:41 System hard lock when closing lid(2nd try) Raúl Sánchez Siles
2007-10-27 11:17 ` Peter Clifton
2007-10-27 12:20 ` Raúl Sánchez Siles
2007-10-28 13:18 ` Peter Clifton [this message]
2007-10-28 9:16 ` Norbert Preining
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=1193577519.6402.9.camel@pcjc2lap \
--to=pcjc2@cam.ac.uk \
--cc=linux-acpi@vger.kernel.org \
--cc=rasasi78@gmail.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