Як я можу налагоджувати проблему Suspend-to-RAM в Linux?

Я сподіваюся отримати на основі досвіду пропозиції щодо вирішення проблеми налагодження призупинення роботи оперативної пам’яті. Поради, характерні для моєї ситуації (детальніше нижче), були б чудовими, але мене також цікавлять загальні поради щодо налагодження таких питань.

Проблема:

Часто, коли я намагаюся призупинити свою машину, вона застрягає у стані "не припинено, але не прокидається". Часто екран буде повністю чорним, але іноді на ньому з’явиться таке повідомлення про помилку:

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

Також цей стан також буде супроводжувати вентилятори, що б'ють у високу передачу. Єдиний спосіб вивести його з цього стану - це вручну вимкнути ноутбук.

Деяка інформація

$ 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

Я подивився /var/log/dmesgі /var/log/pm-suspend.log, але не знаю, що шукаю, і нічого не виділяється. Я не впевнений, що це пов’язано, але я знайшов багато наступного в /var/log/kern.log:

EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro,commit=600

Чи маєте графічний чіпсет Intel? Я отримував те, що схоже на ту ж проблему в моєму ThinkPad X200s під керуванням Ubuntu 10.10, і це вирішення (з 2008 року!) Вирішило для мене: http://ubuntuforums.org/showpost.php?p=6105510&postcount=12

PM_DEBUG та PM_TRACE - це, очевидно, найглибші засоби налагодження, які зараз є. Коли ви не отримуєте нічого значущого з журналів вищого рівня, AFAIK - це єдиний механізм, на який можна відмовитися, стикаючись з жахливим симптомом «таємничий порожній екран під час відновлення». Найчастіше ми маємо справу з, досить часто тонко, зламаним драйвером пристрою. Ви також можете поглянути на мою сагу про налагодження бездротового драйвера Broadcom brcmsmac на базі ядра 34682 щодо того, що пропонують розробники ядра та шукати.

У мене є підозри, що проблема може бути пов’язана з тим, що BIOS неправильно повідомляє про те, який низький вміст він реально використовує.

За замовчуванням ця опція діє:

memory_corruption_check_size=64K

Ви можете спробувати встановити це на більші значення, щоб змусити сканер пошкодження пам’яті вивчити більший шматок lowmem.

Шукайте "memory_corrup_check_size" в

• http://lxr.linux.no/#linux+v2.6.35.7/Documentation/kernel-parameters.txt

тощо.

Мені було б цікаво дізнатися, що ти знайдеш, якщо що.

Мій досвід роботи в цій галузі був в Windows CE, а не в Linux.

Під час циклу призупинення / відновлення ОС буде поступово вимикати функціональність ОС, обмежуючи вашу можливість отримувати точну надійну інформацію про те, що відбувається за допомогою функціональності ОС. Крім того, ваше моніторингове підключення може (наприклад, якщо проблема пов’язана з тимчасовим часом), змінити результат.

Інструменти уподобань починаються з підключення налагоджувача C / C ++ до ОС на найвищому рівні, а на самому низькому рівні надсилають дані через послідовний порт / Коди POST або на апаратний відладчик JTAG або еквіваленти, не апаратні X86. Кінцевим результатом є довгі години відпрацювання потоку коду та пошуку точки, коли він поводиться інакше, ніж звичайна поведінка. У цей момент виправлення, як правило, очевидно. Зберігайте хороші замітки та вносіть зміни по черзі.

Минуло 6 тижнів, щоб визначити проблему з живленням у нас із Windows CE. У нас була процесорна плата PC104, яку ми могли вимкнути на 10 або 60 секунд і живити без проблем. Однак якщо живлення було відключено протягом 25 секунд, воно не вимкнеться. Виявилось, що у нас було достатньо ємності, щоб вміст DRAM був недоторканим без енергії протягом 20 секунд, тому на короткий цикл відключення живлення Windows CE вважав, що він відновлений з призупиненого стану. Коли вся пам'ять збереглась, вона фактично вдалася б виконати резюме, коли пам’ять була частково пошкоджена, вона досить заплуталася під час резюме.

Удачі.