Resume from suspend doesn't work on the Mobile 4 Series chipsets

Bug #276943 reported by Arnold J Noronha
172
This bug affects 23 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Invalid
Medium
linux (Ubuntu)
Fix Released
Medium
Andy Whitcroft
Intrepid
Fix Released
Medium
Andy Whitcroft
xserver-xorg-video-intel (Ubuntu)
Fix Released
High
Unassigned
Intrepid
Invalid
Undecided
Unassigned

Bug Description

Hi,

Resume from suspend locks the system (just a mouse pointer is shown against a black screen). Suspending from a tty works, sometimes suspending from tty and then pressing Ctrl+Alt+F7 after resume locks the system. Interestingly, this lock would mean no input, no keyboard indicators work, but the system automatically reboots after about 1 minute. I tried many quirk combinations using pm-suspend, but none work.

I changed the Xorg driver to "vesa" and now suspend works with any quirks (of course, I lose compiz.)

I am running a Intrepid on a Lenovo X200, with a Mobile 4 series chipset (I think this is some 4700 MHD or something.) I'm attaching lspci output.

Revision history for this message
Arnold J Noronha (arnold) wrote :
Revision history for this message
Jonas Pedersen (jonasped) wrote :

I have the exact same problem on my brand new Lenove ThinkPad T500 with a Intel GMA 4500MHD GFX card. It happens with both pm-suspend and pm-hibernate. I have tested this on a fully updated Intrepid.

Is there any way I can assist in solving this problem as I would really like to suspend/hibernate my laptop?

Revision history for this message
Jonas Pedersen (jonasped) wrote :

Further to my previous post, I can confirm that it is working on Hardy. It is only in Intrepid beta I have this problem. I am not sure at all, but it might be related to bug #277827. This bug is about some other GFX related problems I have on my laptop (GM45 - Intel GMA 4500MHD).

Revision history for this message
minksj (minksj) wrote :

I can confirm with Lenovo ThinkPad T400. Works with dedicated graphics, but does not resume from suspend with intel integrated chip. I have not tried to suspend form tty yet.

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi arnold,

Thanks for including the attached files. Could you also include your /var/log/Xorg.0.log?

Changed in xserver-xorg-video-intel:
status: New → Incomplete
Revision history for this message
Arnold J Noronha (arnold) wrote :

I just tried the intel driver again. Things seem to work even after repeated suspends :-o I am not able to get it to crash, maybe some upgrade along the way fixed it? I'll report back if it crashes again, but last time it was crashing on almost each restore.

Revision history for this message
Jonas Pedersen (jonasped) wrote :

I am still suffering from this bug. Just updated my beta Intrepid with latest updates and it is still an issue for me. Have attached output from lspci as wll as X.org log file.

jonas@miraculix:~$ uname -a
Linux miraculix 2.6.27-7-generic #1 SMP Fri Oct 17 22:24:30 UTC 2008 x86_64 GNU/Linux

Revision history for this message
Jonas Pedersen (jonasped) wrote :
Revision history for this message
minksj (minksj) wrote :

Hi,

I still can't resume from suspend with Intel graphics too.

$USER@$USER:~$ uname -a
Linux jakub-laptop 2.6.27-7-generic #1 SMP Fri Oct 17 22:24:21 UTC 2008 i686 GNU/Linux

Revision history for this message
minksj (minksj) wrote :

and lspci...

Revision history for this message
minksj (minksj) wrote :

Hmm,

last update did not fix it either. I'm not sure about the logistics, but would it be worth bringing this to attention of the Intrepid clean-up efforts? Is it only the subset of Mobile 4 chipsets suffering form this? New Lenovos only? Or only some funny configuration that a few of us have?

Jakub

Revision history for this message
swmike (ubuntu-s-plass) wrote :

I just want to chime in that I have the same problem. Lenovo X200, resume from sleep gives me a mouse pointer on a black screen, and then no response from the system. Default 8.10-rc install, intel display drivers.

This is the only issue I have at this time with Intrepid...

Revision history for this message
jbrea (johannibrea) wrote :

same problem for me.

jb@schulnotebook:~$ uname -a
Linux schulnotebook 2.6.27-7-generic #1 SMP Fri Oct 24 06:42:44 UTC 2008 i686 GNU/Linux

Revision history for this message
jbrea (johannibrea) wrote :

and Xorg.0.log...

Revision history for this message
Aaron (aagbsn) wrote :

Same problem for me. Running on a Lenovo x200.
Linux lox 2.6.27-7-generic #1 SMP Fri Oct 24 06:40:41 UTC 2008 x86_64 GNU/Linux

Revision history for this message
Aaron (aagbsn) wrote :
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Same problem for me. New Lenovo T400. My machine has the 'hybrid graphics' option, but I have disabled the ATI chip in the BIOS, and I am only using the Intel chip.

Linux free-radical 2.6.27-7-generic #1 SMP Fri Oct 24 06:42:44 UTC 2008 i686 GNU/Linux

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

I can confirm that suspend from terminal with "pmi action suspend" works perfectly.

Revision history for this message
Thomas R. N. Jansson (tjansson) wrote :

I am experiencing the same problem on my Lenovo X200. From time to time it comes out of sleep fine but most of the time it freezes with only the mouse pointer on a black screen.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Some potentially useful notes:

From the console (vtty 1), after "pmi action suspend", resume works fine. Then switching over to the running X-server causes the same crash that would occur had I suspended from the GUI.

Restarting gdm/X, via /etc/init.d/gdm does not crash the computer or cause the bug to happen, however:
The screen resolution is not the default (my default is 1440x900, and the x-server starts up in something that looks like 1152x864).

In 8.04, suspend worked just fine.

I'm attaching two versions of my 8.04 Xorg.0.log. '8.04_xorg_before_suspend' and '8.04_xorg_after_suspend'. As the names imply, one is the log before I suspend, and the other is the log after I resume. The difference between the two files appears to show the wakeup process for the intel driver, i.e. restoring connections to appropriate outputs.

In Intrepid, /there is no difference between Xorg.0.log before and after suspend/.

This seems to be an indication that in 8.04, the graphics hardware is successfully told to wakeup from suspend, whereas since there is no extra noise on the log in 8.10, it seems that the signal is not making it to the driver, or the driver is not responding to the signal.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

(adding 8.04_xorg_after_suspend)

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

https://bugs.freedesktop.org/show_bug.cgi?id=17807

This appears to be the same bug, as filed on the Intel driver's bug tracker.

Revision history for this message
Matthias Himber (nomar) wrote :

Confirming this bug on a Thinkpad T500.

This seems to be a multiprocessor concurrency issue. There is a workaround on UbuntuForums: <http://ubuntuforums.org/showpost.php?p=6105510&postcount=12> that fixes the problem by temporarily disabling all but one processor cores on suspend.

Changed in xserver-xorg-video-intel:
status: Incomplete → Confirmed
Changed in xserver-xorg-video-intel:
status: Unknown → Confirmed
Revision history for this message
Thomas R. N. Jansson (tjansson) wrote :

I think I found some sort of "solution" for the suspend problem on my Lenovo X200. By uncommenting 'SLEEP_MODULE="kernel"' in /etc/pm/config.d/00sleep_module and adding acpi_sleep=s3_bios to the boot options my computer is now suspending like it should.

The only strange this is that the screens shows the following error message for 1 second before retuning the screen after a suspend:
pm_op(): usb_dev_resume+0x0/0x10 [usbcore] returns -19
PM: Device 3-4 failed to resume: error -19

I guess this is not a real solution but until a real fix arrives this is really helpful.

Revision history for this message
ThyMythos (thymythos) wrote :

I had the same problem with early Intrepid betas but now it works perfectly.

# uname -a
Linux ThyMYthOS 2.6.27-8-generic #1 SMP Thu Nov 6 17:33:54 UTC 2008 i686 GNU/Linux

# lspci -v
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
        Subsystem: Dell Device 024f
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at f6c00000 (64-bit, non-prefetchable) [size=4M]
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at ef98 [size=8]
        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
        Capabilities: [d0] Power Management version 3

# dpkg -l xserver-xorg-video-intel
ii xserver-xorg-video-intel 2:2.4.1-1ubuntu10 X.Org X server -- Intel i8xx, i9xx display driver

Revision history for this message
Nick Booker (nmbooker) wrote :
Download full text (3.1 KiB)

Nope, still an issue for me. On a T500 2805-52G (this is a machine I'm setting up for a customer), the system freezes on return from suspend or hibernate, just after showing the black screen and mouse pointer. Sometimes, on first suspend after boot, the system will resume correctly but will fail to resume on a subsequent suspend.

Doing pmi action suspend as root at a tty suspends and resumes successfully (I tested without having first logged in at GDM), but then when I log in the resolution becomes 1024x768.

So things are most definitely still broken.

# uname -a
Linux ubuntu 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:20 UTC 2008 i686 GNU/Linux

# lspci
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07)
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
03:00.0 Network controller: Intel Corporation Wireless WiFi Link 5100
15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
15:00.3 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev ff)
15:00.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 11)
15:00.5 System peripheral: Ricoh Co Ltd xD-Picture ...

Read more...

Revision history for this message
Austin Chu (eefi) wrote :

I think I may have localized where the bug is. If I add a sync() call in src/i830_dri.c:I830DRIInstIrqHandler() just before the call to drmCtlInstHandler(), the resume from suspend still fails. If I instead add a sync() call right after the call to drmCtlInstHandler(), the resume succeeds. This is a kludge fix; someone who knows more about this codebase should come up with the appropriate way to synchronize all CPUs here instead of this forcing synchronization indirectly by telling the kernel to flush all buffers to disk.

More information and a temp patch will come tonight if a better fix doesn't appear before then. I have a deadline in another project tonight that I should be working on instead right now...

Revision history for this message
Austin Chu (eefi) wrote :

Okay... to follow up from before, here's the patch that adds a sync() call after the call to drmCtlInstHandler() in src/i830_dri.c:I830DRIInstIrqHandler(). If you put the sync() call before the call to drmCtlInstHandler(), resume will hang as before. Putting this sync() call after the call to drmCtlInstHandler() fixes the resume.

I have tested this on my ThinkPad X301 with GM45 graphics. I actually use plain Debian unstable myself, so I've built a package for Debian unstable at http://web.mit.edu/eefi/www/debian-thinkpad-x301/xserver-xorg-video-intel_2.4.2-2~saffroncity.2_amd64.deb based on the Debian experimental package plus the three patches needed for my laptop (details at http://web.mit.edu/eefi/www/debian-thinkpad-x301/ ).

This package may or may not work with Intrepid; I make no guarantees. If someone wants to build a package for intrepid, then do the usual aptitude build-dep xserver-xorg-video-intel ; apt-get source xserver-xorg-video-intel dance. This patch can be dropped into debian/patches and added to debian/patches/series.

For the actual X.Org developers, the fact that this patch works (sync() forces synchronization between the two CPUs, I believe, in order to ensure flushing of all buffered data to disk) along with the fact that for some people, turning all but one CPU off before suspending helps seems to indicate that what's needed is some kind of synchronization after installation of the DRI IRQ handler so that both CPUs pick that up in time. Note that during the resume process, I830DRIInstIrqHandler() is called from I830EnterVT() in src/i830_driver.c (line 3430 or thereabouts in my copy).

Revision history for this message
Andy Whitcroft (apw) wrote :

This sounds enormously like the problems I am seeing on my Dell Studio 15. Following this work around (as mentioned above) seems to have worked for me:

    http://ubuntuforums.org/showpost.php?p=6105510&postcount=12

Revision history for this message
Nick Booker (nmbooker) wrote :

I tried applying EspeonEefi's patch which seemed to fix resume from hibernate, but resume from suspend still caused a crash.

Anyway Andy's fix worked for the laptop I was setting up, and it agrees with the patch on thinkwiki.org.

Thank you both.

Revision history for this message
Aaron Roydhouse (aaron-roydhouse) wrote :

I've read other threads like this, as I sometimes had the same problem on an Lenovo X301. The workaround for me was to switch to just one cpu core before suspending/hibernating. When you resume/thaw, give it a few seconds and switch the other core back on. This worked for me. The theory is that there is a multi-threading issue somewhere which can affect multi-core CPU, perhaps just these low-power ones. You can automate the fix with a script in /etc/pm/sleep.d/, see thread for example:

  http://ubuntuforums.org/showthread.php?t=959712&page=2

Aaron.

Revision history for this message
Erno Kuusela (erno-iki) wrote :

A co-worker who is running an identical x200 with fedora 10 (beta) hit the same problem, and claimed it is fixed by
kernel drm changes from here: http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-11/msg03815.html

Revision history for this message
Erno Kuusela (erno-iki) wrote :

... and specifically the change described as "i915: Save/restore MCHBAR_RENDER_STANDBY on GM965/GM45" from the above

Revision history for this message
Chris Samuel (chris-csamuel) wrote :

I'm having the same issue with my new work Dell E4200 with Intel Mobile 4 Series integrated graphics; on resume from hibernate or suspend I get a black X screen with the mouse pointer locked solid.

I can also confirm that the work around of taking CPU1 offline prior to hibernating fixes it (haven't tested suspend yet).

Attached lspci -vvvv output, will attach dmesg and Xorg.0.log in subsequent comments.

Revision history for this message
Chris Samuel (chris-csamuel) wrote :
Revision history for this message
Chris Samuel (chris-csamuel) wrote :
Revision history for this message
Chris Samuel (chris-csamuel) wrote :

I can confirm that suspend also works with CPU1 offlined.

Revision history for this message
Jonas Pedersen (jonasped) wrote :

Just tried the workaround with disabling one CPU core during resume/suspend. I can also confirm that this workaround is working. Have used both hibernate and suspend a few times and it works like a charm. The script mentioned in http://ubuntuforums.org/showthread.php?t=959712&page=2 works perfect.

Revision history for this message
Austin Chu (eefi) wrote :

Just to follow up on my earlier comments, I just upgraded to xserver-xorg-video-intel 2.5.1-1 that just landed in Debian experimental, and it seems to work just fine for suspend and hibernate without any patches.

Revision history for this message
Andy Whitcroft (apw) wrote :

@Erno Kuusela -- I can confirm that the change suggested by your collegue does seem to fix the main resume issue without disabling the second CPU. At least that is what my testing seems to show on a Dell Studio 15 (1537).

I pulled the commit below back to the Intrepid kernel and I could suspend and resume without the workaround script. I should note that I have also confirmed that I get a hang always on the second resume with events/1, though it should be noted I am getting some kind of hand always on the second resume (with or without the patch):

  commit 881ee9889c8b98671c5491e43666bf5d4f78a180
  Author: Keith Packard <email address hidden>
  Date: Sun Nov 2 23:08:44 2008 -0800

    i915: Save/restore MCHBAR_RENDER_STANDBY on GM965/GM45

    This register is set by the 2D driver to prevent lockups, and so it needs to
    be preserved across suspend/resume too. This makes my X200s work.

    Signed-off-by: Keith Packard <email address hidden>
    Signed-off-by: Eric Anholt <email address hidden>
    Signed-off-by: Dave Airlie <email address hidden>

Revision history for this message
Andy Whitcroft (apw) wrote :

As there seems to be fixes related to this in the kernel this should also 'affect' the kernel package linux.

Changed in linux:
assignee: nobody → apw
status: New → In Progress
Andy Whitcroft (apw)
Changed in linux:
importance: Undecided → Medium
Revision history for this message
Austin Chu (eefi) wrote :

Just for the record, xserver-xorg-video-intel 2.5.1-1 in Debian experimental actually did not fix the problem for me after all. It just turned it from reliably happening upon every suspend and resume to happening only once in a week.

Revision history for this message
Andy Whitcroft (apw) wrote :

I have been running a -11 (not yet in proposed) with the patch suggested above and at least for me have been having a very good experience. I have performed some 10 suspend/resume cycles without seeing this issue, all without the CPU work around enabled. I will get some test kernels built for testing.

Revision history for this message
Andy Whitcroft (apw) wrote :

I have uploaded some test kernels to the URL below. If those who are seeing this issue could test them and report back here that would be very useful:

    http://people.ubuntu.com/~apw/lp276943/

Revision history for this message
Chris Samuel (chris-csamuel) wrote :

I can happily report that (for IA-32 at least) those proposed -11 kernel seems to work for me (as does 2.6.28-rc8 which I'm using from day to day).

I also discovered that even the -9 kernel that's currently out there doesn't have the problem if you don't have desktop effects enabled in KDE4 (obviously because at that point you're not using DRI).

Revision history for this message
Sebastian Gaul (n-admin-mgvmedia-com) wrote :

Resume does finally work with the kernel, at least for the moment it seems to. Thanks to Andy. But I have two questions:

1. I can't install the header file to the kernel. The deb installer says: "Error: Dependency is not satisfiable: linux-headers-2.6.27-11". Are these headers important? I don't have a clue what they are good for...

2. Resuming takes very long time, something from 5 to 10 seconds... Is this normal? I think booting takes aprox. 20 seconds, so it seems that suspend doesn't make any sense to me for the moment. Is there some log or something like that where I can find out, what the problem is? /var/log/pm-suspend.log does not tell about any problems.

Thanks a lot.

Revision history for this message
Andy Whitcroft (apw) wrote : Re: [Bug 276943] Re: Resume from suspend doesn't not work on the Mobile 4 Series chipsets

On Wed, Dec 17, 2008 at 07:27:51PM -0000, Sebastian Gaul wrote:
> Resume does finally work with the kernel, at least for the moment it
> seems to. Thanks to Andy. But I have two questions:
>
> 1. I can't install the header file to the kernel. The deb installer
> says: "Error: Dependency is not satisfiable: linux-headers-2.6.27-11".
> Are these headers important? I don't have a clue what they are good
> for...

There should be three headers files there, one for i386, one for amd64,
and one for 'all'. You would need both the 'all' and the appropriate
architecture one. They are needed if you have binary drivers such as
nvidia drivers under DKMS.

> 2. Resuming takes very long time, something from 5 to 10 seconds... Is
> this normal? I think booting takes aprox. 20 seconds, so it seems that
> suspend doesn't make any sense to me for the moment. Is there some log
> or something like that where I can find out, what the problem is?
> /var/log/pm-suspend.log does not tell about any problems.

I have not seen that locally, I have seen some odd delays when asking
for the suspend. As yet I have no idea of a cause.

Revision history for this message
Erno Kuusela (erno-iki) wrote : Re: Resume from suspend doesn't not work on the Mobile 4 Series chipsets

Works great over here (amd64, X200s). Hopefully there will fix through the official updates soon?

Revision history for this message
Bryce Harrington (bryce) wrote :

[This is an automatic notice.]

We'd like to forward your bug upstream, however upstream requires
that you first test it against their newer driver code.

To save you the effort of building the driver from source, we've built
packages for the driver and its new dependencies.

So you have a couple options:

 1. Download and test .debs for intrepid, from:
     https://edge.launchpad.net/~intel-gfx-testing/+archive

 -or-

 2. Download and test the Jaunty alpha-2 (or newer) Live CD,
     (which includes a beta of the new xserver 1.6 as well).
     See http://cdimage.ubuntu.com/releases/9.04/ for ISOs

Thanks ahead of time! You can simply reply to this email to report your
findings.

P.S., if you wish to forward your bug upstream yourself, please follow
these directions to do so:
  http://intellinuxgraphics.org/how_to_report_bug.html

Changed in xserver-xorg-video-intel:
status: Confirmed → Incomplete
Revision history for this message
Matteo Collina (matteo-collina) wrote :

Andy, the patch works like a charm. Are there some possibilities to see it in intrepid?
I've also tried the jaunty kernel and it's not affected by the bug: maybe the patch is already there.
(I have a dell E6400 with the intel X4500HD).

Revision history for this message
Andy Whitcroft (apw) wrote :

@Bryce Harrington -- this patch is a backport from a mainline commit, this is our commit which links to it:

    i915: Save/restore MCHBAR_RENDER_STANDBY on GM965/GM45

    commit 881ee9889c8b98671c5491e43666bf5d4f78a180 upstream

    This register is set by the 2D driver to prevent lockups, and so it needs to
    be preserved across suspend/resume too. This makes my X200s work.

    Signed-off-by: Keith Packard <email address hidden>
    Signed-off-by: Eric Anholt <email address hidden>
    Signed-off-by: Dave Airlie <email address hidden>
    Signed-off-by: Andy Whitcroft <email address hidden>

Revision history for this message
Aaron (aagbsn) wrote :

Andy, patch works on my Thinkpad x200 with 8.10 i386

Revision history for this message
Bryce Harrington (bryce) wrote :

Andy, great thanks - since this appears to be a kernel bug fixed by a kernel patch that seems to already be in jaunty, I'll drop the -intel bug task.

Changed in xserver-xorg-video-intel:
importance: Undecided → High
status: Incomplete → Fix Released
Revision history for this message
Andy Whitcroft (apw) wrote :

This fix is already in 2.6.28, and with the Jaunty kernel based on 2.6.28 released is now Fix Released there. For intrepid I am proposing this for SRU.

Changed in xserver-xorg-video-intel:
status: New → Invalid
Changed in linux:
status: New → Fix Committed
status: In Progress → Fix Released
Revision history for this message
Andy Whitcroft (apw) wrote :

SRU Justification:

Impact: Systems with Intel Mobile 4 based graphics will hang on resume

Fix Description: Additional register needs to be saved and restored across suspend/resume

Patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=c06ab899b5bd91953daf7af1d5cee68f157245e0

Risks: This has been tested on actual hardware for a number of weeks, it is specific to identified hardware components.

TEST CASE: suspend/resume will hang without this fix

Revision history for this message
Martin Pitt (pitti) wrote :

Accepted linux into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Revision history for this message
Jan Schneider (yunosh) wrote :

Doesn't show up in intrepid-proposed yet.

Revision history for this message
Jan Schneider (yunosh) wrote :

The new kernel finally showed up and indeed seems to fix the standby/suspend problems, with only a few minor glitches. I'm mentioning them here just in case, though they might be unrelated:
- After resuming I get a message that a new monitor has been detected. When opening the KDE dialog for setting up the monitor, the LDVS and VGA entries are activated, but the VGA does not detect a monitor. It shouldn't anyway, because there is really no monitor attached.
- After resuming from standby, the wlan link is disabled, but it can be turned on manually without problems.
- When going into suspend, the screen is flickering like hell, until the machine is finally turned off.

This is a Dell Inspiron E6500 with an GM45 IGM and an Intel 5300 wifi chip.

Revision history for this message
hasi (whynot-nurfuerspam) wrote :

Jan:

Are you able to do several subsequent suspend/resume cycles successfully? I have almost the same hardware than you (E6400 with GM45 and Intel 5300). My resume works perfect the first time. When I did it the second time, the touchpad did not work correctly. It behaved like it was in PS/2 emulation mode. The third time, the problems became even bigger: the system could not make a WiFi connection, and CPU1 was locked up at 100% by a process called events/0.

I am currently using the latest kernel (2.6.27.11), however, I am on kubuntu 8.10 (with KDE 4.2 beta2). Can you test several suspend/resumes on your machine in order to find out whether this could possibly be a KDE-specific issue?

The problem with the locked up CPU1 I also got frequently in the previous kernel version(s).

Revision history for this message
Jan Schneider (yunosh) wrote :

Even worse, now that I tested it more thoroughly. After the 2nd standby/resume cycle, the display stayed blank, even though X/KDE seem to have been back, judged by the LED activity. Alt-Ctrl-Backspace got it back, but in the wrong resolution. After that, all further standby/resume cycles worked fine.
[Update: maybe this was related to the fact that I still had the CPU-shutdown-workaround installed. After I removed it, it seems to standby/resume much more stable. Still wifi turned off after certain cycles, and monitor detection popup.]

Suspend/resume cycles seem to be completely stable now, beside the flickering.

I've seen then touchpad issues too with my first testing after the kernel update, but not anymore.

Revision history for this message
Georg Sauthoff (g-sauthoff) wrote :

I can confirm this bug on a Thinkpad X200 (on a fresh Intrepid system). The resume after suspend-to-ram does not work, i.e. X hangs and after 1 minute the system reboots.

Enabling the proposed-updates repository und doing a dist-upgrade fixed this bug so far (i.e. now the resume works).

The suspend/resume still is not perfect - i.e. I get a 'new monitor detected' message in kde4, and the 'xrandr' thinks after a resume that ports are connected, which actually aren't and weren't before the suspend.

Revision history for this message
Hanno Stock (hefe_bia) (hanno-stock) wrote :

I can confirm this bug on a Thinkpad T400 (fresh Intrepid system). The symptoms are exactly as described above.

Enabling the proposed-updates repository did NOT fix the bug for me! The symptoms stay the same. I can resume from suspend when I deactivate all but one core before suspend, however the system freezes as soon as I enable the second core again.
(If I do the enabling on a console, the system does not hang until I switch back to X)

hanno@sputnik2:/etc/pm/sleep.d$ uname -a
Linux sputnik2 2.6.27-11-generic #1 SMP Thu Jan 15 11:42:36 UTC 2009 x86_64 GNU/Linux

Also tried the updated graphics driver mentioned above.
(II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so
(II) Module intel: vendor="X.Org Foundation"
 compiled for 1.5.2, module version = 2.5.1
 Module class: X.Org Video Driver
 ABI class: X.Org Video Driver, version 4.1

Revision history for this message
Hanno Stock (hefe_bia) (hanno-stock) wrote :

Suspend / Resume is now working for me, too. The following xorg.conf configuration caused my system to still crash on resume:

Section "Device"
        Identifier "Configured Video Device"
        Option "DynamicClocks" "true"
 Option "NoDri" "true"
EndSection

After deleting this configuration (I had it for power saving) suspend / resume works, except after a login / logout I have the same screen issues as mentioned by Jan Schneider - also gdm will start with the wrong resolution.

I also noticed that the system seems to draw more power and the fan is louder after the resume. (I also had this issue before with the single core workaround)

Revision history for this message
Neville Grech (nevillegrech) wrote :

The fix doesn't make problems disappear for me, system still freezes 1/3 times on average. However before, the system would always freeze on resume.

Revision history for this message
Andy Whitcroft (apw) wrote :

@Neville -- is the freeze exactly the same or are you able to login and then it freezes a little later. I have seen a couple of instances where things hang with the network manager icon "locked".

Changed in linux:
assignee: nobody → apw
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (16.6 KiB)

This bug was fixed in the package linux - 2.6.27-11.25

---------------
linux (2.6.27-11.25) intrepid-proposed; urgency=low

  [ Jeff Layton ]

  * SAUCE: cifs: make sure we allocate enough storage for socket address
    - LP: #318565

linux (2.6.27-11.24) intrepid-proposed; urgency=low

  [ Stefan Bader ]

  * Revert "SAUCE: don't use buggy _BCL/_BCM/_BQC for backlight control"
    - LP: #311716
  * SAUCE: acpi: Hack to enable video and vendor backlight implementations
    - LP: #311716
  * SAUCE: Force vendor backlight control on ThinkPad T61
    - LP: #311716

  [ Upstream Kernel Changes ]

  * Revert "thinkpad_acpi: fingers off backlight if video.ko is serving
    this functionality"
    - LP: #311716

linux (2.6.27-11.23) intrepid-proposed; urgency=low

  [ Andy Whitcroft ]

  * SAUCE: don't use buggy _BCL/_BCM/_BQC for backlight control
    - LP: #311716, #314119

  [ Jim Lieb ]

  * SAUCE: atl2: add tx bytes statistic
    - LP: #268622

  [ Upstream Kernel Changes ]

  * i915: Save/restore MCHBAR_RENDER_STANDBY on GM965/GM45
    - LP: #276943

linux (2.6.27-11.22) intrepid-proposed; urgency=low

  [ Andy Whitcroft ]

  * Revert "synchronise our linux-libc-dev with the kernel userspace
    headers". It was causing regressions.
    - LP: #300803

  [ Brian Rogers ]

  * SAUCE: Add support for MSI TV@nywhere Plus remote
    - LP: #281647

  [ Tim Gardner ]

  * SAUCE: Dell laptop digital mic does not work, PCI 1028:0271
    - LP: #309508

  [ Upstream Kernel Changes ]

  * Revert "sched_clock: prevent scd->clock from moving backwards"
  * AMD IOMMU: enable device isolation per default
  * bonding: fix miimon failure counter
  * x86 Fix VMI crash on boot in 2.6.28-rc8
  * libata: fix Seagate NCQ+FLUSH blacklist
  * e1000e: fix double release of mutex
  * can: Fix CAN_(EFF|RTR)_FLAG handling in can_filter
  * can: omit received RTR frames for single ID filter lists
  * iwlwifi: clean key table in iwl_clear_stations_table function
  * net: eliminate warning from NETIF_F_UFO on bridge
  * unicode table for cp437
  * console ASCII glyph 1:1 mapping
  * key: fix setkey(8) policy set breakage
  * firewire: fw-ohci: fix IOMMU resource exhaustion
  * ieee1394: add quirk fix for Freecom HDD
  * SUNRPC: Fix a performance regression in the RPC authentication code
  * b1isa: fix b1isa_exit() to really remove registered capi controllers
  * macfb: Do not overflow fb_fix_screeninfo.id
  * setup_per_zone_pages_min(): take zone->lock instead of zone->lru_lock
  * xilinx_hwicap: remove improper wording in license statement
  * Linux 2.6.27.10 except for "iwlagn: fix RX skb alignment". Besides causing
    an ABI bump it only applies to machines using > 4K page size (such as PowerPC).
    Pick this one up on the next ABI bumping upload.
    - LP: #309731

linux (2.6.27-11.21) intrepid-proposed; urgency=low

  [ Andy Whitcroft ]

  * synchronise our linux-libc-dev with the kernel userspace headers
    - LP: #300803

  [ Jim Lieb ]

  * SAUCE: [PATCH 1/1] USB: Unusual devs patch for Nokia 5610
    - LP: #287701

  [ Michael Krufky ]

  * sms1xxx: use new firmware for Hauppauge WinTV MiniStick
    - LP: #299671
  * sms1xxx: add autodetection support for Hauppa...

Changed in linux:
status: Fix Committed → Fix Released
Revision history for this message
Neville Grech (nevillegrech) wrote :

@Andy
Sorry for the delayed reply.
I managed to come up with a deterministic sequence of events that always results in a hang when resuming from suspend:

Basically, if the laptop is booted from battery power AND there are no external displays attached, the machine hangs every time on resume (one cannot even log in). Machine doesn't hang if one CPU is offlined.

In any other cases, resume *seems* to work fine.

neville@neville-laptop:~$ uname -a
Linux neville-laptop 2.6.27-11-generic #1 SMP Tue Jan 27 23:53:21 UTC 2009 x86_64 GNU/Linux
neville@neville-laptop:~$

Changed in xserver-xorg-video-intel:
status: Confirmed → Invalid
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
status: Invalid → Unknown
Changed in xserver-xorg-video-intel:
importance: Medium → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
Changed in xserver-xorg-video-intel:
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.