Linux'ta RAM'i Askıya Al sorununu nasıl ayıklayabilirim?

RAM askıya alma sorununu nasıl ayıklayacağınız konusunda deneyime dayalı öneriler almayı umuyorum. Durumuma özel tavsiyeler (aşağıda ayrıntılı olarak açıklanmıştır) harika olurdu, ancak aynı zamanda bu tür sorunların nasıl ayıklanacağı hakkında genel tavsiyelerle ilgileniyorum.

Sorun:

Genellikle, makinemi askıya almaya çalıştığımda, "askıya alınmamış, ancak uyanık değil" durumunda sıkışır. Genellikle ekran tamamen siyah olacaktır, ancak bazen üzerinde aşağıdaki hata mesajı olacaktır:

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

Ayrıca, bu duruma yüksek teçhizata giren fanlar da eşlik edecek. Bu durumdan kurtulmanın tek yolu dizüstü bilgisayarı manuel olarak kapatmaktır.

Biraz bilgi

$ 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

Baktım /var/log/dmesgve /var/log/pm-suspend.logne aradığımı bilmiyorum ve hiçbir şey göze çarpmıyor. İlişkili olup olmadığından emin değilim, ancak aşağıdakilerin çoğunu buldum /var/log/kern.log:

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

Intel grafik yongasetiniz var mı? Ubuntu 10.10 çalıştıran ThinkPad X200'lerimde aynı soruna benziyordu ve bu geçici çözüm (2008'den itibaren!) Benim için düzeltti: http://ubuntuforums.org/showpost.php?p=6105510&postcount=12

PM_DEBUG ve PM_TRACE , şu anda var olan en derin hata ayıklama tesisleridir. Üst düzey günlüklerden anlamlı bir şey elde edemediğinizde, AFAIK bu korkunç "özgeçmişte gizemli boş ekran" belirtisiyle karşılaştığında geri çekilecek tek mekanizmadır. Çoğu zaman, oldukça ince bir şekilde kırık bir aygıt sürücüsü ile uğraşırız. Ayrıca, çekirdek geliştiricilerinin önerdiği ve aradığı şey için çekirdek hata 34682'deki Broadcom brcmsmac kablosuz sürücü hata ayıklama destanına da göz atabilirsiniz .

Sorunun, BIOS'un gerçekten hangi lowmem'i kullandığını doğru bir şekilde bildirmemesinden kaynaklanabileceğinden şüphelerim var.

Varsayılan olarak bu seçenek geçerlidir:

memory_corruption_check_size=64K

Bellek bozulması tarayıcının daha büyük bir lowmem yığınını incelemesi için bunu daha büyük değerlere ayarlamayı deneyebilirsiniz.

İçinde "memory_corruption_check_size" ifadesini arayın

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

vb.

Ne bulduğunuzu bilmek isterim, eğer bir şey varsa.

Bu alanda çalışma deneyimim Linux yerine Windows CE'ydi.

Askıya alma / devam ettirme döngüsü sırasında işletim sistemi, işletim sistemi işlevini kullanarak neler olup bittiğine dair doğru güvenilir bilgi alma yeteneğinizi kısıtlayan işletim sistemi işlevini aşamalı olarak kapatır. Ayrıca, izleme bağlantınız (örneğin, sorun zamanlamayla ilgili ise) sonucu değiştirebilir.

Tercih edilen araçlar, yüksek uçta işletim sistemine bir C / C ++ hata ayıklayıcı bağlantısıyla başlar ve çok düşük seviyede uçta bir seri bağlantı noktası / POST Kodları veya X86 olmayan donanım JTAG hata ayıklayıcısı veya eşdeğerleri üzerinden veri gönderilir. Sonuç, kod akışını çözmek ve normal davranıştan farklı davrandığı noktayı bulmak için uzun saatler. Bu noktada, düzeltme genellikle açıktır. İyi notlar alın ve her seferinde bir değişiklik yapın.

Windows CE ile ilgili güç sorunumuzu belirlemek 6 hafta sürdü. 10 veya 60 saniye boyunca kapatıp sorunsuz bir şekilde çalıştırabileceğimiz bir PC104 işlemci kartımız vardı. Ancak güç 25 saniye boyunca kesilirse açılmaz. DRAM içeriklerini yaklaşık 20 saniye boyunca güç olmadan sağlam tutmak için yeterli kapasiteye sahip olduğumuz ortaya çıktı, bu nedenle kısa bir kapatma döngüsünde Windows CE, askıya alınmış bir durumdan devam ettiğini düşündü. Tüm bellek korunduğunda, aslında bir özgeçmiş gerçekleştirmeyi başarabilir, bellek kısmen bozulduğunda, özgeçmiş sırasında oldukça karışık olur.

İyi şanslar.