slacky.eu

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 ...

EDIT: leggendo qui (non avevo letto bene l'errore tuo) mi affretterei a fare un backup dei dati! hai un settore (il sector=39102336) che e' andato!
fonte: http://www.uwsg.indiana.edu/hypermail/l ... /0393.html

qui hanno risolto sembrerebbe!
http://www.linuxquestions.org/questions ... p?t=480669

in poche parole devi forzare il dma prova e facci sapere!

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 ... !!!

Ecco la fonte ... (c' é anche Alan Cox)
https://bugzilla.redhat.com/bugzilla/sh ... ?id=179564

Ho lo stesso tipo di errore, l'avevo anche con la 11.0 credo che sia da imputare ad un disco rigido mal funzionante! Spero di no!

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.