Hallo Stefan,
> ...
> ich habe hier ein SCSI-Problem. Alle 7 bis 14 Tage klappt das
> n�chtliche Bakup nicht. Stattdessen bekomme ich folgende Meldungen ins
> Logbuch:
>
> Start des Backup:
> 01:05:00 BigBrother kernel: Detected scsi tape st0 at scsi0,
> channel 0, id 5, lun 0
> 01:06:00 BigBrother kernel: st: Unloaded.
> 01:06:21 BigBrother kernel: Detected scsi tape st0 at scsi0,
> channel 0, id 5, lun 0
> .
> .
> .
> Jetzt werden die Dateien gesucht und f�rs Backup vermerkt,
> schlie�lich geht's los:
> .
> .
> .
> 02:19:26 BigBrother kernel: scsi0 : channel 0 target 5 lun 0 request
> sense failed, performing reset.
> 02:19:26 BigBrother kernel: SCSI bus is being reset for host 0
> channel 0.
> 02:19:27 BigBrother kernel: st0: Error 27000008.
> 02:19:28 BigBrother kernel: st0: Error with sense data: extra data
> not valid Current error st09:00: sense key
> Unit Attention
> 02:19:28 BigBrother kernel: Additional sense indicates Power on,
> reset, or bus device reset occurred
> 02:19:28 BigBrother kernel: st0: Error on write filemark.
> 02:20:03 BigBrother kernel: st: Unloaded.
> .
> .
> .
> Ein weiterer Cron-Job schaltet das Tape offline, damit man es
> 'rausnehmen kann.
> .
> .
> .
> 07:05:01 BigBrother kernel: Detected scsi tape st0 at scsi0,
> channel 0, id 5, lun 0
> 07:05:01 BigBrother kernel: st: Can't allocate new tape buffer
> (nbr 0).
> 07:05:01 BigBrother kernel: No tape buffers allocated at
> initialization.
> 07:05:01 BigBrother kernel: st: Can't allocate new tape buffer
> (nbr 0).
> 07:05:01 BigBrother kernel: st0: Can't allocate tape buffer.
> 07:06:01 BigBrother kernel: st: Unloaded.
>
> Wie gesagt, nach einem Reboot klappt alles (ca. 7 - 14 Tage lang)
>
> Beteiligte Ger�te sind:
>
> Asus P2B-Motherboard mit 2x PII-350,
> > Onboard SCSI-Controller AHA-7xxx,
> ICP-Vortex-GDT6527 RAID-Controller
> Quantum DLT4000 Tape (im HP-Surestore DLT40e extern Geh�use)
>
> Kernel: 2.0.36, SMP
>
> Das Tape zeigt sowohl am AHA als auch am GDT nach ein paar Tagen
> dieselben Probleme.
>
> Frage: Was k�nnte die Ursache sein?
> Gibt es L�sungen f�r dieses Problem
mir ist nicht so ganz klar, welche Meldungen jetzt spezifisch f�r
Dein Problem sind. Kannst Du mal die 'normalen' Meldungen
dazustellen? Eventuell per PM.
Es gibt auch eine Mailing-Liste speziell zum Thema B�nder,
Bandlauferke, Backup und Linux, die findest Du unter
[EMAIL PROTECTED], Anmeldung �ber den dortigen
majordomo.
Gesetzt den Fall, da� die 'can't allocate new tape
buffer'-Meldung spezifisch f�r Dein Problem sind, f�llt mir so
ganz dunkel ein, einmal einen Thread gelesen zu haben, der so
ungef�hr darauf hinwies, da� SMP unter 2.0.x-Kerneln nur bedingt
stabil sei. Das sei bei den 2.2.x-Kerneln erheblich verbessert.
Vielleicht liest hier jemand mit, der dazu mehr sagen kann?
Woraus schlie�t Du, da� es wirklich das Band-Laufwerk ist? Du
k�nntest doch mal versuchen, einen Reset des Laufwerks ohne
Reboot zu machen. Das geht ungef�hr so, in dem Du per echo an den
scsi-Treiber im /proc-Baum ein Kommando schickst, das Ger�t aus
der Liste zu streichen, dann nur das Laufwerk ausschalten
(Strom-Versorgung abziehen), anschlie�end Strom wieder drauf und
mit einem passenden Kommando das Ger�t wieder aktivieren.
Genaueres kannst Du in /usr/dow/howto/SCSI-Programming-HOWTO.gz
nachlesen. Wenn Dein Problem so ohne Reboot weg ist, bleiben als
Ursache nur das Laufwerk selber oder der SCSI-Treiber.
Andernfalls d�rfte der Kernel selber noch 'ne Macke haben. Das
l�uft dann auf 2.2.x hinaus.
Sorry, da� ich keine wirkliche L�sung habe, ist ein bi�chen aus
dem Bauch, aber vielleicht hilft's zum Weiterkommen.
Martin
--
Martin Jacobs * Windsbach * [EMAIL PROTECTED] und
[EMAIL PROTECTED]
Registered Linux User #87175
--
Um aus der Liste ausgetragen zu werden, eine Mail an [EMAIL PROTECTED]
schicken, mit dem Text: unsubscribe suse-linux
