On several mashines resume from suspend2-sources-2.6.20 up to including suspend2-sources-2.6.22 causes an Oops #0000 or similar. Not tainted and "VLI" are the major keywords I wrote down. The probabilty of this incident seems to be at least 60% ! When this happend, a reset and reboot with option "noresume" (=noresume2 in my kernel configuration) is only the first step to system-recoverage, which again enforces the reset-button to be pressed, because the root-fs seems to have vanished: As having IDE-drives, block-special(3,8) is my root-fs /dev/hda8 but it always (in that situation, and then only once) complains about some "unknown-block(3,8)". On an other system (here root-fs beeing /dev/hda9) it happily lists all available partitions, also showing the matter of complaint: /dev/hda9 !
Hmmm... Thanks for the report... But I cannot help you... It seems an issue only upstream can solve. I suggest you post a message to list: suspend2-devel@lists.suspend2.net If you have digital camera you should take a picture before you post... It will allow Nigel to know what going on. Sorry...
Created attachment 126809 [details] Screenshot step1: Resume does not work
Created attachment 126811 [details] Screenshot step2: noresume does not help at once
Hello Nigel, Any thoughts?
Off the top of my head, failing to initialise LZF makes me wonder if the LZF code has been built as a module and not loaded prior to trying to resume. That said, I thought I tested only recently that this is handled properly. Regarding the second issue, if we're managing to invalidate the image, the /dev node for the device the image header is using must exist. Could /dev/hda6 be missing from the filesystem in the initrd/initramfs?
I should also ask, is there any chance of reproducing this using a kernel with debugging information (before it gets fixed)? I have zero chance of fixing the underlying problem without that.
No, suspend2-compression is NOT built as module AND I do NOT use any initrd which could cause trouble by missing any device-files. I am now compiling a new kernel with some debugging enabled, but please let me know what checkboxes I should have checked there!
Is Cryptoapi LZF support built in?
You made half a point there, Cryptoapi LZF was not built at all, but is now in static kernel... without much better results (at least 1 out of 4 suspend-resume-cycles means death for the running system) As I suspected LZF to be part of the problem, I disabled suspend2 compression once uppon a time, without better results.
Created attachment 126924 [details] Screenshot step1 on other machine: Resume does not work
I'm leaving for a conference now, and won't be back until Friday evening GMT+10. I don't think I'll have web access, so please accept my apologies if I'm slow to reply. I'll grab your latest screenshot now; perhaps I'll be able to do some work on it while away. Nigel
Hmm. Before I go, I've looked at the screenshot. Do you have more than one swap device? If so, you need to have all swap devices accessible at resume time. Unlike [u]swsusp, Suspend2 will use all available swap when writing the image, so you can't assume that the image has only been stored on the device pointed to by resume=. If you don't want a swap partition/file to be used for writing the image, you'll need to swapoff it before starting the cycle. See you Friday.
It is true that I have a main swap device and two swapfiles! They reside on ext3 and reiser-fs, that are on the same harddisk as the swap device. As having all major filesystems statically built into the kernel I don't think that this is a problem, but I will make some tests without any secondary swap-devices/-files to insure this.
gto_la: Please reopen if you have more information.
