# IDE-Fehlerbehandlung:Linux zu zimperlich im Vgl. zu Windows?

## sprittwicht

Moin!

Mein IDE-Brenner kann keine Daten-CDs mehr einlesen. Nach dem Einlegen blinkt die LED wie wild und im syslog tauchen folgende Fehler auf:

```

Jul 25 12:10:53 gronk kernel: [  511.053884] hdd: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }

Jul 25 12:10:53 gronk kernel: [  511.053892] hdd: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }

Jul 25 12:10:53 gronk kernel: [  511.053895] hdd: possibly failed opcode: 0xa0

Jul 25 12:11:00 gronk kernel: [  518.170363] hdd: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }

Jul 25 12:11:00 gronk kernel: [  518.170375] hdd: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }

Jul 25 12:11:00 gronk kernel: [  518.170382] hdd: possibly failed opcode: 0xa0

Jul 25 12:11:08 gronk kernel: [  525.352526] hdd: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }

Jul 25 12:11:08 gronk kernel: [  525.352538] hdd: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }

Jul 25 12:11:08 gronk kernel: [  525.352545] hdd: possibly failed opcode: 0xa0

Jul 25 12:11:15 gronk kernel: [  532.468887] hdd: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }

Jul 25 12:11:15 gronk kernel: [  532.468896] hdd: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }

Jul 25 12:11:15 gronk kernel: [  532.468899] hdd: possibly failed opcode: 0xa0

Jul 25 12:11:15 gronk kernel: [  532.468904] hdd: DMA disabled

Jul 25 12:11:15 gronk kernel: [  532.515086] hdd: ATAPI reset complete

Jul 25 12:11:22 gronk kernel: [  539.649038] hdd: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }

Jul 25 12:11:22 gronk kernel: [  539.649050] hdd: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }

Jul 25 12:11:22 gronk kernel: [  539.649057] hdd: possibly failed opcode: 0xa0

Jul 25 12:11:29 gronk kernel: [  546.831198] hdd: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }

Jul 25 12:11:29 gronk kernel: [  546.831210] hdd: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }

Jul 25 12:11:29 gronk kernel: [  546.831217] hdd: possibly failed opcode: 0xa0

Jul 25 12:11:36 gronk kernel: [  553.947828] hdd: cdrom_decode_status: status=0x51 { DriveReady SeekComplete Error }

Jul 25 12:11:36 gronk kernel: [  553.947840] hdd: cdrom_decode_status: error=0x40 { LastFailedSense=0x04 }

Jul 25 12:11:36 gronk kernel: [  553.947847] hdd: possibly failed opcode: 0xa0

Jul 25 12:11:36 gronk kernel: [  553.992585] hdd: ATAPI reset complete

Jul 25 12:11:36 gronk kernel: [  554.009039] end_request: I/O error, dev hdd, sector 925440

Jul 25 12:11:36 gronk kernel: [  554.009049] __ratelimit: 2 callbacks suppressed

Jul 25 12:11:36 gronk kernel: [  554.009054] Buffer I/O error on device hdd, logical block 231360

```

Unter Windows keine Probleme, unter Linux vorher auch noch nicht. Irgendwelche Ideen?

EDIT 1.8.2010: Titel angepasstLast edited by sprittwicht on Sun Aug 01, 2010 7:45 am; edited 1 time in total

----------

## Josef.95

Hi

/dev/hdd

Man sollte mittlerweile die veralteten PATA Treibern nicht mehr nutzen, zumindest dann nicht wenn ein aktueller Kernel und udev Version verwendet wird.

Man sollte inzwischen, wo möglich immer die libata Treiber nutzen!

Siehe zb auch Hier

/edit: oder gleich direkt Hier

----------

## sprittwicht

Am Kernel hab ich nichts geändert, ist immer noch 2.6.30 (tuxonice-sources).

Udev hab ich mit und ohne hd*-Regeln probiert, und auch die Vorgängerversion, die vorher problemlos lief.

Wüsste nicht was ich hier geändert habe, dass es auf einmal nicht mehr funktionieren soll, hm...

Mit dem libata-Quatsch probier ich dann mal wenn ich Langeweile hab. Dachte es gäb vielleicht einen schnellen Workaround, oder zumindest eine Erklärung warum's auf einmal nicht mehr tut.

Nebenbei mal wieder ein geniales Update, klammheimlich hd* rauskicken und noch nichtmal per Default das USE-Flag setzen, damit sich die Leute nicht ihr System zerschießen. Ist mir persönlich ja egal, weil nur CD-ROM, aber einigen Leuten mit IDE-Festplatten dürfte das unterhaltsame Augenblicke beschert haben...  :Rolling Eyes: 

----------

## mokia

OFF:

 *sprittwicht wrote:*   

> Nebenbei mal wieder ein geniales Update, klammheimlich hd* rauskicken und noch nichtmal per Default das USE-Flag setzen, damit sich die Leute nicht ihr System zerschießen. Ist mir persönlich ja egal, weil nur CD-ROM, aber einigen Leuten mit IDE-Festplatten dürfte das unterhaltsame Augenblicke beschert haben... 

 

+1

Arbeitsplatz +3

Und das schöne daran, zwei davon werden nicht richtig unter libata unterstützt. 

:FFO

Mit welchen wersionen von udev hast du experimentiert?

----------

## Josef.95

 *sprittwicht wrote:*   

> Nebenbei mal wieder ein geniales Update, klammheimlich hd* rauskicken und noch nichtmal per Default das USE-Flag setzen, damit sich die Leute nicht ihr System zerschießen. Ist mir persönlich ja egal, weil nur CD-ROM, aber einigen Leuten mit IDE-Festplatten dürfte das unterhaltsame Augenblicke beschert haben... 

  Falsch!

Es wurde nichts klammheimlich rausgekickt, und von einer nicht default Use-Flag kann auch keine rede sein.

 *sys-fs/udev-151-r1 wrote:*   

> old-hd-rules use flag is enabled (by default).
> 
> This adds the removed rules for /dev/hd* devices
> 
> Please migrate to the new libata.

   *sys-fs/udev-151-r4 wrote:*   

> This version of udev no longer has use flag old-hd-rules enabled
> 
> So all special rules for /dev/hd* devices are missing
> 
> Please migrate to the new libata if you need these rules.
> ...

 

...

 *sys-fs/udev-157 wrote:*   

> Rules for /dev/hd* devices have been removed
> 
> Please migrate to libata.

 

Wer also ein klein wenig mit drauf achtet was auf dem System beim Update geschieht hat es durchaus mitbekommen können  :Wink: 

BTW: 

```
# eix -Ie udev

[I] sys-fs/udev

     Available versions:  114 115-r1 119 124-r1 124-r2 141 (~)141-r1 (~)145!t (~)145-r1!t (~)145-r2!t (~)145-r3!t (~)146!t 146-r1!t (~)146-r2!t (~)146-r3!t (~)147-r1!t 149 (~)150-r1!t (~)151-r1 (~)151-r2 (~)151-r3 151-r4 (~)154 (~)156 (~)157 [m](~)158 (~)159 (~)160 **9999 {(+)devfs-compat (-)extras (+)old-hd-rules selinux test}                                                                                           

     Installed versions:  160(04:59:56 PM 07/13/2010)(extras -selinux -test)

     Homepage:            http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html

     Description:         Linux dynamic and persistent device naming support (aka userspace devfs)
```

 Und die mittlerweile, ca fünf Jahre alte IDE Platte funkt immer noch einwandfrei  :Wink: 

----------

## sprittwicht

 *Josef.95 wrote:*   

> 
> 
> Es wurde nichts klammheimlich rausgekickt, und von einer nicht default Use-Flag kann auch keine rede sein.
> 
>  *sys-fs/udev-151-r1 wrote:*   old-hd-rules use flag is enabled (by default).
> ...

 

Wann war 151-r1 denn x86 stable?

Bei mir war 149-irgendwas installiert, mit dem nächsten Update kam dann 151-r4 OHNE hdX-USE-Flag. Muss dazu sagen, dass das ein Zweitrechner ist den ich nur am Wochenende nutze, und dementsprechend nicht jeden Tag ein world-Update mache.

 *Josef.95 wrote:*   

> Wer also ein klein wenig mit drauf achtet was auf dem System beim Update geschieht hat es durchaus mitbekommen können  

 

Hat ja nichts mit drauf achten zu tun. Die Meldung kommt NACH dem Update, und damit ist die Bescherung perfekt.

Bei solch gravierenden Änderungen sollte Portage abbrechen. Auch dieser an anderen Stellen benutzte 10-Sekunden-Countdown ist Bullshit. Emerge läuft üblicherweise im Hintergrund, teilweise werden Dutzende von Paketen installiert, da starrt doch kein User auf die Konsole um so ein 10-Sekunden-Fenster für Fingerverrenkungen abzupassen.

Total OT, aber vielleicht als konstruktive Anregung für die Entwickler: Es gibt genug Ebuilds die mit "Lizenz zustimmen yes/no" eine interaktive Zwangspause einlegen. Das würde ich mir für _alle_ Ebuilds wünschen, in denen ein stumpfes Update dazu führt dass das System unter Umständen nicht mehr so läuft wie es eigentlich soll. Diese Abfragen sollten sich dann optional per emerge-Kommandozeilen-Schalter ausschalten lassen, wenn ein User sich der Gefahren bewusst ist und ein längeres Update unbeaufsichtigt durchrattern lassen will.

----------

## cyzz

 *Quote:*   

> 
> 
> Wer also ein klein wenig mit drauf achtet was auf dem System beim Update geschieht hat es durchaus mitbekommen können 
> 
> 

 

Es gibt doch ein Programm, mit dem man diese Messages (post-messages nach emerge) loggen kann.

Ich komm nicht mehr drauf wie das hieß -.-

cc

----------

## mokia

Na Ja, klammheimlich.... 

Bis vor kurzen existierte kein migracion guide zum libata. (Oficielles gibt es überhaupt nicht.) (Seit monathen nichts gefunden)

Das gentoo handbuch hat immernoch nur eine kleine bemerkung zum thema.

Tatsache ist das das ganze theater von kernel endviklung kommt, wo es klar und deutlich gesagt wurde, das kein treiber entfernt wirdt die nicht wollstendich unter libata implementiert ist. (Es wurde allerdings auch gesagt das gewisse chipsets nicht in libata implementiert werden.)

Was ich dammit shagen will das es fa:lle gibt Wo "Please migrate to the new libata." ironisch, oder sogar insultierend klingt.

----------

## Josef.95

 *sprittwicht wrote:*   

> Wann war 151-r1 denn x86 stable?
> 
> Bei mir war 149-irgendwas installiert, mit dem nächsten Update kam dann 151-r4 OHNE hdX-USE-Flag. Muss dazu sagen, dass das ein Zweitrechner ist den ich nur am Wochenende nutze, und dementsprechend nicht jeden Tag ein world-Update mache.
> 
>  *Josef.95 wrote:*   Wer also ein klein wenig mit drauf achtet was auf dem System beim Update geschieht hat es durchaus mitbekommen können  
> ...

 

Wann oder ob udev-151-r1 stable war kann ich dir aktuell  nicht sicher sagen, ich nutze den stable Zweig nicht.

Aber das man solch "gravierenden" Änderungen erst nach dem mergen bemerkt muss nicht sein, da gebe ich dir recht.

Ich mache das aber idR anders herum: Ich nutze für den --sync meist "eix-sync" , somit hat man beim präsentierten eix-diff schon mal eine sehr  gute Übersicht was sich generell im Tree geändert hat. Wenn man dann ein "emerge -avuDN system" losschickt wird einem noch mal sehr schön, sogar in Farbe, dargestellt was sich ändert, und genau dort sollte man sich genau anschauen was sich bei den Use-Flags ändern würde, erst wenn das passt wird bestätigt das Update durchzuführen.

Aber Ok, ich will mich hier nun nicht auf das udev Update festbeißen... :Wink: 

Ich wollte dir eigentlich nur raten, sofern möglich, auf die libata Treiber zu migrieren, denn mit den veralteten Treiber gibt es bei immer mehr Leuten Probleme,  grade auch bei CD-Laufwerken.

----------

## mokia

Und das wichtigste habe ich wergessen.   :Very Happy: 

NeddySeagoon's Rough Guide to libata Migration:

https://forums.gentoo.org/viewtopic-t-837243.html

----------

## sprittwicht

Jo, wollte jetzt auch keine allgemeine Portage-Diskussion vom Zaun brechen.  :Smile: 

Dass an libata kein Weg vorbeiführt ist mir klar, sollte auch kein Problem sein, System ist noch nicht so alt.

Hoffentlich klappt's dann wieder mit dem Brenner, im Moment bin ich mir wie gesagt keiner Änderung bewusst, die das aktuelle Fehlverhalten hätte auslösen können...

----------

## mokia

 *cyzz wrote:*   

> 
> 
> Es gibt doch ein Programm, mit dem man diese Messages (post-messages nach emerge) loggen kann.
> 
> 

 

Mein persönliches fahorit ist:

```
less /var/log/portage/elog/summary.log
```

----------

## musv

Find ich krass, dass es noch immer Leute gibt, die mit den alten IDE-Treibern gearbeitet haben. Weiß nicht, vor wieviel Jahren ich schon auf die neuen Treiber umgestellt hatte. Hab nie Probleme damit gehabt.

----------

## sprittwicht

"Krass"?

"Immer noch"?

Bis 2.6.32 waren die PATA-Treiber noch ausdrücklich als "experimental" gekennzeichnet, also bitte...  :Wink: 

----------

## sprittwicht

Tja, mit libata sehen die Fehler dann so aus:

```

Aug  1 09:29:18 gronk kernel: [22127.513600] sr 7:0:1:0: [sr1] Unhandled sense code

Aug  1 09:29:18 gronk kernel: [22127.513608] sr 7:0:1:0: [sr1] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

Aug  1 09:29:18 gronk kernel: [22127.513615] sr 7:0:1:0: [sr1] Sense Key : Hardware Error [current]

Aug  1 09:29:18 gronk kernel: [22127.513621] sr 7:0:1:0: [sr1] Add. Sense: Timeout on logical unit

Aug  1 09:29:18 gronk kernel: [22127.513631] sr 7:0:1:0: [sr1] CDB: Read(10): 28 00 00 04 67 1a 00 00 01 00

Aug  1 09:29:18 gronk kernel: [22127.513643] end_request: I/O error, dev sr1, sector 1154152

Aug  1 09:29:18 gronk kernel: [22127.513650] Buffer I/O error on device sr1, logical block 288538

Aug  1 09:29:26 gronk kernel: [22134.708326] sr 7:0:1:0: [sr1] Unhandled sense code

Aug  1 09:29:26 gronk kernel: [22134.708334] sr 7:0:1:0: [sr1] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

Aug  1 09:29:26 gronk kernel: [22134.708341] sr 7:0:1:0: [sr1] Sense Key : Hardware Error [current]

Aug  1 09:29:26 gronk kernel: [22134.708348] sr 7:0:1:0: [sr1] Add. Sense: Timeout on logical unit

Aug  1 09:29:26 gronk kernel: [22134.708357] sr 7:0:1:0: [sr1] CDB: Read(10): 28 00 00 04 67 1a 00 00 01 00

Aug  1 09:29:26 gronk kernel: [22134.708368] end_request: I/O error, dev sr1, sector 1154152

Aug  1 09:29:26 gronk kernel: [22134.708375] Buffer I/O error on device sr1, logical block 288538

Aug  1 09:29:33 gronk kernel: [22141.878323] sr 7:0:1:0: [sr1] Unhandled sense code

Aug  1 09:29:33 gronk kernel: [22141.878330] sr 7:0:1:0: [sr1] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

Aug  1 09:29:33 gronk kernel: [22141.878337] sr 7:0:1:0: [sr1] Sense Key : Hardware Error [current]

Aug  1 09:29:33 gronk kernel: [22141.878344] sr 7:0:1:0: [sr1] Add. Sense: Timeout on logical unit

Aug  1 09:29:33 gronk kernel: [22141.878353] sr 7:0:1:0: [sr1] CDB: Read(10): 28 00 00 04 67 1a 00 00 01 00

Aug  1 09:29:33 gronk kernel: [22141.878364] end_request: I/O error, dev sr1, sector 1154152

Aug  1 09:29:33 gronk kernel: [22141.878371] Buffer I/O error on device sr1, logical block 288538

```

Weder eine abgeschlossene CDR, noch eine offene Multisession-CDR wird vom Brenner geschluckt. Das CD-ROM produziert ähnliche Fehler, kann die CDs aber meistens (!) doch noch lesen.

OK, wahrscheinlich haben die Medien einen Hau weg, aber: Unter Windows null Probleme mit beiden Medien, auf beiden Laufwerken.

----------

## toralf

[quote="cyzz"] *Quote:*   

> Es gibt doch ein Programm, mit dem man diese Messages (post-messages nach emerge) loggen kann.
> 
> Ich komm nicht mehr drauf wie das hieß -.-

 Das heißt Mailprogramm :

```
tfoerste@n22 ~ $ grep ELOG /etc/make.conf

PORTAGE_ELOG_CLASSES="log warn error"

PORTAGE_ELOG_SYSTEM="save mail"

PORTAGE_ELOG_MAILURI="tfoerste@localhost"

PORTAGE_ELOG_MAILFROM="portage@localhost"

```

----------

## marens

[quote="toralf"] *cyzz wrote:*   

>  *Quote:*   Es gibt doch ein Programm, mit dem man diese Messages (post-messages nach emerge) loggen kann.
> 
> Ich komm nicht mehr drauf wie das hieß -.- Das heißt Mailprogramm :
> 
> ```
> ...

 

Praktisch finde ich es auch sich bei Fehlern oder Warnungen direkt per app-portage/portage-mod_jabber anquäken zu lassen.

```
jabber:error,warn
```

Die normalen Meldungen schau ich mir sonst auch immer per Mailprogramm an.

----------

