Bug 151747

Please run /usr/share/doc/packages/powersave/powersave_logs and append the logfile-archive created from that script.

Created attachment 68988 [details]
powersave_logs.tar.gz

Just to clarify: "does not work" in this case *really* means "does not work". The machine starts to prepare, after displaying "synching disks 50%" it locks the display, and that's it. No more visible progress. 

Please increase the debug level:
  Set DEBUG="" to DEBUG="15" in /etc/powersave/common

Do suspend to disk and paste the output in /var/log/messages starting from the suspend. Thanks.

echo "disk" > /sys/power/state
results in "echo: write error: Invalid argument", /sys/power/state is still "mem". -> kernel-bug
Kernel is 2.6.16-rc3-git3-2-smp for x86_64. 

Just to make this clear. /sys/power/state on x86_64 with Beta 3.95 _only_ contains 'mem'. Assigning to kernel maintainer...

The problem is still present in beta4. 

Stefan, is it broken on other x86-64 systems, too? Did someone disable CONFIG_SWSUSP or what?

i have no idea, but the kernel team has lots of x86_64 machines in the suse network; should be easy to check.

Heh, we should really get at least one x86_64 machine near to you. Perhaps you can steal Bodo's :-).

Too late, I already got Bodo's old machi^YYes, you could steal Bodo's, I think. ;-)

Anyway, from /proc/config.gz:
CONFIG_SOFTWARE_SUSPEND=y

Does it happen on more than one machine? Holger, can you reproduce it?

i am installing an x86_64 machine right now.

works fine. Works also fine on Rasmus' machine. It might be that there was a problem after the first boot (maybe the resume-partition setup was incorrect?) that caused the missing "disk" in /sys/power/state, but now everything is fine.

So i' would say...

OK, so you mixed something up (suspending NLD10 b4 does not mean it's working with SL10.1 b4 also), and I mixed something up, because the 
CONFIG_SOFTWARE_SUSPEND on SL10.0 is actually not set (comment #13 was NLD10 b4, because I also mixed up the installations). 

(In reply to comment #17)
> OK, so you mixed something up (suspending NLD10 b4 does not mean it's working
> with SL10.1 b4 also), and I mixed something up, because the 
> CONFIG_SOFTWARE_SUSPEND on SL10.0 is actually not set (comment #13 was NLD10
> b4, because I also mixed up the installations). 

So there is a difference between NLD10B4 kernel and SL10.1B4 kernel.

since Code10 is binary identical packages, this is a blocker IMO

Please prove that they are different:

aj@reger:/mounts/dist/install/SLP/NLD-10-Beta4/i386/CD1/suse/i586> l kernel-default-2.6.16_rc3_git3-2.i586.rpm
-rw-r--r--  1 root root 17814624 2006-02-16 03:49 kernel-default-2.6.16_rc3_git3-2.i586.rpm

2aab37dc63f60000436ad90624b32de1  kernel-default-2.6.16_rc3_git3-2.i586.rpm


aj@reger:/mounts/dist/install/SLP/SUSE-10.1-Beta4/i386/CD1/suse/i586> l kernel-default-2.6.16_rc3_git3-2.i586.rpm
-rw-r--r--  1 root root 17814624 2006-02-16 03:49 kernel-default-2.6.16_rc3_git3-2.i586.rpm
aj@reger:/mounts/dist/install/SLP/SUSE-10.1-Beta4/i386/CD1/suse/i586> md5sum kernel-default-2.6.16_rc3_git3-2.i586.rpm
2aab37dc63f60000436ad90624b32de1  kernel-default-2.6.16_rc3_git3-2.i586.rpm


So, the two media have exactly the same kernel.

Rasmus, either show what you installed or close as invalid :-)

/etc/SuSE-release
SUSE LINUX 10.0.42 (X86-64) OSS Beta4
VERSION = 10.0.42
kernel-default-2.6.16_rc3_git3-2
/proc/config.gz:
# CONFIG_SOFTWARE_SUSPEND is not set
-> powersave -U does not work


/etc/SuSE-release
Novell Linux Desktop 10 (x86_64)
VERSION = 10
RELEASE = 9
kernel-default-2.6.16_rc3_git3-2
/proc/config.gz:
CONFIG_SOFTWARE_SUSPEND=y
-> powersave -U does work


I'm not sure what Andreas wants to tell us by quoting i386 kernel md5sums, but fact is that the x86_64 kernels are identical, too. 

NLD10 beta4:
# uname -a
Linux kaczynski 2.6.16-rc3-git3-2-default #1 Wed Feb 15 15:03:23 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux
# rpm -q kernel-default --changelog |head
* Wed Feb 15 2006 - axboe@suse.de
- patches.drivers/sata-mv-fua: FUA write command missing from
  its dma list.

* Wed Feb 15 2006 - hare@suse.de
- patches.arch/s390-01-09-october2005.diff
  Add statistics support for zfcp (149742 - LTC21427)
- patches.arch/s390-statistic-disclamier.diff
  Add disclaimer for statistics interface.
- Update config files


SL10.1 beta4
# uname -a
Linux kaczynski 2.6.16-rc3-git3-2-smp #1 SMP Wed Feb 15 15:03:23 UTC 2006 x86_64 x86_64 x86_64 GNU
/Linux
# rpm -q kernel-default --changelog |head
* Wed Feb 15 2006 - axboe@suse.de
- patches.drivers/sata-mv-fua: FUA write command missing from
  its dma list.

* Wed Feb 15 2006 - hare@suse.de
- patches.arch/s390-01-09-october2005.diff
  Add statistics support for zfcp (149742 - LTC21427)
- patches.arch/s390-statistic-disclamier.diff
  Add disclaimer for statistics interface.
- Update config files


Andreas said to close and retest with beta5...

Problem still exists with beta7:
- NLD kernel is able to suspend to disk (CONFIG_SOFTWARE_SUSPEND=y)
- SL kernel is not able to suspend to disk (# CONFIG_SOFTWARE_SUSPEND is not set)

I don't believe it and will come to your office on monday to look personally at the machine.

You're welcome (don't forget to bring some cake, though! ;-). 

The SL 10.1 beta7 installation can be identified by:
# cat /etc/SuSE-release
SUSE LINUX 10.0.42 (X86-64) OSS Beta6
VERSION = 10.0.42

The NLD 10 beta7 installation can be identified by:
# cat /etc/SuSE-release
Novell Linux Desktop 10 (x86_64)
VERSION = 10
RELEASE = 9

You know it has to be beta7, because the one number that definitely is not involved is a "7"...

Comment #26 was a SMP Beta6 kernel vs. a UP Beta7 kernel.  Those are configured
differentely...

Rasmus, better install everywhere an UP kernel!

Beta8, SLED (SL works), the story continues: 

uname -r
2.6.16-rc6-git1-4-smp

/proc/cmdline
root=/dev/hda2 vga=791 selinux=0 resume=/dev/hda3 splash=silent
[I had to add the "resume=" manually, it was not put there by the installation procedure]

/proc/config.gz:
# CONFIG_SOFTWARE_SUSPEND is not set
CONFIG_SUSPEND_SMP=y

/sys/power/state 
mem 

Symptom: System does not suspend to disk. 

Now, please don't tell me "please install the right kernel" here. *I* didn't install anything, I simply hit "enter" the whole time during installation, so if the outcome is wrong, there is a bug. Having an Enterprise Desktop that is unable to suspend to disk on a machine where it's possible to do so is not good. 

and even smp kernels on AMD64 should be able to suspend AFAIK.

The bug your reported is fixed.

this is a different bug - and fixed:
-------------------------------------------------------------------
Wed Mar 22 16:17:02 CET 2006 - trenn@suse.de

- Update config files.
  Added CONFIG_SOFTWARE_SUSPEND=y for x86_64 smp.