backlight failed after suspend to ram on IBM X40

I upgraded my X40 from Hardy Heron to 8.10, and now have the same issue, systematically. The only workaround is to shutdown and reboot, rather than use suspend.

Yeah, same issue here, looks like it's systematically reproducible. I also occasionally get it going back to sleep directly after having woken up.

This is driving me nuts, so would be incredibly grateful for any fix/workaround!

Wow.. I tried so many things to get this working again.
There are bugreports about this issue everywhere.
It's even listed as a kernel bug: http://bugzilla.kernel.org/show_bug.cgi?id=10985

What happened?

From what I have found out, the following thing happened:
- Ubuntu was using uswsusp / s2ram to suspend prior to intrepid. Everything was fine.
- Someone decided that uswsusp was not cool and removed it from the repository, to force everyone to use pm-utils.
  ( see https://bugs.launchpad.net/ubuntu/+source/uswsusp/+bug/134238 )
- pm-utils uses the kernel builtin suspend functions.
- this is the point at which we are at the "kernel bug". Everything is bad.

What to do?

Well, pm-utils / pm-suspend seems to have the same "quirk" options as s2ram had, with the difference that s2ram works for me and pm-suspend doesn't. I tried nearly every quirk / combination of quirks (which took hours!).

I will now describe what I did, to get suspend working on my laptop again.
(My laptop is a Samsung q30, but i had the same issues)

Because I couldn't find uswsusp in the ubuntu repository i downloaded it from
http://packages.debian.org/en/sid/uswsusp
and installed it.

Next step is to find out, which quirks your laptop needs.
Many laptops are listed in the s2ram whitelist.
If your laptop is in this list, a simple "sudo s2ram" in the console should do the trick.
If not, you have to force s2ram and probably use some quirks.
(All options are listed if you type "s2ram --help" or "man s2ram")

The ibm x40 laptop is listed in this whitelist (from what i have seen),
so you should be able to use "sudo s2ram".
If that does not work, try "sudo s2ram --force --acpi_sleep 3".
For my Samsung Q30 "sudo s2ram --force --vbe_post" did the trick.

Last step was to force ubuntu to use s2ram again...
But that's another (very ugly) story.
Please let me know if your x40 laptops do suspend using s2ram and if you want me to write how i managed to force ubuntu to use s2ram.

pm-suspend --quirk-vbe-post has no effect.
(or all quirks (/ hal fdi files) are ignored since intrepid)

On Sun, 2008-11-09 at 00:18 +0000, japi wrote:
> pm-suspend --quirk-vbe-post has no effect.
> (or all quirks (/ hal fdi files) are ignored since intrepid)
>
> ** Changed in: pm-utils (Ubuntu)
> Sourcepackagename: None => pm-utils
>
vbe_post()
{
        local rom="/var/run/video.rom"
        # if we do not have a romfile, do not post with it.
        [ -f "$rom" ] || unset rom
        vbe post $rom
        sleep 0.1
}

It seems that this is run upon resume if you call pm-suspend --quirk-vbe-post. Do you have a file /var/run/video.rom?
--
Chow Loong Jin

One thing I'd like to mention is that you don't have to "force" Ubuntu
to use s2ram, it's a choice that's made
here: /etc/pm/config.d/00sleep_module. Uncomment the SUSPEND_MODULE line
and set it to "uswsusp".

--
Chow Loong Jin

I have no /var/run/video.rom and couldn't find a file with that name anywhere in the system.
But why doesn't s2ram need that file?

> One thing I'd like to mention is that you don't have to "force" Ubuntu
> to use s2ram, it's a choice that's made
> here: /etc/pm/config.d/00sleep_module. Uncomment the SUSPEND_MODULE line
> and set it to "uswsusp".

I have already tried that.
First problem here is, that uswsusp has no s2ram in ubuntu anymore. So switching to uswsusp as suspend_module has no real effect.

I bypassed this problem by installing the debian uswsusp with s2ram.

But there is a second problem:
The setting there seems to be ignored anyway, because still everything runs over "/usr/lib/hal/scripts/linux/hal-system-power-suspend-linux" in the end.
And there is a nice comment stating: "# We only support pm-utils", which seems to be true.
Changing the line
"/usr/sbin/pm-suspend $QUIRKS"
into
"/usr/sbin/s2ram --force --vbe_post"
works nicely for me.

On Sun, 2008-11-09 at 12:02 +0000, japi wrote:
> I have no /var/run/video.rom and couldn't find a file with that name anywhere in the system.
> But why doesn't s2ram need that file?
>
>
> > One thing I'd like to mention is that you don't have to "force" Ubuntu
> > to use s2ram, it's a choice that's made
> > here: /etc/pm/config.d/00sleep_module. Uncomment the SUSPEND_MODULE line
> > and set it to "uswsusp".
>
> I have already tried that.
> First problem here is, that uswsusp has no s2ram in ubuntu anymore. So switching to uswsusp as suspend_module has no real effect.
>
> I bypassed this problem by installing the debian uswsusp with s2ram.
>
> But there is a second problem:
> The setting there seems to be ignored anyway, because still everything runs over "/usr/lib/hal/scripts/linux/hal-system-power-suspend-linux" in the end.
> And there is a nice comment stating: "# We only support pm-utils", which seems to be true.
> Changing the line
> "/usr/sbin/pm-suspend $QUIRKS"
> into
> "/usr/sbin/s2ram --force --vbe_post"
> works nicely for me.
>
Sorry, I forgot you need pm-utils 1.1.2.4-1ubuntu8 from
intrepid-proposed for that to have effect. Please test. pm-suspend has a
few backends that it uses, which are tuxonice, kernel, and uswsusp. If
uswsusp is selected, as of ubuntu8, it'll use s2ram if found, otherwise
it'll use the kernel backend for suspend and s2disk for hibernate.

So yeah HAL supports only pm-utils, but pm-utils supports uswsusp,
kernel, and tuxonice. Don't bypass it.
--
Chow Loong Jin

Another thing I forgot to mention... if you can ssh into the computer,
try this command:
sudo vbetool post

This is the pm-utils vbe-post quirk. If it doesn't work, something is
wrong with vbetool, and the bug should be marked as affecting vbetool.
--
Chow Loong Jin

sudo vbetool post does work.
(i can switch to tty1 and type the command, which then switches my backlight on)

I have now switched to pm-utils 1.1.2.4-1ubuntu8,
but still
sudo pm-suspend --quirk-vbe-post
has no effect.
(i have tried it with suspend_module="uswsusp" and "kernel" in /etc/pm/config.d/00sleep_module)

On Sun, 2008-11-09 at 14:10 +0000, japi wrote:
> sudo vbetool post does work.
> (i can switch to tty1 and type the command, which then switches my backlight on)
>
> I have now switched to pm-utils 1.1.2.4-1ubuntu8,
> but still
> sudo pm-suspend --quirk-vbe-post
> has no effect.
> (i have tried it with suspend_module="uswsusp" and "kernel" in /etc/pm/config.d/00sleep_module)
>
It has to be in caps. One line that looks like this:
SUSPEND_MODULE="uswsusp"

Could you post your /var/log/pm-suspend.log after each test case
(running pm-suspend with uswsusp and kernel)?
--
Chow Loong Jin

Okay, sorry for that, i meant SLEEP_MODULE="uswsusp".
Just to be sure i have used SLEEP_MODULE and SUSPEND_MODULE for the following tests :-) :

Here is my logfile for SLEEP_MODULE="kernel":
http://www.ziqu.de/launchpad/pm-suspend.log_kernel.txt

and here for SLEEP_MODULE="uswsusp":
http://www.ziqu.de/launchpad/pm-suspend.log_uswsusp.txt

(also attached here as tarfile)

On Sun, 2008-11-09 at 14:53 +0000, japi wrote:
> Okay, sorry for that, i meant SLEEP_MODULE="uswsusp".
> Just to be sure i have used SLEEP_MODULE and SUSPEND_MODULE for the following tests :-) :
>
> Here is my logfile for SLEEP_MODULE="kernel":
> http://www.ziqu.de/launchpad/pm-suspend.log_kernel.txt
>
> and here for SLEEP_MODULE="uswsusp":
> http://www.ziqu.de/launchpad/pm-suspend.log_uswsusp.txt
>
> (also attached here as tarfile)
>
> ** Attachment added: "logfiles_pm-suspend.tar"
> http://launchpadlibrarian.net/19511716/logfiles_pm-suspend.tar
>
Out of curiosity, what's in /etc/pm/sleep.d/config? Not that it'll
change anything, since it's not working, as shown by the lines in
pm-suspend.log

Also, sorry, I meant SLEEP_MODULE. You can remove the SUSPEND_MODULE
line.

It seems that the tty is switched to TTY1 in the case of uswsusp, but
not in the case of kernel. Could you test if running pm-suspend
--quirk-vbe-post from TTY1 works? With SLEEP_MODULE="kernel" I mean.

Thanks for your help.
--
Chow Loong Jin

Oh, that's something left from my testing in the last days...
just a file with the two lines
SUSPEND_MODULES="button uhci_hcd"
and
S2RAM_OPTS="--force --vbe_post"
in it.
Found that on the net somewhere (suse i think).
I deleted it now.

pm-suspend --quirk-vbe-post
does not work from tty1 (neither with SLEEP_MODULE kernel nor with uswsusp).

I attached my pm-suspend.log (generated with SLEEP_MODULE="kernel", /etc/pm/sleep.d/config deleted, and "pm-suspend
--quirk-vbe-post" run from tty1).

(I have to thank you! :-)

I just noticed, that s2ram does that switch to vt1 and back.
I think that s2ram is run (if using uswsusp module), just not with the --vbe_post option (although pm-suspend is run with --quirk-vbe-post).

On Sun, 2008-11-09 at 16:59 +0000, japi wrote:
> I just noticed, that s2ram does that switch to vt1 and back.
> I think that s2ram is run (if using uswsusp module), just not with the --vbe_post option (although pm-suspend is run with --quirk-vbe-post).
>
Okay, could you check if there's a
file /var/run/pm-utils/storage/parameters.rm ? If there is, please post
it here.
--
Chow Loong Jin

Yes, there is a file with the content:

--quirk-dpms-on
--quirk-dpms-suspend
--quirk-vbe-post
--quirk-vbe-post
--quirk-vga-mode3
--quirk-vbemode-restore
--quirk-vbestate-restore
--quirk-reset-brightness
--quirk-radeon-off

On Sun, 2008-11-09 at 17:29 +0000, japi wrote:
> Yes, there is a file with the content:
>
> --quirk-dpms-on
> --quirk-dpms-suspend
> --quirk-vbe-post
> --quirk-vbe-post
> --quirk-vga-mode3
> --quirk-vbemode-restore
> --quirk-vbestate-restore
> --quirk-reset-brightness
> --quirk-radeon-off
>
Okay, now try removing /usr/lib/pm-utils/98smart-kernel-video. Back it
up somewhere first so you can restore it if necessary. Then try again
(both with uswsusp and kernel).

By the way, what's your GPU? (lspci -nn|grep VGA)
--
Chow Loong Jin

lspci -nn|grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)

sudo s2ram -i
This machine can be identified by:
    sys_vendor = "Samsung Electronics"
    sys_product = "SQ30"
    sys_version = "Revision 01"
    bios_version = "01LK"

I don't have a 98smart-kernel-video at /usr/lib/pm-utils/ but have one in /usr/lib/pm-utils/sleep.d , so i removed that.

Great news:
sudo pm-suspend --quirk-vbe-post
now works!
(in every case:
- from tty1 with kernel
- from X with kernel
- from tty1 with uswsusp
- from X with uswsusp)

:-)

Even the gnome power manager / suspend buttons of the laptop work now :-)

Thank you!

On Sun, 2008-11-09 at 18:11 +0000, japi wrote:
> lspci -nn|grep VGA
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)
>
> sudo s2ram -i
> This machine can be identified by:
> sys_vendor = "Samsung Electronics"
> sys_product = "SQ30"
> sys_version = "Revision 01"
> bios_version = "01LK"
>
> I don't have a 98smart-kernel-video at /usr/lib/pm-utils/ but have one
> in /usr/lib/pm-utils/sleep.d , so i removed that.
>
> Great news:
> sudo pm-suspend --quirk-vbe-post
> now works!
> (in every case:
> - from tty1 with kernel
> - from X with kernel
> - from tty1 with uswsusp
> - from X with uswsusp)
>
> :-)
>
> Even the gnome power manager / suspend buttons of the laptop work now
> :-)
>
> Thank you!
>
Awesome.

Okay, now to get the packaging part... we need to make an exception for
your Thinkpad series.

Right now, the check used is.. if /sys/module/i915 is present, and
kernel version >= 2.6.26. We need to find a way to exclude all affected
users, before a patch for this can be rolled out to Intrepid.

I don't know how, though. Perhaps the original author of this particular
file would know?

  subscribe victor-lowther
--
Chow Loong Jin

Hyperair, could you summarize what I need to do on my thinkpad x40 in order to test this fix?

Hm.. I don't get it...
Why does 98smart-kernel-video remove these quirks which are "known to work"?
(My laptop for example: it is listed in /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-samsung.fdi with the right quirk, vbe-post.
The ibm x40 can be found in 20-video-quirk-pm-ibm.fdi...
But regardless of that the quirks seem to be removed.)
Am I mixing things up?

Thanks,
Jan

On Sun, 2008-11-09 at 22:52 +0000, Pieter Hintjens wrote:
> Hyperair, could you summarize what I need to do on my thinkpad x40 in
> order to test this fix?
>
Delete /usr/lib/pm-utils/sleep.d/98smart-kernel-video. It's not a "fix"
but a temporary workaround. Either way the problem now is to make this
an official fix in the pm-utils package, while not causing regressions
to those not affected by the bug. What's your GPU, by the way?
--
Chow Loong Jin

On Mon, Nov 10, 2008 at 12:18 AM, hyperair <email address hidden> wrote:

> Delete /usr/lib/pm-utils/sleep.d/98smart-kernel-video. It's not a "fix"
> but a temporary workaround. Either way the problem now is to make this
> an official fix in the pm-utils package, while not causing regressions
> to those not affected by the bug. What's your GPU, by the way?

lspci reports "VGA compatible controller: Intel Corporation
82852/855GM Integrated Graphics Device (rev 02)"

I can confirm the workaround: after deleting the 98smart-kernel-video
file, resume now works properly. This is really great. Thanks!

Do you think this might be related to
https://bugs.launchpad.net/ubuntu/+bug/294640?

Cheers,
Pieter

On Sun, 2008-11-09 at 23:38 +0000, Pieter Hintjens wrote:
> On Mon, Nov 10, 2008 at 12:18 AM, hyperair <email address hidden> wrote:
>
> > Delete /usr/lib/pm-utils/sleep.d/98smart-kernel-video. It's not a "fix"
> > but a temporary workaround. Either way the problem now is to make this
> > an official fix in the pm-utils package, while not causing regressions
> > to those not affected by the bug. What's your GPU, by the way?
>
> lspci reports "VGA compatible controller: Intel Corporation
> 82852/855GM Integrated Graphics Device (rev 02)"
>
> I can confirm the workaround: after deleting the 98smart-kernel-video
> file, resume now works properly. This is really great. Thanks!
>
> Do you think this might be related to
> https://bugs.launchpad.net/ubuntu/+bug/294640?
>
> Cheers,
> Pieter
>
Other than that it's the same hardware, and same driver, no not related.
Anyway, could you post the output of this command?
lshal | grep quirk

Also, coud you try sticking back
the /usr/lib/pm-utils/sleep.d/98smart-kernel-suspend hook and trying
this:
pm-suspend --quirk-s3-mode --quirk-s3-bios

More information:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487278

--
Chow Loong Jin

On Mon, Nov 10, 2008 at 6:20 AM, hyperair <email address hidden> wrote:

> Anyway, could you post the output of this command?
> lshal | grep quirk

Empty: no quirk in the lshal output.

> Also, coud you try sticking back
> the /usr/lib/pm-utils/sleep.d/98smart-kernel-suspend hook and trying
> this:
> pm-suspend --quirk-s3-mode --quirk-s3-bios

I replaced the 98smart-kernel-suspend-hook, but can no longer
reproduce the original problem. Suspend/resume now works, shutting
the lid, using the KDE power manager 'Suspend' option, and also using
the pm-suspend command.

On Mon, Nov 10, 2008 at 11:00 AM, Pieter Hintjens <email address hidden> wrote:

> I replaced the 98smart-kernel-suspend-hook, but can no longer
> reproduce the original problem. Suspend/resume now works, shutting
> the lid, using the KDE power manager 'Suspend' option, and also using
> the pm-suspend command.

Correction: "pm_suspend --quirk-s3-mode --quirk-s3-bios" seems to be
sticky. That is, running it once fixed the suspend/resume
functionality, even over a reboot. Running "pm_suspend" with no
arguments then caused the backlighting failure to come back.

-Pieter

On Mon, 2008-11-10 at 10:00 +0000, Pieter Hintjens wrote:
> On Mon, Nov 10, 2008 at 6:20 AM, hyperair <email address hidden> wrote:
>
> > Anyway, could you post the output of this command?
> > lshal | grep quirk
>
> Empty: no quirk in the lshal output.
>
> > Also, coud you try sticking back
> > the /usr/lib/pm-utils/sleep.d/98smart-kernel-suspend hook and trying
> > this:
> > pm-suspend --quirk-s3-mode --quirk-s3-bios
>
> I replaced the 98smart-kernel-suspend-hook, but can no longer
> reproduce the original problem. Suspend/resume now works, shutting
> the lid, using the KDE power manager 'Suspend' option, and also using
> the pm-suspend command.
>
Heh, that's strange, what did you change besides removing the hook?
What's your version of pm-utils and uswsusp?
--
Chow Loong Jin

On Mon, Nov 10, 2008 at 11:08 AM, hyperair <email address hidden> wrote:

> Heh, that's strange, what did you change besides removing the hook?
> What's your version of pm-utils and uswsusp?

I installed and then removed uswsusp, before removing the hook.

Don't have either of pm-utils or uswsusp installed.

Fwiw, I get this behaviour reproducibly:

 - reboot, then run pm_suspend -> backlight failure on resume
 - run pm_suspend with quirks -> correct resume
 - run pm_suspend without quirks again -> correct resume

-Pieter

On Mon, 2008-11-10 at 10:49 +0000, Pieter Hintjens wrote:
> On Mon, Nov 10, 2008 at 11:08 AM, hyperair <email address hidden> wrote:
>
> > Heh, that's strange, what did you change besides removing the hook?
> > What's your version of pm-utils and uswsusp?
>
> I installed and then removed uswsusp, before removing the hook.
>
> Don't have either of pm-utils or uswsusp installed.
>
> Fwiw, I get this behaviour reproducibly:
>
> - reboot, then run pm_suspend -> backlight failure on resume
> - run pm_suspend with quirks -> correct resume
> - run pm_suspend without quirks again -> correct resume
>
> -Pieter
>
You can't not have pm-utils. That's where pm-suspend is.

Anyway, regarding no quirks in lshal, this is an interesting
development. What this means is that the bug does not lie in pm-utils.
It lies in hal-info. However, for the moment, I'll leave the pm-utils
bug open, because it seems like the Samsung Q30 or something is affected
as well.

@japi: Could you post the output of lshal | grep quirk on both your
systems?

  affects ubuntu/hal-info
--
Chow Loong Jin

Oh I forgot to mention... everyone, please post the output of
lshal | grep system.hardware
--
Chow Loong Jin

japi@jypd:~$ lshal | grep quirk
  power_management.quirk.vbe_post = true (bool)
japi@jypd:~$ lshal | grep system.hardware
  system.hardware.primary_video.product = 13698 (0x3582) (int)
  system.hardware.primary_video.vendor = 32902 (0x8086) (int)
  system.hardware.product = 'SQ30' (string)
  system.hardware.serial = '123490EN400015' (string)
  system.hardware.uuid = '604EC084-E01D-B211-8000-AEF914A58E70' (string)
  system.hardware.vendor = 'Samsung Electronics' (string)
  system.hardware.version = 'Revision 01' (string)
japi@jypd:~$ sudo s2ram -i
This machine can be identified by:
    sys_vendor = "Samsung Electronics"
    sys_product = "SQ30"
    sys_version = "Revision 01"
    bios_version = "01LK"

I only have a Samsung Q30.

Have you noticed, that there are multiple versions of X40 Laptops?
Some of them need the s3-bios and s3-mode quirk, others need none of them.
(see in /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-ibm.fdi in the comments on:
- line 44
- line 64 (two times)
- line 105)
The s2ram whitelist also has multiple entries on the x40.
Probably this contributes to the bug.

On Mon, 2008-11-10 at 11:49 +0000, japi wrote:
> japi@jypd:~$ lshal | grep quirk
> power_management.quirk.vbe_post = true (bool)
> japi@jypd:~$ lshal | grep system.hardware
> system.hardware.primary_video.product = 13698 (0x3582) (int)
> system.hardware.primary_video.vendor = 32902 (0x8086) (int)
> system.hardware.product = 'SQ30' (string)
> system.hardware.serial = '123490EN400015' (string)
> system.hardware.uuid = '604EC084-E01D-B211-8000-AEF914A58E70' (string)
> system.hardware.vendor = 'Samsung Electronics' (string)
> system.hardware.version = 'Revision 01' (string)
> japi@jypd:~$ sudo s2ram -i
> This machine can be identified by:
> sys_vendor = "Samsung Electronics"
> sys_product = "SQ30"
> sys_version = "Revision 01"
> bios_version = "01LK"
>
> I only have a Samsung Q30.
>
> Have you noticed, that there are multiple versions of X40 Laptops?
> Some of them need the s3-bios and s3-mode quirk, others need none of them.
> (see in /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-ibm.fdi in the comments on:
> - line 44
> - line 64 (two times)
> - line 105)
> The s2ram whitelist also has multiple entries on the x40.
> Probably this contributes to the bug.
>
Multiple version of X40 Laptops? That explains it. Either way it looks
like a bug in both hal-info and pm-utils. hal-info doesn't pass
--quirk-s3-bios and --quirk-s3-mode for Pieter's machine, and pm-utils
removes --quirk-vbe-post on yours.
--
Chow Loong Jin

frank@gondolin:~$ lshal | grep system.hardware
  system.hardware.primary_video.product = 13698 (0x3582) (int)
  system.hardware.primary_video.vendor = 32902 (0x8086) (int)
  system.hardware.product = '2372GHG' (string)
  system.hardware.serial = '99DT135' (string)
  system.hardware.uuid = '403A7401-4766-11CB-953E-FB6BD513CD8B' (string)
  system.hardware.vendor = 'IBM' (string)
  system.hardware.version = 'ThinkPad X40' (string)

On Mon, Nov 10, 2008 at 12:14 PM, hyperair <email address hidden> wrote:

> You can't not have pm-utils. That's where pm-suspend is.

You're right, the package is installed, but I have no idea how to see
what version it is. pm-utils is not a command and "pm-suspend -v"
does a suspend... :-)

Here is the grep of system.hardware:

root@nb200802:/usr/lib/pm-utils/sleep.d# lshal | grep system.hardware
  system.hardware.primary_video.product = 13698 (0x3582) (int)
  system.hardware.primary_video.vendor = 32902 (0x8086) (int)
  system.hardware.product = '2372GHG' (string)
  system.hardware.serial = '99DT676' (string)
  system.hardware.uuid = '3C711681-4793-11CB-AC6D-FB1692D47557' (string)
  system.hardware.vendor = 'IBM' (string)
  system.hardware.version = 'ThinkPad X40' (string)
root@nb200802:/usr/lib/pm-utils/sleep.d#

-Pieter

What firmware version do you have?
( lshal | grep system.firmware.version )
If it's not 1UETD2WW,
I would suggest adding 2372 to the list of product prefixes on line 65 in the 20-video-quirk-pm-ibm.fdi.
(2371 is already in the list)

Thanks,
Jan

On Mon, 2008-11-10 at 14:21 +0000, Pieter Hintjens wrote:
>
> You're right, the package is installed, but I have no idea how to see
> what version it is. pm-utils is not a command and "pm-suspend -v"
> does a suspend... :-)
apt-cache policy pm-utils
--
Chow Loong Jin

On Mon, Nov 10, 2008 at 6:39 PM, hyperair <email address hidden> wrote:
> apt-cache policy pm-utils

ph@nb200802:~$ apt-cache policy pm-utils
pm-utils:
  Installed: 1.1.2.4-1ubuntu7
  Candidate: 1.1.2.4-1ubuntu7
  Version table:
 *** 1.1.2.4-1ubuntu7 0
        500 http://be.archive.ubuntu.com intrepid/main Packages
        100 /var/lib/dpkg/status

ph@nb200802:~$ lshal | egrep firmware
  system.firmware.release_date = '01/07/2005' (string)
  system.firmware.vendor = 'IBM' (string)
  system.firmware.version = '1UETA5WW (1.55 )' (string)

-Pieter

On Sun, 2008-11-09 at 23:18 +0000, japi wrote:
> Hm.. I don't get it...
> Why does 98smart-kernel-video remove these quirks which are "known to work"?
> (My laptop for example: it is listed in /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-samsung.fdi with the right quirk, vbe-post.
> The ibm x40 can be found in 20-video-quirk-pm-ibm.fdi...
> But regardless of that the quirks seem to be removed.)
> Am I mixing things up?

Because the i915 DRM driver in 2.6.27 should not require any quirks but
the s3 ones. You can edit the 98smart-kernel-video hook to have it not
remove --quirk-vbe-post for Intel graphics if that helps on your system.

> Thanks,
> Jan
>
--
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

On Sun, 2008-11-09 at 23:18 +0000, hyperair wrote:
> On Sun, 2008-11-09 at 22:52 +0000, Pieter Hintjens wrote:
> > Hyperair, could you summarize what I need to do on my thinkpad x40 in
> > order to test this fix?
> >
> Delete /usr/lib/pm-utils/sleep.d/98smart-kernel-video. It's not a "fix"
> but a temporary workaround.

Please don't remove the hook -- just edit it to not remove the quirks
specifically needed.

> Either way the problem now is to make this
> an official fix in the pm-utils package, while not causing regressions
> to those not affected by the bug. What's your GPU, by the way?
> --
> Chow Loong Jin
>
--
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

On Sun, 2008-11-09 at 12:02 +0000, japi wrote:
> I have no /var/run/video.rom and couldn't find a file with that name anywhere in the system.
> But why doesn't s2ram need that file?

That is only needed if you are using a g80 or later nVidia GPU. Intel
GPUS can be posted from the regualr BIOS normally.

> > One thing I'd like to mention is that you don't have to "force" Ubuntu
> > to use s2ram, it's a choice that's made
> > here: /etc/pm/config.d/00sleep_module. Uncomment the SUSPEND_MODULE line
> > and set it to "uswsusp".
>
> I have already tried that.
> First problem here is, that uswsusp has no s2ram in ubuntu anymore. So switching to uswsusp as suspend_module has no real effect.
>
> I bypassed this problem by installing the debian uswsusp with s2ram.
>
> But there is a second problem:
> The setting there seems to be ignored anyway, because still everything runs over "/usr/lib/hal/scripts/linux/hal-system-power-suspend-linux" in the end.
> And there is a nice comment stating: "# We only support pm-utils", which seems to be true.
> Changing the line
> "/usr/sbin/pm-suspend $QUIRKS"
> into
> "/usr/sbin/s2ram --force --vbe_post"
> works nicely for me.
>
--
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

On Mon, 2008-11-10 at 21:32 +0000, vlowther wrote:
> Please don't remove the hook -- just edit it to not remove the quirks
> specifically needed.
I'm a little worried that this will cause regressions on systems where
the --quirk-vbe-post is reported wrongly by HAL. Will that be an issue?

--
Chow Loong Jin

On Tue, 2008-11-11 at 01:51 +0000, hyperair wrote:
> On Mon, 2008-11-10 at 21:32 +0000, vlowther wrote:
> > Please don't remove the hook -- just edit it to not remove the quirks
> > specifically needed.
> I'm a little worried that this will cause regressions on systems where
> the --quirk-vbe-post is reported wrongly by HAL. Will that be an issue?

That is what I am saying -- instead of removing the entire hook, just
remove the --quirk-vbe-post lines in the smart_kernel_intel function of
the 98smart-kernel-video hook. That will cause the hook to not remove
the --quirk-vbe-post quirk if it is passed to pm-utils.

> --
> Chow Loong Jin
>
--
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

On Tue, 2008-11-11 at 13:46 +0000, vlowther wrote:
>
> That is what I am saying -- instead of removing the entire hook, just
> remove the --quirk-vbe-post lines in the smart_kernel_intel function
> of
> the 98smart-kernel-video hook. That will cause the hook to not remove
> the --quirk-vbe-post quirk if it is passed to pm-utils.
What if HAL wrongly reports that a system requires --quirk-vbe-post,
when it doesn't? According to vbetool's manpage, it can cause
"undefined" behaviour, whatever that means.

--
Chow Loong Jin

On Nov 11, 2008, at 8:04 AM, hyperair <email address hidden> wrote:

> On Tue, 2008-11-11 at 13:46 +0000, vlowther wrote:
>>
>> That is what I am saying -- instead of removing the entire hook, just
>> remove the --quirk-vbe-post lines in the smart_kernel_intel function
>> of
>> the 98smart-kernel-video hook. That will cause the hook to not
>> remove
>> the --quirk-vbe-post quirk if it is passed to pm-utils.
> What if HAL wrongly reports that a system requires --quirk-vbe-post,
> when it doesn't? According to vbetool's manpage, it can cause
> "undefined" behaviour, whatever that means.

We can fix hal easily enough in that case.

>
> --
> Chow Loong Jin
>
> --
> backlight failed after suspend to ram on IBM X40
> https://bugs.launchpad.net/bugs/292256
> You received this bug notification because you are a direct subscriber
> of the bug.

On Tue, 2008-11-11 at 20:58 +0000, vlowther wrote:
> On Nov 11, 2008, at 8:04 AM, hyperair <email address hidden> wrote:
>
> > On Tue, 2008-11-11 at 13:46 +0000, vlowther wrote:
> >>
> >> That is what I am saying -- instead of removing the entire hook, just
> >> remove the --quirk-vbe-post lines in the smart_kernel_intel function
> >> of
> >> the 98smart-kernel-video hook. That will cause the hook to not
> >> remove
> >> the --quirk-vbe-post quirk if it is passed to pm-utils.
> > What if HAL wrongly reports that a system requires --quirk-vbe-post,
> > when it doesn't? According to vbetool's manpage, it can cause
> > "undefined" behaviour, whatever that means.
>
> We can fix hal easily enough in that case.
>
> >
> > --
> > Chow Loong Jin
> >
> > --
> > backlight failed after suspend to ram on IBM X40
> > https://bugs.launchpad.net/bugs/292256
> > You received this bug notification because you are a direct subscriber
> > of the bug.
>
Alright, here's a debdiff.
--
Chow Loong Jin

Thanks, hyperair. Can you please create an upstream bug for this and discuss it there, too? If we deviate this logic from upstream permanently, then we have a high risk of making the hal-info database incompatible, too, so we must avoid that. Thanks!

Same problem here with an ASUS L1400 laptop. Video card is i830M.

 lshal | grep system.hardware
  system.hardware.primary_video.product = 13687 (0x3577) (int)
  system.hardware.primary_video.vendor = 32902 (0x8086) (int)
  system.hardware.product = 'L1400B series Notebook PC' (string)
  system.hardware.serial = '000000000' (string)
  system.hardware.uuid = '' (string)
  system.hardware.vendor = 'ASUSTeK Computer Inc.' (string)
  system.hardware.version = '0001' (string)

 lshal | grep system.firmware
  system.firmware.release_date = '10/15/2002' (string)
  system.firmware.vendor = 'Award Software, Inc.' (string)
  system.firmware.version = '0201' (string)

 lspci | grep VGA
  00:02.0 VGA compatible controller: Intel Corporation 82830 CGC [Chipset Graphics Controller] (rev 03)

 lshal | grep quirk
  (empty)

Removing the two "--quirk-vbe-post" lines helps, "lshal | grep quirk" is still empty.

I have just come across this on a Thinkpad x40 with a fresh install (yesterday) of Intrepid. Reading the posts above, I am using this work around to suspend and resume:

From gnome,
switch to a console ctrl-alt-f1

to suspend to RAM:
$ sudo pw-suspend

when it wakes up again with a dead back light, type:
$ sudo vbetool post

You can then flick back to the gnome console with a few presses of alt-right

Adding 2372 to the list, as Japi suggests, fixes the bug - for my hardware; and as this is the same 2372 as Pieter Hintjens reports, this might close the bug. (Note: it's still there in Jaunty)

$ lshal | grep system.hardware
  system.hardware.primary_video.product = 13698 (0x3582) (int)
  system.hardware.primary_video.vendor = 32902 (0x8086) (int)
  system.hardware.product = '2372GHG' (string)
  system.hardware.serial = 'L3DV054' (string)
  system.hardware.uuid = 'AACECC81-47C5-11CB-84D7-E673F0CF4971' (string)
  system.hardware.vendor = 'IBM' (string)
  system.hardware.version = 'ThinkPad X40' (string)

Thank you for confirming my solution.

I think the problem will be solved at the root now and soon no workarounds will be necessary anymore (afaik).
Please have a look at http://www.ubuntu.com/testing/jaunty/beta#Suspend/resume%20testing
The Kernel Team seems to be dealing with issues regarding suspend/resume now.

But personally i find it a little frustrating, that we already had worked out a solution (inclusive .debdiff provided by Chow Loong Jin - hyperair) and it did not find its way into ubuntu...

Let's hope it gets fixed this time :-)
(I will run the tests on my laptop in the next days)

On Sun, 2009-03-29 at 13:55 +0000, japi wrote:
> But personally i find it a little frustrating, that we already had
> worked out a solution (inclusive .debdiff provided by Chow Loong Jin
> -
> hyperair) and it did not find its way into ubuntu...
This is probably because the upstream bug did not get any attention at
all. See https://bugs.freedesktop.org/show_bug.cgi?id=18461
--
Chow Loong Jin

unfortunately this still exists in Jaunty...

@hyperair:
Okay...
Is there anything we can do to get this fixed sometime?
Should we all register at the freedesktop bugtracker and write that this is no hoax?
I spent some hours to get this bug fixed for me and you also wrote a debdiff file, so the 'final' bugfix is only a click away.
The bug is confirmed (at least here) and assigned (here and there) (to someone who already has attention btw!).
I really can't understand why this doesn't get fixed and can't think of anything more i could contribute to get this fixed...
(except to confirm the bug over at freedesktop, which seems unnecessary to me)
Please help :-(

On Fri, 2009-04-24 at 23:00 +0000, japi wrote:
> @hyperair:
> Okay...
> Is there anything we can do to get this fixed sometime?
> Should we all register at the freedesktop bugtracker and write that this is no hoax?
> I spent some hours to get this bug fixed for me and you also wrote a debdiff file, so the 'final' bugfix is only a click away.
> The bug is confirmed (at least here) and assigned (here and there) (to someone who already has attention btw!).
> I really can't understand why this doesn't get fixed and can't think of anything more i could contribute to get this fixed...
> (except to confirm the bug over at freedesktop, which seems unnecessary to me)
> Please help :-(
>
Now that Jaunty's out with a new kernel and GPU driver for Intel, why
don't you test with that and see if it works?
--
Regards,
Chow Loong Jin

Whoops forgot to read thep previous post. I'll see who I can poke.
--
Regards,
Chow Loong Jin

FWIW I'm on Jaunty / 9.04 on my X40 as well now. As stated above, the problem persists and the vbetool post solution still works.

cheers

Matthew

guys, edit the file of pm-utils
/usr/lib/pm-utils/defaults

maximi89@Maximiliano:/usr/share/emesene$ cat /usr/lib/pm-utils/defaults
##########################################################
# DO NOT EDIT THIS FILE! #
# #
# Add files in /etc/pm/config.d/ instead! #
##########################################################

# Default method to power down the system when hibernating.
# If commented out, the system will use the kernel default as a
# default value.
#
# Check /sys/power/disk for valid values. The default value
# will be surrounded by [square brackets].
HIBERNATE_MODE="shutdown"

# Whether we need to post the video card when resuming from
# hibernate. You should not normally need to set this.
# In the future pm-utils will get this setting from HAL.
#
# Valid values are "no" and "yes"
# HIBERNATE_RESUME_POST_VIDEO="no"

# The default sleep/wake system to use. Valid values are:
# kernel The built-in kernel suspend/resume support.
# Use this if nothing else is supported on your system.
# uswsusp If your system has support for the userspace
# suspend programs (s2ram/s2disk/s2both), then use this.
# tuxonice If your system has support for tuxonice, use this.
#
# The system defaults to "kernel" if this is commented out.
SLEEP_MODULE="uswsusp"

# These variables will be handled specially when we load files in
# /etc/pm/config.d.
# Multiple declarations of these environment variables will result in
# their contents being concatenated instead of being overwritten.

# If you need to unload any modules to suspend/resume, add them here.
SUSPEND_MODULES="nvidia ehci_hcd ohci_hcd uhci_hcd iwl3945"

# If you want to keep hooks from running, add their names here.
# HOOK_BLACKLIST=""

# If you want to unconditionally add parameters to the commandline,
# add them here.
# ADD_PARAMETERS=""

# If you want to ignore commandline parameters, add them here.
# DROP_PARAMETERS=""

# If you need to synchronize the system clock across a suspend/resume or
# hibernate/thaw cycle, set this variable.
# NEED_CLOCK_SYNC="true"

i get the same as you, the suspend mode hangs my computer, but editing this file i get working all again...

On Mon, 2009-05-18 at 21:25 +0000, maximi89 wrote:
> guys, edit the file of pm-utils
> /usr/lib/pm-utils/defaults
>
> maximi89@Maximiliano:/usr/share/emesene$ cat /usr/lib/pm-utils/defaults
> ##########################################################
> # DO NOT EDIT THIS FILE! #
> # #
> # Add files in /etc/pm/config.d/ instead! #
> ##########################################################
>
> # Default method to power down the system when hibernating.
> # If commented out, the system will use the kernel default as a
> # default value.
> #
> # Check /sys/power/disk for valid values. The default value
> # will be surrounded by [square brackets].
> HIBERNATE_MODE="shutdown"
>
> # Whether we need to post the video card when resuming from
> # hibernate. You should not normally need to set this.
> # In the future pm-utils will get this setting from HAL.
> #
> # Valid values are "no" and "yes"
> # HIBERNATE_RESUME_POST_VIDEO="no"
>
> # The default sleep/wake system to use. Valid values are:
> # kernel The built-in kernel suspend/resume support.
> # Use this if nothing else is supported on your system.
> # uswsusp If your system has support for the userspace
> # suspend programs (s2ram/s2disk/s2both), then use this.
> # tuxonice If your system has support for tuxonice, use this.
> #
> # The system defaults to "kernel" if this is commented out.
> SLEEP_MODULE="uswsusp"
>
> # These variables will be handled specially when we load files in
> # /etc/pm/config.d.
> # Multiple declarations of these environment variables will result in
> # their contents being concatenated instead of being overwritten.
>
> # If you need to unload any modules to suspend/resume, add them here.
> SUSPEND_MODULES="nvidia ehci_hcd ohci_hcd uhci_hcd iwl3945"
>
> # If you want to keep hooks from running, add their names here.
> # HOOK_BLACKLIST=""
>
> # If you want to unconditionally add parameters to the commandline,
> # add them here.
> # ADD_PARAMETERS=""
>
> # If you want to ignore commandline parameters, add them here.
> # DROP_PARAMETERS=""
>
> # If you need to synchronize the system clock across a suspend/resume or
> # hibernate/thaw cycle, set this variable.
> # NEED_CLOCK_SYNC="true"
>
>
> i get the same as you, the suspend mode hangs my computer, but editing this file i get working all again...
>
Did you read the header of the file? It said "DO NOT EDIT THIS FILE! Add
files in /etc/pm/config.d/ instead", which is what you should have done.
The reason for this is that if you modify the variables h...

Thanks! Chow,
how looks your configuration?...

you think this file need come with a default settings for works?
in my case with the default settings doesn't works...
i going to make more test, but i don't undersdtand really how i can use the
/etc/pm/config.d
refer: http://en.opensuse.org/Pm-utils

in this case creating a file called "modules" or "config" inside
/etc/pm/config.d this would work?...
i think the default set for this file need to be with the next modules

SUSPEND_MODULES="button ehci_hcd ohci_hcd uhci_hcd iwl3945"
HIBERNATE_MODE="shutdown"

Because the default configuration it's platform, and that does not works...
about the modules, if you suspend without this parameters suspend
don't works too... still poweron and freeze...
What do you think about?
all here... what think about this? who have problems or need make this
change when installd the system?

2009/5/19 Chow Loong Jin <email address hidden>

> On Mon, 2009-05-18 at 21:25 +0000, maximi89 wrote:
> > guys, edit the file of pm-utils
> > /usr/lib/pm-utils/defaults
> >
> > maximi89@Maximiliano:/usr/share/emesene$ cat /usr/lib/pm-utils/defaults
> > ##########################################################
> > # DO NOT EDIT THIS FILE! #
> > # #
> > # Add files in /etc/pm/config.d/ instead! #
> > ##########################################################
> >
> > # Default method to power down the system when hibernating.
> > # If commented out, the system will use the kernel default as a
> > # default value.
> > #
> > # Check /sys/power/disk for valid values. The default value
> > # will be surrounded by [square brackets].
> > HIBERNATE_MODE="shutdown"
> >
> > # Whether we need to post the video card when resuming from
> > # hibernate. You should not normally need to set this.
> > # In the future pm-utils will get this setting from HAL.
> > #
> > # Valid values are "no" and "yes"
> > # HIBERNATE_RESUME_POST_VIDEO="no"
> >
> > # The default sleep/wake system to use. Valid values are:
> > # kernel The built-in kernel suspend/resume support.
> > # Use this if nothing else is supported on your system.
> > # uswsusp If your system has support for the userspace
> > # suspend programs (s2ram/s2disk/s2both), then use this.
> > # tuxonice If your system has support for tuxonice, use this.
> > #
> > # The system defaults to "kernel" if this is commented out.
> > SLEEP_MODULE="uswsusp"
> >
> > # These variables will be handled specially when we load files in
> > # /etc/pm/config.d.
> > # Multiple declarations of these environment variables will result in
> > # their contents being concatenated instead of being overwritten.
> >
> > # If you need to unload any modules to suspend/resume, add them here.
> > SUSPEND_MODULES="nvidia ehci_hcd ohci_hcd uhci_hcd iwl3945"
> >
> > # If you want to keep hooks from running, add their names here.
> > # HOOK_BLACKLIST=""
> >
> > # If you want to unconditionally add parameters to the commandline,
> > # add them here.
> > # ADD_PARAMETERS=""
> >
> > # If you want to ignore commandline parameters, add them here.
> > ...

On Wed, 2009-05-20 at 01:30 +0000, maximi89 wrote:
> Thanks! Chow,
> how looks your configuration?...
My configuration is the default. I did not change it.
> you think this file need come with a default settings for works?
> in my case with the default settings doesn't works...
> i going to make more test, but i don't undersdtand really how i can use the
> /etc/pm/config.d
> refer: http://en.opensuse.org/Pm-utils
Any file in /etc/pm/config.d will be evaluated for configuration
variables, which are listed in /usr/lib/pm-utils/defaults.
>
> in this case creating a file called "modules" or "config" inside
> /etc/pm/config.d this would work?...
> i think the default set for this file need to be with the next modules
>
> SUSPEND_MODULES="button ehci_hcd ohci_hcd uhci_hcd iwl3945"
> HIBERNATE_MODE="shutdown"
Yes, just dump these lins inside a file in /etc/pm/config.d. Any name can be used for the file.
> Because the default configuration it's platform, and that does not works...
> about the modules, if you suspend without this parameters suspend
> don't works too... still poweron and freeze...
> What do you think about?
> all here... what think about this? who have problems or need make this
> change when installd the system?
platform is the default because it mean that system-specific
optimizations can be done. If disk works for you then use disk, but
platform will remain the default, because that's what works for most
people.
--
Regards,
Chow Loong Jin

2009/5/20 Chow Loong Jin <email address hidden>

> On Wed, 2009-05-20 at 01:30 +0000, maximi89 wrote:
> > Thanks! Chow,
> > how looks your configuration?...
> My configuration is the default. I did not change it.
> > you think this file need come with a default settings for works?
> > in my case with the default settings doesn't works...
> > i going to make more test, but i don't undersdtand really how i can use
> the
> > /etc/pm/config.d
> > refer: http://en.opensuse.org/Pm-utils
> Any file in /etc/pm/config.d will be evaluated for configuration
> variables, which are listed in /usr/lib/pm-utils/defaults.

why edit another file? because the defaults config of that file will be
overwrite with the default settings that does´t works... i think we need to
ask to the people what configuration works in all cases.

>
> >
> > in this case creating a file called "modules" or "config" inside
> > /etc/pm/config.d this would work?...
> > i think the default set for this file need to be with the next modules
> >
> > SUSPEND_MODULES="button ehci_hcd ohci_hcd uhci_hcd iwl3945"
> > HIBERNATE_MODE="shutdown"
> Yes, just dump these lins inside a file in /etc/pm/config.d. Any name can
> be used for the file.

Sorry, but i hear a lot of people with the same problem, because platform
does not work, for me works hibernate only with pm-utils, but when i install
uswsusp this come with platform, and that don´t works for alot of people,
susend to disk don´t work in all...this need some parameters, most people
don´t use hibernate, so they don´t report this problems, i think pm-utils
need come with the modules be default.

>
> > Because the default configuration it's platform, and that does not
> works...
> > about the modules, if you suspend without this parameters suspend
> > don't works too... still poweron and freeze...
> > What do you think about?
> > all here... what think about this? who have problems or need make this
> > change when installd the system?
> platform is the default because it mean that system-specific
> optimizations can be done. If disk works for you then use disk, but
> platform will remain the default, because that's what works for most
> people.
> --
> Regards,
> Chow Loong Jin
>
> --
> backlight failed after suspend to ram on IBM X40
> https://bugs.launchpad.net/bugs/292256
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Thanks!

--
Maximiliano Augusto Castañón Araneda
Santiago, Chile
Linux user # 394821

Hmm. Karmic Koala still has the bug and worse: pm-suspend --quirk-s3-mode --quirk-s3-bios does not help anymore (so adding the configuration to -----pm-ibm.fdi is not a solution anymore). This is just a preliminary notice, will see if I can find something that does work.

hope there will be a solution until karmic is coming...

Valentijn Sessink, do you use a laptop?
what say:
gnome-power-manager --verbose

can you see anything strange about the backlight?

Shall I post my output of this as well?

By the way, here is a workaround for karmic: https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/417599

Yes, I'm running a laptop; no, there's nothing strange about the backlight in gnome-power-manager --verbose.

KMS is involved: a better workaround for me is to use i915.modeset=0 as kernel option - no KMS, means quirks enabled, means backlight working (with Japi's fix, that is; the 2372 type should still be included in the 20-video-quirk-pm-ibm.fdi file).

Here is the kernel bug, with a patch that is supposed to fix it:
http://bugzilla.kernel.org/show_bug.cgi?id=10985
I did not check the patch, maybe someone could?

All right. I had the time to test the patchhttp://bugzilla.kernel.org/attachment.cgi?id=23409 (mentioned in my previous post). This fixes the problem.

Patch available in upstream bug.

Accepted linux into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I tested the kernel from proposed and yes, this works as it should: backlight is enabled automatically. Good work!

Just wanted to confirm that the new kernel also solves the bug for the samsung q30 series. :-)
Thank you very much!

unassigned canonical kernel team per policy.

Marking Fix Released per comment #72 and #73

-JFo

In 2.6.31-19-generic (Ubuntu Karmic Koala, 9.10), the problem seems to be back. Could anyone confirm this?

Never mind, 2.6.31-20-generic is OK again.

Jeremy, the kernel that fixes this issue for karmic is still waiting in karmic-proposed queue; once other fixes also included in that version are verified not to introduce regressions, then it will get released to karmic-updates (and launchpad should auto-close that task of this bugreport at that time). Until then, it should remain fix-committed for karmic. Thanks!

This bug was fixed in the package linux - 2.6.31-20.57

---------------
linux (2.6.31-20.57) karmic-proposed; urgency=low

  [ Kees Cook ]

  * SAUCE: x86: brk away from exec rand area
    - LP: #452175

  [ Keng-Yu Lin ]

  * SAUCE: (drop after 2.6.31) input: Add hotkey quirk for Samsung
    Q210/P210 laptops
    - LP: #385683

  [ Pascal Bach ]

  * SAUCE: (drop after 2.6.31) input: Add hotkey quirk for Fujitsu Amilo
    1848+u
    - LP: #458503

  [ Stefan Bader ]

  * Revert "[Upstream] (drop after 2.6.31) acerhdf: fix fan control for
    AOA150 model"
    - LP: #494633
  * [Config] Disable CONFIG_USB_DEVICEFS
    - LP: #488274

  [ Upstream Kernel Changes ]

  * Revert "ext4: Don't update superblock write time when filesystem is
    read-only"
    - LP: #496816
  * Revert "ide: try to use PIO Mode 0 during probe if possible"
    - LP: #503430
  * Revert "isdn: isdn_ppp: Use SKB list facilities instead of home-grown
    implementation."
    - LP: #503430
  * nilfs2: fix kernel oops in error case of nilfs_ioctl_move_blocks
    - LP: #494633
  * cifs: don't use CIFSGetSrvInodeNumber in is_path_accessible
    - LP: #494633
  * cifs: clean up handling when server doesn't consistently support inode
    numbers
    - LP: #494633
  * cifs: clear server inode number flag while autodisabling
    - LP: #494633
  * CIFS: fix oops in cifs_lookup during net boot
    - LP: #494633
  * CIFS: Duplicate data on appending to some Samba servers
    - LP: #494633
  * rtl8187: Fix kernel oops when device is removed when LEDS enabled
    - LP: #494633
  * md: don't clear endpoint for resync when resync is interrupted.
    - LP: #494633
  * md/raid5: make sure curr_sync_completes is uptodate when reshape starts
    - LP: #494633
  * md/raid1/raid10: add a cond_resched
    - LP: #494633
  * ALSA: usb-audio: fix combine_word problem
    - LP: #494633
  * ALSA: hda - Dell Studio 1557 hd-audio quirk
    - LP: #494633
  * ALSA: AACI: fix AC97 multiple-open bug
    - LP: #494633
  * ALSA: AACI: fix recording bug
    - LP: #494633
  * jffs2: Fix memory corruption in jffs2_read_inode_range()
    - LP: #494633
  * sound: rawmidi: disable active-sensing-on-close by default
    - LP: #494633
  * sound: rawmidi: fix checking of O_APPEND when opening MIDI device
    - LP: #494633
  * sound: rawmidi: fix double init when opening MIDI device with O_APPEND
    - LP: #494633
  * sound: rawmidi: fix MIDI device O_APPEND error handling
    - LP: #494633
  * highmem: Fix race in debug_kmap_atomic() which could cause warn_count
    to underflow
    - LP: #494633
  * highmem: Fix debug_kmap_atomic() to also handle KM_IRQ_PTE, KM_NMI, and
    KM_NMI_PTE
    - LP: #494633
  * powerpc: Fix DEBUG_HIGHMEM build break from d4515646699
    - LP: #494633
  * kmap: fix build errors with DEBUG_HIGHMEM enabled
    - LP: #494633
  * V4L/DVB (13169): bttv: Fix potential out-of-order field processing
    - LP: #494633
  * V4L/DVB (13170): bttv: Fix reversed polarity error when switching video
    standard
    - LP: #494633
  * V4L/DVB (13109): tda18271: fix signedness issue in
    tda18271_rf_tracking_filters_init
    - LP: #494633
  * V4L/DVB (13107): tda18271: fix overflow in FM radio frequency...