Bug 16706

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?

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.

Heya Jesse,

DOS:  http://launchpadlibrarian.net/12764250/proc.acpi.video.star.DOS
dsdt:  http://launchpadlibrarian.net/12764269/proc.acpi.dsdt

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

Bryce, any news here?  Can we get register dumps from before and after lid close/open?

No news yet.  I've re-pinged the reporter.

try to close due to not enough update from bug reporter...

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

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

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

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

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?

 Justyn, response?

lost response from bug reporter...

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!

Created attachment 37183 [details]
Intel register dumps before/during/after screen closing, from Dan Lenski

Created attachment 37321 [details] [review]
disable kernel lid event

as a workaround for GPU hangs from lid events, apply this patch to kernel source

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

(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

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.