Allgemein geht es darum, das ein inquiry Kommando (36 oder mehr Byte) einen haenger verursacht. Das Treibermodul "st" ist waehrend
dessen zwei mal in gebrauch.
Nach etwa 15 Minuten ist der Vorgang abgeschlossen, bis man das
naechste Kommando absetzt.
Das ist ziemlich langweilig.
OS/Programme:
dmesg sagt:
Das: "Consider BLIST_INQUIRY_36 for this device" ist zwar vorausschauend, hilft anscheinend leider nicht.
Config:
Soweit, sogut!
Die Platten funktionieren einwandfrei.
Quantum beschreibt einiges zur Installation unter Linux in ihrer Doku.
Leider nur fuer SCSI-LWs, nicht SATA. Was an sich auch nicht schlimm
ist.
Aber der "inquiry Fehler" scheint mir ursaechlich mit dem mt-st/st-treiber
zusammen zu haengen.
Im Handbuch wird dann noch gesagt, dass man das Laufwerk nur alleine
an einem Controllerport betreiben soll. Das Verhalten des st-treiber aendert
sich aber auch dann nicht.
An Quantum habe ich schon zwei support Anfragen per e-mail geschickt,
keine Antwort.
Soviel zum Thema "Servicewueste Deutschland", da sind wir wohl nicht alleine... :/
Google hat mir einen Entwicklertread ausgeworfen, aus dem ich
allerdings nicht so recht schlau werde.
Selbstverstaendlich finde ich den Tread nicht mehr..
Hat jemand damit Erfahrung gemacht oder "die" Loesung fuer diese Herausforderung?
Gruss
dessen zwei mal in gebrauch.
Code:
sg_inq -36 /dev/st0
naechste Kommando absetzt.
Das ist ziemlich langweilig.
OS/Programme:
Code:
SUSE LINUX 10.0 (i586)
2.6.13-15.11-default
mt_st-0.7-423
dmesg sagt:
Code:
scsi scan: 58 byte inquiry failed. Consider BLIST_INQUIRY_36 for this device
Vendor: QUANTUM Model: DLT-V4 Rev: 0500
Type: Sequential-Access ANSI SCSI revision: 05
Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 1
...
st: Version 20050501, fixed bufsize 32768, s/g segs 256
Attached scsi tape st0 at scsi1, channel 0, id 0, lun 0
st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 1048575
...
program stinit is using a deprecated SCSI ioctl, please convert it to SG_IO
Config:
Code:
lspci:
01:09.0 RAID bus controller: Silicon Image, Inc. Adaptec AAR-1210SA SATA HostRAID Controller (rev 02)
01:0a.0 RAID bus controller: Silicon Image, Inc. Adaptec AAR-1210SA SATA HostRAID Controller (rev 02)
dmesg Auszug:
ata1: SATA max UDMA/100 cmd 0xE081A080 ctl 0xE081A08A bmdma 0xE081A000 irq 3
ata2: SATA max UDMA/100 cmd 0xE081A0C0 ctl 0xE081A0CA bmdma 0xE081A008 irq 3
Code:
sgdiag utility v1.12 for SCSI disks
******************************************
Log file /var/log/sgdiag.log is open, debug=0
Num Name [bus:ch:id:lun] Type Vendor Device_Model FW Serial# Size
0 /dev/sg0 [0:0:0:0] Disk ATA Maxtor 6V080E0 VA11 [em]
1 /dev/sg1 [1:0:0:0] Tape QUANTUM DLT-V4 0500 A [em]
2 /dev/sg2 [2:0:0:0] Disk ATA Maxtor 6V080E0 VA11 [em]
3 /dev/sg3 [3:0:0:0] Disk ATA Maxtor 6V080E0 VA11 [em]
Quantum beschreibt einiges zur Installation unter Linux in ihrer Doku.
Leider nur fuer SCSI-LWs, nicht SATA. Was an sich auch nicht schlimm
ist.
Aber der "inquiry Fehler" scheint mir ursaechlich mit dem mt-st/st-treiber
zusammen zu haengen.
Im Handbuch wird dann noch gesagt, dass man das Laufwerk nur alleine
an einem Controllerport betreiben soll. Das Verhalten des st-treiber aendert
sich aber auch dann nicht.
An Quantum habe ich schon zwei support Anfragen per e-mail geschickt,
keine Antwort.
Soviel zum Thema "Servicewueste Deutschland", da sind wir wohl nicht alleine... :/
Google hat mir einen Entwicklertread ausgeworfen, aus dem ich
allerdings nicht so recht schlau werde.
Selbstverstaendlich finde ich den Tread nicht mehr..
Hat jemand damit Erfahrung gemacht oder "die" Loesung fuer diese Herausforderung?
Gruss