SuSE-9.2: DELL C840 ACPI Suspend-to-RAM and backlight problems
Hi! With SuSE-9.2 I have some trouble with resuming my DELL-C840 from suspend-to-RAM within ACPI. The problem is that the display backlight does not switch on after resume. I can login from remote and shutdown and reboot the system. Everything else seems to work after resume. Suspend-to-disk works, but is really slowly. Does anybody know how to switch on the backlight? Best regards, Michael -- michael@karbach.org www.karbach.org
Guten Morgen, On Fri, Nov 05, 2004 at 07:42:06PM +0100, Michael Karbach wrote:
Hi!
With SuSE-9.2 I have some trouble with resuming my DELL-C840 from suspend-to-RAM within ACPI. The problem is that the display backlight does not switch on after resume. I can login from remote and shutdown and reboot the system. Everything else seems to work after resume.
lucky you... :-) Suspend to RAM with ACPI actually works only with very few machines.
Suspend-to-disk works, but is really slowly.
later...
Does anybody know how to switch on the backlight?
no, not generic. If you find out how to do it, please tell it the guys on the acpi-devel mailinglist :-) There are some hardware-specific hacks floating around, they all include patching the kernel and some other of them need some userspace tools to reactivate the graphics card. Search the acpi-devel archives, there are many threads about these problems. There is also documentation about things to try in /usr/src/linux/Documentation/power/video.txt (needs kernel-source package installed). But why is suspend to disk so slow for you? There are some things you can do to speed it up: - remove the useless screenlock at suspend: remove "screen_saver" from POWERSAVE_EVENT_GLOBAL_SUSPEND2DISK in /etc/sysconfig/powersave/events - unload less module before suspend. The USB and firewire modules are only unloaded to prevent users from doing stupid things and complaining about it later (if you do not unload them, you should of course not do stupid things like suspending with an external USB/firewire drive attached). So just remove 'usb_storage sbp2 ohci_hcd uhci_hcd ehci_hcd ohci1394' from POWERSAVE_UNLOAD_MODULES_BEFORE_SUSPEND2DISK in /etc/sysconfig/powersave/sleep. With those two changes, i get reasonably fast suspend to disk (less than half a minute from "powersave -U" until poweroff and ~40 seconds from pressing enter at the GRUB prompt until i can work again). -- Stefan Seyfried
Hi Stefan, thank you for the information! On Monday, 8. November 2004 11:27, Stefan Seyfried wrote:
Guten Morgen,
On Fri, Nov 05, 2004 at 07:42:06PM +0100, Michael Karbach wrote:
Hi!
With SuSE-9.2 I have some trouble with resuming my DELL-C840 from suspend-to-RAM within ACPI. The problem is that the display backlight does not switch on after resume. I can login from remote and shutdown and reboot the system. Everything else seems to work after resume.
lucky you... :-)
Not really ;-)
Does anybody know how to switch on the backlight?
no, not generic. If you find out how to do it, please tell it the guys on the acpi-devel mailinglist :-) There are some hardware-specific hacks floating around, they all include patching the kernel and some other of them need some userspace tools to reactivate the graphics card. Search the acpi-devel archives, there are many threads about these problems. There is also documentation about things to try in /usr/src/linux/Documentation/power/video.txt (needs kernel-source package installed).
OK, I will check the documentation.
But why is suspend to disk so slow for you?
Yes, in my point of view with a formerly working APM-suspend-resume, it is really slow. Now with SuSE-9.2-2.6.8 compared to 9.1-2.6.5 it is much better. For suspending roughly: 1:30min and for resuming (with a real working machine;-) 2:00min. But in some occasions it needs up to 3-5min for suspending. In this cases the last step (with the measuring percentage number) is the worst one. May be this is related to 768MB RAM? I have altogether 3GB SWAP, may be this is too much? I have tried before 1GB and also 2GB, but I have not yet done comparisons between different scenarios.
There are some things you can do to speed it up: - remove the useless screenlock at suspend: remove "screen_saver" from POWERSAVE_EVENT_GLOBAL_SUSPEND2DISK in /etc/sysconfig/powersave/events
This I have done before and was included in my statement about suspend/resume-speed.
- unload less module before suspend. The USB and firewire modules are only unloaded to prevent users from doing stupid things and complaining about it later (if you do not unload them, you should of course not do stupid things like suspending with an external USB/firewire drive attached). So just remove 'usb_storage sbp2 ohci_hcd uhci_hcd ehci_hcd ohci1394' from POWERSAVE_UNLOAD_MODULES_BEFORE_SUSPEND2DISK in /etc/sysconfig/powersave/sleep.
OK, I will try this.
With those two changes, i get reasonably fast suspend to disk (less than half a minute from "powersave -U" until poweroff and ~40 seconds from pressing enter at the GRUB prompt until i can work again).
This will be more than twice as fast as my enviroment. I will inform you. Thanks, Michael -- michael@karbach.org www.karbach.org
On Mon, Nov 08, 2004 at 06:39:43PM +0100, Michael Karbach wrote:
Hi Stefan,
thank you for the information!
But why is suspend to disk so slow for you?
Yes, in my point of view with a formerly working APM-suspend-resume, it is really slow. Now with SuSE-9.2-2.6.8 compared to 9.1-2.6.5 it is much better.
well, APM must have been suspend to RAM since APM suspend-to-disk is _really_ slow, it just saves the total amount of RAM without any "intelligence" on what may be discarded etc.
For suspending roughly: 1:30min and for resuming (with a real working machine;-) 2:00min. But in some occasions it needs up to 3-5min for suspending. In this cases the last step (with the measuring percentage number) is the worst one.
Yes, this is a bug. I have seen this, too. Unfortunately, i never had a serial console ready to debug this. Usually it should write the pages to swap with full harddisk-speed but sometimes it doesn't. It works fine for me ~98% of all cases but sometimes it is slow writing to disk. The worst i have seen was ~25 _minutes_ of writing to swap. But it happens very infrequently and is though hard to debug :-(
May be this is related to 768MB RAM? I have altogether 3GB SWAP, may be this is too much? I have tried before 1GB and also 2GB, but I have not yet done comparisons between different scenarios.
no, this _should_ not matter. I have used suspend2disk on 512MB and 1G machines and it worked on all of them. I have 512MB RAM and 1G swap right now. You should have only one swap partition though, with more than one you are very lucky if it works at all! (it sounds like you have two swap partitions with 1G and 2G).
So just remove 'usb_storage sbp2 ohci_hcd uhci_hcd ehci_hcd ohci1394' from POWERSAVE_UNLOAD_MODULES_BEFORE_SUSPEND2DISK in /etc/sysconfig/powersave/sleep.
OK, I will try this.
This will not help the "slow writing to disk"-bug, it will speed up "pre-suspend" and "post-resume" but the in-kernel part will stay the same. Damn, if i only could reproduce this kerenl bug reliably... -- Stefan Seyfried
On Monday, 8. November 2004 20:21, Stefan Seyfried wrote:
On Mon, Nov 08, 2004 at 06:39:43PM +0100, Michael Karbach wrote:
Hi Stefan,
thank you for the information!
But why is suspend to disk so slow for you?
Yes, in my point of view with a formerly working APM-suspend-resume, it is really slow. Now with SuSE-9.2-2.6.8 compared to 9.1-2.6.5 it is much better.
well, APM must have been suspend to RAM since APM suspend-to-disk is _really_ slow, it just saves the total amount of RAM without any "intelligence" on what may be discarded etc.
Yes it was suspend to RAM, unfortunately the fallback (acpi=off apm=on) in 2.6 is actually not the same as it was with kernel 2.4, because with 2.4 APM-suspend-to-RAM has worked in my case perfectly, but the fallback does not work at all;-)
For suspending roughly: 1:30min and for resuming (with a real working machine;-) 2:00min. But in some occasions it needs up to 3-5min for suspending. In this cases the last step (with the measuring percentage number) is the worst one.
Yes, this is a bug. I have seen this, too. Unfortunately, i never had a serial console ready to debug this. Usually it should write the pages to swap with full harddisk-speed but sometimes it doesn't. It works fine for me ~98% of all cases but sometimes it is slow writing to disk. The worst i have seen was ~25 _minutes_ of writing to swap. But it happens very infrequently and is though hard to debug :-(
Yes in one case I have observed 15minutes too. Usually in any case I avoid to reboot my system and try resolve all problems without a boot, so my statistics is not very convincing, but as far as I remember it has happend nearly in every instance after the first resume/suspend cycle (out of 4 or 5 since I have SuSE-9.2).
May be this is related to 768MB RAM? I have altogether 3GB SWAP, may be this is too much? I have tried before 1GB and also 2GB, but I have not yet done comparisons between different scenarios.
no, this _should_ not matter. I have used suspend2disk on 512MB and 1G machines and it worked on all of them. I have 512MB RAM and 1G swap right now. You should have only one swap partition though, with more than one you are very lucky if it works at all! (it sounds like you have two swap partitions with 1G and 2G).
Right, and it works. But nice to hear, so I will remove one.
So just remove 'usb_storage sbp2 ohci_hcd uhci_hcd ehci_hcd ohci1394' from POWERSAVE_UNLOAD_MODULES_BEFORE_SUSPEND2DISK in /etc/sysconfig/powersave/sleep.
OK, I will try this.
This will not help the "slow writing to disk"-bug, it will speed up "pre-suspend" and "post-resume" but the in-kernel part will stay the same.
OK, may be for the normal suspend, which I try right after this Email! Michael www.karbach.org
On Mon, Nov 08, 2004 at 09:13:07PM +0100, Michael Karbach wrote:
no, this _should_ not matter. I have used suspend2disk on 512MB and 1G machines and it worked on all of them. I have 512MB RAM and 1G swap right now. You should have only one swap partition though, with more than one you are very lucky if it works at all! (it sounds like you have two swap partitions with 1G and 2G).
Right, and it works. But nice to hear, so I will remove one.
You had a lot of luck, then. Watch out for the "resume=..." parameter in your bootloader config (usually /boot/grub/menu.lst), it has to match your swap partition or resuming will fail. -- Stefan Seyfried
On Tuesday, 9. November 2004 12:31, Stefan Seyfried wrote:
On Mon, Nov 08, 2004 at 09:13:07PM +0100, Michael Karbach wrote:
no, this _should_ not matter. I have used suspend2disk on 512MB and 1G machines and it worked on all of them. I have 512MB RAM and 1G swap right now. You should have only one swap partition though, with more than one you are very lucky if it works at all! (it sounds like you have two swap partitions with 1G and 2G).
Right, and it works. But nice to hear, so I will remove one.
You had a lot of luck, then. Watch out for the "resume=..." parameter in your bootloader config (usually /boot/grub/menu.lst), it has to match your swap partition or resuming will fail.
I have done this before and both swap-devices match each other. For the resume/suspend cycles, now I am down to 1:10min and 1:30min for resume and suspend, respectively. Now I have to resolve the next problem concerning suspend alsasound (see my next posting;-) Thanks, Michael -- michael@karbach.org www.karbach.org
participants (2)
-
Michael Karbach -
Stefan Seyfried