Bug 327601

Can you try it from minimal system? At the point it locks up, does it react to console switches? Can you do sysrq-9, sysrq-P to list processes at that point?

sysrq(PrintScrn)+9 only puts a 9 on the screen.
sysrq(PrintScrn)+p only puts a p on the screen.
No reaction after this.
Is this what you mean with "console switches"?

Antoon, alt-sysrq-9 and alt-sysrq-P is the correct combination. Thanks.

First an addition to my first report:
After the line
Sep 22 14:50:17 linux-q9bp kernel: Restarting tasks ... done.
appears the following line appears after 3 minutes:
SFW2-INext-DROP-DEFLT IN=eth1 OUT= MAC= SRC=83.87.118.121 DST=224.0.0.251 LEN=64 TOS=0x00 PEC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44
and this line is repeated every 3 minutes.

And now the reaction to the console switches 
(-)=hit the keys after each other 
(+)=hit all the keys at the same time

alt-sysrq-9  -> 9
alt-sysrq-p  -> p
alt+sysrq+9  -> sysRq : This sysrq operation is disabled
alt+sysrq+p  -> sysRq : This sysrq operation is disabled

Yes, you need to enable magic sysrq combinations. You probably need echo 1 > /proc/sys/kernel/sysrq or something.

From http://en.opensuse.org/Bugs/Kernel
In addition, you may want to edit /etc/sysconfig/sysctl and change the variable ENABLE_SYSRQ to "yes". This will ensure that sysrq is enabled after reboot.
I followed the above method.

Output of Alt+SysRq+9 is:

SysRq : Changing Loglevel
Loglevel set to 9
Oct 10 20:44:09 53577679 kernel: Loglevel set to 9

Output of Alt+SysRq+P is:

SysRq : Show Regs

Pid: 0, comm:                swapper
EIP: 0060:[<c0103246>] CPU: 0
EIP is at mwait_idle_with_hints+0x3b/0x3f
 EFLAGS: 00000246      Tainted: G         N  (2.6.22.5-23-default #1)
EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX:00000000\par
ESI: 00000000 EDI: c0386008 EBP: 00001d76 DS: 007b ES: 007b FS: 00d8
CR0: 8005003b CR2: b735a378 CR3: 1fa30000 CR4: 000006d0
 [<c010324a>] mwait_idle+0x0/0x13
 [<c01033af>] cpu_idle+0xaa/0xcb
 [<c038c9a4>] start_kernel+0x352/0x35a
 [<c038c17e>] unknown_bootoption+0x0/0x216
 =====================
Oct 10 20:44:25 53577679 kernel: 
Oct 10 20:44:25 53577679 kernel: Pid: 0, comm:                  swapper
Oct 10 20:44:25 53577679 kernel: EIP: 0060:[<c0103246>] CPU: 0
Oct 10 20:44:25 53577679 kernel: EIP is at mwait_idle_with_hints+0x3b/0x3f
Oct 10 20:44:25 53577679 kernel:  EFLAGS: 00000246      Tainted: G         N  (2.6.22.5-23-default #1)
Oct 10 20:44:25 53577679 kernel: EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX:00000000
Oct 10 20:44:25 53577679 kernel: ESI: 00000000 EDI: c0386008 EBP: 00001d76 DS: 007b ES: 007b FS: 00d8
Oct 10 20:44:25 53577679 kernel: CR0: 8005003b CR2: b735a378 CR3: 1fa30000 CR4: 000006d0
Oct 10 20:44:25 53577679 kernel: [<c010324a>] mwait_idle+0x0/0x13
Oct 10 20:44:25 53577679 kernel: [<c01033af>] cpu_idle+0xaa/0xcb
Oct 10 20:44:25 53577679 kernel: [<c038c9a4>] start_kernel+0x352/0x35a
Oct 10 20:44:25 53577679 kernel: [<c038c17e>] unknown_bootoption+0x0/0x216
Oct 10 20:44:25 53577679 kernel: =====================

Why is your kernel tainted: N?

Is it still broken in opensuse 10.3 final?

can you try it from init=/bin/bash?

Created attachment 178219 [details]
GM_suspendtodisk info

Created attachment 178220 [details]
sysrqGMinfo

can you try it from init=/bin/bash?
I do not understand what you mean with this question.
Please more info on this.

Is it still broken in opensuse 10.3 final?
I have installed openSUSE-10.3-GM-DVD-i386 and I am using the KDE desktop.
The suspend to disk - start behaviour is more unstable then in the RC1 version.

I have performed the test 10 times with the following results:

4 times the the KDE desktop was shown with a slow cursor movement response
and a failing Yast launch (no response after supplying the rootpassword)
and shutting down the PC ends somewhere in the shutdown procedure.
The only thing I could do was to activte the reset button.

6 times the result was as in the first post of this bugreport 
The screeninfo can be seen in the GM_suspendtodisk attachment.
The sysrqinfo can be seen in the Sysrq9p_GM attachment.

Thanks for testing.

init=/bin/bash... you need to add that onto kernel commandline to test with miminal system.

Where did you get "N" taint?

Created attachment 179314 [details]
Behaviour of suspend to disk with no kernelpanic

Created attachment 179315 [details]
Behaviour of suspend to disk wit kernelpanic

With the help of http://www.alleslinux.com/forum/viewtopic.php?t=6307
and http://en.opensuse.org/ACPI_Suspend_debugging
I managed to get a minimal system.

I did this as follows 

The default entry in /boot/grub/menu.lst was: 
title openSUSE 10.3 - 2.6.22.9-0.4
    root (hd0,11)
    kernel /boot/vmlinuz-2.6.22.9-0.4-default root=/dev/disk/by-id/scsi-SATA_Maxtor_6L250R0_L50LYG1G-part12 vga=0x31a resume=/dev/sda2 splash=silent showopts 
    initrd /boot/initrd-2.6.22.9-0.4-default

I made a new entry 
title openSUSE 10.3 - 2.6.22.9-0.4 minimal
    root (hd0,11)
    kernel /boot/vmlinuz-2.6.22.9-0.4-default init=/bin/bash
    initrd /boot/initrd-2.6.22.9-0.4-default
and set the new entry as default.

Putting the system into suspend to disk and restarting from the suspendmode gives two different behaviours.
See attachment suspendtodisk_panic.txt and suspendtodisk_nopanic.txt for the discription.
It was not possible to put the system into supendmode for a second time.
To repeat the test I had to start in fullsystem(KDE) mode and then in minimalsystem mode.

And your question "Where did you get "N" taint?"
My answer: This is produced by suse 10.3 GM (DVD)+ all the updates untill today.

(You should not be changing bug ownership).

Pavel, the "N" taint means "unsupported." It has no meaning on non-SLE kernels. Most users will have a N tainted kernel without taking any action themselves. If the system is working correctly and loading drivers for their hardware automatically, it will probably end up loading a driver that will carry the N taint.

(In reply to comment #12 from Pavel Machek)

> Where did you get "N" taint?

The "N" taint is from "unsupported (by Novell) module". It is harmless unless on an enterprise product support call.

Jeff: Sometimes "N" taint means "lm_sensors", that's why I'm careful :-)

The panic from minimal system seems interesting. Did it print anything more between these lines?

Call Trace:
 =======================
Code: f0 5f 60 00 00 8f 10 c0 00 00 f8 00 00 85 00 00 90 60 60 00 00 8f 10 c0 a0
 60 60 00 00 8f 10 c0 b0 60 60 00 00 8f 10 c0 c0 60 60 <00> 00 8f 10 c0 00 54 60
 00 00 8f 2c c0 c0 51 60 00 00 8e 2c c0
EIP: [<c0378063>] 0xc0378063 SS:ESP 0068:c0389fd8
Kernel panic - not syncing: Attempted to kill the idle task

? I'd need call trace to do anything inteligent :-(.

No it did not print more lines on my screen.
The lines between "c0378063" and "Kernel panic...." are all the lines that showed up on my screen.
I did check it again today, and all the values are the same as in the attachment.

What kind of machine is that?

Did hibernation ever work for you?

The mobo is an ASRock 775Dual-VSTA Motherboard with a Intel Pentium 4 3GHz processor.
See http://www.asrock.com/mb/overview.asp?Model=775Dual-VSTA
As stated in my first post hibernation to disk in Suse 10.2 was not a problem.

Ok, can you try to reproduce the problem with vanilla 2.6.23?

You asked to produce the problem with vanilla 2.6.23.
The kernelupdate of 08/11/07 gives the 2.6.22.12-0.1-default kernel and not 2.6.23.
I did a minimal systemtest with this 2.6.22.12-0.1-default kernel and repeated it 20 times.
The result is that the test ended 18 times without a problem.
2 times the result was a kernel panic.
After this I did a desktop(KDE) hibernation test and repeated it 5 times.
They all failed the same way as in my first report.

Ok, can you lsmod at full system, then boot with minimal system, and try to find out which module breaks it?

I did a lsmod at full system and at minimal system.
I will post them as attachments.
I presume one off the modules which is in full system and not in minimal system breaks the system.
How can I find the one which I am looking for?

Created attachment 184286 [details]
Lsmod at full system

Created attachment 184287 [details]
LSmod at minimal system

You can binary-search for the module that breaks it. I'd begin with

pci_hotplug            33216  1 shpchp

Hmm. And you have lm_sensors:

i2c_viapro             12436  0
parport_pc             40764  0
i2c_core               27520  1 i2c_viapro

Unload them.

Through an update I have a new 2.6.22.13-0.3-default kernel.
After adding 
blacklist shpchp
blacklist pci_hotplug
blacklist i2c_viapro
blacklist parport_pc
blacklist i2c_core
to the /etc/modprobe.conf.local file the modules have disappeared from the lsmodlist.
(see attachment Lsmod at full system with unload1)
A 20x fullsystem hibernationtest gives the following result:
16x as discribed in my first report (no change).
4x a KDE desktop with or without a working lan interface and a loginprompt when I try to shutdown the PC.
In this situation the only way to shutdown the PC is to use the mains switch.
After this I tried to blacklist snd_pcm_oss and snd_mixer_oss.
As these two snd_.. modules where listed in lsmod after a restart ???
I stop testing for this moment and wait for further instructions.

Created attachment 185991 [details]
Lsmod at full system with unload1

Changed NEEDINFO status.

Ok, try to unload everything you can, perhaps difference is somewhere else than module list. ...also agpgart unloading/not trying from X might be useful.

Created attachment 188931 [details]
Lsmod at full system with unload2

The contents of /etc/modprobe.conf.local is now:
blacklist shpchp
blacklist pci_hotplug
blacklist i2c_viapro
blacklist parport_pc
blacklist i2c_core
blacklist via_agp
blacklist agpgart
See attachment [Lsmod at full system with unload2] for the loaded modules.
The behaviour of the fullsystem(KDE) hibernationtest didn't change.(it fails)

So it mostly suspends with minimal list of modules, and reliably does not with full list, right?

Try disabling snd_hda_intel, fuse, via_rhine, pcnet32 (why do you have both?), ehci_hcd, uhci_hcd and see what happens...

Created attachment 190987 [details]
Lsmod at full system with unload3

During testing my system was made corrupt.
Starting the system always ended in a kernel panic.
To solve this problem I had to reinstall the system from DVD+updates.
The kernel is now 2.6.22.13-0.3-default (the same as in comment #30).

Your question: via_rhine, pcnet32 (why do you have both?)
Answer: I have an additional LAN-card installed.

The contents of /etc/modprobe.conf.local is now:
blacklist shpchp
blacklist pci_hotplug
blacklist i2c_viapro
blacklist parport_pc
blacklist i2c_core
blacklist via_agp
blacklist agpgart
blacklist snd_hda_intel
blacklist fuse
blacklist via_rhine
blacklist pcnet32
blacklist ehci_hcd
blacklist uhci_hcd
See attachment [Lsmod at full system with unload3] for the loaded modules.
With this blacklist there is no sound and LAN interface.
The behaviour of the hibernationtest didn't change.
Minimal systemtest see comment #24
Full(KDE) systemtest see comment #30

...so, even with unload3, it mostly works from minimal system, and mostly breaks from KDE?

Are you using FUSE?

Does idle=poll (on kernel command line) help?

...so, even with unload3, it mostly works from minimal system, and mostly
breaks from KDE?
Answer: Yes, correct.

Are you using FUSE?
Answer: A search=fuse in Yast>Software Management shows that libfuse2 and
        ntfs-3g are installed.

Does idle=poll (on kernel command line) help?
I added idle=poll at the end of the kernel command line in 
/boot/grub/menu.lst.
A 5x Full(KDE) systemhibernationtest all failed.
This doesn't change anything.

Ok, so more tests... boot full KDE, then init 3 to get back to minimal system. Will suspend work?

boot full kde, but then switch to text console, and try if suspend works?

After a start of KDE I start a Root-konsole (+rootpassword) and give the 
command 'init 3'
KDE is closed and the following screen appears.
.
.
Starting CRON daemon                                                      done
Starting smartd                                                           done
Starting Firewall Initialization (phase 2 of 2)..........
                                                                          done
                                                                          done
Master Recource Control: runlevel 5 has beeb                           reached
Failed services in runlevel5:                                        network

Welcome to openSUSE 10.3 (i586) - Kernel 2.6.22.13-0.3-default (tty1).

linux-cmi2 login: atolboo
Wachtwoord:
Laatste keer aangemeld: ma jan 28 20:35:04 CET van console op :0
Have a lot of fun...
atolboo@linux-cmi2:~> su
Wachtwoord:
linux-cmi2:/home/atolboo # echo disk > /sys/power/state

The PC goes into hibernation now and the power is switched off.
After pushing the powerbutton the blue screen 'Resume From Hibernation' and 
the Grubscreen appears and the image data pages are loaded.
It ends with the following screen.

.
.
Laatste keer aangemeld: ma jan 28 20:35:04 CET van console op :0
Have a lot of fun...
atolboo@linux-cmi2:~> su
Wachtwoord:
linux-cmi2:/home/atolboo # echo disk > /sys/power/state
linux-cmi2:/home/atolboo # 
In order to restart into KDE I give the command 'reboot -f'.

I tested the above 10x with the same (above) result.
So suspend from int 3 works.
Is this also what you mean with 'switch to text console...'?

Ok, so suspend works for init 3.

Next test: can you leave KDE running, press ctrl-alt-F1 to get to the text console, and hibernate from there?

Suspend from ctrl+alt+F1 also works.
I have tested this 10 times with good results.
The blacklist is still the same as in Comment #38.

Ok, lets try from ctrl-alt-f1, but w/o the blacklist.

But this is very strange. suspend code internally switches to console 1, anyway. Is splash screen interfering? Or is it some weird X problem?

ctrl+alt+F1 with an empty blacklist in /etc/modprobe.conf.local gives the same behaviour as in comment #44 (no change)

Instead of using ctrl+alt+F1 I have done the same test in a userKonsole.

In KDE I open a userKonsole.

atolboo@linux-cmi2:~> su
Wachtwoord:
linux-cmi2:/home/atolboo # echo disk > /sys/power/state

And the PC goes into hibernation.
After a restart KDE appears including the userKonsole with the contents:

atolboo@linux-cmi2:~> su
Wachtwoord:
linux-cmi2:/home/atolboo # echo disk > /sys/power/state
linux-cmi2:/home/atolboo # 
linux-cmi2:/home/atolboo # 

And I can open and close my home directory with Konqueror.
The response of the cursormovement is not smooth (shacky).
I can do a restart with 'reboot -f' in the userKonsole.
When I try to reboot in Kmenu>Log out...>Restart Computer I get a init 3 screen (see comment #42)
So this works more or less but it is not 100% OK.
I repeated this test 10 times with the same above result.
I hope this gives more lights on the problem (and maybe a solution).

Lets declare slowness a separate problem. nohz=off highres=off might help there.

So echo disk > /sys/power/state from shell works...

Can you try powersave -U  from root shell?

Addition to comment #46:
Besides the cursormovemennt I had a failing launch of Yast (no response after supplying the rootpassword).

A 'powersave -U' from root-shell gives the same behaviour as in my first description (it fails).
I tested this 5 times.

Hello, I recently got a new Lenovo Thinkpad T61P and I'm experiencing the behaviour explained in the summary of this bug ("System fails after resume from hibernation in 10.3").

How do you guys think that I should proceed now? Should I create a new bug for my case or stick to this one? How could I provide debugging information to you?

Please let me know anything I should do in order to help with this issue.
Thanks!

Andres: new bug, please. We have thinkpads around here, so that one should be easier to deal with.

Stefan, can you help here? It mostly works with echo disk, breaks with powersave -U.

Pavel: thanks for your answer, I created bug 373189.

Ok. Antoon, could you please try if it works with "powersave -U" after you have created a file /etc/pm/config.d/config with the content

HIBERNATE_METHOD="kernel"

This will find out if the method used is actually to blame or if it is something we are doing around suspend in pm-utils.

Before trying the /etc/pm/config.d/config file I retested the "'powersave -U' from root-shell" (comment #48).
To my surprise the behaviour from my first description could not be reproduced (see also comment #48).
I tested this 5 times.
Going into hibernation the ZZ screen with the progressionbar stops at 15% from the right, and the powerled stays on.
After activating the reset button (this is the only possibility) a normal coldstart is performed (no blue 'Resume from Hibernation' screen).

On this PC I still have Suse 10.2 with kernel 2.6.18.8-0.9-default (I will not remove this as long as this bug is open).
To exclude behaviourchange with hardware I retested hibernation with 10.2. a number(5x?) of times
It passed without any problems.

I decided to do a new 10.3 installation from DVD + all updates.
The kernel has now changed from 2.6.22.13-0.3-default (comment #42) to 2.6.22.17-0.1-default
The hibernation behaviour is still the above mentioned '15% progressionbar ZZ' screen.
Tested 5 times.

After this I modified /boot/grub/menu.lst (see comment #15) to do a minimal systemtest.
The result is the same as in attachment 'Behaviour of suspend to disk with no kernelpanic'
(including the attempt to put it into hibernation for the second time).
In comment #15 I wrote: To repeat the test I had to start in fullsystem(KDE) mode and then in minimalsystem mode.
But not this time.
It always (minimal and KDE-mode) ends with:

Waiting for device /dev/disk/by-id/scsi-SATA_Maxtor_6L250R0_L50LYG1G-part12 to appear:  ok
fsck 1.40.2 (12-Jul-2007)
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -C0 /dev/disk/by-id/scsi-SATA_Maxtor_6L250R0_L50LYG1G-part12
SUSE10.3GM (/dev/disk/by-id/scsi-SATA_Maxtor_6L250R0_L50LYG1G-part12: recovering journal
SUSE10.3GM (/dev/disk/by-id/scsi-SATA_Maxtor_6L250R0_L50LYG1G-part12: clean, 128880/669120 files, 785072/1337403 blocks
fsck succeeded. Mounting root device read-write.
Mounting root /dev/disk/by-id/scsi-SATA_Maxtor_6L250R0_L50LYG1G-part12
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda12, internal journal
EXT3-fs: mounted filesystem  with ordered data mode.
/bin/run-init: /bin/sh: Permission denied
Kernel panic - not syncing: Attempted to kill init!

And I am not able to end this 'Kernel panic' situation.
Is there a way to end this situation?
I will do a new installation and then apply the /etc/pm/config.d/config file and restart testing.
I hope I do not have to do a new installation every time I get in a 'Kernel panic' situation.
So the behaviour has changed and gone from bad to worse.

After a new installation the behaviour is still the same as in comment #54.
After installing the /etc/pm/config.d/config file from comment #53 the behaviour of "'powersave -U' from root-shell" is as follows:
The KDE-desktop is replaced with the following lines on the screen.

Preparing hibernate...
Stopping tasks ... done.
Shrinking memory... done (0 pages freed)
Freed 0 kbytes in 0.03 seconds (0.00 MB/s)
Suspending console(s)

The powerled stays on.
After activating the reset button a normal coldstart (with 0 seconds Grub delay time and no blue 'Resume from Hibernation' screen) is performed.

The behaviour of the minimal system test is the same as in comment #54.
To avoid the 'Kernel panic' situation I do a full KDE cycle in between the minimal system tests.
I finish the minimal system test with reboot -f.
The first KDE statup ends with:
Read 25772 kbytes in 0.47 seconds (54.83 MB/s)
Suspending console(s)
A second KDE cycle is succesfull and I can do the next minimal system test without a 'Kernel panic' situation.
So a minimal system test is succesfull in hibernation.

So hibernation works from minimal system, and is broken from KDE.

Can you try to find out what exactly matters? I believe we went through module lists and there was nothing really suspect.

Can you try starting just the Xserver if maybe that breaks the hibernation?

Your question: Can you try starting just the Xserver if maybe that breaks the hibernation?

How can I do that?
I know how to start with minimal system and full KDE-system.

one way would probably be (i have not tested that now, it's from memory):

boot into text mode, by adding the number "3" to the boot commandline
log in as root on the text console
start the X server like that:

  X :0 &

wait until the X server starts up empty, switch back to text console with ctrl-alt-f1
start an xterm

  DISPLAY=:0 xterm

switch back to X with alt-f7, you should have a terminal window, nothing else. In that terminal window, type either "powersave -U" or plain "pm-hibernate".

This should give you suspend to disk from an as minimal X setup as possible.

First let me say that there is nothing wrong with your memory.
Everything is as you wrote down in comment #58.
After I enter 'powersave -U' or 'pm-hibernate' in the terminal window the following happens:
The X server with the terminal window disapppears and the following text appears on the monitor.

Preparing hibernate...
Stopping tasks ... done.
Shrinking memory... done (0 pages freed)
Freed 0 kbytes in 0.03 seconds (0.00 NB/s)
Suspending console(s)

The monitor and powerled of the PC stay ON.
I can only push the reset button to start again.
I performed the above test 5x with the same result.

Could you try opensuse 11? There's good chance it is fixed there.

When I give  Suspend to Disk in Kpowersave I get a "Error while prepare Suspend to Disk - KPowersave" popup screen with:
Could not umount extereal media before suspend/standby. (Reason: Could not call DCOP interface to umount external media.) Would you like to continue suspend/standby anyway? (Warning: Continue suspend can cause data loss!)

After selecting [Suspend anyway] a "Error while Suspend to Disk - Kpowersave" popup screen with:
An unknown error occurred while Suspend to Disk. The errorcode is: '1'

There is NO external media connected to the computer.

When I open a konsole and become root(su) and give "powersave -U' the response is 'Suspend to disk request sent.'
And nothing is happening.

opensuse 11.0 beta3 refuses to go into suspend to disk.

This is probably bug https://bugzilla.novell.com/show_bug.cgi?id=386969
You need to add your swap partition to fstab if you installed from the live-cd.
After adding swap to fstab and rebooting, suspend to disk should work.

After adding swap to fstab I still get the "Error while prepare Suspend
to Disk - KPowersave" popup screen.
After selecting [Suspend anyway] the pc goes into hibernation and the ZZ screen appears with the progressionbar which stops at 15% from the right, and the powerled stays on.
After activating the reset button (this is the only possibility) a normal
coldstart is performed (no blue 'Resume from Hibernation' screen).
The behaviour is the same as in comment #54 (with 10.3).
With 'powersave -U' I get the same ZZ screen.

(In reply to comment #63 from Antoon Tolboom)
> After adding swap to fstab I still get the "Error while prepare Suspend
> to Disk - KPowersave" popup screen.

Ok. This seems to be a different bug, i'd ask you to file a separate report for that (mixing up issues in one report will make things harder to understand for everyone)

> After selecting [Suspend anyway] the pc goes into hibernation and the ZZ screen
> appears with the progressionbar which stops at 15% from the right, and the
> powerled stays on.
> After activating the reset button (this is the only possibility) a normal
> coldstart is performed (no blue 'Resume from Hibernation' screen).
> The behaviour is the same as in comment #54 (with 10.3).
> With 'powersave -U' I get the same ZZ screen.

Bad :-(

Please try the following: become root, then issue the following command:

echo "splash = n" >> /etc/suspend.conf

This will make the ZZ screen go away and you will see some text, which might give us hints where the problem is.

Output on monitor:

type=1505 audit(1211468511.210:2): operation="profile_load" name="/bib/ping" name2="default" pid=1524
type=1505 audit(1211468511.282:3): operation="profile_load" name="/sbin/klogd" name2="default" pid=1543
type=1505 audit(1211468511.318:4): operation="profile_load" name="/sbin/syslog-ng" name2="default" pid=1544
type=1505 audit(1211468511.354:5): operation="profile_load" name="/sbin/syslogd" name2="default" pid=1545
type=1505 audit(1211468511.398:6): operation="profile_load" name="/usr/sbin/avahi-daemon" name2="default" pid=1546
type=1505 audit(1211468511.430:7): operation="profile_load" name="/usr/sbin/identd" name2="default" pid=1547
type=1505 audit(1211468511.466:8): operation="profile_load" name="/usr/sbin/mdnsd" name2="default" pid=1548
type=1505 audit(1211468511.502:9): operation="profile_load" name="/usr/sbin/nscd" name2="default" pid=1549
type=1505 audit(1211468511.574:10): operation="profile_load" name="/usr/sbin/ntpd" name2="default" pid=1550
type=1505 audit(1211468511.670:11): operation="profile_load" name="/usr/sbin/traceroute" name2="default" pid=1569
IA-32 Microcode Update Driver: v1.14a <tigran@aivazian.fsnet.co.uk>
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
ip6_tables: (C) 2000-2006 Netfilter Core Team
powernow: This module only works with AMD K7 CPUs
ip_tables: (C) 2000-2006 Netfilter Core Team
BIOS EDD facility v0.16 2004-Jun-25, 6 devices found
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
May 22 17:01:57 linux network: NetworkManagerDispatcher is not installed, skipping it. Please set
May 22 17:01:57 linux network: /etc/sysconfig/network/config:NetworkManagerDispatcher=no or install NetworkManagerDispatcher.
May 22 17:05:49 linux dhclient: receive_packet failed on eth0: Network is down
s2disk: Snapshotting system

How much memory does affected machine have, btw?

From My Computer:

Total memory(RAM): 1,011.4MB
Free memory: 657.7MB (+158.6MB Caches)
Free swap: 1.9GB

Can you try opensuse 11.0 final? Hopefully problem will be gone there.

(Sorry, there's no obvious solution, and no easy way to debug this without the hardware).

The behaviour of opensuse 11.0 final is the same as in Comment #63
After selecting [Suspend to disk] the pc goes into hibernation and the ZZ screen
appears with the progressionbar which stops at 15% from the right, and the
powerled stays on.
After activating the reset button (this is the only possibility) a normal
coldstart is performed (no blue 'Resume from Hibernation' screen).
The behaviour is the same as in comment #54 (with 10.3).