Se avete problemi con l'installazione e la configurazione di Slackware postate qui. Non usate questo forum per argomenti generali... per quelli usate Gnu/Linux in genere.
Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Slackware, se l'argomento è generale usate il forum Gnu/Linux in genere.
3) Leggere attentamente le risposte ricevute.
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Ho installato la 12.0 su un Celeron 400 , mainboard chipset BX UDMA 33 funziona quasi tutto ma ho un fastidioso problema al boot ...
... il chipset del controller non viene riconosciuto correttamente e dal dmsg
vedo tutta una serie di errori e l' l ultradma viene disattivato ... inutile dire che se al termine del boot lo riattivo funziona tutto quanto ...
Ecco uno stralcio ...
Se disattivo udev tutto torna a posto ma ovviamente i driver del controller sono in modalità compatibile ... (modulo ata_generic) ma come lo rilancio riviene fuori questo pasticcio ...
Ultima modifica di Luci0 il gio 2 ago 2007, 14:20, modificato 1 volta in totale.
Ho fatto ricerche ... il disco testato con le utility della Seagate é ok ... il problema sembra essere che per qualche motivo la routine di attivazione dell' UDMA.
Cerco di spiegare ...
Il kernel ha un valore di LBA uguale a 39102336, letto dal firmware del disco e prima di attivare l'UDMA controlla se é vero cercando di leggere proprio l' ultimo settore , ma causa del valore errato il settore non esiste fisicamente, il test ritorna un errore e il kernel che fa il suo lavoro diligentemente lascia il disco in pio mode ...
Hdparm fa il suo lavoro senza controllare e funziona.
Sono affetti da questo bug i dischi della serie U5 Seagate (quelli con la gomma) qualcuno ha ipotizzato che dovrebbe essere sufficiente non fare partizioni fino alla fine del disco per risolvere il problema ... ma io ho fatto prima... l' ho sostituito perchè oltre ad essere incompatibile con linux é lento e rumoroso ... !!!
Ho riscritto il post precedente spero che sia più chiaro ...
Una soluzione potrebbe essere quella di riprogramme il firmware per far sì che il disco riporti un valore di LBA più basso, in tal modo il kernel riuscirebbe a leggere il settore ... forse nelle seatools c' é in utility ... per fare questo ... ora ci provo .... tanto ormai il disco l' ho clonato ...
Aggiornamento ... con le utility Seatools si può cambiare il valore LBA ... ma il kernel continua imperterrito a riportare lo stesso valore ... sembra non risolvibile a meno di un vero update del fimware dell' hard disk ...
Ecco quello che dice Alan Cox ...
I'm going to close this WONTFIX, simply because the required work to fix it in the old IDE layer is huge and would be risky. Realistically it won't happen. The SCSI core (used by libata) appears to already handle the odd sized media cases correctly.
