Modalità sospensione Raspberry Pi, come evitare

Uso l'ultima versione di "wheezy". Il dispositivo fornisce alcune funzionalità del servizio Web e suppone di essere attivo 24/7. Tuttavia, se il server non è stato richiesto per un certo periodo di tempo (è difficile stabilire l'ora esatta), il dispositivo sembra andare in sospensione (si spera non si blocchi). Il dispositivo si è collegato alla rete tramite dongle wi-fi. Ho trovato alcune risposte qui che un motivo per il congelamento del dispositivo può essere che la scheda Wi-Fi sta funzionando in modalità economica, quindi ho seguito le istruzioni e posso confermare che il dongle non va in modalità di sospensione ma inizia a lampeggiare come se non ci si accedesse da computer. significa che il dispositivo continua a dormire anche se il wi-fi è attivo. La soluzione, come acquistare un altro Raspberry Pi e renderlo sempre in modalità ping, non funziona, poiché solo essere un server che riceve richieste impedisce al dispositivo di andare in sospensione. Cercare di eseguire il polling di qualcosa dal dispositivo non impedisce di passare in modalità sospensione. In realtà non posso confermare che quel dispositivo andrà in sospensione. Non ho il monitor o la tastiera collegati e tento di collegare qualcosa che riavvia il dispositivo. Quindi al momento non ho idea di cosa possa emettere il comportamento. E sì, ho applicato tutti i rimedi per prevenire arresti anomali del sistema operativo in quanto nessun turbo e aumento della dimensione minima della memoria della VM.

Ho usato semplici passaggi e ha funzionato perfettamente per me:

1. Apri un terminale di root in Raspberry Pi. Ora devi modificare lo script che avvia X. Nella build predefinita con lightdm.

2. Apri il file "lightdm.conf" che si trova in,

   /etc/lightdm/lightdm.conf

3. Aggiungi la riga seguente nella sezione SeatDefault(o Seat:*nelle versioni LightDM più recenti).

   [SeatDefaults]

   xserver-command = X -s 0 -dpms

4. Riavvia il tuo Raspberry Pi.

Ora il problema dovrebbe essere risolto.

Link alla fonte: http://chamaras.blogspot.com/2013/03/how-to-deactivate-monitor-sleep-in.html

Qualcosa è sbagliato. Il pi non ha una "modalità sleep".

Ho avuto il mio pi solo poche settimane e non l'ho lasciato per tutto il tempo, ma ho intenzione di farlo alla fine e l'ho lasciato acceso per alcuni lunghi tratti. Sto eseguendo raspbian e ho una antipatia personale per NetworkManager, lol, quindi è disabilitato. Per mantenere il wifi attivo, eseguo uno script che esegue il ping del router ogni cinque secondi. Se il ping fallisce, uccide l'attuale dhcpcd e prova a impostare nuovamente il wifi ogni 5 secondi fino a quando non riesce. Registra i tentativi, e infatti è attivo da oltre 24 ore senza bisogno di riconnettersi una volta, e quando vado a ssh in, nessun problema.

Hai già detto "Cercare di eseguire il polling di qualcosa dal dispositivo non impedisce di passare in modalità sospensione", quindi il mio punto qui è che il mio ovviamente non ha questo problema, quindi qualcosa non va.

Dici che "dormirà" ma sembra che tu debba effettivamente riavviare. Perché credi che stia dormendo? AFAICT, il pi non può andare a dormire, non ha una tale capacità. Cercando su Google, sembra esserci un po 'di confusione al riguardo da parte di persone che hanno problemi come il tuo.

Tieni presente che è presente un LED rosso che rimane acceso ogni volta che viene collegata l'alimentazione, indipendentemente dal fatto che il pi funzioni. Ma il pi è o avviato e in esecuzione o arrestato, non ha una modalità di sospensione, standby, ibernazione, ecc .

Quindi il tuo pi si è schiantato, arrestato o si trova in una sorta di errato stato di congelamento. Senti di vedere se è più che leggermente caldo, il che indicherebbe che il processore è in un ciclo occupato perpetuo (un motivo per cui potrebbe essere acceso ma non risponde).

Immagino che uno dei motivi per cui credi che stia dormendo è il "tentativo di collegare qualcosa che riavvia il dispositivo". Ciò può accadere quando il dispositivo è completamente arrestato (provalo); è perché alcuni dispositivi causeranno una breve caduta di tensione (ma vedi NOTA) quando viene collegato per la prima volta, il che equivale a scollegare il pi quindi a ricollegarlo di nuovo - che come sai, ricollegarlo provoca l'avvio. Il mio dongle wifi di dimensioni nano farà questo.

NOTA: In realtà i nostri pi sono stati probabilmente realizzati dall'agosto scorso, quando i polifusi sono stati sostituiti con "pantaloncini" - so molto poco sui componenti elettronici o sull'elettricità, ma evidentemente il problema WRT al riavvio da dispositivi USB rimane lo stesso .

So che questa è una vecchia domanda, ma è stato il primo risultato che è emerso nella mia ricerca quando ho avuto essenzialmente lo stesso problema sul mio Pi Zero appena installato.

Ho trovato la chiave della mia risposta su quest'altra domanda , tra le altre fonti.

Quindi sostanzialmente, sebbene il Pi stesso apparentemente non abbia una modalità di sospensione, i singoli dispositivi in ​​Linux (inclusi gli adattatori di rete) possono. Quando ho provato a eseguire il comando iw wlan0 get power_savecome menzionato sopra, all'inizio ho continuato a ricevere un errore. Ciò è stato risolto aggiornando il sistema operativo:

sudo apt-get update && apt-get upgrade

Quindi ho riavviato: sudo reboot now

Successivamente, il iwcomando ha verificato che la modalità power_save era effettivamente attivata. Quindi l'ho spento:

sudo iw wlan0 set power_save off

Da allora, va tutto bene. Il mio schermo andrà in sospensione, ma la connessione di rete rimane attiva e sono in grado di accedere al mio Pi anche dopo che è rimasto inattivo per un po '.

Sembra che il tuo dongle wifi inizi a pulsare come un laptop in modalità standby, ma non hai confermato che il Pi stesso si sta spegnendo. Ho riscontrato lo stesso problema.

Ho provato questo, ma non l'ho applicato abbastanza a lungo per sapere se ha risolto il mio problema specifico: https://raspberrypi.stackexchange.com/a/4518/4271

Verificherei problemi di alimentazione. Il collegamento di dispositivi che causano il riavvio di RPI non sembra correlato a nessun tipo di modalità di sospensione.

Come test rapido, farei questo: scrivere un piccolo script (python / will, qualunque cosa sia più maneggevole) e farlo inviare una semplice e-mail "I am good" e inserirla nel crontab per eseguire ogni 30 minuti circa e guarda come va

Mi chiedo se sto sperimentando qualcosa di simile. Sarei interessato al set di chip del tuo dongle e al driver che stai usando?

Ne ho uno basato sul chip RT3072 usando il driver rt2800usb / cfg80211. Se lo eseguo in modalità Master, ad es. Un punto di accesso o come client normale per un punto di accesso / router, sembra che vada in modalità sospensione e impieghi un po 'di tempo a rispondere. Ho impostato il mio laptop per eseguire il ping del pi attraverso l'adattatore wifi a intervalli di circa 1 secondo. Ho confermato che sia in modalità master che client, a volte il ping sarebbe scaduto ~ 5-10 secondi in modalità client e 5-25 secondi in modalità Master. In modalità master, i timeout sono stati peggiorati molto se ho eseguito l'AP in 'n mode' con HT e WMM abilitati in hostapd.conf. In 'g mode' non era affatto così cattivo.

Ho sperimentato un altro dongle wifi utilizzando il chip RTL8188SU con driver di staging r8712u. Sfortunatamente, non sono riuscito a farlo funzionare in modalità Master ma, come client, era molto più stabile di quello RT3072.

Con il 3072 in modalità client non c'era un tipico ritardo del ping - erano casuali da 2ms - 320ms con un timeout occasionale. Con 8188SU, il ritardo di ping tipico era di 2-3 ms con un ritardo occasionale di 166-200 ms - nessun timeout osservabile. Ciò che era particolarmente strano era che se avessi aperto una sessione ssh sul pi e impostato il top in esecuzione a 0,01 secondi - quindi c'era un sacco di carico della CPU e un 'sacco' di traffico wifi, le prestazioni del 3072 erano notevolmente migliorate con tempi di ping in genere 2-3ms. Il caricamento ha avuto un effetto simile sul 3072 funzionante in modalità Master.

Non so cosa stia succedendo, ma sarei molto interessato se altri utenti potessero prendere il tempo di fare un test ping simile sul loro pi e riferire i loro risultati insieme alla loro configurazione e driver. Sarebbe interessante se gli altri trovassero che i tempi di risposta casuali e scarsi sono migliorati caricando il traffico del processore / wifi usando top come ho fatto io, o dire di trovare qualsiasi cosa che crei un po 'di lavoro e traffico tcp / ip sul wifi.

Solo per informazione, ho avuto questo problema, quindi ho cercato una soluzione qui e ho trovato questa domanda.

Tuttavia in seguito ho scoperto che era solo il mio Pi che si surriscaldava per l'aspetto delle cose. Una volta l'ho tirato fuori dal suo caso. Il problema sembra essere scomparso

Per me ha funzionato modificando /etc/X11/xinit/xserverrce cambiando

exec /usr/bin/X -nolisten tcp "$@"

di

exec /usr/bin/X -s 0 dpms -nolisten tcp "$@"

Sto usando Raspbian "wheezy" e inizio la mia sessione X con startx.

Fonte: http://www.raspberrypi.org/forums/viewtopic.php?f=66&t=18200

Mentre sono d'accordo con @goldilocks sul fatto che il dispositivo pi non ha una funzione sleep, il kernel può comunque spegnere l'I / O specifico mentre il dispositivo è in esecuzione. È attraverso questo ragionamento che potresti voler provare la seguente modifica nei file KBD e riavviare il dispositivo:

Apporta la seguente modifica in / etc / kbd / config: POWERDOWN_TIME = 0

Presumo che tu definisca dormire come lo schermo che si spegne. Questo è quello che ho scoperto di funzionare:

sudo setterm -powersave off