ACPI è un modo fondamentalmente nuovo di utilizzare dispositivi, gestire le risorse elettriche, e fornire accesso standardizzato all'hardware gestito precedentemente dal BIOS. Si stanno facendo progressi per far funzionare ACPI su tutti i sistemi, ma continuano ad apparire bachi nel codice del Linguaggio Macchina ACPI (AML), incompletezza nel sottosistema kernel di FreeBSD, e bachi nell'interprete ACPI-CA di Intel®.
Questo documento è creato per aiutarti ad assistere i manutentori di ACPI di FreeBSD nell'identificare le cause primarie dei problemi che riscontri e debuggare e sviluppare una soluzione. Grazie per l'attenzione e speriamo di poter risolvere i problemi del tuo sistema.
Prima di sottomettere un problema, accertati di avere in esecuzione l'ultima versione del BIOS e, se disponibile, la versione del firmware del controller integrato.
Per quelli di voi che vogliono sottomettere un problema subito, per favore inviate la seguente informazione a freebsd-acpi@FreeBSD.org:
Descrizione del comportamento affetto da bachi, inclusi il tipo di sistema ed il modello e tutto quello che fa sì che il baco appaia. Inoltre, per favore annotati il più accuratamente possibile quando il baco è iniziato ad apparire se è nuovo per il tuo sistema.
L'output del comando dmesg(8) dopo
boot -v
, incluso ogni messaggio di errore
generato dal tuo sistema mentre investigavi questo baco.
L'output del comando dmesg(8) dopo
boot -v
con ACPI
disabilitato, se disabitarlo ti aiuta a rimettere
a posto il sistema.
L'output di sysctl hw.acpi
.
Anche questo è un buon modo di figurarti
quali caratteristiche il tuo sistema offre.
URL dove il tuo ACPI Source Language (ASL) risiede. Non inviare la ASL direttamente alla lista dato che può essere molto grande. Generate una copia della vostra ASL eseguendo questo comando:
#
acpidump -dt > name-system.asl
(Sostituite name
con la vostra login ed il modello/manifattura
del sistema
. Ad esempio
njl-FooCoo6000.asl
)
Molti degli sviluppatori seguono la mailing list su FreeBSD-CURRENT ma per favore sottomettete i vostri problemi a freebsd-acpi per essere sicuri che siano visti. Per favore siate pazienti, abbiamo tutti lavori full-time altrove. Se i vostri bachi non sono chiarissimi, vi chiederemo di sottomettere un PR attraverso send-pr(1). Quando si invia un PR, per favore includete le stesse informazioni sopracitate. Questo aiuterà a tracciare il problema e risolverlo. Non inviare un PR senza prima inviare una email a freebsd-acpi, dato che noi usiamo PR come promemoria di problemi esistenti, non come meccanismo di reporting. È probabile che i vostri problemi siano stati riportati da qualcun altro prima.
ACPI è presente su tutti i computer moderni che conformi all'architettura ia32(x86), ia64 (Itanium), e amd64 (AMD). L'intero standard ha molte caratteristiche che includono la gestione della performance della CPU, il controllo dei piani energetici, delle zone termiche, delle batterie del sistema, controller incorporati, ed enumerazione dei bus. Molti sistemi implementano meno dello standard completo. Per esempio, un sistema desktop di solito implementa le parti di enumerazione dei bus mentre un laptop potrebbe avere il raffreddamento ed anche il supporto alla gestione della batteria. I laptop hanno anche sospensioni e riavvii, con la loro complessità associata.
Un sistema ACPI-compliant ha molte componenti. Il BIOS ed i venditori di chipset forniscono varie tabelle fisse in memoria (ad esempio FADT) che specificano cose come la mappa APIC (usata per SMP), i registri di configurazione, e semplici valori di configurazione. Inoltre viene fornita una tabella di codici di byte (la Differentiated System Description Table DSDT) per specificare uno spazio dei nomi ad albero di dispositivi e metodi.
Il driver ACPI deve fare il
parse delle tabelle fisse, implementare un interprete
per il codice di byte, e modificare i device driver ed
il kernel per accettare informazioni dal sottosistema
ACPI. Per FreeBSD, Intel® ha fornito
un interprete (ACPI-CA) che è
condiviso fra Linux e NetBSD. Il path al codice
sorgente ACPI-CA è
src/sys/contrib/dev/acpica
.
Il codice che permette ad ACPI-CA di lavorare
con FreeBSD è in src/sys/dev/acpica/Osd
.
Finalmente, i driver che implementano vari dispositivi
ACPI si trovano in
src/sys/dev/acpica
.
Affincè ACPI funzioni correttamente tutte le parti devono funzionare correttamente. Ci sono alcuni problemi comuni, in ordine di frequenza di apparizione, ed alcuni possibili workaround o mezzi per aggiustarli.
In alcuni casi, ripartire dopo una operazione di
sospensione, fa sì che il mouse non riparta.
Un noto workaround è aggiungere
hint.psm.0.flags="0x3000"
al file /boot/loader.conf
.
Se questo non funziona allora per favore considera
l'invio di un report del baco come descritto
in precedenza.
ACPI ha tre stati di sospensione
RAM (STR),
S1
-S3
ed un
stato di sospensione disco (STD
),
chiamato S4
. S5
è il «soft off» ed è
il normale stato in cui il tuo sistema
si trova quando è collegato ma non acceso.
S4
può essere implementato
in due modi separati. S4
BIOS è una
sospensione BIOS-assistita
da disco. S4
OS
è implementato direttamente
dal sistema operativo.
Inizia a controllare
sysctl hw.acpi
per
le entry relative alla sospensione.
Questi sono i risultati per un Thinkpad:
hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.s4bios: 0
Questo significa che possiamo usare
acpiconf -s
per testare
S3
, S4
OS,
S5
. Se s4bios
fosse stato uno (1
), avremmo supporto a
S4
BIOS
invece di S4
OS.
Quando si testa la sospensione/riavvio, inizia con
S1
, se supportato.
È più probabile che funzioni questo stato
dato che non richiede molto supporto dal driver.
Nessuno ha implementato S2
,
ma se tu lo hai, è simile a S1
.
La prossima cosa da provare è S3
.
Questo è lo stato più profondo
STR e richiede molto supporto
dal driver per reinizializzare il tuo hardware.
Se hai problemi a riavviarlo, sentiti libero
di segnalarlo via mail alla lista freebsd-acpi ma non
aspettarti che il problema sia risolto dato che ci
sono molti driver/hardware che hanno bisogno
di test e di lavoro aggiuntivo.
Per aiutare ad isolare il problema, rimuovi quanti
più driver possibile dal tuo kernel. Se funziona,
puoi scoprire quale driver causa il problema
caricando dei driver fino a che il problema si
ripresenta. Tipicamente i driver binari come
nvidia.ko
, i driver di display
di X11, e USB avranno la maggior parte
dei problemi mentre interfacce Ethernet funzioneranno bene.
Se puoi caricare/scaricare driver correttamente, puoi
automatizzare questo piazzando i comandi appropriati
in /etc/rc.suspend
e
/etc/rc.resume
. C'è
un esempio commentato su come caricare e scaricare un driver.
Prova a impostare hw.acpi.reset_video
a zero
(0
) se il tuo display è confuso
dopo il riavvio. Prova a impostare valori più lunghi
o corti per hw.acpi.sleep_delay
per
vedere se aiuta.
Un'altra cosa da provare è caricare una distribuzione Linux recente con supporto ACPI e testare il loro supporto sospensione/riavvio sullo stesso hardware. Se funziona su Linux, è probabile che sia un problema driver relativo a FreeBSD e restringere il campo di indagine su quale driver causi il problema può aiutare a risolvere il problema. Notate che i manutentori di ACPI non mantengono altri driver (ad esempio suono, ATA, etc.) così ogni lavoro fatto sull'identificazione del problema del driver dovrebbe alla fine essere risolto dalla lista freebsd-current e inviato via mail al manutentore del driver. Se ti senti avventuroso, vai avanti e inizia a porre qualche printf(3) in un driver che dà problemi per tracciare in quale driver nella sua funzione di resume vada in palla.
Alla fine, cerca di disabilitare ACPI ed ad abilitare APM invece. Se la sospensione ed il riavvio funziona con APM, è meglio che tu continui con APM, specialmente su hardware vecchio (pre-2000). Ci vuole un pò di tempo per i venditori per ottenere un supporto corretto all'ACPI e l'hardware più vecchio è più probabile che abbia problemi BIOS con ACPI.
La maggior parte dei blocchisono causati da interrupt persi o da una tempesta di interrupt. I chipset hanno un sacco di problemi su come il BIOS configuri gli interrupt prima del boot, la correttezza delle tabelle ACPI (MADT) ed il routing del System Control Interrupt (SCI).
Le tempeste di interrupt possono essere distinte
da interrupt persi controllando l'output di
vmstat -i
e guardando alla linea che
riguarda acpi0
. Se il contatore
sta avanzando più di un paio di secondi per volta,
hai una tempesta di interrupt. Se il sistema si blocca,
cerca di di entrare in DDB
(CTRL+ALT+ESC sulla
console) e digita show interrupts
.
Il modo migliore in caso di problemi di interrupt è
provare a disabilitare il supporto APIC
con hint.apic.0.disabled="1"
in
loader.conf
.
I panici sono relativamente rari per ACPI
e sono il primo problema ad essere
corretto. Il primo passo da fare è riprodurre
il panico (se possibile) ed ottenere un backtrace. Segui
l'avvertimento per abilitare options DDB
e imposta una console seriale (vedi la Sezione 24.6.5.3, «Accesso al Debugger DDB dalla Linea Seriale»)
o imposta una partizione di dump(8). Puoi ottenere
un backtrace in DDB con tr
.
Se hai scritto a mano il backtrace, accertati di ottenere
le ultime cinque (5) e le prime cinque (5) linee nella
traccia.
Poi, prova ad isolare il problema facendo boot con
ACPI disabilitato. Se funziona, puoi
isolare il sottosistema ACPI usando vari valori
di debug.acpi.disable
. Leggi la pagina di
manuale di acpi(4) per alcuni esempi.
Prima, cerca di impostare
hw.acpi.disable_on_poweroff="0"
in
loader.conf(5).
Questo fa sì che ACPI abbia disabilitato
alcuni eventi durante il processo di shutdown. Alcuni sistemi
hanno bisogno di impostare questo valore a 1
(il default) per la stessa ragione. Questo di solito aggiusta
il problema di un sistema che si accende spontaneamente dopo
una sospensione o uno spegnimento.
Se hai altri problemi con ACPI (lavorare con un docking station, dispositivi non trovati, ecc.), per favore invia via mail una descrizione anche alla mailing list; comunque, alcune di queste questioni possono essere correlate a parti del sottosistema ACPI così può volerci un pò prima che siano implementate. Per favore sii paziente e preparato a testare le patch che ti vengono inviate.
Il più comune problema è il BIOS di venditori che forniscono bytecode incorretto (o addirittura con bachi). Questo si deduce usualmente da messaggi del kernel come questo:
ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\ (Node 0xc3f6d160), AE_NOT_FOUND
Spesso puoi risolvere questi problemi aggiornando il tuo
BIOS all'ultima versione. La maggior parte
dei messaggi di console non indica nulla di notevole, ma se hai
altri problemi come lo stato della batteria non funzionante, questi sono
un buon inizio per iniziare a cercare problemi in
AML.
Il bytecode, noto come AML, è compilato da
un insieme di codici sorgenti chiamato ASL.
L'AML, è trovato nella
tabella nota come come DSDT. Per trovare una
copia del tuo ASL usa acpidump(8). Dovresti
usare entrambe le opzioni -t
(mostra i
contenuti della tabella fissa) e la -d
(disassembla
AML ad ASL).
Vedi la sezione Fornire
Informazione di Debug per un esempio della sintassi.
Il tuo primo controllo che puoi fare è ricompilare il tuo ASL per controllare errori. Possono essere ignorati i 'warning' ma gli errori sono bachi che impediranno all'ACPI di funzionare correttamente. Per ricompilare il tuo ASL, usa il comando seguente:
#
iasl your.asl
Alla lunga, il nostro obiettivo è avere
ACPI che funzioni per tutti senza intervento. A
questo punto, comunque stiamo ancora sviluppando workaround per errori
comuni fatti dal venditore del BIOS.
L'interprete Microsoft® (acpi.sys
e
acpiec.sys
) non è strettamente conforme
agli standard, e così molti venditori
BIOS che testano solo ACPI
sotto Windows® non aggiustano mai il loro ASL.
Vogliamo continuare a identificare e documentare esattamente
quali comportamenti non standard sono concessi dall'interprete
Microsoft® e replicarlo cosicchè FreeBSD può
funzionare senza forzare gli utenti ad usare ASL.
Come workaround e per aiutarci ad identificare il comportamento
puoi fissare la ASL manualmente.
Se questo funziona per favore invia un diff(1)
del vecchio e del nuovo ASL,
cosicchè possiamo lavorare attorno al
comportamento bacato di ACPI-CA e così
rimettere a posto il necessario.
Qui c'è una lista di messaggi di errori comuni, le loro cause e come fissarli:
Alcuni AML assumono che il mondo
consiste di varie versioni Windows®. Puoi far sì che
FreeBSD simuli qualsiasi OS per vedere se questo
risolve il problema che hai. Un modo facile per sovrascrivere
questo è porre hw.acpi.osname="Windows 2001"
in /boot/loader.conf
o altre stringhe simili
che trovi nella ASL.
Alcuni metodi non ritornano esplicitamente un valore
come i requisiti standard. Mentre ACPI-CA
non gestisce questo, FreeBSD ha un workaround che permette
di ritornare i valori implicitamente. Puoi anche aggiungere
espliciti Valori di Ritorno dove si richiede se sai quale
valore dovrebbe essere ritornato. Per forzare
iasl
a compilare l'ASL
usa il flag -f
.
Dopo che personalizzi il tuo your.asl
,
potresti volerlo compilare, esegui:
#
iasl your.asl
Puoi aggiungere il flag -f
per forzare
la creazione dell'AML, anche se ci
sono errori durante la compilazione. Ricorda che alcuni
errori (ad esempio valori di Ritorno mancanti) sono
automaticamente riaggiustati dall'interprete.
DSDT.aml
è il nome del file
di default del comando iasl
.
Puoi caricare questo invece della copia
difettosa del tuo BIOS (che è
ancora presente in memoria) editando il file
/boot/loader.conf
come segue:
acpi_dsdt_load="YES" acpi_dsdt_name="/boot/DSDT.aml"
Assicurati di copiare il tuo file DSDT.aml
nella directory /boot
.
Il driver ACPI ha una facility di debug molto utile. Permette di specificare un insieme di sottosistemi come anche un livello di verbosità. I sottosistemi che desideri debuggare sono specificati come «strati» e sono divisi in componenti ACPI-CA (ACPI_ALL_COMPONENTS) e supporto hardware ACPI (ACPI_ALL_DRIVERS). La verbosità dell'output di debug è specificata come «livello» e varia da ACPI_LV_ERROR (riporta solo gli errori) ad ACIP_LV_VERBOSE (tutto). Il «livello» è una bitmask che fa sì che molte opzioni possano essere impostate una alla volta, separate da spazi. In pratica, puoi usare una console seriale per loggare l'output se è così lungo da riempire il buffer di messaggi della console. Una lista completa degli strati individuali e dei livelli è disponibile nella pagina man acpi(4).
L'output di debug non è abilitato di default.
Per abilitarlo, aggiungi options ACPI_DEBUG
al tuo file di configurazione del kernel se ACPI
è compilato nel kernel. Puoi aggiungere
ACPI_DEBUG=1
al tuo
/etc/make.conf
per abilitarlo in modo globale.
Se è un modulo, puoi ricompilare soltanto il tuo modulo
acpi.ko
come segue:
#
cd /sys/modules/acpi/acpi && make clean && make ACPI_DEBUG=1
Installa acpi.ko
in
/boot/kernel
ed aggiungi il tuo livello desiderato e gli strati
in loader.conf
.
Questo esempio abilita i messaggi per tutti i
componenti ACPI-CA e tutti i driver
hardware ACPI (CPU,
LID, etc.). Produrrà solo
messaggi di errore, i meno verbosi.
debug.acpi.layer="ACPI_ALL_COMPONENENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_ERROR"
Se l'informazione che vuoi ottenere è prodotta da
un evento specifico (ad esempio, una sospensione ed un riavvio),
puoi tralasciare i cambiamenti di loader.conf
ed invece usare sysctl
per specificare lo
strato ed il livello dopo il boot e preparare il tuo sistema
per l'evento specifico. I sysctl
sono nominati
allo stesso modo dei parametri in
loader.conf
.
Maggiori informazioni su ACPI possono essere trovate nei seguenti posti:
Gli archivi della mailing list ACPI
http://lists.freebsd.org/pipermail/freebsd-acpi/
I vecchi archivi della mailing list ACPI
http://home.jp.FreeBSD.org/mail-list/acpi-jp/
La specificazione ACPI 2.0
http://acpi.info/spec.htm
Le pagine man di FreeBSD: acpi(4), acpi_thermal(4), acpidump(8), iasl(8), acpidb(8)
Le risorse di debugging di DSDT. (Usa Compaq come esempio ma è sempre utile.)
Questo, ed altri documenti, possono essere scaricati da ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Per domande su FreeBSD, leggi la
documentazione prima di contattare
<questions@FreeBSD.org>.
Per domande su questa documentazione, invia una e-mail a
<doc@FreeBSD.org>.