Linux에서 Suspend-to-RAM 문제를 어떻게 디버깅 할 수 있습니까?

15

RAM 일시 중단 문제를 디버깅하는 방법에 대한 경험 기반 제안을 얻고 싶습니다. 내 상황 (아래에 자세히 설명)에 대한 조언은 훌륭하지만 그러한 문제를 디버깅하는 방법에 대한 일반적인 조언에도 관심이 있습니다.

문제 :

종종 컴퓨터를 일시 중지하려고하면 "일시 중지되지 않았지만 깨어나지 않는"상태에 빠지게됩니다. 종종 화면이 완전히 검지 만 때때로 다음과 같은 오류 메시지가 나타납니다.

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

linux debugging suspend

— 스티븐 D
소스

1

여기에 언급 된 특정 버그에 물린 것으로 생각되면 "나도"답변을 올리지 마십시오. 실제로 답변이 아닙니다. 다른 사람이 답변하도록 장려하기 위해이 질문을 자유롭게 올리십시오. 결국 좋은 대답은이 특정 문제를 해결하기위한 조언뿐만 아니라 이러한 유형의 문제를 디버깅하기위한 조언을 제공합니다.

— Steven D

교사 라운지에서 설명을 삭제 한 후 삭제되었습니다. 잠재적으로 유일하게 유용한 정보는 No LSB modules are available.바로 뒤에 표시됩니다 lsb_release -a.

— Maciej Piechotka

나는 "나를 위해 일했다"라는 답변을 표시했지만 여전히 일반적인 "램 일시 중단을 디버그하는 방법"답변이 도움이 될 것이라고 생각합니다.

— Steven D

3

인텔 그래픽 칩셋이 있습니까? Ubuntu 10.10을 실행하는 ThinkPad X200에서 동일한 문제가 발생하는 문제가 발생했으며이 해결 방법 (2008 년부터)으로 해결되었습니다. http://ubuntuforums.org/showpost.php?p=6105510&postcount=12

— 잔디밭
소스

6

PM_DEBUG 및 PM_TRACE 는 현재 가장 깊은 디버깅 기능입니다. 더 높은 수준의 로그에서 아무런 의미가없는 경우 AFAIK는 "이력서에 신비한 빈 화면"증상이 나타날 때 다시 사용되는 유일한 메커니즘입니다. 가장 자주 우리는 매우 미묘하게 깨진 장치 드라이버를 처리합니다. 커널 개발자들이 제안하고 찾는 것에 대한 커널 버그 34682에서 Broadcom brcmsmac 무선 드라이버 디버깅 사가를 살펴볼 수도 있습니다.

— 크라 크라브
소스

1

BIOS가 실제로 사용하는 저용량을 올바르게보고하지 않아서 문제가 발생할 수 있다는 의혹이 있습니다.

기본적으로이 옵션은 다음과 같습니다.

memory_corruption_check_size=64K

메모리 손상 스캐너가 더 큰 lowmem 덩어리를 검사하도록이 값을 더 큰 값으로 설정할 수 있습니다.

에서 "memory_corruption_check_size"를 찾으십시오.

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

기타

나는 당신이 무엇을 발견하는지 알고 싶어합니다.

0

이 분야에서 일한 경험은 Linux가 아닌 Windows CE에있었습니다.

일시 중지 / 다시 시작주기 동안 OS는 OS 기능을 점차 종료하여 OS 기능 사용에 대한 정확한 정보를 얻을 수있는 기능을 제한합니다. 또한 모니터링 연결 (예 : 문제가 타이밍과 관련된 경우)로 결과가 변경 될 수 있습니다.

선호 도구는 하이 엔드에서 OS에 대한 C / C ++ 디버거 연결 및 매우 낮은 레벨에서 직렬 포트 / POST 코드 또는 비 X86 하드웨어 JTAG 디버거 또는 이와 동등한 것으로 데이터를 보내는 것으로 시작됩니다. 결과적으로 코드 흐름을 해결하고 정상적인 동작과 다르게 동작하는 지점을 찾는 데 오랜 시간이 걸립니다. 이 시점에서 수정은 일반적으로 분명합니다. 좋은 메모를하고 한 번에 하나씩 변경하십시오.

Windows CE의 전원 문제를 확인하는 데 6 주가 걸렸습니다. 우리는 10 초 또는 60 초 동안 전원을 끄고 아무런 문제없이 전원을 켤 수있는 PC104 프로세서 보드를 가지고있었습니다. 그러나 전원이 25 초 동안 제거 된 경우 전원이 켜지지 않습니다. 약 20 초 동안 DRAM 내용을 전원없이 그대로 유지하기에 충분한 정전 용량이있는 것으로 나타났습니다. 따라서 짧은 전원 끄기주기에서 Windows CE는 일시 중단 상태에서 다시 시작되었다고 생각했습니다. 모든 메모리가 보존되면 실제로 재개를 수행하는 데 성공하고 메모리가 부분적으로 손상되면 재개 중에 다소 혼동됩니다.

행운을 빕니다.

— 마이클 쇼
소스