http://blog.gmane.org/gmane.linux.swsusp.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.swsusp.general/10054 <pre>Some help here please. Firstly, my 64-bit nvidia-using laptop hibernate works without compression, but can't resume when compression is turned on. Here's the dmesg - http://pastebin.com/CsXSuesZ The interesting (to me) lines are as follows:- TuxOnIce 3.2.1 (http://tuxonice.net) input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0 TuxOnIce: Can't translate "/dev/sda7" into a device id yet. PM: Checking hibernation image partition swap:/dev/sda7:0x1087070 PM: Hibernation image not present or could not be loaded. After this, the system continues booting as if from a cold boot. This is the contents of tuxonice.conf (minus the commented lines). lzf or lzo makes no difference. Both kernel modules have been tried either within initramfs or compiled into the kernel. UseTuxOnIce yes Reboot no EnableEscape yes DefaultConsoleLevel 7 Compressor lzo Encryptor none SuspendDevice swap:/dev/sda7:0x1087070 ProcSetting extra_pages_allowance 7500 ProcSetting userui_program /usr/sbin/tuxoniceui_text FullSpeedCPU yes Any suggestions on what else I should try? </pre> Oon-Ee Ng 2012-05-07T07:08:30 http://permalink.gmane.org/gmane.linux.swsusp.general/10053 <pre>On 1 May 2012, NeilBrown told this: Ah. Yeah, this is ToI-added, in submit_bio(), and clearly has that purpose, conditionalized on a variable turned on by the freezer and turned off in late resume and freeze/resume abort: if (unlikely(trap_non_toi_io)) BUG_ON(!(bio-&gt;bi_rw &amp; REQ_TOI)); Possible fix below (not tested yet, more places may need REQ_TOI added, but eating birthday cake comes before compiling kernels :P ) So I bugged you unnecessarily, sorry! (Not that I thought it was your code at fault anyway, md code is as near bug-free as it's ever been my pleasure to use, and ToI code is remarkably free of bugs as well. This was bound to be some unexpected interaction somewhere, and if I'd just noticed the 'kernel BUG at' line rather than focusing singlemindedly on the backtrace I'd have spotted it without prompting: I always overlook that line in BUGs, hiding away up there). That makes a lot of sense. I remember in 3.2 we tended to get a brief flicker of RAID reconstruction kicking in before the restore started (and, obviously, reset md's state to its resumed, non-reconstructing state). On a RAID-5 or RAID-6 array rather than a RAID-1 array a magically interrupted restore like that feels extremely risky to me! No bitmap here. Possible fix, obviously should apply to the ToI tree not upstream, will try this evening: diff --git a/drivers/md/md.c b/drivers/md/md.c index 74efd50..19cf17b 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c &lt; at &gt;&lt; at &gt; -851,7 +851,7 &lt; at &gt;&lt; at &gt; void md_super_write(struct mddev *mddev, struct md_rdev *rdev, bio-&gt;bi_end_io = super_written; atomic_inc(&amp;mddev-&gt;pending_writes); -submit_bio(WRITE_FLUSH_FUA, bio); +submit_bio(WRITE_FLUSH_FUA | REQ_TOI, bio); } void md_super_wait(struct mddev *mddev) </pre> Nix 2012-05-01T08:35:58 http://permalink.gmane.org/gmane.linux.swsusp.general/10052 <pre> Presumably the BUG_ON you are hitting is something added by TuxOnIce to ensure nothing gets written to disk after the snapshot has been taken. Not entirely unreasonable I guess. md is updating the metadata at this point to ensure it is marked as clean. This probably isn't really needed but is done on a better-safe-than-sorry basis. The newer code won't write the md superblock unless it has to, but it looks like it will write the bitmap metadata unnecessarily. Maybe that could be improved. What exactly is the BUG you are tripping. Maybe it should really be a WARN .... If you make it a WARN, can you then resume successfully? NeilBrown _______________________________________________ TuxOnIce-users mailing list TuxOnIce-users&lt; at &gt;lists.tuxonice.net http://lists.tuxonice.net/listinfo/tuxonice-users</pre> NeilBrown 2012-05-01T01:20:17 http://permalink.gmane.org/gmane.linux.swsusp.general/10051 <pre>On 30 Apr 2012, Matt Graham spake thusly: Yep. I was using it in 3.2, and it worked :) md_notify_reboot() has changed completely, in this commit: commit ed1b69c5592d1fcb4e3151fd5900e22772f22919 Author: NeilBrown &lt;neilb&lt; at &gt;suse.de&gt; Date: Mon Mar 19 12:46:37 2012 +1100 md: don't set md arrays to readonly on shutdown. commit c744a65c1e2d59acc54333ce80a5b0702a98010b upstream. It seems that with recent kernel, writeback can still be happening while shutdown is happening, and consequently data can be written after the md reboot notifier switches all arrays to read-only. This causes a BUG. So don't switch them to read-only - just mark them clean and set 'safemode' to '2' which mean that immediately after any write the array will be switch back to 'clean'. This could result in the shutdown happening when array is marked dirty, thus forcing a resync on reboot. However if you reboot without performing a "sync" first, you get to keep both halves. This is suitable for any stable kernel (though there might be some conflicts with obvious fixes in earlier kernels). Signed-off-by: NeilBrown &lt;neilb&lt; at &gt;suse.de&gt; Signed-off-by: Greg Kroah-Hartman &lt;gregkh&lt; at &gt;linuxfoundation.org&gt; </pre> Nix 2012-04-30T16:46:51 http://permalink.gmane.org/gmane.linux.swsusp.general/10050 <pre> [snippage] These symptoms and the stack trace look very similar to some stuff that I ran into last year with md and tuxonice. What Nigel came up with then was a one-line patch in md_notify_reboot() in md.c , &lt; at &gt;&lt; at &gt; -8056,7 +8056,7 &lt; at &gt;&lt; at &gt; static int md_notify_reboot(struct notifier_block *this, struct list_head *tmp; mddev_t *mddev; - if ((code == SYS_DOWN) || (code == SYS_HALT) || (code == SYS_POWER_OFF)) { + if (((code == SYS_DOWN) || (code == SYS_HALT) || (code == SYS_POWER_OFF)) &amp;&amp; !freezer_state) { printk(KERN_INFO "md: stopping all md devices.\n"); ...this worked just fine for me and apparently a few other people in the 3.0 series as well as the 3.2 series. Original message was on the tuxonice list 2011-09-14 or thereabouts. I'm not sure how much has changed in 3.3 that would make this fail miserably, cause machines to explode, or anything like that, because I haven't had time to do much fiddling with 3.3. </pre> Matt Graham 2012-04-30T16:17:12 http://permalink.gmane.org/gmane.linux.swsusp.general/10049 <pre>[Neil: Cc:ed even though this is probably a TuxOnIce problem because I figure you might be interested in crashes with md even tangentially involved, and it's right at the heart of this one, dancing a folie a deux with TuxOnIce] I see this on suspend with 3.3.4, and a kernel panic on resume (with nothing logged over the netconsole, just a quintuple pulse of the keyboard lights and a reboot during atomic copy). I'm using the 3.3-tuxonice branch merged to 3.3.4 because that branch is not at 3.3.4 itself yet. (No merge conflicts.) I'm not sure what to do about this. We can't stop md until everything is written, but it is clear that this is too late. [29422.686424] Initiating a hibernation cycle. [29455.808465] ------------[ cut here ]------------ [29455.808516] kernel BUG at block/blk-core.c:1703! [29455.808550] invalid opcode: 0000 [#1] PREEMPT SMP [29455.808584] CPU 0 [29455.808596] Modules linked in: firewire_ohci firewire_core [29455.808631] [29455.808641] Pid: 17239, comm: hibernate Not tainted 3.3.4-05156-g27b4c53-dirty #1 System manufacturer System Product Name /P6T [29455.808705] RIP: 0010:[&lt;ffffffff8125b27a&gt;] [&lt;ffffffff8125b27a&gt;] submit_bio+0x33/0xf6 [29455.808753] RSP: 0018:ffff8802ba009b48 EFLAGS: 00010246 [29455.808782] RAX: 0000000000000e11 RBX: ffff8803313e8a88 RCX: 0000000000000400 [29455.808820] RDX: 00000000000000a8 RSI: ffff8803313e8a88 RDI: 0000000000000e11 [29455.808859] RBP: ffff8802ba009b98 R08: 0000000000000000 R09: ffff8803313e8a88 [29455.808896] R10: 0000000000000002 R11: ffff880331002800 R12: ffff88032d592c00 [29455.808935] R13: 0000000000000008 R14: ffff8803313e8a88 R15: 0000000000000400 [29455.808973] FS: 00007fd9074fc700(0000) GS:ffff88033fc00000(0000) knlGS:0000000000000000 [29455.809016] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [29455.809047] CR2: 000000000047efa2 CR3: 00000002fa780000 CR4: 00000000000006f0 [29455.809085] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [29455.809123] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [29455.809161] Process hibernate (pid: 17239, threadinfo ffff8802ba008000, task ffff8802cd871670) [29455.809206] Stack: [29455.809218] ffffffff810ee0ba ffff880331002800 ffff88032d592c00 ffff880331002800 [29455.809264] ffff88032d592c00 0000000000000008 ffff8803313e8a88 ffff880331002800 [29455.809309] ffff88032d592c00 0000000000000008 ffff8802ba009be8 ffffffff81448207 [29455.809354] Call Trace: [29455.809443] [&lt;ffffffff810ee0ba&gt;] ? __lock_page+0x68/0x68 [29455.809475] [&lt;ffffffff81448207&gt;] md_super_write+0x85/0x94 [29455.809506] [&lt;ffffffff814485a1&gt;] md_update_sb+0x306/0x46a [29455.809537] [&lt;ffffffff81078909&gt;] ? abort_exclusive_wait+0x8e/0x8e [29455.809572] [&lt;ffffffff814491db&gt;] __md_stop_writes+0x71/0x75 [29455.809603] [&lt;ffffffff814492fe&gt;] md_notify_reboot+0x54/0xd7 [29455.809636] [&lt;ffffffff8107cd67&gt;] notifier_call_chain+0x37/0x63 [29455.809669] [&lt;ffffffff8107cea2&gt;] __blocking_notifier_call_chain+0x4b/0x60 [29455.809707] [&lt;ffffffff8107cecb&gt;] blocking_notifier_call_chain+0x14/0x16 [29455.809745] [&lt;ffffffff8106e901&gt;] kernel_shutdown_prepare+0x28/0x41 [29455.809780] [&lt;ffffffff8106e92d&gt;] kernel_power_off+0x13/0x4a [29455.809813] [&lt;ffffffff81097e1f&gt;] __toi_power_down+0xec/0x130 [29455.809846] [&lt;ffffffff810980f9&gt;] toi_power_down+0x8b/0x92 [29455.809877] [&lt;ffffffff810a198c&gt;] ? memory_bm_next_pfn+0x10/0x12 [29455.809911] [&lt;ffffffff81091dc6&gt;] ? map_ps2_pages+0x15/0x1c [29455.809942] [&lt;ffffffff810925e3&gt;] do_toi_step+0x5cf/0x6c0 [29455.809971] [&lt;ffffffff810929f6&gt;] toi_try_hibernate+0x102/0x13e [29455.811390] [&lt;ffffffff810911ea&gt;] toi_main_wrapper+0xe/0x10 [29455.812847] [&lt;ffffffff81091404&gt;] toi_attr_store+0x208/0x255 [29455.814323] [&lt;ffffffff8118908c&gt;] sysfs_write_file+0xf4/0x130 [29455.815819] [&lt;ffffffff8112ed1d&gt;] vfs_write+0xb2/0x142 [29455.817332] [&lt;ffffffff8112efa7&gt;] sys_write+0x4a/0x71 [29455.818864] [&lt;ffffffff815a4922&gt;] system_call_fastpath+0x16/0x1b [29455.820416] Code: 53 48 83 ec 38 66 66 66 66 90 48 63 c7 48 89 f3 8b 4e 30 48 0b 46 20 83 3d fb 63 ac 00 00 48 89 46 20 74 09 a9 00 00 00 20 75 02 &lt;0f&gt; 0b 48 85 db 0f 84 a5 00 00 00 48 83 7b 48 00 0f 84 9a 00 00 [29455.824196] RIP [&lt;ffffffff8125b27a&gt;] submit_bio+0x33/0xf6 [29455.826089] RSP &lt;ffff8802ba009b48&gt; [29455.828023] ---[ end trace f92d5dbe423f8fb7 ]--- [29455.829966] Kernel panic - not syncing: Fatal exception [29455.831944] panic occurred, switching back to text console [29455.833944] Rebooting in 5 seconds.. </pre> Nix 2012-04-30T10:29:29 http://permalink.gmane.org/gmane.linux.swsusp.general/10048 <pre>Hi Matt, Matt Price wrote: Yes, you can remove them. The packages in the PPA install their own initramfs scripts and hooks. If it does not work for you, please tell me and I can try to add the necessary script/hook to the packages. Martin </pre> Martin Schläffer 2012-04-29T18:03:17 http://permalink.gmane.org/gmane.linux.swsusp.general/10047 <pre>this is great Martin! I haven't used Tuxonice for quite a while, and I see the PPA now says: In general, you do NOT need to change any configuration file and you do NOT need to install the hibernate package. TuxOnIce automatically determines your swap partition. Just install the 3 packages above and try to supend and resume ("sudo pm-hibernate" in command line). Does this mean I should remove the old tuxonice-resume script &amp; tuxonice-userui hook from /etc/initramfs-tools? in fact I notice /etc/initramfs-tools is now completely empty except for tuxonice-related files I added by hand ages ago -- has it been completely superseded by new mechanisms? thanks! matt </pre> Matt Price 2012-04-29T13:18:20 http://permalink.gmane.org/gmane.linux.swsusp.general/10046 <pre>Hi all, tuxonice is ready for Ubuntu 12.04 (and for many previous versions). Simply add the tuxonice PPA: https://launchpad.net/~tuxonice/+archive/ppa and install the following 3 packages: "tuxonice-userui linux-generic-tuxonice linux-headers-generic-tuxonice" On Ubuntu 12.04 hibernate is disabled by default. Re-enable it as follows: https://help.ubuntu.com/12.04/ubuntu-help/power-hibernate.html It's disabled for the LTS version of Ubuntu, since in-kernel hibernation is not reliable enough. We hope this is much better using TuxOnIce! Martin </pre> Martin Schläffer 2012-04-29T09:47:02 http://permalink.gmane.org/gmane.linux.swsusp.general/10045 <pre>Hi. On 21/04/12 01:17, Damjan wrote: I'm sorry - I thought my script to get updates was working right, but it missed those new versions. I've updated my trees, including doing this merge. Nigel </pre> Nigel Cunningham 2012-04-20T22:17:01 http://permalink.gmane.org/gmane.linux.swsusp.general/10044 <pre> After finding out that other people had the same problem and were not using TOI, it turned out it was a problem in dhclient. For some reason it would decide to clear the hostname (the scumbag). Switching to dhcpcd fixed the problem. -- дамјан _______________________________________________ TuxOnIce-users mailing list TuxOnIce-users&lt; at &gt;lists.tuxonice.net http://lists.tuxonice.net/listinfo/tuxonice-users</pre> Damjan 2012-04-20T15:23:56 http://permalink.gmane.org/gmane.linux.swsusp.general/10043 <pre>Has anyone succeeded in merging the latest 3.3.2 release with the 3.3 branch of tuxonice-kernel? I get conflicts in kernel/power/user.c kernel/kmod.c which I'm not entirely sure how to fix. I'm trying to merge two git branches, if that matters. Haven't tried patches. </pre> Damjan 2012-04-20T15:17:56 http://permalink.gmane.org/gmane.linux.swsusp.general/10042 <pre> Thanks for the hint. I've reordered things in the argument parsing too and now it works. Here's the patch: http://paste.pocoo.org/show/579479/ I also had to comment out that "active_ops = NULL" since handle_params(argc, argv) was setting it. But, I can't understand the logic when setting next_ops in common_keypress_handler() and then what does might_switch_ops() do??? Shouldn't common_keypress_handler() call switch_active_ops() directly? </pre> Damjan 2012-04-11T12:35:17 http://permalink.gmane.org/gmane.linux.swsusp.general/10041 <pre> The new tuxoniceui doesn't have two binaries for _text and _fbsplash. It's all in one /usr/sbin/tuxoniceui I do add the "-f" argument to enable the fb splash, and I can confirm it after resume in /sys/power/tuxonice/user_interface/program Also, when I run the test with "tuxonice -f -t" the graphical splash doesn't show. </pre> Damjan 2012-04-11T11:53:24 http://permalink.gmane.org/gmane.linux.swsusp.general/10040 <pre>Check your common.conf There should be a line like this: ProcSetting userui_program /usr/local/sbin/tuxonice_fbsplash ( or wherever your tuxonice_fbsplash is located ) when I want to switch from graphical to text splash I change this line with : ProcSetting userui_program /usr/local/sbin/tuxoniceui_text ( or wherever your tuxoniceui_text is located ) and I go text Pierluigi On Wednesday 11 April 2012, Frédéric Boiteux wrote: _______________________________________________ TuxOnIce-users mailing list TuxOnIce-users&lt; at &gt;lists.tuxonice.net http://lists.tuxonice.net/listinfo/tuxonice-users</pre> Pierluigi Frullani 2012-04-11T11:42:56 http://permalink.gmane.org/gmane.linux.swsusp.general/10039 <pre>https://github.com/NigelCunningham/Tuxonice-Userui/issues/4 </pre> Andrey Rahmatullin 2012-04-11T11:38:57 http://permalink.gmane.org/gmane.linux.swsusp.general/10038 <pre>Le mer. 21 mars 2012 21:08:01 CET, Damjan &lt;gdamjan&lt; at &gt;gmail.com&gt; a écrit : I've tried it also, and found a small bug about fbsplash, but didn't find time to show it... You should look at fbsplash selection, I remember it's an error with a table index... Fred. _______________________________________________ TuxOnIce-users mailing list TuxOnIce-users&lt; at &gt;lists.tuxonice.net http://lists.tuxonice.net/listinfo/tuxonice-users</pre> Frédéric Boiteux 2012-04-11T11:21:47 http://permalink.gmane.org/gmane.linux.swsusp.general/10037 <pre>Thanks man nice to hear that. Best regards </pre> TheSkullBurner 2012-04-11T05:39:27 http://permalink.gmane.org/gmane.linux.swsusp.general/10036 <pre>Hi. On 11/04/12 10:49, SkullBurner wrote: Thanks for the report; I'm looking into another bug at the moment, and will look into this next, Lord willing. Regards, Nigel </pre> Nigel Cunningham 2012-04-11T01:53:38 http://permalink.gmane.org/gmane.linux.swsusp.general/10035 <pre>Hello, I have now tested hibernation with tuxonice kernels versions 3.0.0-15 and 3.0.0-11 and both behave same as the newest tuxonice kernel version. Tuxonice kernel version 3.0.0-11 was the earliest version I could get from the tuxonice ppa. It seems that this problem is existing in all available tuxonice kernels from the series 3.0.0. Perhaps someone more knowledgeable of tuxonice hibernation implementation should compare the tuxonice modification and kernel stock hibernation method because with stock kernel hibernation method dead ACPI events as I described don't happen. If there is something else I could do to help to find a solution please let me know. Best regards! Am 10.04.2012 09:55, schrieb Martin Schläffer: </pre> SkullBurner 2012-04-10T22:49:21 http://permalink.gmane.org/gmane.linux.swsusp.general/10034 <pre>Hi, I just tried tuxonice kernel version 3.0.0-16 and effects are same as with version 3.0.0-17. best regards! Am 10.04.2012 09:55, schrieb Martin Schläffer: </pre> SkullBurner 2012-04-10T18:54:34 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.swsusp.general