> So you got hibernate working now with pm-utils*and* the prop. Nvidia > drivers. That's good - although a bit contrary to what you said in > Comment 29: > I was told so, long time ago struggling to get nvidia prop to resume from hibernation, I found out that uswsusp was better for it (googling or on irc), and it indeed worked better, or with less effort at least, back then. I made that comment thinking this was true but I just proved myself wrong...
> till puzzles me is that while others are having problems, > suspend-utils/uswsusp work for me almost 100 % of the time, except for a > few extreme test-cases in the past. You also said that it worked > "flawlessly" for yo Yes! It worked pretty good on version 18.04.1 of ubuntu with kernel 4.15.0-42 and 41 using uswsusp. There was a long problem with nvidia props that wouldn't let the system resume, but this was fixed when I upgraded to the latest version of the 415 nvidia driver. I kept like one month just hibernating to switch to windows and coming back to the restored snapshot of linux. You can check my apt history here: https://launchpadlibrarian.net/415602746/aptHistory.log. At the Start-Date: 2019-02-02 15:40:45, I'm 100% sure it was perfect. I am 100% sure that it wasn't already working anymore having the s2disk freeze issue at Start-Date: 2019-03-05 10:38:4. uswsusp also worked fine on ubuntu 16.04, but I dont remember the kernel versions. Now I'm currently with the nvidia 418.56, ubuntu 18.04.2, kernel 4.18.0-17-generic and hibernation with pm-utils works. I haven't found any major problem with it besides failing to suspend to ram yesterday, which I don't know if is related to it or not, but today I tested it after and before hibernation and seems to be ok. > So I'm wondering whether used-up swap space might play a role in this > matter, too. At least for the cases that I've seen on my system, I can't > rule this out. And when I look at the screenshot you provided in Comment > 27 (https://launchpadlibrarian.net/417327528/i915.jpg), sparse > swap-space could have been a factor in that case as well. Because > roughly 3.5 GB free swap-space doesn't seem much for a 16-GB-RAM box. On my many tests with uswsusp and a 16gb swap partition and 16 gb of ram, I noticed that it would be less likely to fail when less than something about 2 gb of ram, like just after boot up, it would though after the 3rd or 4th followed hibernation cycle. If after the boot up I allocate more than that value if would be much more likely to happen like always on the 2nd attempt, and if more than around 6gb would fail on the first attempt. Those aren't sure values, sometimes it failed regardless of ram usage, specially on my latest tests. also once it hibernated with more than 11gb ram usage and failed on the second attempt. So this is all happening pretty randomly. What I described above is just most of the cases and maybe this is just random anyway. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1328727 Title: [Asus 1000HE] s2disk/hibernate hangs during saving of image data Status in Linux: Confirmed Status in linux package in Ubuntu: Triaged Bug description: Hibernation with the pm-hibernate command works fine on a freshly booted system, but when a significant portion of the RAM is in use, for instance by starting gimp, google-chrome and firefox at the same time, it stalls at the start of the saving of the image data: s2disk: Snapshotting system s2disk: System snapshot ready. Preparing to write s2disk: Image size: 441652 kilobytes s2disk: Free swap: 1798624 kilobytes s2disk: Saving 110413 image data pages (press backspace to abort) ... 0% The system is not usable at this point, although alt-sysrq still works. It looks like some sort of deadlock. The system is an Asus eeePC 1000HE with 2GB RAM and a 2GB swap partition and a Samsung SSD 840 EVO. The Ubuntu release is 14.04 LTS. The kernel package is linux-image-3.13.0-27-generic version 3.13.0-27.50 (32 bit). I found a kernel bug report that looks exactly the same: https://bugzilla.kernel.org/show_bug.cgi?id=75101 In that bug report, the problem was bisected to commit a1c3bfb2. This commit is part of the 3.14 kernel, but was apparently backported to the 3.13 Ubuntu kernel. I've rebuild the kernel package with this commit reverted, and it seems to fix this issue for me. --- ApportVersion: 2.14.1-0ubuntu3.2 Architecture: i386 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: dick 1719 F.... pulseaudio CurrentDesktop: Unity DistroRelease: Ubuntu 14.04 HibernationDevice: RESUME=UUID=c6b78f80-b4a1-4b1a-91b4-8ae5c41b36f4 InstallationDate: Installed on 2013-04-28 (408 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release i386 (20130424) MachineType: ASUSTeK Computer INC. 1000HE Package: linux (not installed) ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-27-generic root=UUID=54684f57-2a33-403f-ae4d-ad6b3d0168ea ro acpi_osi=Linux acpi_backlight=vendor quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 3.13.0-27.50hib-generic 3.13.11 RelatedPackageVersions: linux-restricted-modules-3.13.0-27-generic N/A linux-backports-modules-3.13.0-27-generic N/A linux-firmware 1.127.2 Tags: trusty Uname: Linux 3.13.0-27-generic i686 UpgradeStatus: Upgraded to trusty on 2014-04-26 (45 days ago) UserGroups: adm cdrom dialout dip fuse lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 06/24/2009 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 0902 dmi.board.asset.tag: To Be Filled By O.E.M. dmi.board.name: 1000HE dmi.board.vendor: ASUSTeK Computer INC. dmi.board.version: x.xx dmi.chassis.asset.tag: 0x00000000 dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTek Computer INC. dmi.chassis.version: x.x dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0902:bd06/24/2009:svnASUSTeKComputerINC.:pn1000HE:pvrx.x:rvnASUSTeKComputerINC.:rn1000HE:rvrx.xx:cvnASUSTekComputerINC.:ct10:cvrx.x: dmi.product.name: 1000HE dmi.product.version: x.x dmi.sys.vendor: ASUSTeK Computer INC. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1328727/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
