1 |
"Avuton Olrich" <avuton@×××××.com> posted |
2 |
3aa654a40808271947v183adf76lc84264f945588171@××××××××××.com, excerpted |
3 |
below, on Wed, 27 Aug 2008 19:47:45 -0700: |
4 |
|
5 |
> On Wed, Aug 27, 2008 at 4:56 PM, Sebastian Geiger <sbastig@×××.net> |
6 |
> wrote: |
7 |
>> I just upgraded to 2.6.26 and if I enter hibernate-ram the system |
8 |
>> suspends but never wakes up again untill I do a cold reboot. Are there |
9 |
>> any known issues currently with this Kernel version? I am using the |
10 |
>> 2.6.26 tuxonice-sources and the latest hibernate script on amd64. |
11 |
> |
12 |
> ACPI on linux is probably the most undependable things about the system. |
13 |
> That being said, I've had much luck getting 'suspend to disk', aka |
14 |
> hibernate, to work over 'suspend to ram', also known as sleep. |
15 |
> |
16 |
> Best of luck, but suspend to ram working is like expecting all the |
17 |
> planets to align with the sun. Each driver for each chip in your |
18 |
> computer must be ready for it, or it's not happening. |
19 |
|
20 |
... And the kernel devs will say the same thing. They /are/ trying, and |
21 |
things /are/ generally improving gradually in that area, but it's well |
22 |
known that suspend to disk is /much/ more likely to work than suspend to |
23 |
RAM. |
24 |
|
25 |
One thing you might try if you haven't already... X and video drivers |
26 |
throw in a /lot/ more complexity. Many people find that suspend (of |
27 |
either form) works MUCH better if they switch to a console before |
28 |
suspending (leaving X running). If that works fine returning you to a |
29 |
console but switching back to X afterward does /not/ work, try shutting X |
30 |
down entirely before suspending. That may work. |
31 |
|
32 |
Beyond that, you can try unloading all non-critical modules and reloading |
33 |
them after you resume. |
34 |
|
35 |
After you find a combination that works, you can of course script it, so |
36 |
it all happens automatically. |
37 |
|
38 |
That said, if it was working with older kernels it'll be considered a |
39 |
regression and the kernel folks are likely to be very interested in it, |
40 |
particularly if you have time to file a kernel bug and do some follow-up |
41 |
for them as they ask you to. I've had several bugs that I filed fixed, |
42 |
but then I usually start running the -rcs (or trying to run them, anyway) |
43 |
around -rc3 or so, and if I see a problem and it's not fixed by -rc4 or - |
44 |
rc5, I'll bug it, and so far, they've always had it fixed before the full |
45 |
release version. But it /can/ take rebuilding the kernel a few times, |
46 |
often with debug-logging patches applied so they can find out what's |
47 |
going on. Another common techique is "bisecting", that is, taking the |
48 |
last known working version and the first known trouble version and |
49 |
testing an rc about in the middle, thus cutting the problem space in |
50 |
half, then one in the middle of that, etc, until you nail the bad rc, |
51 |
then doing the same thing with the daily snapshots between the last good |
52 |
rc and the first bad one, until you get the culprit day. Often given the |
53 |
problem they can nail it once they know the day, but you can go farther |
54 |
if you want to using git to bisect the day's patches until you find the |
55 |
exact patch. (Or, do as I sometimes do and bisect the kernel sources |
56 |
directory by directory and file by file until I find the file, then diff |
57 |
the files and narrow it down to a specific changed line or set of lines, |
58 |
tho that doesn't always work once you get beyond the file level since |
59 |
often the changes are dependent on one another.) |
60 |
|
61 |
I may not be a coder, and I'm DEFINITELY not a kernel hacker, but I can |
62 |
file and help trace down bugs as I see 'em, thereby contributing my |
63 |
little bit to an improved Linux! =8^) |
64 |
|
65 |
-- |
66 |
Duncan - List replies preferred. No HTML msgs. |
67 |
"Every nonfree program has a lord, a master -- |
68 |
and if you use the program, he is your master." Richard Stallman |