ubuntuusers.de

So, nun haben wir einen Fehler eingefangen. Der Fehlercode war 7

1

#define DID_ERROR       0x07    /* Internal error       */

Leider kommt dieser Fehler massenhaft im Linux Kern vor.

Daher ist es notwendig in did Systemfehlermeldungen zu sehen und zu hoffen, daß der Kern eine verständliche Fehlermeldung ausgegeben hat...

Also sieh mal in die Meldungen des Kern und suche nach dem Zeitstempel als dieser error 7 gemeldet wurde.

Hi,

cdrecord-fubude: sg_io.host_status = 0x7

Das ist die erhoffte Einsicht:

http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/x291.html

SG_ERR_DID_ERROR [0x07] Internal error detected in the host adapter.
This may not be fatal (and the command may have succeeded). The aic7xxx
and sym53c8xx adapter drivers sometimes report this for data underruns
or overruns. [1]

Der Text stammt aus der Zeit von Linux 2.4 (~ 2001). Die erwaehnte SCSI Hardware hat natuerlich mit Deiner nichts mehr zu tun.

Tja ... da waeren wir wieder bei USB 3 und dem elenden Umgang mancher Linux Kernels damit.

Es ist gerade mal ein halbes Jahr her, da hatte ich einen host_status 0x7 auf dem Tisch https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789260. Folgendes wurde am Schluss kolportiert:

"After disabling USB 3.0 in BIOS I was able to successfully burn DVD using cdrskin." (Er hat USB 3.0 im BIOS abgeschaltet. Dann konnte er DVD mit cdrskin brennen.)

"Google says that different devices fail after different time or volume of data. Reliable kernels seem to be 3.12.32, 3.17.4-3.17.6. Maybe 4.0.1 and 4.0.5." (Angeblich haengt es von Zeit und Datenmenge ab, wann es schiefgeht. Die genannten Kernelversionen sollen zuverlaessig sein.)

Ist der Brenner zur Zeit an einem USB 3 Stecker ? Wenn ja: Kannst Du ihn an USB 2 haengen oder USB 3 abschalten ?

cdrecord: Eingabe-/Ausgabefehler. write_g1: scsi sendcmd: retryable error

Aha. Meine Aenderung an der Timeout-Entscheidung zeigt eine Wirkung.

cdrecord: A write error occured.

Ich haette ja gedacht, dass ein "retriable error" zu einem Re-Try fuehrt. Tut es aber nicht. Naja, haette in diesem Fall auch eher keinen Zweck, wenn meine Vermutung richtig ist.

write track data: error after 32006016 bytes Writing time: 50.891s (00:00:50.891) Average write speed 143,7x.

Joerg. Da stimmt was nicht mit der Geschwindigkeitsberechnung.

Warum er schreit das mein Hauptspeicher zu wenig wäre. keine Ahnung

Wahrscheinlich duerfen normale User nicht mit der Systemfunktion mlockall(2) einen Klumpen Arbeitsspeicher vor dem Auslagern in die Auslagerungsdatei schuetzen. K3B macht wohl kein sudo. Es wird ja dann noch weiter gemeckert wegen fehlender Rechte.

da mein Urlaub vorbei ist

Ich kondoliere herzlich zum Jahresbeginn und der damit verbundenen Wiederaufnahme der Arbeit.

Have a nice day ☺

Thomas

Also data over/under-runs sind Fehler, die eigentlich zu resid != 0 führen sollten (größer oder kleiner 0), aber Linux SCSI ist von der Qualität leider nur Mittelklasse.

Eines der größten Handycaps ist übrigens die Tatsache, daß Linux beim auto-request-sense (welches auf einem Multi-taskting System zwingend notwendig ist) nur 16 Bytes Daten liefert, obwohl der Standard seit ca. 1984 mindestens 18 Bytes vorschreibt. Dadurch sind bestimmte Fehler in Linux nicht interpretierbar.

Gut das ich scg auf SunOS implementiert habe und nicht auf Linux, sonst wäre scg genauso schlecht... aber wen's interessiert: scg ist das weltweit erste SCSI Universalinterface und ich habe es im Sommer 1986 geschrieben (das war übrigens 2 Jahre vor dem 2. vergleichbaren Interface: ASPI von Adaptec). Seit dem ist das Programmierinterface (also die zugrundeliegenden Datenstrukturen) unverändert geblieben.

Wer mal testen will, wie korrekt seine Implementierung ist kann "scgcheck" verwenden. Es testet diverse Fehlersituationen und legt ein Logfile an aus dem man sehen kann was alles korret oder fehlerhaft gemeldet wird.

Übrigens ist dieser Fehler aus Sicht der libscg in der Tat ein Retryable error, weil nicht klar ist, ob es gar keinen Zweck hat es nochmal zu probieren. Nicht "retryable Fehler" sind z.B. Fehler bei denen das Target nicht selektierbar war. Ob ein Fehler im Einzelnen durch Wiederholung heilbar ist, das hängt aber von der Situation ab, die nur das Programm kennt, das das Kommando abgeschickt hat.

Die Geschwindigkeitsberechnung orientiert sich an der Gesamtdatenmenge und mag bei Fehlern nicht stimmen 😉

Achja, nochmal generell etwas zu den Meldungen beim Kompilieren:

* gmake hat Bugs die zu fehlerhaften Fehlermeldungen führen. Diese Bugs habe ich 1988 gemeldet und die wurden damals auch vom Maintainer bestätigt. 18 Jahre scheinen für eine Beseitigung bei diesen Leuten aber nicht auszureichen.

* Debian zerpatcht den gcc, so daß er danach nicht mehr standardkonform ist. Meldungen zu ignorierten Fehlercodes sind die Folge, obwohl mit Hilfe der C Standardkonstruktion (void) angezeigt wurde das der Returncode bewußt ignoriert wird, z.B. weil es unsinnig ist bei einer Fehlerausgabe zu prüfen, ob diese evt. wegen eines Fehlers nicht geklappt hat.

* Darüberhinaus kommen bei einigen GCC Versionen auch bei abgeschalteten erweiterten Warnungen Meldungen zu dem printf() Format "%r", daß von DECCUS und UNOS 1980 eingeführt wurde. Diese Meldungen sind also ein Zeichen für einen zu dummen gcc.

Mit ordentlichen Kompilern kommen keine Warnungen beim Kompilieren. Lustig ist dabei übrigens zu erwähnen, daß der C-kompiler von DEC auf true64 meckert, wenn man dem gcc nachgibt.... Resultat dind dabei Meldungen über doppelt initialisierte Variablen. Der gcc hat einen sehr schlechten Algorithmus zum Erkennen uninitialisierter Variablen.

Hi,

Also data over/under-runs sind Fehler,

Sehe ich auch so. Aber die werden ja nur mit antiker Ultra SCSI Hardware assoziert. EgLes Brenner ist ein SATA Laptopdrive in einer Box mit USB-SATA Bruecke.

Vermutlich der hier, obwohl es auch einen aelteren Combo mit der selben Bezeichnung gibt. http://www.mydvddrives.com/sata-bd-rre-blu-ray-drive-replace-for-panasonic-uj230as-86702

Eines der größten Handycaps ist übrigens die Tatsache, daß Linux beim auto-request-sense [...] nur 16 Bytes Daten liefert,

Ich finde es auch laestig, dass es seine eigenen synthetischen Sense Daten mit Response Code 0x72 herstellt, also im Format "Descriptor", wo Key in Byte 1, ASC in Byte 2 und ASCQ in Byte 3 steht. Google mal nach "Sense Bytes: 72".

Übrigens ist dieser Fehler aus Sicht der libscg in der Tat ein Retryable error,

cdrecord scheint aber trotzdem nicht zu wiederholen. Da muesste es ja entweder weitergehen, oder es muesste ein Protest "Invalid Address" vom Brenner kommen.

Im Sommer 2015 hat libburn-1.3.2 unter Brasero versucht, zu wiederholen und diesen Protest wirklich vom Brenner bekommen. Mittlerweile sollte sie nicht mehr versuchen zu wiederholen.

Die Geschwindigkeitsberechnung orientiert sich an der Gesamtdatenmenge und mag bei Fehlern nicht stimmen

Ah. Beabsichtigte Datenmenge pro durchgehaltener Zeit.

Have a nice day ☺

Thomas

Hallo,

hoffe habe euch zu weiteren Erkenntnisse geholfen? 😉

Soll ich noch was testen?

Ansonsten würde ich mich damit soweit abfinden und das ganze dann erst mit Kubuntu 16.04 (LTS) ? wieder neu probieren, dann sollte ja auch ein recht neuer Kernel drinn sein.

Aber auf alle Fälle bedanke ich mich bei euch für eure Hilfe und Tips 👍

Hi EgLe,

Soll ich noch was testen?

Ja, die Frage klaeren, ob der Brenner zur Zeit an USB 3 eingestoepselt ist. Das waere dann ein plausibler (und hoffentlich behebbarer) Grund, warum der Kernel ab und zu host_status 7 meldet.

Falls er an USB 3 ist, probier bitte, ob das Brennen an USB 2 zuverlaessig funktioniert.

Have a nice day ☺

Thomas

Vielleicht noch ein wichtiger Punkt:

Die Überprüfung des DMA Residual Counts auf Linux wurde vor 10,5 Jahren eingeführt und hat bislang nie Probleme bereitet.

Daher wäre es falsch, den Wert in Produktionsversionen dauerhaft forciert auf 0 zu setzen.

Ich suche noch Vorschläge, wie man mit dem Problem umgehen sollte.

Hi Joerg,

Die Überprüfung des DMA Residual Counts auf Linux wurde vor 10,5 Jahren eingeführt und hat bislang nie Probleme bereitet.

Gab es jemals Anzeichen, dass sg_io.resid wirklich > 0 war, ohne dass auch SCSI Sense Daten vorhanden waren oder sg_io.host_status != 0 ?

Unsere 30 KB pro Kommando muesste ein Brenner mit >= 1 MB Pufferspeicher doch wohl im Ganzen schlucken koennen. (Tun sie ja auch normalerweise.)

Ich suche noch Vorschläge, wie man mit dem Problem umgehen sollte.

Wenn es mehr als ein individueller Ausrutscher von EgLes System ist, und wenn sg_io.resid > 0 auf anderen Linux bekernelten Systemen bei optischen Brennern wirklich eine Aufforderung zur Wiederholung ist, dann koenntest Du es immer noch dem User ueberlassen, sich eine Reaktion auszusuchen. -ignore-linux-resid oder so.

Wenn erst ein sg_io.resid war und bei der Wiederholung "Invalid address" kommt, koennte man dem User sogar automatisch empfehlen, es bei der naechsten CD mal mit -ignore-linux-resid zu versuchen.

Have a nice day ☺

Thomas

Ob resid jemals != 0 war weis ich nicht mehr.

Das kann man aber mit Hilfe von "scgcheck" herausbekommen, denn da ist ein DMA resid Test drin. Allerdings kann das zum Aufhängen des Systems führen wenn der Kern buggy ist, weil es u.A. auch einen DMA Overrun provoziert.

Cdrecord fragt ja normalerweise den Brenner vorher ob es noch in den Puffer paßt.

-ignore-linux-resid gefällt mir nicht, weil es so ein typisch unsystematisches Feature ist wie auch die Hälfte aller gtar Optionen. Star kann das z.B. dank libfind eleganter.

Ich suche eher an einer systematischen Methode libscg zu informieren...

Hi Joerg,

Cdrecord fragt ja normalerweise den Brenner vorher ob es noch in den Puffer paßt.

Es sieht aber in den SCSI logs nicht nach lueckenloser Voranfrage aus. Die Kommandos 0x5C READ BUFFER CAPACITY kommen nur am Start der einzelnen Tracks. (Weil kein -v bei den Optionen war ?)

https://media-cdn.ubuntu-de.org/forum/attachments/54/01/7999588-cdrecord_fubude_1_log.txt

https://media-cdn.ubuntu-de.org/forum/attachments/20/01/8001458-cdrecord_fubude_2_log.txt.tar.gz

Have a nice day ☺

Thomas

Cdrecord tut das wenn der Brenner "long write in progress" meldet. Sonst wird davon ausgegangen, daß es dank Disconnect-reconnect bei SCSI kein Problem ist.

Anders gesagt, es wird letztlich ein halbwegs korrekt implementierter SCSI Stack vorausgesetzt.

Hallo ping,

es wird in den nächsten Tagen eine neue Version der cdrtools im Schil-tool-Bündel geben.

Darin wird erstmal testweise cdrecord mit einer neuen Option scgopts= ausgerüstet sein. Wenn man "cdrecord scgopts=ignore-resid ..." aufruft, dann wird der DMA residual Count ignoriert.

Auch ping,

ich will das mit dem USB 3 wissen. Wir haben noch keine Erklaerung fuer den host_status 7, der jeden zweiten cdrecord Lauf sabotiert und auch mit libburn toedlich waere.

Have a nice day ☺

Thomas

So, ich habe mal eine Vorabversion der Schilytools unter: http://sourceforge.net/projects/schilytools/files/schily-dist-pre1.tar.xz abgelegt.

Dort enthalten ist ein neues cdrecord, das die neue libscg Schnittstelle für SCSI Optionen unterstützt:

cdrecord scgopts=ignore-resid ...

sollte dann die Auswertung des DMA Residual Counters deaktivieren. Wenn das funktioniert, dann bau ich das auch in die anderen SCG basierten Programme ein.

Hallo,

ich kann leider nix mehr testen, denke mein Brenner hat nun einen schlag ab ☹

Kann ihn nur noch am USB3 betreiben, zum auslesen usw. aber nicht mehr schreiben.

Am USB2 schreibt er nun auch nicht mehr und wenn er dort angeschlossen ist und ich meinen Rechner runterfahren will, geht er kurz aus, und 3 Sekunden später schaltet er sich wieder ein.

Muss also erst klären ob ich den nun mittels Garantie getauscht bekomme ☹

Sorry hätte gerne noch weiter für euch getestet, können wir aber gerne machen wenn ich neuen Brenner habe.

Melde mich dann wenn ich wieder einsatzbereit bin und ihr noch einen Tester braucht...