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

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?

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

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.

Hi arnold,

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

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.

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

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

and lspci...

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

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

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

and Xorg.0.log...

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

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

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

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.

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.

(adding 8.04_xorg_after_suspend)

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.

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.

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.

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

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

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

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

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

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.

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.

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

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

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.

I can confirm that suspend also works with CPU1 offlined.

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.

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.

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

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

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.

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.

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/

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

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.

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.

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

[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

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

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

Andy, patch works on my Thinkpad x200 with 8.10 i386

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.

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.

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

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!

Doesn't show up in intrepid-proposed yet.

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.

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

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.

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.

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

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)

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.

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

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

@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:~$