From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KYdeh-0000IX-N8 for garchives@archives.gentoo.org; Thu, 28 Aug 2008 09:19:03 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3CEACE01B9; Thu, 28 Aug 2008 09:19:02 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by pigeon.gentoo.org (Postfix) with ESMTP id DF156E01B9 for ; Thu, 28 Aug 2008 09:19:01 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KYdea-0007vZ-KA for gentoo-amd64@lists.gentoo.org; Thu, 28 Aug 2008 09:18:56 +0000 Received: from ip68-231-12-43.ph.ph.cox.net ([68.231.12.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Aug 2008 09:18:56 +0000 Received: from 1i5t5.duncan by ip68-231-12-43.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Aug 2008 09:18:56 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Hibernate-ram Date: Thu, 28 Aug 2008 09:18:44 +0000 (UTC) Message-ID: References: <48B5E9CB.4050608@gmx.net> <3aa654a40808271947v183adf76lc84264f945588171@mail.gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-12-43.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: d9219618-9c31-4dc3-a4df-fc49ca752120 X-Archives-Hash: 6e90839443ca8ab842cbd55bb748c20c "Avuton Olrich" posted 3aa654a40808271947v183adf76lc84264f945588171@mail.gmail.com, excerpted below, on Wed, 27 Aug 2008 19:47:45 -0700: > On Wed, Aug 27, 2008 at 4:56 PM, Sebastian Geiger > wrote: >> I just upgraded to 2.6.26 and if I enter hibernate-ram the system >> suspends but never wakes up again untill I do a cold reboot. Are there >> any known issues currently with this Kernel version? I am using the >> 2.6.26 tuxonice-sources and the latest hibernate script on amd64. >=20 > ACPI on linux is probably the most undependable things about the system= . > That being said, I've had much luck getting 'suspend to disk', aka > hibernate, to work over 'suspend to ram', also known as sleep. >=20 > Best of luck, but suspend to ram working is like expecting all the > planets to align with the sun. Each driver for each chip in your > computer must be ready for it, or it's not happening. ... And the kernel devs will say the same thing. They /are/ trying, and=20 things /are/ generally improving gradually in that area, but it's well=20 known that suspend to disk is /much/ more likely to work than suspend to=20 RAM. One thing you might try if you haven't already... X and video drivers=20 throw in a /lot/ more complexity. Many people find that suspend (of=20 either form) works MUCH better if they switch to a console before=20 suspending (leaving X running). If that works fine returning you to a=20 console but switching back to X afterward does /not/ work, try shutting X= =20 down entirely before suspending. That may work. Beyond that, you can try unloading all non-critical modules and reloading= =20 them after you resume. After you find a combination that works, you can of course script it, so=20 it all happens automatically. That said, if it was working with older kernels it'll be considered a=20 regression and the kernel folks are likely to be very interested in it,=20 particularly if you have time to file a kernel bug and do some follow-up=20 for them as they ask you to. I've had several bugs that I filed fixed,=20 but then I usually start running the -rcs (or trying to run them, anyway)= =20 around -rc3 or so, and if I see a problem and it's not fixed by -rc4 or - rc5, I'll bug it, and so far, they've always had it fixed before the full= =20 release version. But it /can/ take rebuilding the kernel a few times,=20 often with debug-logging patches applied so they can find out what's=20 going on. Another common techique is "bisecting", that is, taking the=20 last known working version and the first known trouble version and=20 testing an rc about in the middle, thus cutting the problem space in=20 half, then one in the middle of that, etc, until you nail the bad rc,=20 then doing the same thing with the daily snapshots between the last good=20 rc and the first bad one, until you get the culprit day. Often given the= =20 problem they can nail it once they know the day, but you can go farther=20 if you want to using git to bisect the day's patches until you find the=20 exact patch. (Or, do as I sometimes do and bisect the kernel sources=20 directory by directory and file by file until I find the file, then diff=20 the files and narrow it down to a specific changed line or set of lines,=20 tho that doesn't always work once you get beyond the file level since=20 often the changes are dependent on one another.) I may not be a coder, and I'm DEFINITELY not a kernel hacker, but I can=20 file and help trace down bugs as I see 'em, thereby contributing my=20 little bit to an improved Linux! =3D8^) --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman