Newsgroup: it.comp.os.linux.iniziare
Titolo: Linux su Amilo A1655G e ventole sempre accese

Salve,
Ho un problema con questo portatile, cioè le ventole rimangono sempre 
accese quando avvio linux. (ho provato varie distribuzioni ma hanno 
tutte lo stesso problema)
Ho notato che, se prima avvio win e poi riavvio il sistema con linux, le 
ventole funzionano come dovrebbero.
Siccome vorrei levarmi via dal pc win al più presto, non è che qualcuno 
possa aiutarmi a risolvere questo problema?
Ringrazio anticipatamente


Dico la mia...
E' probabile che su Windows hai la impostato gestione automatica della
frequenza della Cpu e questa perciò, lavorando col moltiplicatore più basso,
riscaldi di meno.
Sul tuo linux devi configurare la stessa cosa altrimenti la Cpu gira
sempre al max e quindi diventa subito rovente con conseguente ventola a
palla.
La tua macchina dovrebbe montare un AMD Turion quindi puoi provare ad
installare Powernowd, ti gestisce la potenza in modalità "on demand",
cioè alza e abbassa la frequenza in relazione al carico di lavoro sul 
processore.
Se invece vuoi qualcosa di più personalizzabile puoi usare cpufreq, ma
io mi trovo ottimamente col primo sul mio Barton 2500+.
Saluti
VooLkaNo

 processore.
A questo ci avevo pensato anche io, ma, anche se gli metto lo scaling 
della cpu le ventole non si fermano, rimangono sempre accese come se non 
  avessi messo nulla.
Ho notato anche che, se avvio windows e poi riavvio il sistema con linux 
anche senza powernowd le ventole si accendono e si spengono come in windows.
Ho provato anche a fermarle con
  echo -n "3" > /proc/acpi/fan/FN.../state
  echo -n "on" > /proc/acpi/fan/FN.../state
ma le ventole non rispondono e rimangono sempre accese (ovviamente 
quando avvio la macchina senza aver avviato precedentemente win).
Ho trovato sul sito della Fujitsu-Siemens un aggiornamento del bios che 
aggiunge il gestore delle ventole anche per sistemi dos, ma è solo per 
cpu a 35W e la mia è una da 25W.
Adesso non ho proprio più idee su cosa fare.
Ringrazio anticipatamente di tutto.


Purtroppo è un problemaccio.
Risposta corta.
La gestione ACPI delle ventole non è perfettamente aderente alle 
specifiche ACPI, per cui con Linux le ventole vanno un po' come gli pare...
Per maggiori dettagli:
http://acpi.sourceforge.net/
Risposta lunga.
L'origine di tutto è in una tabella denominata DSDT (Differentiated 
System Description Table), che neanche i membri del consorzio ACPI 
spesso forniscono totalmente conforme allo standard da loro stessi 
definito. Il problema è aggravato dal fatto che Intel ha creato un 
compilatore per questa tabella (ebbene sì, esiste un linguaggio sorgente 
ed un linguaggio macchina anche per questo...) che è strettamente 
conforme alo standard. Il compilato viene incluso nel BIOS, e viene 
utilizzato dall'interprete ACPI del sistema operativo che altro non è 
che una macchina a stati, una sorta di microcontroller.
Fin qui tutto bene, ma entra in scena zio Bill, che come sapete ha  i 
suoi di standard, e si crea il suo compilatore del linguaggio ACPI (per 
la cronaca il linguaggio si chiama ASL, ACPI Source Language). Questo 
compilatore è di "bocca buona" e ignora alcune delle specifiche ACPI. 
Ovviamente il compilato è usato sull'interprete ACPI di zio Bill, che è 
altrettanto di "bocca buona", ed ignora gli errori.
Il problema esce fuori quando si usa un differente s.o. con le tabelle 
ACPI create dal compilatore di zio Bill, che nella più rosea ipotesi 
"funzionicchiano"...
Ho un Compaq Armada 1700, vecchiotto, ma in perfette condizioni. Dopo 
una ventina di minuti di uso normale andava in spegnimento di emergenza 
per surriscaldamento. Il problema era proprio lì, nella tabella DSDT, 
che faceva rimanere le ventole immobili anche quando il processore era 
incendescente. Unico modo per farle partire era staccare per un momento 
l'alimentazione a rete e riattaccarla, e le ventole partivano e non si 
fermavano più. Dopo tre-quattro shutdown di emergenza ho capito che non 
era il caso di rischiare la rottura, e mi sono armato di Google, 
trovando tutte le informazioni che ho appena dato, ed una possibile 
soluzione, anche se laboriosa e certamente non alla portata di tutti.
Esistono varie patch del kernel che permettono di caricare una tabella 
DSDT alternativa al momento del boot. Per ragioni che ignoro, non è 
possibile caricare la tabella successivamente, deve essere fatto alla 
partenza del kernel.
Una delle patch, che trovo molto comoda, permette di accodare una 
immagine della tabella DSDT al ramdisk iniziale (l'initrd per 
intenderci), e caricarla all'avvio. Questo permette di cambiare a 
piacimento la tabella fino a trovare la versione funzionante, senza 
dover ricompilare il kernel ogni volta. Alcune distribuzioni, 
sicuramente SUSE, includono questa patch nel kernel della distribuzione.
Il problema diventa poi trovare o creare una tabella DSDT corretta.
Sul sito ACPI in Sourceforge esiste una raccolta di DSDT funzionanti 
(con cui ho corretto quella del mio Armada 1700, che ora funziona 
perfettamente), ma da quello che ho visto il tuo modello non c'è.
Insomma: la soluzione definitiva include una probabile ricompilazione 
del kernel con patch "dsdt-in-initrd", la correzione della tabella DSDT 
e vari riavvii sperimentali...
Vedi tu se il gioco ne vale la candela...
-- 
Mario "Reliant" Pascucci
"From" field altered. Please use ilpettegolo(a)
yahoo.it
 for private mail.
http://ilpettegolo.altervista.org/

 
Sisi, il gioco vale la candela visto che non ho voglia di formattare il 
pc ogni 2 settimane circa perchè si impalla o perchè ha problemi di 
vario genere (attualmente ho win che ci mette tipo 10minuti per aprirmi 
la schermata della stampante e devo aspettarne altrettanti perchè si 
decida a capire che ho premuto ok per la stampa, oltre i 1000messaggi 
per avvertirmi che il programma si è impiantato).