http://bugzilla.opensuse.org/show_bug.cgi?id=935086
http://bugzilla.opensuse.org/show_bug.cgi?id=935086#c29
--- Comment #29 from Uwe Geuder
From the picture we see that after reporting the compresssion ratio there will be 2 lines of size information of the compressed image.
When the hang occurs only 0 or 1 line of compressed image statistics is written and then the system hangs (as shown in previous attachments 639392 and 639393) If you look at code starting from line 669 in load.c you see that it does nothing besides printf() http://paste.opensuse.org/45471188 That really would look like printf() is hanging, but I cannot believe that. On one side it could vaguely explain why rd.break=pre-mount makes a difference, the console can be in different state after having been in an interactive shell just before. But in the normal setup stdout of the resume process is not the console at all, it's the socket to journald. And the hang has been reproducible with the socket and with the console. So no, hanging in printf() makes no sense to me. My printf debugging occurs even later, so we are not even close to the place where the kernel switches to the structures restored from snapshot. The hang seems to occur while the resume process runs in user space or does trivial printf() at most. Of course getting a call stack of the resume process might be helpful. -- You are receiving this mail because: You are on the CC list for the bug.