Problemi all'uscita da Suspend2Ram

[Webbino]

'Salve

Ho letto con interesse la soluzione che ho trovato in questo precedente post:

viewtopic.php?f=7&t=22107


L'impostazione che ha proposto alessiopdf lo ho trovata veramente molto comoda (dato, che usando xfce non dispongo dei software con la K o di gnomi vari).


Il problema, come si intuisce dal titolo, che una volta chiuso il coperchio, il portatile effettua correttamente (almeno credo) il suspend2ram ma una volta aperto, non riesco più a farlo uscire dal "letargo".

L'unica modo è premere per quei 4/5 secondi il tasto dell'accensione per forzare lo shutdown (con i rischi che questa operazione causa alla struttura del filesystem).


Ora, non so se dato il modello, esiste un particolare tasto magico per svegliarlo (spero di non dover ricorrere al principe azzurro) o se c'è la possibilità di modificare lo script stesso per "svegliarlo" forzatamente quando il coperchio si apre

Il portatile è un (vecchio) Compaq Presario 1120, il kernel è l'ultimo stabile attualmente (2.6.23.14)


Se c'è bisogno di allegarvi il config del kernel delle sezioni acpi (o altro), ovviamente non è un problema


Vi ringrazio, in anticipo, per l'aiuto


Saluti

[alessiodf]

purtroppo, questo accade spesso su alcuni hardware.. cerca magari in giro qualcuno con il tuo stesso notebook, e vedi se qualcuno ha risolto!

[Webbino]

Ti ringrazio per la risposta alessio, ho provato a fare qualche ricerca su google in merito ma ho trovato poco o nulla.

Visto che, sicuramente, sei più avvezzo te di me sull'acpi è possibile imporre uno script che risvegli il Pc quando si apre lo schermo (dopo il Suspend2Ram) ?

Visionando il file /proc/acpi/button/lid/LID/state viene riconosciuto correttamente l'evento (chiusura e apertura), dato che premere ogni tasto sembra inutile, pensavo di aggirare il problema in questo modo (lasciando il compito del buongiorno a acpi/kernel)


'Saluti

[alessiodf]

se hai usato il mio script del post precedente, quello usa proprio le chiamate del kernel.. di default, quando il LID e' open, il suspend2ram riceve un segnale di risveglio. Se questo non accade, comunque il susp2ram deve risvegliarsi (in teoria) premendo qualsiasi tasto del mouse/power button/space_bar

Ps: sul mio computer (desktop) mi succede ad esempio la stessa roba.. si sospende, ma non si risveglia..

semmai, hai provato a controllare i logs del kernel dopo il suspend + reset della macchina?

non so piu' che altro dirti

[Webbino]

Il file log di Acpid è il seguente:

Codice: Seleziona tutto

[Sun Jan 20 20:21:37 2008] starting up
[Sun Jan 20 20:21:37 2008] 1 rule loaded
[Sun Jan 20 20:21:41 2008] client connected from 2290[82:82]
[Sun Jan 20 20:21:41 2008] 1 client rule loaded
[Sun Jan 20 20:21:46 2008] client connected from 2317[0:0]
[Sun Jan 20 20:21:46 2008] 1 client rule loaded
[Sun Jan 20 20:22:01 2008] received event "battery BAT1 00000080 00000001"
[Sun Jan 20 20:22:01 2008] notifying client 2290[82:82]
[Sun Jan 20 20:22:01 2008] notifying client 2317[0:0]
[Sun Jan 20 20:22:01 2008] executing action "/etc/acpi/acpi_handler.sh battery BAT1 00000080 00000001"
[Sun Jan 20 20:22:01 2008] BEGIN HANDLER MESSAGES
[Sun Jan 20 20:22:01 2008] END HANDLER MESSAGES
[Sun Jan 20 20:22:01 2008] action exited with status 0
[Sun Jan 20 20:22:01 2008] completed event "battery BAT1 00000080 00000001"
[Sun Jan 20 20:24:08 2008] received event "battery BAT1 00000080 00000001"
[Sun Jan 20 20:24:08 2008] notifying client 2290[82:82]
[Sun Jan 20 20:24:08 2008] notifying client 2317[0:0]
[Sun Jan 20 20:24:08 2008] executing action "/etc/acpi/acpi_handler.sh battery BAT1 00000080 00000001"
[Sun Jan 20 20:24:08 2008] BEGIN HANDLER MESSAGES
[Sun Jan 20 20:24:08 2008] END HANDLER MESSAGES
[Sun Jan 20 20:24:08 2008] action exited with status 0
[Sun Jan 20 20:24:08 2008] completed event "battery BAT1 00000080 00000001"
[Sun Jan 20 20:25:11 2008] received event "battery BAT1 00000080 00000001"
[Sun Jan 20 20:25:11 2008] notifying client 2290[82:82]
[Sun Jan 20 20:25:11 2008] notifying client 2317[0:0]
[Sun Jan 20 20:25:11 2008] executing action "/etc/acpi/acpi_handler.sh battery BAT1 00000080 00000001"
[Sun Jan 20 20:25:11 2008] BEGIN HANDLER MESSAGES
[Sun Jan 20 20:25:11 2008] END HANDLER MESSAGES
[Sun Jan 20 20:25:11 2008] action exited with status 0
[Sun Jan 20 20:25:11 2008] completed event "battery BAT1 00000080 00000001"
[Sun Jan 20 20:26:14 2008] received event "battery BAT1 00000080 00000001"
[Sun Jan 20 20:26:14 2008] notifying client 2290[82:82]
[Sun Jan 20 20:26:14 2008] notifying client 2317[0:0]
[Sun Jan 20 20:26:14 2008] executing action "/etc/acpi/acpi_handler.sh battery BAT1 00000080 00000001"
[Sun Jan 20 20:26:14 2008] BEGIN HANDLER MESSAGES
[Sun Jan 20 20:26:14 2008] END HANDLER MESSAGES
[Sun Jan 20 20:26:14 2008] action exited with status 0
[Sun Jan 20 20:26:14 2008] completed event "battery BAT1 00000080 00000001"
[Sun Jan 20 20:27:16 2008] received event "battery BAT1 00000080 00000001"
[Sun Jan 20 20:27:16 2008] notifying client 2290[82:82]
[Sun Jan 20 20:27:16 2008] notifying client 2317[0:0]
[Sun Jan 20 20:27:16 2008] executing action "/etc/acpi/acpi_handler.sh battery BAT1 00000080 00000001"
[Sun Jan 20 20:27:16 2008] BEGIN HANDLER MESSAGES
[Sun Jan 20 20:27:16 2008] END HANDLER MESSAGES
[Sun Jan 20 20:27:16 2008] action exited with status 0
[Sun Jan 20 20:27:16 2008] completed event "battery BAT1 00000080 00000001"
[Sun Jan 20 20:28:20 2008] received event "battery BAT1 00000080 00000001"
[Sun Jan 20 20:28:20 2008] notifying client 2290[82:82]
[Sun Jan 20 20:28:20 2008] notifying client 2317[0:0]
[Sun Jan 20 20:28:20 2008] executing action "/etc/acpi/acpi_handler.sh battery BAT1 00000080 00000001"
[Sun Jan 20 20:28:20 2008] BEGIN HANDLER MESSAGES
[Sun Jan 20 20:28:20 2008] END HANDLER MESSAGES
[Sun Jan 20 20:28:20 2008] action exited with status 0
[Sun Jan 20 20:28:20 2008] completed event "battery BAT1 00000080 00000001"


Leggendo il log a quanto pare la fase di risveglio viene avviata correttamente e a questo punto credo che il problema principale sia lo schermo, quando apro lo sportello la ventola ricomincia a funzionare e dal rumore sembra che anche l'hardisk comincia a prendere vita.



Allego anche il pezzo del file .config relativo all'acpi.. magari mi è sfuggito qualcosa

Codice: Seleziona tutto

# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND_UP_POSSIBLE=y
CONFIG_SUSPEND=y
CONFIG_HIBERNATION_UP_POSSIBLE=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
# CONFIG_ACPI_VIDEO is not set
# CONFIG_ACPI_FAN is not set
CONFIG_ACPI_DOCK=m
# CONFIG_ACPI_BAY is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=m
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
# CONFIG_APM is not set


Grazie x le eventuali dritte

[alessiodf]

a quanto pare la fase di risveglio viene avviata correttamente e a questo punto credo che il problema principale sia lo schermo, quando apro lo sportello la ventola ricomincia a funzionare e dal rumore sembra che anche l'hardisk comincia a prendere vita.

questa gia' e' una buona cosa... quindi, mi devi fornire i log di sistema, non di acpi!

in genere li' e' che dovresti vedere qual'e' il modulo che non fa il suo dovere

[Webbino]

Ti sembrerà strano, ma nel file log del kernel (/var/log/syslog) non trovo nulla a riguardo (confrontando le date del file acpid)..

[alessiodf]

guarda, questo e' quella che accade a me, dopo una sospensione e un risveglio (effettuato con successo)
/var/log/messages

Codice: Seleziona tutto

Jan 20 21:41:26 joybook kernel: eth1: Going into suspend...
Jan 20 21:41:26 joybook kernel: ACPI: PCI interrupt for device 0000:06:03.0 disabled
Jan 20 21:41:26 joybook kernel: ACPI: PCI interrupt for device 0000:06:01.3 disabled
Jan 20 21:41:26 joybook kernel: ACPI: PCI interrupt for device 0000:00:1e.2 disabled
Jan 20 21:41:26 joybook kernel: ACPI: PCI interrupt for device 0000:00:1d.7 disabled
Jan 20 21:41:26 joybook kernel: ACPI: PCI interrupt for device 0000:00:1d.3 disabled
Jan 20 21:41:26 joybook kernel: ACPI: PCI interrupt for device 0000:00:1d.2 disabled
Jan 20 21:41:26 joybook kernel: ACPI: PCI interrupt for device 0000:00:1d.1 disabled
Jan 20 21:41:26 joybook kernel: ACPI: PCI interrupt for device 0000:00:1d.0 disabled
Jan 20 21:41:26 joybook kernel: Intel machine check architecture supported.
Jan 20 21:41:26 joybook kernel: Intel machine check reporting enabled on CPU#0.
Jan 20 21:41:26 joybook kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ 10
Jan 20 21:41:26 joybook kernel: ACPI: PCI Interrupt 0000:00:1c.0[A] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
Jan 20 21:41:26 joybook kernel: ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKH] -> GSI 11 (level, low) -> IRQ 11
Jan 20 21:41:26 joybook kernel: ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
Jan 20 21:41:26 joybook kernel: ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10
Jan 20 21:41:26 joybook kernel: ACPI: PCI Interrupt 0000:00:1d.3[D] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ 10
Jan 20 21:41:26 joybook kernel: ACPI: PCI Interrupt 0000:00:1d.7[A] -> Link [LNKH] -> GSI 11 (level, low) -> IRQ 11
Jan 20 21:41:26 joybook kernel: ACPI: PCI Interrupt 0000:00:1e.2[A] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
Jan 20 21:41:26 joybook kernel: ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10
Jan 20 21:41:26 joybook kernel: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[10]  MMIO=[b8007000-b80077ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
Jan 20 21:41:26 joybook kernel: ACPI: PCI Interrupt 0000:06:01.3[A] -> Link [LNKG] -> GSI 10 (level, low) -> IRQ 10
Jan 20 21:41:26 joybook kernel: eth1: Coming out of suspend...
Jan 20 21:41:26 joybook kernel: ACPI: PCI Interrupt 0000:06:03.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
Jan 20 21:41:26 joybook kernel: eth0: link down
Jan 20 21:41:26 joybook kernel: eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1


/var/log/syslog

Codice: Seleziona tutto

Jan 20 21:45:22 joybook kernel: Stopping tasks ... done.
Jan 20 21:45:22 joybook kernel: Suspending console(s)
Jan 20 21:45:22 joybook kernel: PCI: Enabling device 0000:00:1d.0 (0000 -> 0001)
Jan 20 21:45:22 joybook kernel: usb usb1: root hub lost power or was reset
Jan 20 21:45:22 joybook kernel: PCI: Enabling device 0000:00:1d.1 (0000 -> 0001)
Jan 20 21:45:22 joybook kernel: usb usb2: root hub lost power or was reset
Jan 20 21:45:22 joybook kernel: PCI: Enabling device 0000:00:1d.2 (0000 -> 0001)
Jan 20 21:45:22 joybook kernel: usb usb4: root hub lost power or was reset
Jan 20 21:45:22 joybook kernel: PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
Jan 20 21:45:22 joybook kernel: usb usb5: root hub lost power or was reset
Jan 20 21:45:22 joybook kernel: PCI: Enabling device 0000:06:03.0 (0000 -> 0002)
Jan 20 21:45:22 joybook kernel: ipw2200: Radio Frequency Kill Switch is On:
Jan 20 21:45:22 joybook kernel: Kill switch must be turned off for wireless networking to work.
Jan 20 21:45:22 joybook kernel: Restarting tasks ... done.

non so cos'altro aggiungere

[Webbino]

Spulciando un po' su /var/log/messages ho trovato quanto segue:

Codice: Seleziona tutto

Jan 20 20:21:47 darkstar kernel: ACPI: PCI Interrupt 0000:01:05.0[A] -> Link [LNK0] -> GSI 10 (level, low) -> IRQ 10
Jan 20 20:21:47 darkstar kernel: [drm] Initialized radeon 1.28.0 20060524 on minor 0
Jan 20 20:21:49 darkstar kernel: agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
Jan 20 20:21:49 darkstar kernel: agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
Jan 20 20:21:49 darkstar kernel: agpgart: Putting AGP V2 device at 0000:01:05.0 into 4x mode
Jan 20 20:21:50 darkstar kernel: [drm] Setting GART location based on new memory map
Jan 20 20:21:50 darkstar kernel: [drm] writeback test succeeded in 1 usecs
Jan 20 20:22:01 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:22:24 darkstar kernel: eth0: DSPCFG accepted after 0 usec.
Jan 20 20:22:24 darkstar kernel: eth0: link up.
Jan 20 20:22:24 darkstar kernel: eth0: Setting full-duplex based on negotiated link capability.
Jan 20 20:24:08 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:25:11 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:26:14 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:27:16 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:28:20 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:29:25 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:30:28 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:31:30 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:34:39 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:35:44 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:36:49 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:37:54 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:38:59 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:40:00 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:41:02 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:42:06 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:43:07 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:44:10 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:45:12 darkstar logger: ACPI group battery / action BAT1 is not defined
Jan 20 20:46:14 darkstar logger: ACPI group battery / action BAT1 is not defined


A sapere cos'è BAT1..

[JohnnyMnemonic]

BAT1 sarebbe la seconda batteria, quegli eventi che tu hai nel log corrispondo alla rimozione/inserimento della batteria

BAT0 -> prima batteria
BAT1 -> seconda batteria

[Webbino]

BAT1 sarebbe la seconda batteria, quegli eventi che tu hai nel log corrispondo alla rimozione/inserimento della batteria

BAT0 -> prima batteria
BAT1 -> seconda batteria

E come potrai immaginare non ho cercato di manometterne ne la prima ne la seconda (che, per quanto ne possa dire il file log, non esiste !)


La situazione direi che si sta facendo abbastanza anomala...