Problem Suspending on Debian Etch (Solved)

[jantzen]

Hi Tim, thanks for getting back to back me to quickly.  I've been
inspecting the hal-system-power-suspend script.  And I see that
Etch actually installs both uswsusp (with s2both/s2disk/s2ram) and
hibernate and it's scriptlets in the laptop profile.
hal-system-power-suspend first finds and tries s2both, which fails on
pre 2.6.17 kernels because, as I dimly understand it, it links into
tools built directly into the new kernel for suspend/hibernate
behavior.  

So, the short answer is that it's borken because Debian testing supplies
uswsusp and the 2.6.16 kernel (or did three weeks ago when I installed).
Hibernate never gets called then, nor do the fallback mechanisms in the
script.  But, it's just as well because hibernate blows up: on my new
Asus I get a "9836 Segmentation fault" out of the VBETool scriptlet, and
on my venerable Inspiron 7000 I get "write error: Operation not
permitted".

Would it be possible for future versions of hal-system-power-suspend to
check $? after each call to a power management system to see if the one
that it found actually succeeded, and in the case of failure to continue
looking for ways to suspend?  That would enable systems like mine to
bonk on uswsusp and hibernate and hit the failsafe option.

In any case suspend at least works on my new primary work machine now.
That's definitely a good thing.  The last wrinkle is that it doesn't
play nice with my Intel 3945 wifi driver, and locks the machine during
suspend, so I have to unload the module first.  I'd really like to be
able to automatically unload/load the module when suspending as with the
hibernate package's scriptlets, but I don't see a facility in uswsusp to
do that. I could put a hack in the hal-system-power-suspend script, but
I'd really rather not.

Do you know if the future of Linux power management is uswsusp?  If so,
I'm a bit perplexed since the hibernate package seems far more mature
and configurable with it's scriptlets approach.  

Thanks,
David

On Wed, 2006-09-27 at 09:41 +0200, Tim Dijkstra wrote: 
> Op Tue, 26 Sep 2006 22:34:49 -0700
> schreef jantzen <david.jantzen at comcast.net>:
> 
> > Well, perhaps I can stop bugging people about this.  Last week as part
> > of an otherwise ill-advised upgrade from unstable (to solve this
> > issue), I obtained the kernel image 2.6.17-2-amd64.  Since the update
> > hosed my graphics driver and I had to rollback Xorg, I never got
> > around to testing suspend with the new kernel image til now.  It
> > works.  No idea why.  I'd listen to an explanation if anyone has one.
> > 
> > > 
> > > Linux kernel: 2.6.16-2-em64t-p4-smp
> > > HAL: 0.5.7.1-2
> > > udev: 0.100-1
> 
> There were lots of changes to suspend between 2.6.16 and 2.6.17, so
> that maybe related.
> 
> Btw, to better debug such a situation, it is good to know that hal just
> calls a script
> 	/usr/share/hal/scripts/hal-system-power-suspend
> Which just tries to find if various known programs to suspend are
> available. In the end it will fall back to 
> 	echo disk > /sys/power/state
> 
> Hal (or udev) by it self does not know how to suspend. So if you have
> problems you're better of getting it work from the command line first.
> 
> grts Tim