SCSI-Tape-Library läuft nicht unter SuSE 9.0
Hallo! Ich habe ein heftiges Problem mit einer Tape-Library (Overland LoaderXpress mit Quantum DLT7000) unter SuSE 9.0: Egal, ob ich das Ding an einen LSI-Logic, an einen Dawicontrol, oder an einen Adaptec hänge, ich kriege Fehler und der Backup-Vorgang (Arkeia) bricht ab. Nur zwei Beispiele: sym53c8xx am LSI Logic Sym53c1010-33 (onBoard ASUS CURDLS) meldet nach kürzester Zeit: kernel: sym0:4:0: ABORT operation started. kernel: sym0:4:control msgout: 80 6. kernel: sym0:4:0: ABORT operation complete. kernel: sym0:4:0: DEVICE RESET operation started. kernel: sym0:4:0: DEVICE RESET operation failed. kernel: sym0:4:0: BUS RESET operation started. kernel: sym0:4:0: BUS RESET operation failed. kernel: sym0:4:0: HOST RESET operation started. kernel: sym0:4:0: HOST RESET operation failed. kernel: scsi: device set offline - command error recover failed: host 0 channel 0 id 4 lun 0 ncr53c8xx und sym53c8xx-old am gleichen Controller erzählen was von timeout und resetten ebenfalls: kernel: scsi : aborting command due to timeout : pid 96, scsi0, channel 0, id 6, lun 0 Move medium/play audio(12) 00 00 00 00 02 00 f0 00 00 00 00 kernel: ncr53c8xx_abort: pid=96 serial_number=97 serial_number_at_timeout=97 kernel: SCSI host 0 abort (pid 96) timed out - resetting kernel: SCSI bus is being reset for host 0 channel 0. kernel: ncr53c8xx_reset: pid=96 reset_flags=2 serial_number=97 serial_number_at_timeout=97 Die Hardware-Seite habe ich so gut ich konnte abgecheckt: Terminierung, Parität, SCSI-IDs, Kabel, etc kommen als Ursache nicht mehr in Frage. Die Library selbst habe ich auch schon ausgetauscht. Es ist auch völlig gleichgültig, ob ich das Device im SCSI-BIOS auf "removable" setzte. Wenn ich ein Kernel-Downgrade auf den letzten SuSE-8.2-Kernel (2.4.20-108) mache, läuft alles durch, allerdings erhalte ich diese Fehlermeldungen: kernel: st0: Error with sense data: Current st09:00: sns = 70 6 kernel: ASC=28 ASCQ= 0 kernel: Raw sense data:0x70 0x00 0x06 0x00 0x00 0x00 0x00 0x16 0x00 0x00 0x00 0x00 0x28 0x00 0x00 0x00 0x00 0x00 0x82 0x02 0x51 0x00 0x00 0x00 0x69 0x00 0x9a 0xbd 0x2d 0x00 Doch mit diesen Fehlermeldungen leben wir nun seit 2 Jahren ohne Schmerzen (schon unter SuSE 8.0). Natürlich möchte ich kein inkonsistentes halb-9.0-halb-8.2-System haben, zumal es sich um unseren wichtigsten Fileserver handelt. Was ist zwischen 8.2 und 9.0 geschehen? Sind die SCSI-Treiber pedantischer geworden? Wenn ja, welche? Wie bekomme ich einen sauberen 9.0-Kernel hin, ohne allzuviel downpatchen zu müssen? Vielen Dank Frank Schneider
On 22 Mar 2004 at 20:20, Frank Schneider wrote:
Ich habe ein heftiges Problem mit einer Tape-Library (Overland LoaderXpress mit Quantum DLT7000) unter SuSE 9.0: Egal, ob ich das Ding an einen LSI-Logic, an einen Dawicontrol, oder an einen Adaptec hänge, ich kriege Fehler und der Backup-Vorgang (Arkeia) bricht ab. Nur zwei Beispiele: sym53c8xx am LSI Logic Sym53c1010-33 (onBoard ASUS CURDLS) meldet nach kürzester Zeit: ncr53c8xx und sym53c8xx-old am gleichen Controller erzählen was von timeout und resetten ebenfalls:
Hallo Frank, Unterschied von der 8.x zur 9.0 ist z.B. dass bei der 9.0 HZ per default auf 1000 gesetzt ist anstatt wie bisher auf 100. Der sg, erwartet aber seine Werte in Abhängigkeit von HZ=100. Dadurch wird die Zeit, die dein Anwendungsprogramm wartet, bevor Sie einen Timeout meldet um den Faktor 10 kleiner, d.h. aus z.B. 5 Min werden gerade mal 30 Sekunden, was beim Bandwechsel schon zu einem Timeout führen kann. Versuch doch einfach mal den Kernel ohne den Parameter "desktop" zu booten. Ich verwende zwar nicht Arkeia aber bei mir hat das geholfen. Mit freundlichen Grüßen Thomas Kempf -- Thomas Kempf Atelier Hueper im Bruehl 1, 89520 Heidenheim Fon: +49 7321 969845 Fax: +49 7321 969891
Hallo Thomas!
Ich habe ein heftiges Problem mit einer Tape-Library (Overland LoaderXpress mit Quantum DLT7000) unter SuSE 9.0:
Unterschied von der 8.x zur 9.0 ist z.B. dass bei der 9.0 HZ per default auf 1000 gesetzt ist anstatt wie bisher auf 100. Der sg, erwartet aber seine Werte in Abhängigkeit von HZ=100. Dadurch wird die Zeit, die dein Anwendungsprogramm wartet, bevor Sie einen Timeout meldet um den Faktor 10 kleiner, d.h. aus z.B. 5 Min werden gerade mal 30 Sekunden, was beim Bandwechsel schon zu einem Timeout führen kann. Versuch doch einfach mal den Kernel ohne den Parameter "desktop" zu booten. Ich verwende zwar nicht Arkeia aber bei mir hat das geholfen.
Auf den ersten Blick tut es das bei mir auch. Scheint in jedem Fall der richtige Regler zu sein. VIELEN DANK! Frank Schneider
participants (2)
-
Frank Schneider
-
Thomas Kempf