Dotaz: Fedora 14, Hibrnate funguje, suspend se neprobudi.

[debil]

Ahoj,

Titulek asi mluvi za vse. Neco o prostredi: Laptop: MSI S271, 2GB RAM CPU Sempron 3500+ System Fedora 14 Linux nocouz 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux Grafika 01:05.0 VGA compatible controller: ATI Technologies Inc RS482 [Radeon Xpress 200M]

Driver GK je 'radeon'.

Kdyz spustim hibernate, tak se vse ulozi&uspi, kdyz zapnu laptop, vse se nacte a vse jde pouzivat. Hibernate mohu spustit z GUI, pm-hibernate nebo jen echo disk>/sys/power/state - vzdy vse funguje bez problemu.

Kdyz spustim suspen (tedy S3 suspend to ram), vse vypada, jako uspesny suspend, laptop se vypne a zustane blikat indikator uspani. Kdyz stisknu "resume" tlacitko (v mem pripade je to Power talcitko), tak zblika HD led (spolecne s ni i CD mechanika) blikne zvlastne display a pak nic. CAPS/NUM lock mrtve, sit mrtva, do laptopu se nelze dostat. Prosel jsem vsemozne Suspend/hiberate debugging co jsem na netu nasel (s pm_trace a pm_test jsem kamarad) a stale nic.

V ruznych dokumentech po web jsem vycetl, ze hibernate je slozitejsi a kdyz funguje hibernate, suspend musi fungovat take, coz je v protikladu s mym stavem.

Jeste nakonec poznamka: Drive mi na tom samem HW s Fedora12 suspend i hibernate fungpvalo na 100%. Vse slo do kytek az po instalaci F14.

A ted k dotazu: Mam podezreni, ze se to pri resume zasekne z nejakeho duvodu v BIOSu. Je mozne, aby se pouhou preinstalaci linuxu (F12=>F14 z liveusb) zmenil BIOS nebo nejaka jeho konfigurace, ktera by mohla vyse popsany problem zpusobovat? Jinak protoze je to laptop, tak v nastaveni BIOSu moc moznosti nastaveni neni.

Odpovědi

[michich]

Prosel jsem vsemozne Suspend/hiberate debugging co jsem na netu nasel (s pm_trace a pm_test jsem kamarad) a stale nic.

Tzn. že po zapnutí pm_trace, uspání, neúspěšném probuzení a rebootu se v dmesg vypsané "Magic number" neshodovalo s žádným hashem?

A kam až ses dostal s tím pm_test? Ani s "core" to ještě nezdechlo?

[debil]

Hash matches budto ukazovalo na nejaky radek v kernelu (muzu doplnit, pokud vas to bude zajimat), nebo na LNXSYSTM:0, nebo jen device, ktere neexistuje (nenasel jsem v /sys). Nekdy mi to ani zadny hash matches nevyhodi i prestoze dam:

echo 1>/sys/power/pm_trace .

Nize viz priklad jednoho z poslednich. Zajimave je, ze je tam vypis "PM: Resume from disk failed.", prestoze jsem hibernate (ci suspend to disk) nevolal.

...
[    0.809112] PM: Resume from disk failed.
[    0.809130] registered taskstats version 1
[    0.809481]   Magic number: 15:422:472
[    0.809560] acpi LNXSYSTM:00: hash matches
[    0.809600] rtc_cmos 00:02: setting system clock to 2011-02-09 08:29:13 UTC (1297240153)
...

Nize je relevantni vystup dmesg po: echo core >/sys/power/pm_test;echo mem >/sys/power/state

[ 2131.795624] PM: Syncing filesystems ... done.
[ 2132.244299] PM: Preparing system for mem sleep
[ 2132.446082] mmc0: card b368 removed
[ 2132.447814] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 2132.459147] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 2132.470145] PM: Entering mem sleep
[ 2132.470186] Suspending console(s) (use no_console_suspend to debug)
[ 2132.470583] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 2132.470778] sd 0:0:0:0: [sda] Stopping disk
[ 2132.947294] btusb_intr_complete: hci0 urb ffff880072fc3cc0 failed to resubmit (1)
[ 2132.948277] btusb_bulk_complete: hci0 urb ffff8800675cd240 failed to resubmit (1)
[ 2132.949274] btusb_bulk_complete: hci0 urb ffff8800675cd3c0 failed to resubmit (1)
[ 2132.968387] ACPI handle has no context!
[ 2132.968702] rt61pci 0000:05:09.0: PCI INT A disabled
[ 2132.968715] ACPI handle has no context!
[ 2132.979168] ACPI handle has no context!
[ 2132.979178] sdhci-pci 0000:05:04.2: PCI INT A disabled
[ 2132.979189] ACPI handle has no context!
[ 2132.990125] ACPI handle has no context!
[ 2133.280062] radeon 0000:01:05.0: PCI INT A disabled
[ 2133.493156] HDA Intel 0000:00:14.2: PCI INT A disabled
[ 2133.504211] pata_atiixp 0000:00:14.1: PCI INT A disabled
[ 2133.504250] ehci_hcd 0000:00:13.2: PCI INT A disabled
[ 2133.504266] ohci_hcd 0000:00:13.1: PCI INT A disabled
[ 2133.504281] ohci_hcd 0000:00:13.0: PCI INT A disabled
[ 2133.504625] sata_sil 0000:00:12.0: PCI INT A disabled
[ 2133.504812] PM: suspend of devices complete after 1034.331 msecs
[ 2133.505120] r8169 0000:04:00.0: PME# enabled
[ 2133.505145] pcieport 0000:00:07.0: wake-up capability enabled by ACPI
[ 2133.527176] PM: late suspend of devices complete after 22.345 msecs
[ 2133.527344] ACPI: Preparing to enter system sleep state S3
[ 2133.528283] PM: Saving platform NVS memory
[ 2133.550937] Disabling non-boot CPUs ...
[ 2133.551009] suspend debug: Waiting for 5 seconds.
[ 2133.551229] ACPI: Waking up from system sleep state S3
[ 2133.552217] pcieport 0000:00:07.0: restoring config space at offset 0x1 (was 0x100107, writing 0x40100107)
[ 2133.552278] sata_sil 0000:00:12.0: restoring config space at offset 0x1 (was 0x2b00103, writing 0x2b00107)
[ 2133.563051] ehci_hcd 0000:00:13.2: BAR 0: set to [mem 0xffefc000-0xffefcfff] (PCI address [0xffefc000-0xffefcfff]
[ 2133.563101] ehci_hcd 0000:00:13.2: restoring config space at offset 0x1 (was 0x2b00000, writing 0x2b00113)
[ 2133.563209] pata_atiixp 0000:00:14.1: restoring config space at offset 0x1 (was 0x2300001, writing 0x2300005)
[ 2133.574045] HDA Intel 0000:00:14.2: BAR 0: set to [mem 0xffef8000-0xffefbfff 64bit] (PCI address [0xffef8000-0xffefbfff]
[ 2133.574069] HDA Intel 0000:00:14.2: restoring config space at offset 0xf (was 0x0, writing 0x3)
[ 2133.574101] HDA Intel 0000:00:14.2: restoring config space at offset 0x3 (was 0x0, writing 0xf010)
[ 2133.574114] HDA Intel 0000:00:14.2: restoring config space at offset 0x1 (was 0x4100000, writing 0x4100002)
[ 2133.585037] radeon 0000:01:05.0: BAR 0: set to [mem 0xd0000000-0xd7ffffff pref] (PCI address [0xd0000000-0xd7ffffff]
[ 2133.585049] radeon 0000:01:05.0: BAR 1: set to [io  0x6800-0x68ff] (PCI address [0x6800-0x68ff]
[ 2133.585059] radeon 0000:01:05.0: BAR 2: set to [mem 0xff2f0000-0xff2fffff] (PCI address [0xff2f0000-0xff2fffff]
[ 2133.585083] radeon 0000:01:05.0: restoring config space at offset 0x1 (was 0x2b00103, writing 0x2b00107)
[ 2133.596039] r8169 0000:04:00.0: BAR 0: set to [io  0x8800-0x88ff] (PCI address [0x8800-0x88ff]
[ 2133.596056] r8169 0000:04:00.0: BAR 2: set to [mem 0xffbff000-0xffbfffff 64bit] (PCI address [0xffbff000-0xffbfffff]
[ 2133.596118] r8169 0000:04:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100007)
[ 2133.607040] firewire_ohci 0000:05:04.0: BAR 0: set to [mem 0xffcff000-0xffcfffff] (PCI address [0xffcff000-0xffcfffff]
[ 2133.607054] firewire_ohci 0000:05:04.0: BAR 1: set to [mem 0xffcfe800-0xffcfefff] (PCI address [0xffcfe800-0xffcfefff]
[ 2133.607075] firewire_ohci 0000:05:04.0: restoring config space at offset 0xf (was 0x100, writing 0x107)
[ 2133.607111] firewire_ohci 0000:05:04.0: restoring config space at offset 0x3 (was 0x800000, writing 0x80f810)
[ 2133.607126] firewire_ohci 0000:05:04.0: restoring config space at offset 0x1 (was 0x2100080, writing 0x2180117)
[ 2133.618040] sdhci-pci 0000:05:04.2: BAR 0: set to [mem 0xffcfe400-0xffcfe4ff] (PCI address [0xffcfe400-0xffcfe4ff]
[ 2133.618061] sdhci-pci 0000:05:04.2: restoring config space at offset 0xf (was 0x1ff, writing 0x107)
[ 2133.618099] sdhci-pci 0000:05:04.2: restoring config space at offset 0x3 (was 0x0, writing 0xf810)
[ 2133.618114] sdhci-pci 0000:05:04.2: restoring config space at offset 0x1 (was 0x4100000, writing 0x4100102)
[ 2133.629040] rt61pci 0000:05:09.0: BAR 0: set to [mem 0xffcf0000-0xffcf7fff] (PCI address [0xffcf0000-0xffcf7fff]
[ 2133.629092] rt61pci 0000:05:09.0: restoring config space at offset 0x1 (was 0x4100113, writing 0x4100117)
[ 2133.629205] PM: early resume of devices complete after 77.097 msecs
[ 2133.830423] sata_sil 0000:00:12.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[ 2133.831128] ohci_hcd 0000:00:13.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 2133.852082] ohci_hcd 0000:00:13.1: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 2133.873066] ehci_hcd 0000:00:13.2: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 2133.873154] pata_atiixp 0000:00:14.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 2133.876579] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 2133.888681] radeon 0000:01:05.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 2133.899052] [drm] radeon: 2 quad pipes, 1 z pipes initialized.
[ 2133.899826] [drm] radeon: ring at 0x0000000080000000
[ 2133.899851] [drm] ring test succeeded in 1 usecs
[ 2133.899872] [drm] ib test succeeded in 0 usecs
[ 2134.005419] pcieport 0000:00:07.0: wake-up capability disabled by ACPI
[ 2134.005431] r8169 0000:04:00.0: PME# disabled
[ 2134.011093] r8169 0000:04:00.0: eth0: link down
[ 2134.040085] ata3.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered out
[ 2134.040095] ata3.00: ACPI cmd ef/03:42:00:00:00:a0 (SET FEATURES) filtered out
[ 2134.046645] ata3.00: configured for UDMA/33
[ 2134.062104] firewire_core: skipped bus generations, destroying all nodes
[ 2134.062135] sdhci-pci 0000:05:04.2: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[ 2134.062180] rt61pci 0000:05:09.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[ 2134.142083] ata2: SATA link down (SStatus 0 SControl 310)
[ 2134.142162] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 2134.145389] ata1.00: ACPI cmd ef/03:46:00:00:00:a0 (SET FEATURES) filtered out
[ 2134.263180] sd 0:0:0:0: [sda] Starting disk
[ 2134.563102] firewire_core: rediscovered device fw0
[ 2136.187641] ata1.00: configured for UDMA/100
[ 2136.218340] PM: resume of devices complete after 2589.079 msecs
[ 2136.301493] PM: Finishing wakeup.
[ 2136.301499] Restarting tasks ... done.
[ 2136.414690] video LNXVIDEO:00: Restoring backlight state
[ 2136.603337] mmc0: new SDHC card at address b368
[ 2136.612991] mmcblk0: mmc0:b368 SDC   3.72 GiB 
[ 2136.631475]  mmcblk0: p1
[ 2140.279961] SELinux: initialized (dev mmcblk0p1, type fuseblk), uses genfs_contexts

Zacinam se domnivat, ze to bude neco s tim mym BIOSem, protoze jsem o tom u Redhat vyplnil bug a prestoze jsem se snazil vse otestovat a oreportovat, nikdo se na to ani neozval . Jen si chci byt jisty, ze je to vubec mozne.

[debil]

Jeste doplnim, ze jsem vse testoval i po bootu do "single" rezimu, s "norhgb" (prepinac vypinajici graf. boot) a "nomodeset", tak abych mohl hned po bootu odstranit moduly radeon, ttm, drm (a vsechny jeho zavislosti), vsechny ruzne usb, zvukkove, firewire, apod. moduly (proste vse co slo odstranit). Bohuzel i pres to se resume nepodari.

[debil]

Jeste doplnim, ze jsem vse testoval i po bootu do "single" rezimu, s "norhgb" (prepinac vypinajici graf. boot) a "nomodeset", tak abych mohl hned po bootu odstranit moduly radeon, ttm, drm (a vsechny jeho zavislosti), vsechny ruzne usb, zvukkove, firewire, apod. moduly (proste vse co slo odstranit). Bohuzel i pres to se resume nepodari.

Mozna to s tim nesouvisi, ale zajimave je, ze kdyz dam restart systemu (treba pomoci reboot nebo pres GNOME GUI), tak re system jakoby restartuje, ale zustane trcet zcela nepouzitelny, takze ho musim vypnout/zapnout. Leceni techto symptomu jsem si take prodelal (zmena zpusobu jak se bude volat reset - b/w) a bez vysledku.

[jadd]

Někdo tady na fóru psal že by mu možná pomohlo aktualizovat BIOS, v tom tvém případě by to mohlo být řešení. Kontroloval jsi na podpoře jestli je pro tvůj notes dostupná novější verze ?

[debil]

No mam celkem strach flashovat BIOS uz proto, ze jinak vse funguje a drive fungovalo. Jedine co se zmenilo je F12 => F14.

S flashovanim tohoto BIOSu je take problem s tim, ze S271 od MSI je neco trosku jineho nez cesky S271 s nalepkou MSI. Treba ten CPU Sempron 3500+ neni v zahranici u tohoto modelu bezny. MSI tak0 vydalo tri verze BIOS pro ruzne Windows systemy. Na webu pak tyto flashe majitele techto laptopu celkem pomlouvaji. Kdyz jsem laptop koupil, byl tam dokonce najaky brandovany BIOS od Alza.cz a prvni co se mi zobrazilo po prvnim zapnuti, byl ten jejich zelenej maskot a ten mi "jakoby rozbil" monitor (bohuzel nechtene mi pak laptip prestal fungovat ) no pak do nej pri reklamaci nahrali jakysi BIOS se kterym to "nejak funguje" a tak to fungovalo ay do ted.

Bohuzel prozatim mam z celkoveho flashe BIOS obavy z toho aby to vubec nabehlo. Spise by mne zajimalo, zda je mozne nejak (toolem z os / treba s free dos) menit nebo jen zobrazit konfiguraci BIOSu (tedy ne program, jen jeho konfiguraky nekde v pameti - drive CMOS ).

[jadd]

Jo tak s toho mám strach dodnes, vždy jsem zaváděl z diskety nebo na sočasném notesu, z Vist. Byl přibalenej prográmek od výrobce notesu.

[michich]

echo 1>/sys/power/pm_trace

Tady na to pozor - mezi tím číslem a zobákem musí být mezera, jinak to shell chápe jako číslo deskriptoru. Druhá možnost je používat uvozovky.

[debil]

Jo, to vim, kdyz tam neni mezera, zarve to nejakou hlasku. Vzdy si hlidam.

[michich]

[    0.809481]   Magic number: 15:422:472
[    0.809560] acpi LNXSYSTM:00: hash matches
[    0.809600] rtc_cmos 00:02: setting system clock to 2011-02-09 08:29:13 UTC (1297240153)

pm_trace ukládá ty své značky do hodin reálného času. 2011-02-09 je dnešní datum. Je hodně nepravděpodobné, že by se ta značka náhodou trefila zrovna do takové hodnoty, aby odpovídala dnešnímu datu. Tudíž jsou tyto možnosti:

1. Toto není výpis z bootu po neúspěšném probuzení, nebo
2. při tom uspání nebyl zapnutý pm_trace, nebo
3. to probouzení selhává velmi brzo, ještě před zapsáním první značky.

To správné datum dostáváš při každém pokusu?

[debil]

Shoulasim a je mi to divne. Dela to az dnes. Drive mi to rozhodilo hodiny a tak byl cely proces zdlouhavy, protoze pri jakemkoliv zapisu na disk mi to pri naslednem rebootu vynutilo kontrolu disku.

Protoze jsem to neladil vice nez mesic, a behem te doby udelal update, domnival jsem se, ze soudruzi v Redhat/Fedora vymysleli trick jak si ulozit hodiny. Pri znalosti ze se system bootuje po pm_trace a vyrazne jinem case RTC by to nemusel byt zas takovy orisek. Pravda, cas by byl spatny, ale jen malo vyrazne a tedy by nezpusobil nesmyslne timestampy na filesystemu.

Jinak snazim se system nahodit co nejdrive, aby se informace v RTC neposkodila. Na webu jsem se dovedel hodnoty do 60sec.

[debil]

Jeste jsem zapomnel zminit, ze si tu hodnotu "1" pm_trace kontroluji naslednym cat /sys/power/pm_trace

[michich]

domnival jsem se, ze soudruzi v Redhat/Fedora vymysleli trick jak si ulozit hodiny. Pri znalosti ze se system bootuje po pm_trace a vyrazne jinem case RTC by to nemusel byt zas takovy orisek. Pravda, cas by byl spatny, ale jen malo vyrazne a tedy by nezpusobil nesmyslne timestampy na filesystemu.

Žádný takový fígl tam určitě není.

Jinak snazim se system nahodit co nejdrive, aby se informace v RTC neposkodila. Na webu jsem se dovedel hodnoty do 60sec.

Ten limit je 3 minuty (drivers/base/power/trace.c).

Budu teda předpokládat, že to vytuhne velmi brzo. Má ten laptop funkční PC speaker? Můžeš ověřit:

modprobe pcspkr
echo -ne '\x7' > /dev/tty1

Měl bys uslyšet klasické pípnutí. Jestli jo, tak další test může být:

echo 4 > /proc/sys/kernel/acpi_video_flags
echo mem > /sys/power/state

Po probuzení bys měl uslyšet morseovkou oznámené písmeno V (..._; dělá to arch/x86/kernel/acpi/realmode/wakemain.c).

[debil]

Speaker funguje. Musel jsem vsak unmute (zapnout) na zvukovce prepinac "Beep" a pak ho zesilit na max.

echo 4 > /proc/sys/kernel/acpi_video_flags
echo mem > /sys/power/state

mi vsak po resume nezabeepuje. Nemuze to byt tim, ze se pri resume zmeni nastaveni zvukovky tak, ze se je kanal "Beep" ztlumeny?

Dnes uz koncim , zitra na to nemam cas, kazdopadne jeste jednou dik moc za rady a vas cas. Pokud byste mel dalsi tipy, rad se priucim a urcite to vyzkousim. Nejradeji bych presel zpet na F12, ale potrebuji mit system up-to-date a tak volim radeji mensi zlo.

Mam stazeny zdrojaky jadra a tak mne napadlo si najit misto, kde se dela resume a zkusit tam narvat nejaky debugovaci hlasky. Vypadato ze mate prehled, pokud byste mel tip kam se kouknout, budu rad. Urcite to nebude snadne, ale alespon se neco naucim.

[michich]

Speaker funguje. Musel jsem vsak unmute (zapnout) na zvukovce prepinac "Beep" a pak ho zesilit na max. [...] po resume nezabeepuje. Nemuze to byt tim, ze se pri resume zmeni nastaveni zvukovky tak, ze se je kanal "Beep" ztlumeny?

Jo, bohužel. Samostatný PC speaker tam není a jede to přes zvukovku, která je v tom okamžiku ještě vypnutá. To jsem měl u laptopu očekávat. Čili tento test nám nic neprozradí.

Ten bug, který jsi hlásil je 650525?

[debil]

Jo. Pozdeji jsem zjistil, ze to dela i na 32bit. Nikoho ten bug nezajimal a tak jsem to tam uz ani nepsal. Nejdrive jsem si tam vratil starej system ze zalohy, ale pak jsem musel prejit na F14. Tak ted laptop radeji nevypinam, no a protoze je to opruz, tak cas od casu dostanu energii to opravit - coz je prave ted.

[michich]

OK, s dalšími návrhy budu pokračovat v té Bugzille.

[jadd]

Zkoušel jsi resume i z něčeho jinýho ? třeba z myši ?

[debil]

Nevim jak to nastavit. Je mozne tonastavit v linuxu? V nastaveni BIOSu meho laptopu bohuze nic takoveho neni. Zkousel jsem WOL (po siti), ale to mi funguje jen kdyz je laptop vypnuty. Pokud je v S3 suspend, tak se neprobudi. Toto chovani (neprobuzeni po siti) je vsak shodne i s jinymi pocitaci, na kterych mi to funguje - tedy WOL jsem jeste nevidel fungovat spolecne se S3 suspend.

[jadd]

Ne muselo by to být v BIOSu. Zvláštní taky mám laptop (Asus), těch možností tam je víc...

[michich]

Ještě bys to mohl testnout s co nejnovějším kernelem. Kernel z Rawhide by měl jít bez problému na F14 nainstalovat:

yum install fedora-release-rawhide
yum --enablerepo=rawhide install kernel

[debil]

No to uz jsem drive zkousel, ale mam dnes dobrou naladu a cas, tak jdu na to . Dam vedet...

[debil]

S timto jadrem z rawhide Linux nocouz 2.6.38-0.rc4.git0.1.fc15.x86_64 #1 SMP Tue Feb 8 01:57:21 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux to nejede.

[michich]

Další nápad - nabootuj s parametry acpi_osi="!Windows 2009" acpi_osi="!Windows 2006 SP2" acpi_osi="!Windows 2006 SP1" acpi_osi="!Windows 2006.1".

[debil]

Dekuji moc za vas cas.

Bohuzel nepomohlo. Proveril jsem, ze parametry kernel urcite dostal.Tady je rozdil vystupu dmesg v porovnani z predchozim logem bez parametru, ktery to potvrzuje.

...
ACPI: Deleted _OSI(Windows 2009)
ACPI: Deleted _OSI(Windows 2006 SP2)
ACPI: Deleted _OSI(Windows 2006 SP1)
ACPI: Deleted _OSI(Windows 2006.1)
...

Prestoze jsem si vyhledal strucny popis techto parametru (treba tady), neni mi moc zrejme jak to ve vnitr funguje. Nepomohlo by se naopak pro BIOS vydavat za nejaky ten WinXX system?

[debil]

Nyni se s pomoci pm_trace vynorilo toto:

  Magic number: 15:173:289
tty tty22: hash matches

Coz tedy nechapu.

V /sys/devices/virtual/tty/tty22/dev je 4:22. V /etc/modprobe.d/dist.conf je

alias char-major-4-* serial

Kontrolou lsmod vsak zadny modul serial nenalezam. Modinfo mi rekne, ze takovy modul ani nezna.

[debil]

Dalsi pokus s pm_trace:

bdi 7:3: hash matches
system 00:0a: hash matches

Coz je opet divne. Zadne takove zarizeni v laptopu nemam. Prestoze reboot probehne do minuty, vysledky jsou podivne. Myslim, ze pouziti RTC je v mem pripade nespolehlive.

[debil]

Oprava: nasel jsem zarizeni system 00:0a .

/sys/bus/acpi/devices/PNP0C01:00

obsah adresare:

#ls -la
drwxr-xr-x.  3 root root    0 Feb  9 19:01 .
drwxr-xr-x. 14 root root    0 Feb  9 19:01 ..
-r--r--r--.  1 root root 4096 Feb  9 19:22 hid
-r--r--r--.  1 root root 4096 Feb  9 19:22 modalias
-r--r--r--.  1 root root 4096 Feb  9 19:22 path
lrwxrwxrwx.  1 root root    0 Feb  9 19:22 physical_node -> ../../../pnp0/00:0a
drwxr-xr-x.  2 root root    0 Feb  9 19:15 power
lrwxrwxrwx.  1 root root    0 Feb  9 19:02 subsystem -> ../../../../bus/acpi
-rw-r--r--.  1 root root 4096 Feb  9 19:01 uevent
#cat hid
PNP0C01
#cat uevent 
MODALIAS=acpi:PNP0C01:
#cat modalias 
acpi:PNP0C01:
# cat path 
\_SB_.RMEM

[michich]

Nevím, jestli jsi zkoušel i parametr acpi_sleep=nonvs.

[debil]

Myslim, ze drive ano. Dnes rano jsem to pro jistotu proveril jeste jednou. Bezuspechu.

[jadd]

Podívejte se na tuhle stránku, trochu dolejš, píšou o nějaké opravě s autosuspendem. Ale nevím, jestli je to co hledáte. Díval jsem se do jaderných novin, prohlížel jsem všechny zprávy o 2.6.37 ale o suspendu ani zmínka... Než bych se ale prokousával, různýma citátama, radši jsem hledal ve stránce pomocí FF.

[michich]

Nefunguje mu 2.6.35.10 ani 2.6.38-rc4, takže není důvod zkoumat nějak speciálně 2.6.37. A autosuspend je něco jiného než suspend-to-RAM.

[jadd]

Dobrá, já na to narazil, když jsem hledal něco jinýho. Tak nic už mlčím...