15

I'm hoping to get experience-based suggestions on how to go about debugging suspend-to-RAM issue. Advice specific to my situation(detailed below) would be great, but I am also interested in general advice about how to debug such issues.

The problem:

Often, when I attempt to suspend my machine, it gets stuck in a "not suspended but not awake" state. Often the screen will be completely black but sometimes it will have the following error message on it:

GLib-WARNING **: getpwuid_r(): failed due to unknown user id (0)

Also, this state will also be accompanied by the fans kicking into high gear. The only way to get it out of this state is to manually power off the laptop.

Some Information

$ uname -a
Linux baltar 2.6.35-22-generic #34-Ubuntu SMP Sun Oct 10 09:26:05 UTC 2010 x86_64 GNU/Linux

$ lsb_release -a
Distributor ID:    Ubuntu
Description:    Ubuntu 10.10
Release:    10.10
Codename:    maverick

I've taken a look at /var/log/dmesg and /var/log/pm-suspend.log, but I don't know what I'm looking for and nothing stands out. I'm unsure if it is related, but I did find a lot of the following in /var/log/kern.log:

EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro,commit=600
Improve this question
3
  • 1
    If you believe you are being bitten by the specific bug I mention here, please do not post a "me too" answer--since it really isn't an answer. Feel free to upvote this question to encourage others to respond to it. In the end, a good answer would provide not only advice to solve this particular problem, but advice for debugging these types of issues.
    – Steven D
    Oct 25, 2010 at 19:12
  • Deleted after clarification on Teachers' Lounge. The only potentially valuable informations is No LSB modules are available. displayed just after lsb_release -a.
    – Maciej Piechotka
    Oct 26, 2010 at 22:01
  • I've marked a "worked for me" answer, but I still think a more general "how to debug suspend-to-ram" answer would be really helpful here.
    – Steven D
    Nov 22, 2010 at 18:50

5 Answers 5

Reset to default
6

PM_DEBUG and PM_TRACE are apparently the deepest debugging facilities there are right now. When you're getting nothing meaningful from higher level logs, AFAIK this is the only mechanism to fall back on when encountering the dreaded "mysterious blank screen on resume" symptom. Most often we're dealing with a, quite often subtly, broken device driver. You can also take a look at my Broadcom brcmsmac wireless driver debugging saga at kernel bug 34682 for what kernel developers suggest and look for.

Improve this answer
3

Do you have an Intel graphics chipset? I was getting what sounds like the same problem on my ThinkPad X200s running Ubuntu 10.10, and this workaround (from 2008!) fixed it for me: http://ubuntuforums.org/showpost.php?p=6105510&postcount=12

Improve this answer
0
1

I have suspicions that the issue may be due to the BIOS not correctly reporting on what lowmem it really uses.

By default this option is in effect:

memory_corruption_check_size=64K

You can try setting that to larger values to make the memory corruption scanner examine a larger chunk of lowmem.

Look for "memory_corruption_check_size" in

etc.

I'd be interested in knowing what you find, if anything.

Improve this answer
0

My experience in working in this area was in Windows CE, rather than Linux.

During the suspend /resume cycle, the OS will progressively shut down OS functionality restricting your ability to get accurate dependable information on what is going on using OS functionality. In addition, your monitoring connection can (e.g. if the issue is timing related) alter the outcome.

Tools of preference start with a C/C++ debugger connection to the OS at the high end, and at the very low level end sending data down a serial port / POST Codes or on non X86 hardware JTAG debugger or equivalents. The end result is long hours working out the code flow and finding the point when it behaves differently from normal behaviour. At that point, the fix is usually obvious. Keep good notes, and make one change at a time.

It took 6 weeks to identify the power up problem we had with Windows CE. We had a PC104 processor board that we could power off for 10 or 60 seconds and power up with no problems. However if power was removed for 25 seconds, it would not power up. It turned out that we had enough capacitance to keep the DRAM contents intact with no power for around 20 seconds, so on a short power off cycle, Windows CE thought it was resuming from a suspended state. When all the memory was preserved, it would actually succeed performing a resume, when the memory was partially corrupt, it would get rather confused during the resume.

Good luck.

Improve this answer
0

For anyone still struggling with suspend on a macbook here's a solution that worked for me: https://forums.debian.net/viewtopic.php?t=149965

More precisely:

1. open terminal: sudo nano /etc/default/grub
2. go to: GRUB_CMDLINE_LINUX="" and add/change to: GRUB_CMDLINE_LINUX="init_on_alloc=0"
3. save and exit
4. sudo update-grub
5. reboot pc
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .