Old:ACPI e DSDT: differenze tra le versioni

m
nessun oggetto della modifica
mNessun oggetto della modifica
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 <tt>sources.list</tt> un repository per Etch, ed impartire, da root, il comando
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>/proc</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 /proc/acpi/dsdt > dsdt.dat</pre>
<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 (<tt>Error 1048</tt>), oltre ad un warning. Andiamo a vedere le sezioni incriminate. La prima è:
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 <tt>Local0</tt>, ma non viene mai dichiarata.  
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 <tt>Store</tt> è una funzione di assegnazione verso destra: alla variabile a destra viene assegnato il valore (o il valore della variabile) che si trova a sinistra.  
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 <tt>Local0</tt> il valore che ha già, quindi per correggere l'errore non faccio altro che cancellare l'istruzione commentandola:
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 <tt>\_WAK</tt>, 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.
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) <tt>0x56</tt> alla variabile <tt>SMIP</tt>, se invece si chiama 'Microsoft Windows NT' assegna <tt>0x58</tt> alla variabile <tt>SMIP</tt> e zero alle variabili <tt>OSFX</tt> e <tt>OSFL</tt>; se il S.O. è diverso da quelli elencati assegna alle tre variabili, rispettivamente, <tt>0x57</tt>, <tt>0x02</tt> e <tt>0x02</tt>".
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 <tt>SMIP</tt>, <tt>OSFX</tt> e <tt>OSFL</tt> vengono inizializzate altrove, e quindi, in sostanza, il presente codice è inutile (se non dannoso ;-)), quindi l'ho semplicemente eliminato.
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 <tt>file</tt>.  
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 <tt>gzip</tt>: per indagare oltre è sufficiente decomprimere una copia del file (notate l'aggiunta del suffisso .gz, senza il quale <tt>gunzip</tt> rifiuta di decomprimere il file): l'initramfs è un archivio <tt>cpio</tt>.
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 <tt><versione></tt> è il nome della directory che contiene i moduli, e che trovate in <tt>/lib/modules/</tt>.
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):
6 999

contributi