6 999
contributi
Old:ACPI e DSDT: differenze tra le versioni
m
nessun oggetto della modifica
S3v (discussione | contributi) mNessun oggetto della modifica |
S3v (discussione | contributi) mNessun oggetto della modifica |
||
| Riga 35: | Riga 35: | ||
Uno dei motivi per cui le DSDT sono spesso difettose è che vengono compilate con il compilatore fornito da Microsoft, invece che con quello fornito da Intel. Curiosamente i sistemi Microsoft riescono ad evitare gli errori commessi dal compilatore della stessa società, mentre, come si può immaginare, la stessa cosa non succede per Linux. | Uno dei motivi per cui le DSDT sono spesso difettose è che vengono compilate con il compilatore fornito da Microsoft, invece che con quello fornito da Intel. Curiosamente i sistemi Microsoft riescono ad evitare gli errori commessi dal compilatore della stessa società, mentre, come si può immaginare, la stessa cosa non succede per Linux. | ||
Per installare il compilatore Intel è sufficiente avere nel < | Per installare il compilatore Intel è sufficiente avere nel <code>sources.list</code> un repository per Etch, ed impartire, da root, il comando | ||
<pre> | <pre> | ||
# aptitude install iasl | # aptitude install iasl | ||
| Riga 47: | Riga 47: | ||
=== Ottenere una DSDT === | === Ottenere una DSDT === | ||
È possibile ottenere la DSDT attualmente installata per poi correggere gli eventuali errori e problemi, copiandola da un file reso appositamente disponibile dal filesystem virtuale <code>/ | È possibile ottenere la DSDT attualmente installata per poi correggere gli eventuali errori e problemi, copiandola da un file reso appositamente disponibile dal filesystem virtuale <code>/sys</code>: | ||
<pre># cat / | <pre># cat /sys/firmware/acpi/tables/DSDT > dsdt.dat</pre> | ||
Ciò creerà un file '''dsdt.dat''' che contiene la DSDT compilata. | Ciò creerà un file '''dsdt.dat''' che contiene la DSDT compilata. | ||
| Riga 103: | Riga 103: | ||
</pre> | </pre> | ||
in sostanza, c'è un errore ripetuto identico tre volte (< | in sostanza, c'è un errore ripetuto identico tre volte (<code>Error 1048</code>), oltre ad un warning. Andiamo a vedere le sezioni incriminate. La prima è: | ||
<pre> | <pre> | ||
Scope (\_SI) | Scope (\_SI) | ||
| Riga 117: | Riga 117: | ||
} | } | ||
</pre> | </pre> | ||
Come si vede viene utilizzata due volte la variabile < | Come si vede viene utilizzata due volte la variabile <code>Local0</code>, ma non viene mai dichiarata. | ||
Vediamo di capire almeno un minimo il significato di questo pezzo di codice. | Vediamo di capire almeno un minimo il significato di questo pezzo di codice. | ||
La funzione < | La funzione <code>Store</code> è una funzione di assegnazione verso destra: alla variabile a destra viene assegnato il valore (o il valore della variabile) che si trova a sinistra. | ||
In questo caso, però, è evidente che questa assegnazione è del tutto inutile, perché viene assegnato alla variabile < | In questo caso, però, è evidente che questa assegnazione è del tutto inutile, perché viene assegnato alla variabile <code>Local0</code> il valore che ha già, quindi per correggere l'errore non faccio altro che cancellare l'istruzione commentandola: | ||
<pre> | <pre> | ||
Scope (\_SI) | Scope (\_SI) | ||
| Riga 165: | Riga 165: | ||
Le ultime righe mi danno la prova che l'errore ha a che fare con le porte USB, come avevo già notato. | Le ultime righe mi danno la prova che l'errore ha a che fare con le porte USB, come avevo già notato. | ||
Cercando in rete scopro che il metodo < | Cercando in rete scopro che il metodo <code>\_WAK</code>, che è una funzione utilizzata al risveglio da uno stato di risparmio energetico (o di spegnimento), deve restituire un valore, che indichi se l'operazione di risveglio è riuscita o meno. | ||
Una possibile diagnosi del mio problema, a questo punto, è che in certi casi durante il boot viene richiamato questo metodo, e il sistema si blocca in attesa di un risultato, che però non viene mai restituito. (N.d.A.: la diagnosi è evidentemente sbagliata, perché il problema persiste :() | Una possibile diagnosi del mio problema, a questo punto, è che in certi casi durante il boot viene richiamato questo metodo, e il sistema si blocca in attesa di un risultato, che però non viene mai restituito. (N.d.A.: la diagnosi è evidentemente sbagliata, perché il problema persiste :() | ||
| Riga 201: | Riga 201: | ||
} | } | ||
</pre> | </pre> | ||
Anche senza conoscere il linguaggio, il codice è facilmente interpretabile: "se il Sistema Operativo si chiama 'Microsoft Windows' assegna il valore (esadecimale) < | Anche senza conoscere il linguaggio, il codice è facilmente interpretabile: "se il Sistema Operativo si chiama 'Microsoft Windows' assegna il valore (esadecimale) <code>0x56</code> alla variabile <code>SMIP</code>, se invece si chiama 'Microsoft Windows NT' assegna <code>0x58</code> alla variabile <code>SMIP</code> e zero alle variabili <code>OSFX</code> e <code>OSFL</code>; se il S.O. è diverso da quelli elencati assegna alle tre variabili, rispettivamente, <code>0x57</code>, <code>0x02</code> e <code>0x02</code>". | ||
Per qualche motivo a me ignoto chi ha impostato questa DSDT ha fatto in modo di cambiare le funzionalità del sottosistema ACPI a seconda del S.O. che si usa. Poiché questo non mi rende particolarmente felice, ho modificato il codice in questo modo, eliminando di fatto il controllo: | Per qualche motivo a me ignoto chi ha impostato questa DSDT ha fatto in modo di cambiare le funzionalità del sottosistema ACPI a seconda del S.O. che si usa. Poiché questo non mi rende particolarmente felice, ho modificato il codice in questo modo, eliminando di fatto il controllo: | ||
| Riga 230: | Riga 230: | ||
Ora il mio sistema funziona un pochino meglio :-) | Ora il mio sistema funziona un pochino meglio :-) | ||
Aggiornamento: ricontrollando il codice ho notato che le tre variabili < | Aggiornamento: ricontrollando il codice ho notato che le tre variabili <code>SMIP</code>, <code>OSFX</code> e <code>OSFL</code> vengono inizializzate altrove, e quindi, in sostanza, il presente codice è inutile (se non dannoso ;-)), quindi l'ho semplicemente eliminato. | ||
| Riga 270: | Riga 270: | ||
Se usate un kernel standard Debian non è necessario ricompilare il kernel: è sufficiente posizionare la tabella DSDT nel posto giusto e ricreare l'initrd o l'initramfs. | Se usate un kernel standard Debian non è necessario ricompilare il kernel: è sufficiente posizionare la tabella DSDT nel posto giusto e ricreare l'initrd o l'initramfs. | ||
Per fare questo dovete prima verificare se il vostro kernel usa l'initrd o l'initramfs. | Per fare questo dovete prima verificare se il vostro kernel usa l'initrd o l'initramfs. | ||
I kernel Debian standard usano l'initramfs a partire dalla versione 2.6.14 compresa, ma per essere sicuri è sufficiente usare il comando < | I kernel Debian standard usano l'initramfs a partire dalla versione 2.6.14 compresa, ma per essere sicuri è sufficiente usare il comando <code>file</code>. | ||
Per esempio nel mio sistema ho: | Per esempio nel mio sistema ho: | ||
<pre> | <pre> | ||
| Riga 284: | Riga 284: | ||
che invece è un initramfs. | che invece è un initramfs. | ||
Distro diverse da Debian non usano il cramfs, e può darsi che a questa prima analisi si trovi comunque un file compresso con < | Distro diverse da Debian non usano il cramfs, e può darsi che a questa prima analisi si trovi comunque un file compresso con <code>gzip</code>: per indagare oltre è sufficiente decomprimere una copia del file (notate l'aggiunta del suffisso .gz, senza il quale <code>gunzip</code> rifiuta di decomprimere il file): l'initramfs è un archivio <code>cpio</code>. | ||
<pre> | <pre> | ||
| Riga 298: | Riga 298: | ||
# mkinitrd -o initrd-<versione> <versione> | # mkinitrd -o initrd-<versione> <versione> | ||
</pre> | </pre> | ||
in cui < | in cui <code><versione></code> è il nome della directory che contiene i moduli, e che trovate in <code>/lib/modules/</code>. | ||
Se usate l'initramfs (sempre da root): | Se usate l'initramfs (sempre da root): | ||