Bug 16706

Summary: [915GM] lid close breaks X
Product: xorg Reporter: Bryce Harrington <bryce>
Component: Driver/intelAssignee: Jesse Barnes <jbarnes>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: major    
Priority: medium CC: dlenski
Version: unspecifiedKeywords: NEEDINFO
Hardware: All   
OS: Linux (All)   
URL: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/156824
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
registration dump
none
Intel register dumps before/during/after screen closing, from Dan Lenski
none
disable kernel lid event none

Description Bryce Harrington 2008-07-14 07:14:05 UTC
Forwarding this bug report from a Ubuntu user:

HW:  HP Compaq TC4200 - a tablet that uses mostly Intel hardware, a Broadcom wired ethernet (it works), and a Texas Instruments card reader.

When I come back to it after I've closed the lid (Under Power Management Preferences I have it set to "When laptop lid is closed: Blank screen", the default), the poor thing becomes possessed:

 * The cursor jumps around insanely when I move the mouse.
 * Everything becomes painfully sluggish and unusable.
 * Sometimes windows I'm working with go dark and unresponsive (Compiz effect, though I have this same issue if I turn off desktop effects, so it's probably not Compiz related)
 * top shows that Xorg is hogging up between 40% and 70% of CPU cycles.
 * I can't get a Ctrl-Alt-F1-F6 consoles to come up (They flash onscreen for a split second and then the screen goes black, sometimes with a white arrow cursor frozen on it somewhere...).
 * When I do a Ctrl-Alt-Backspace to reset the X server, I notice the characters "^@" start appearing across the screen.
 * A Ctrl-Alt-Backspace doesn't fix the problem.
 * Sometimes the X server resets itself with no outside influence (behaves like I'd hit Ctrl-Alt-Backspace)
 * Sometimes/eventually the laptop becomes completely unresponsive.

 I only recently figured out that the problem seemed to happen after I closed the lid and opened it back up.

 I've tried changing the "When laptop lid is closed" settings,
and have even gone so far as to re-installing in case it was a problem
cause by going through the update process rather than doing a clean
install.  All to no avail."

Also tried setting  Option "ForceEnablePipeA" "true"  but it made no difference, so the usual pipe-A quirk solution doesn't seem applicable here.

(Maybe is this a kernel/ACPI bug rather than X?)

xorg.conf:  http://launchpadlibrarian.net/12764165/etc.X11.xorg.conf
Xorg.0.log:  http://launchpadlibrarian.net/12764168/var.log.Xorg.0.log
Xorg.0.log.old:  http://launchpadlibrarian.net/12764187/var.log.Xorg.0.log.old
dsdt:  http://launchpadlibrarian.net/12764269/proc.acpi.dsdt
dmesg:  http://launchpadlibrarian.net/12764276/dmesg.output
Comment 1 Jesse Barnes 2008-07-15 19:07:39 UTC
What's the ACPI DOS setting in this case (/proc/acpi/video/.../DOS)?  I wonder if one of the ACPI methods is changing the video config in a way we don't expect, causing the driver to get confused...

If you VT switch to a console before lid close, then back to X after open, does the problem go away?
Comment 2 Jesse Barnes 2008-07-17 14:21:16 UTC
Also, it would be good to get register dumps from before and after the lid close/open.  Since X is up the whole time, just capturing it from an xterm or something before and after should be fine.
Comment 4 Jesse Barnes 2008-07-18 12:28:00 UTC
> > --- Comment #3 from Bryce Harrington <bryce@bryceharrington.org> 
> > 2008-07-18 05:23:47 PST --- Heya Jesse,
> >
> > DOS:  http://launchpadlibrarian.net/12764250/proc.acpi.video.star.DOS
> > dsdt:  http://launchpadlibrarian.net/12764269/proc.acpi.dsdt
> 
> Setting DOS to 0 might work better, depending on the BIOS, but the register 
> dumps will probably be the most helpful.
Comment 5 Jesse Barnes 2008-08-20 12:23:07 UTC
Bryce, any news here?  Can we get register dumps from before and after lid close/open?
Comment 6 Bryce Harrington 2008-08-21 18:14:54 UTC
No news yet.  I've re-pinged the reporter.
Comment 7 Michael Fu 2008-09-25 01:35:00 UTC
try to close due to not enough update from bug reporter...
Comment 8 Justyn Butler 2008-09-25 11:11:13 UTC
As with some of the other posters in the downstream Launchpad bug:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/156824

I am experiencing a jittery mouse and unresponsive system for a number of seconds (5 - 10 seconds) after opening my laptop lid.

I am seeing this behavior under:
Ubuntu 8.04 Hardy Heron
Ubuntu 8.10 Intrepid Alpha 5
Fedora 9

Note that I am usually running Ubuntu 8.04 Hardy on this machine currently.

In fact on Ubuntu 8.04 the behavior is more severe - the icons on the desktop flash four or five times during the 10 second period and if I have desktop effects disabled (and am therefore using metacity I assume) all the application windows flash on and off also!

Under Fedora 9 and Ubuntu 8.10 Alpha 5 the more tame but frustrating effect reported by the other posters is seen - the system and mouse are "jittery" and only partially responsive for around 5 to 10 seconds after opening the lid.

During the period after opening the lid "top" shows Xorg is using 40-48% of CPU.

My system is a Dell Inspiron 9400 with Intel Core Duo T2300 at 1.66GHz (from cpuinfo).
The graphics card is Intel 945GM (from dmesg output).

Please tell me what I can do to help diagnose this issue. I have spare partitions on this machine that I can use to install other distros if that it helpful (ie to test other versions of xorg).
Comment 9 Justyn Butler 2008-09-25 12:13:57 UTC
"If you VT switch to a console before lid close, then back to X after open, does
the problem go away?"

The answer seems to be yes, it goes away.

I have attempted to test this on Ubuntu 8.04 with desktop effects off and used a stopwatch to keep an eye on timings.

What I did:

I logged into a virtual terminal and ran top.
I also ran top in gnome-terminal on X.
In each case I started timing as I opened the lid.

Results:

When I open the lid in X and stay in X, Xorg is using excessively high CPU for 12 seconds.

When I open the lid in X and immediately switch to the virtual terminal Xorg CPU usage has returned to normal idle levels by the time the stopwatch shows 8 seconds.

When I open in X, switch to virtual terminal and the instant it is visible switch back to X the problem has gone, X shows normal idle levels and only 6 seconds have passed since opening the lid.

When I switch to VT mode before closing the lid, then after I have opened switch to X, the problem has gone and 5 seconds have passed.

(On a side note - if I close and open my lid in a VT the screen is blank and the only way to get it to show anything is to switch to another VT, or X, and back again. I assume this is unrelated).


ps. I forgot to add that in the three distros I have tested this bug, I have always been running Gnome.
Comment 10 Mike 2008-10-20 17:25:48 UTC
Created attachment 19776 [details]
registration dump

Using Ubuntu 8.10 Beta and having trouble with this bug.
my intel_reg_dumper from before lid close, during blinking, and after stabilizing is attached
Comment 11 Michael Fu 2008-11-11 17:15:24 UTC
(In reply to comment #10)
> Created an attachment (id=19776) [details]
> registration dump
> 
> Using Ubuntu 8.10 Beta and having trouble with this bug.
> my intel_reg_dumper from before lid close, during blinking, and after
> stabilizing is attached
> 

Mike, are you having the same HW as the original bug report? for this kind of bug, different platform usually means different bugs..
Comment 12 Jesse Barnes 2008-12-18 13:37:35 UTC
This is pretty weird... So X is consuming a bunch of CPU after lid open.  Is there any way you could use a profiler like oprofile or sysprof to figure out where X is spending time while it misbehaves?  Does anything change if you set your _DOS value to 6 instead of 4?
Comment 13 Michael Fu 2008-12-28 22:37:09 UTC
 Justyn, response?
Comment 14 Michael Fu 2009-01-18 23:42:39 UTC
lost response from bug reporter...
Comment 15 Dan Lenski 2010-07-19 11:48:21 UTC
Hi all,
My otherwise very well-supported Acer 1410 notebook has been suffering from this bug for a number of months.  My symptoms are very similar to the OP's: high CPU usage when the screen is closed, flickering and unresponsiveness after it is reopened.  If I leave the screen closed for more than a few minutes, the system become permanently unresponsive AFAICT, and SysRq-B is the only way to reboot.

If I flip to a virtual terminal, then close the screen... there is no problem.  It is *only* when I am on the X terminal that this problem occurs.

I have tried setting /proc/acpi/video/*/DOS to 0, 4, and 6.  None of these fix the problem.

I am running Ubuntu 10.04's kernel 2.6.32-21-generic, on i386.  I do not have Compiz enabled.

Here is my lspci -nn output:

00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07)
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03)
00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03)
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 [8086:2946] (rev 03)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93)
00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03)
00:1f.2 SATA controller [0106]: Intel Corporation ICH9M/M-E SATA AHCI Controller [8086:2929] (rev 03)
00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 03)
01:00.0 Ethernet controller [0200]: Atheros Communications AR8131 Gigabit Ethernet [1969:1063] (rev c0)
02:00.0 Network controller [0280]: Intel Corporation WiFi Link 5100 [8086:4232]

I have attached a tarball with the outputs of intel_reg_dumper before, during, and after the screen close for DOS values of 0, 4, and 6.  I used this simple script to produce these:

echo $DOS | tee /proc/acpi/video/OVGA/DOS; echo before; intel_reg_dumper > before.DOS=$DOS; sleep 10; echo during; intel_reg_dumper > during.DOS=$DOS; sleep 10; echo after; intel_reg_dumper > after.DOS=$DOS

I can provide more diagnostic information in a timely fashion if it is useful.  Thanks!
Comment 16 Dan Lenski 2010-07-19 11:50:26 UTC
Created attachment 37183 [details]
Intel register dumps before/during/after screen closing, from Dan Lenski
Comment 17 Dongxu Li 2010-07-22 12:23:12 UTC
Created attachment 37321 [details] [review]
disable kernel lid event

as a workaround for GPU hangs from lid events, apply this patch to kernel source
Comment 18 Jesse Barnes 2010-07-23 13:41:58 UTC
Can you try this with a more recent kernel?  E.g. 2.6.35-rc6?  Ubuntu has some bleeding edge kernel packages to make that easier...
Comment 19 Dongxu Li 2010-07-28 13:23:23 UTC
(In reply to comment #18)
> Can you try this with a more recent kernel?  E.g. 2.6.35-rc6?  Ubuntu has some
> bleeding edge kernel packages to make that easier...

you are right, the lid close&open issue is fixed in kernel 2.6.35-rc6.

I built kernel from -git head,

$ uname -a
Linux gateway 2.6.35-rc6-next-20100728+ #2 SMP Wed Jul 28 06:57:40 EDT 2010 x86_64 Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz GenuineIntel GNU/Linux

$ git log
commit 1068a69ac1475dcbf68b78de0be410805fbdc4f5

dmesg is full of,

intel ips 0000:00:1f.6: MCP power or thermal limit exceeded
intel ips 0000:00:1f.6: MCP power or thermal limit exceeded
intel ips 0000:00:1f.6: MCP power or thermal limit exceeded
intel ips 0000:00:1f.6: MCP power or thermal limit exceeded
intel ips 0000:00:1f.6: MCP power or thermal limit exceeded
Comment 20 Jesse Barnes 2010-07-28 13:39:07 UTC
Great, thanks for confirming.  You can ignore those messages for now, they won't appear when the IPS driver finally lands upstream.  Or you can just change the message to a dev_info from a dev_warn in intel_ips.c.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.