I'm using swsusp on my new HP dv1000 notebook. In general most everything
works just fine, in terms of general computing anyways, after resume.
However, some of the ancilary functions, such as LCD brightness, RF kill
switch, and volume mute button do not work after resuming.
Figuring that some hardware parameters were not being restored, I verified
that by forcing a cold boot (boot up to GRUB, issue the 'halt' command to
power off, then power on again and let the kernel resume from swsusp),
everything works perfectly again just as it should because the BIOS takes
care of the initialisation then, which it normally skips after a soft-off/S4.
Asside from trying to figure out exactly what hardware parameteres are not
being saved/restored, I'm happy to let the BIOS initialise those things.
But, I need a way to perform a normal power-off/S5 after swsusp instead of a
soft-off/S4 so that I don't have to go though the double-grub-boot process
every time. Can this be done?
Regards,
Ian Morgan
--
-------------------------------------------------------------------
Ian E. Morgan Vice President & C.O.O. Webcon, Inc.
imorgan at webcon dot ca PGP: #2DA40D07 http://www.webcon.ca
* Customized Linux Network Solutions for your Business *
-------------------------------------------------------------------
[now cc-ed l-k, sorry for duplicate]
Hi!
> works just fine, in terms of general computing anyways, after resume.
>
> However, some of the ancilary functions, such as LCD brightness, RF kill
> switch, and volume mute button do not work after resuming.
>
> Figuring that some hardware parameters were not being restored, I verified
> that by forcing a cold boot (boot up to GRUB, issue the 'halt' command to
> power off, then power on again and let the kernel resume from swsusp),
> everything works perfectly again just as it should because the BIOS takes
> care of the initialisation then, which it normally skips after a
> soft-off/S4.
>
> Asside from trying to figure out exactly what hardware parameteres are not
> being saved/restored, I'm happy to let the BIOS initialise those things.
> But, I need a way to perform a normal power-off/S5 after swsusp instead of a
> soft-off/S4 so that I don't have to go though the double-grub-boot process
> every time. Can this be done?
echo shutdown > /sys/power/disk should do that. If it does
not... well, see what is different in those two codepaths...
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
On Mon, 2 May 2005, Pavel Machek wrote:
>> works just fine, in terms of general computing anyways, after resume.
>>
>> However, some of the ancilary functions, such as LCD brightness, RF kill
>> switch, and volume mute button do not work after resuming.
>>
>> Figuring that some hardware parameters were not being restored, I verified
>> that by forcing a cold boot (boot up to GRUB, issue the 'halt' command to
>> power off, then power on again and let the kernel resume from swsusp),
>> everything works perfectly again just as it should because the BIOS takes
>> care of the initialisation then, which it normally skips after a
>> soft-off/S4.
>>
>> Asside from trying to figure out exactly what hardware parameteres are not
>> being saved/restored, I'm happy to let the BIOS initialise those things.
>> But, I need a way to perform a normal power-off/S5 after swsusp instead of a
>> soft-off/S4 so that I don't have to go though the double-grub-boot process
>> every time. Can this be done?
>
> echo shutdown > /sys/power/disk should do that. If it does
> not... well, see what is different in those two codepaths...
I found out that 'shutdown' is the default and that I was already using
that. Strange.
I did finally now get around to doing a more through battery of tests with
many combinations of hibernating with 'platform' and 'shutdown' modes, and
various GRUB 'halt' and 'reboot' commands. What I came up with is that
basically nothing works.
In essentially all cases (except for rare inexplicable instances when it
_does_ work, though I cannot replicate it with any consistency) the special
keys _are_ functional immediately after power-on, through GRUB, through
kernel initialization, through reading the suspended image. But then
immediately after control is passed to the resumed system, the keys stop
working.
Does this give you any other clues as to what might be going on?
Regards,
Ian Morgan
--
-------------------------------------------------------------------
Ian E. Morgan Vice President & C.O.O. Webcon, Inc.
imorgan at webcon dot ca PGP: #2DA40D07 http://www.webcon.ca
* Customized Linux Network Solutions for your Business *
-------------------------------------------------------------------
Hi!
> >>Asside from trying to figure out exactly what hardware parameteres are not
> >>being saved/restored, I'm happy to let the BIOS initialise those things.
> >>But, I need a way to perform a normal power-off/S5 after swsusp instead
> >>of a
> >>soft-off/S4 so that I don't have to go though the double-grub-boot process
> >>every time. Can this be done?
> >
> >echo shutdown > /sys/power/disk should do that. If it does
> >not... well, see what is different in those two codepaths...
>
> I found out that 'shutdown' is the default and that I was already using
> that. Strange.
>
> I did finally now get around to doing a more through battery of tests with
> many combinations of hibernating with 'platform' and 'shutdown' modes, and
> various GRUB 'halt' and 'reboot' commands. What I came up with is that
> basically nothing works.
>
> In essentially all cases (except for rare inexplicable instances when it
> _does_ work, though I cannot replicate it with any consistency) the special
> keys _are_ functional immediately after power-on, through GRUB, through
> kernel initialization, through reading the suspended image. But then
> immediately after control is passed to the resumed system, the keys stop
> working.
>
> Does this give you any other clues as to what might be going on?
No idea :-(. Something bad in ACPI land.
If there are some effects that survive reboot or powerdown, complain
to your system vendor about crappy hardware. We should fix Linux, too,
but that will be hard to do remotely.
Just go through swsusp and normal code paths, and see whats
different...
Pavel
On 05/02/05 05:13:15PM -0400, Ian E. Morgan wrote:
> I'm using swsusp on my new HP dv1000 notebook. In general most everything
> works just fine, in terms of general computing anyways, after resume.
>
> However, some of the ancilary functions, such as LCD brightness, RF kill
> switch, and volume mute button do not work after resuming.
I had a similar issue in that the power button wouldn't issue any acpi
events after resuming. This was annoying because I could hit the power key
to suspend only once. The solution was to simply remove the acpi button
module before suspend and reload it after resume, if you can figure out
which modules drive the functions that aren't working for you the same
might be possible.
Note that I was using swsusp2 and not the in-kernel swsusp, but I doubt
that would make a difference.
>
> Regards,
> Ian Morgan
Jim.
On Mon, 30 May 2005, Jim Crilly wrote:
> On 05/02/05 05:13:15PM -0400, Ian E. Morgan wrote:
>> However, some of the ancilary functions, such as LCD brightness, RF kill
>> switch, and volume mute button do not work after resuming.
>
> I had a similar issue in that the power button wouldn't issue any acpi
> events after resuming. The solution was to simply remove the acpi button
> module before suspend and reload it after resume. If you can figure out
> which modules drive the functions that aren't working for you the same
> might be possible.
Unfortunately the LCD/Wifi buttons seem to be managed directly by the
hardware/BIOS. They do not generate input or ACPI events. I have no problem
with the power button or lid generating acpi events.
My best idea at one point was to figure out some way to reset the keyboard
driver, but I don't know how. In theory I could modularize the whole
serio/keyboard system etc, but then I would have no way to unload/reload the
necessary modules without some other form of input, like over a network
connection. I might try that anyways just as an exercise in futility.
> Note that I was using swsusp2 and not the in-kernel swsusp, but I doubt
> that would make a difference.
I tried suspend2 on a lark, but could not get it to work.. always complained
about not being able to allocate enough pages for the image.. which was
clearly bull.. but who knows. Google didn't turn up much.
Thanks for your input, Jim.
Regards,
Ian Morgan
--
-------------------------------------------------------------------
Ian E. Morgan Vice President & C.O.O. Webcon, Inc.
imorgan at webcon dot ca PGP: #2DA40D07 http://www.webcon.ca
* Customized Linux Network Solutions for your Business *
-------------------------------------------------------------------
On 05/31/05 10:35:56AM -0400, Ian E. Morgan wrote:
> On Mon, 30 May 2005, Jim Crilly wrote:
>
> >On 05/02/05 05:13:15PM -0400, Ian E. Morgan wrote:
> >>However, some of the ancilary functions, such as LCD brightness, RF kill
> >>switch, and volume mute button do not work after resuming.
> >
> >I had a similar issue in that the power button wouldn't issue any acpi
> >events after resuming. The solution was to simply remove the acpi button
> >module before suspend and reload it after resume. If you can figure out
> >which modules drive the functions that aren't working for you the same
> >might be possible.
>
> Unfortunately the LCD/Wifi buttons seem to be managed directly by the
> hardware/BIOS. They do not generate input or ACPI events. I have no problem
> with the power button or lid generating acpi events.
>
> My best idea at one point was to figure out some way to reset the keyboard
> driver, but I don't know how. In theory I could modularize the whole
> serio/keyboard system etc, but then I would have no way to unload/reload the
> necessary modules without some other form of input, like over a network
> connection. I might try that anyways just as an exercise in futility.
Well if you use the swsusp2 hibernate script, you can have it unload,
reload modules or just run whatever scripts you want if you need to do
something more. The hibernate script was written for swsusp2 but you can
configure it to use swsusp instead really easily.
>
> >Note that I was using swsusp2 and not the in-kernel swsusp, but I doubt
> >that would make a difference.
>
> I tried suspend2 on a lark, but could not get it to work.. always complained
> about not being able to allocate enough pages for the image.. which was
> clearly bull.. but who knows. Google didn't turn up much.
If you're using reiserfs for your rootfs that's probably the problem, AFAIK
that's being worked on but I haven't paid much attention to the issue since
i don't use reiserfs and the only swsusp2 problem I've had were nVidia
related.
>
> Thanks for your input, Jim.
>
> Regards,
> Ian Morgan
Jim.