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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.