SCSI-1 Platte unter Linux ansprechen

[Manfred Ugubait]

Hi,

ich möchte eine historische (ca. 1987) Festplatte ansprechen, die ein
SCSI-1 Interface hat. Hardwaremäßig ist das kein Problem. An meinen
Tekram DC390 SCSI-II-Hostadapter gehängt, lässt sie sich unter DOS
z.B. mit Bart Lagerweijs SCSITOOL ansprechen.

Das Problem ist nun, dass die Platte einen recht beschränkten SCSI-
Kommandosatz versteht. So ist z.B. INQUIRY, das Kommando zum
Ermitteln von Hersteller- und Modellnamen und unterstützten Features,
nicht implementiert. (Das war in SCSI-1 noch nicht Pflicht.)
Vermutlich liegt es daran, dass der Linux-Treiber (tmscsim) des
Hostadapters die Platte nicht findet. Ich habe es mit mehreren
Knoppix-CDs ausprobiert und je nach Kernelversion hängt der Treiber
bei der Initialisierung oder findet schlichtweg die Platte nicht.

Gibt es einen Weg, Linux bzw. den tmscsim-Treiber davon zu
überzeugen, dass die Platte doch da ist. MODE SENSE liefert korrekte
Daten über die Plattengröße etc., so dass der Betrieb prinzipiell
möglich sein sollte.

Manfred
PS: Wer ein Crosspost mit Follow-Up für angebracht hält, bitte...

[Olaf Kaluza]

Post by Manfred Ugubait
nicht implementiert. (Das war in SCSI-1 noch nicht Pflicht.)
Vermutlich liegt es daran, dass der Linux-Treiber (tmscsim) des
Hostadapters die Platte nicht findet. Ich habe es mit mehreren

Ich wuerde vermuten das dein Hostadapter ein Problem mit der Platte
hat. Da ist doch auch noch Firmware drin oder?
Probier doch einfach mal einen anderen. Grundsaetzlich sollte SCSI-1
unter Linux laufen. Ich hab jedenfalls schon sehr frueh SCSI an einem
ST01 benutzt und da lief (nach etwas loeten) neben meiner Platte sogar
ein Streamer dran.

Andererseits muss es schon besondere Gruende (Liebe? :-) sein um sich
noch so eine Platte anzutun, schliesslich bekommt man modernere
Scheiben doch nachgeworfen.

Olaf

[Alexander Skwar]

Post by Olaf Kaluza

Post by Manfred Ugubait
nicht implementiert. (Das war in SCSI-1 noch nicht Pflicht.)
Vermutlich liegt es daran, dass der Linux-Treiber (tmscsim) des
Hostadapters die Platte nicht findet. Ich habe es mit mehreren

Ich wuerde vermuten das dein Hostadapter ein Problem mit der Platte
hat.

Wie kommst Du denn auf die Idee? Besonders folgendes aus dem OP
lässt mich daran zweifeln:

,----[ Im OP ]
| Hardwaremäßig ist das kein Problem. An meinen
| Tekram DC390 SCSI-II-Hostadapter gehängt, lässt sie sich unter DOS
| z.B. mit Bart Lagerweijs SCSITOOL ansprechen.
`----

Gruss,

Alexander Skwar

[Joern Abatz]

Post by Manfred Ugubait
Gibt es einen Weg, Linux bzw. den tmscsim-Treiber davon zu
überzeugen, dass die Platte doch da ist. MODE SENSE liefert korrekte
Daten über die Plattengröße etc., so dass der Betrieb prinzipiell
möglich sein sollte.

Wenn man sowas sucht, braucht man die Kernel-Sourcen. Da steht sowas
entweder in "Documentation" oder notfalls im Quelltext. Woanders steht
sowas meistens nur aus zweiter Hand.

/usr/src/linux/Documentation/scsi/tmscsim.txt

Das sieht ganz gut aus, finde ich.

Jörn

[Michael Baeuerle]

Post by Manfred Ugubait
ich möchte eine historische (ca. 1987) Festplatte ansprechen, die ein
SCSI-1 Interface hat. Hardwaremäßig ist das kein Problem. An meinen
Tekram DC390 SCSI-II-Hostadapter gehängt, lässt sie sich unter DOS
z.B. mit Bart Lagerweijs SCSITOOL ansprechen.

D.h. ihr Interface funktioniert.

Post by Manfred Ugubait
Das Problem ist nun, dass die Platte einen recht beschränkten SCSI-
Kommandosatz versteht. So ist z.B. INQUIRY, das Kommando zum
Ermitteln von Hersteller- und Modellnamen und unterstützten Features,
nicht implementiert. (Das war in SCSI-1 noch nicht Pflicht.)

Bist du da ganz sicher? Bisher hatte jede noch so alte Gurke die mir in
die Finger gekommen ist INQUIRY implementiert. Und 1987 ist ja nicht
wirklich alt, da war SCSI1 schon final und es wurde bereits an SCSI2
gearbeitet.

Was ist es denn fuer eine Platte?

Post by Manfred Ugubait
Vermutlich liegt es daran, dass der Linux-Treiber (tmscsim) des
Hostadapters die Platte nicht findet.

Ist INQUIRY wirklich nicht implementiert, wird die Platte vermutlich mit
keinem Linux Treiber funktionieren. INQUIRY und TEST UNIT READY benutzen
die alle.

Post by Manfred Ugubait
Ich habe es mit mehreren
Knoppix-CDs ausprobiert und je nach Kernelversion hängt der Treiber
bei der Initialisierung oder findet schlichtweg die Platte nicht.

Das ist aber ein starkes Indiz, dass das Problem woanders liegt. Waere
INQUIRY wirklich nicht implementiert, sollte die Platte mit CHECK
CONDITION und Sense key 5 (Illegal request) reagieren und es nicht zu
einem Haenger kommen.

Post by Manfred Ugubait
Gibt es einen Weg, Linux bzw. den tmscsim-Treiber davon zu
überzeugen, dass die Platte doch da ist. MODE SENSE liefert korrekte
Daten über die Plattengröße etc., so dass der Betrieb prinzipiell
möglich sein sollte.

MODE SENSE wird von Linux verwendet um den Schreibschutzstatus
auszulesen und muss implementiert sein (obwohl es bis heute nach SCSI
spec optional ist). Fuer die Bestimmung der Groesse wird READ CAPACITY
verwendet, das muss auch implementiert sein. Der Inhalt der Mode pages
ist dagegen fuer die Erkennung nicht relevant.

Du wirst wild patchen muessen um das im Kernel umzubiegen. Besser
erstmal mit einen anderen Hostadapter testen ...
Darauf achten, dass der Selection Abort Timeout [1] auf 250ms steht, das
ist z.B. bei den Adaptec Treibern nicht der default.


Micha

[1] Die Zeit die die Platte maximal brauchen darf um den Bus zu
uebernehmen wenn sie angesprochen wird. Der maximal zulaessige Wert war
bei SCSI1 250ms.

[Manfred Ugubait]

Post by Michael Baeuerle
Bist du da ganz sicher? Bisher hatte jede noch so alte Gurke die mir in
die Finger gekommen ist INQUIRY implementiert.
[...]
Was ist es denn fuer eine Platte?

Diese beherrscht tatsächlich kein INQUIRY, genauer gesagt ihr
Controller beherrscht es nicht. Es ist eine MFM-Platte mit ST506-
Interface, die an einem Adaptec ACB4000A-SCSI-Controller hängt.
Leider beherrscht der Controller auch kein "Extended Sense Data
Format" sondern liefert nur 4 Bytes Sense mit afaik
herstellerspezifischen Fehlermeldungen zurück. Bei INQUIRY halt den
Code für "Illegal command".

Post by Michael Baeuerle
Das ist aber ein starkes Indiz, dass das Problem woanders liegt. Waere
INQUIRY wirklich nicht implementiert, sollte die Platte mit CHECK
CONDITION und Sense key 5 (Illegal request) reagieren und es nicht zu
einem Haenger kommen.

Evtl. kommt die Version des Treibers, die sich aufhängt, mit der
Fehlermeldung nicht klar oder irgendwas mit dem Timing stimmt dort
nicht. Die anderen Versionen hängen ja nicht, finden nur auch nichts.

Post by Michael Baeuerle
MODE SENSE wird von Linux verwendet um den Schreibschutzstatus
auszulesen und muss implementiert sein (obwohl es bis heute nach SCSI
spec optional ist). Fuer die Bestimmung der Groesse wird READ CAPACITY
verwendet, das muss auch implementiert sein.

Also lt. Handbuch kennt der ACB4000 READ CAPACITY [*]. SCSITOOL zeigt
die Plattengröße auch richtig an.

Manfred
[*] weiterhin READ, SEEK, RECEIVE DIAGNOSTIC, TEST UNIT READY, FORMAT
UNIT, WRITE, SEND DIAGNOSTIC, VERIFY, REZERO UNIT, MODE SELECT,
SEARCH DATA EQUAL, REQUEST SENSE, WRITE AND VERIFY, MODE SENSE,
TRANSLATE

[Henning Paul]

Post by Manfred Ugubait

Post by Michael Baeuerle
Bist du da ganz sicher? Bisher hatte jede noch so alte Gurke die mir
in die Finger gekommen ist INQUIRY implementiert.
[...]
Was ist es denn fuer eine Platte?

Diese beherrscht tatsächlich kein INQUIRY, genauer gesagt ihr
Controller beherrscht es nicht.

Sogar der Controller hier:
Loading Image...
unterstützt INQUIRY. Und meldet sich je nach angeschlossenem
Floppylaufwerk mit anderer Kennung... :-)

Gruß
Henning

[Manfred Ugubait]

Post by Henning Paul
http://home.arcor.de/henning.paul/gallery/vaxfloppy.jpg
unterstützt INQUIRY.

Nett. Der ist aber auch neuer. Datecodes von nach 1990. Das Handbuch
des ACB4000 ist mit 14.10.1983 datiert. Ganz so alt sind Platte und
Controller bei mir nicht, aber ich fürchte die Firmware ist auch bei
mir noch von 1983. Und sie kann definitiv KEIN INQUIRY.

Manfred

[Christian Zietz]

Post by Henning Paul
http://home.arcor.de/henning.paul/gallery/vaxfloppy.jpg
unterstützt INQUIRY. Und meldet sich je nach angeschlossenem
Floppylaufwerk mit anderer Kennung... :-)

Da kann man normale Floppylaufwerke anschließen und er erkennt deren
Typ? Wie geht das denn?

CU Christian

[Henning Paul]

Post by Christian Zietz

Post by Henning Paul
http://home.arcor.de/henning.paul/gallery/vaxfloppy.jpg
unterstützt INQUIRY. Und meldet sich je nach angeschlossenem
Floppylaufwerk mit anderer Kennung... :-)

Da kann man normale Floppylaufwerke anschließen und er erkennt deren
Typ? Wie geht das denn?

Er seekt beim Poweron. Ein 5,25" hatte ich allerdings noch nicht dran.

Gruß
Henning

[Christian Zietz]

Post by Henning Paul
Er seekt beim Poweron.

Und das führt ohne Diskette zu einem Resultat? Die Floppylaufwerke, die
ich kenne, sind in der Hinsicht absolut dumm, können nicht erkennen, wo
der Kopf gerade steht und seeken auch fröhlich immer und immer wieder
gegen den Endanschlag.
Zumal: Wie kann der Controller ohne eingelegte Diskette HD-fähige und
nicht-HD-fähige LW unterscheiden?

CU Christian

[Henning Paul]

Post by Christian Zietz

Post by Henning Paul
Er seekt beim Poweron.

Und das führt ohne Diskette zu einem Resultat? Die Floppylaufwerke,
die ich kenne, sind in der Hinsicht absolut dumm, können nicht
erkennen, wo der Kopf gerade steht und seeken auch fröhlich immer und
immer wieder gegen den Endanschlag.

Das ist Absicht: Man zählt die Schritte von Endanschlag bis Endanschlag.
Sind das 40, ist es ein DD-Laufwerk, sind es 80, ist es ein
HD-Laufwerk. IBM hat(te) da übrigens mal ein Patent drauf, die haben um
1997 herum BIOS-Hersteller abgemahnt.

Post by Christian Zietz
Zumal: Wie kann der Controller ohne eingelegte Diskette HD-fähige und
nicht-HD-fähige LW unterscheiden?

Nur die lassen sich unterscheiden, s.o.

Lustigerweise ist die Kennung mit versehentlich verkehrt herum
aufgestecktem Floppystecker wieder anders.

Das Ding hat auch noch Dipswitches, damit kann man dann wohl 18- und
15-Sektor-Laufwerke auswählen.

Gruß
Henning

[Christian Zietz]

Post by Henning Paul
Das ist Absicht: Man zählt die Schritte von Endanschlag bis Endanschlag.
Sind das 40, ist es ein DD-Laufwerk, sind es 80, ist es ein
HD-Laufwerk.

3.5"-DD-Laufwerke haben ebenfalls (ca.) 80 Spuren, nur eine geringere
Datenrate pro Spur (iirc 250 kBit/s) und daher im Regelfall nur 9
Sektoren/Spur. Außerdem melden die LW, die ich kenne, nur den Anschlag
bei Spur 0, den anderen nicht. Weist man sie an, weiter zu steppen als
die 82-85 Spuren, die der Kopf anfahren kann, knallt dieser stumpf gegen
den Anschlag, ohne dass das Laufwerk irgendeinen Fehler meldet. (Und
dann gab es iirc sogar noch einseitige 3.5"-DD-Laufwerke, ebenfalls mit
80 Spuren aber eben mit nur einem Kopf und somit gegenüber herkömmlichen
Laufwerken halbierter Kapazizät pro Diskette.)
Fazit: Ich wüsste nicht, wie man alle diese LW ohne eingelegte Diskette
unterscheiden könnte. Ein 40-spuriges LW könnte man bestenfalls so
erkennen: Man startet bei Spur 0 und steppt sagen wir mal 50 Spuren.
Dabei knallt der Kopf halt bis zu zehn Mal gegen den Anschlag. Steppt
man zurück, braucht man folglich weniger als 50 Spuren, bis man wieder
bei Spur 0 ist. Laufwerkschonend ist das aber nicht.

CU Christian

[Michael Baeuerle]

Post by Christian Zietz

Post by Henning Paul
Er seekt beim Poweron.

Und das führt ohne Diskette zu einem Resultat? Die Floppylaufwerke, die
ich kenne, sind in der Hinsicht absolut dumm, können nicht erkennen, wo
der Kopf gerade steht und seeken auch fröhlich immer und immer wieder
gegen den Endanschlag.

Deswegen gibt es ja den Track0 Indikator als Referenzmarke. Ob es ein
40Track oder 80Track Laufwerk ist kann man damit rausfinden:
- Seek 80Tracks nach innen
- Seek 50Tracks nach aussen (falls ein 40er ein paar mehr unterstuetzt)
- Ist man noch nicht auf Track0 ist es ein 80Track drive

Post by Christian Zietz
Zumal: Wie kann der Controller ohne eingelegte Diskette HD-fähige und
nicht-HD-fähige LW unterscheiden?

Gar nicht? Ist aber egal, Befehle wie READ CAPACITY oder WRITE werden
ohne Medium ja sowieso pauschal abgewiesen. Er kann einfach warten bis
eine Diskette eingelegt wird. Dann gibts eine UNIT ATTENTION condition
und neue Werte fuer Geometrie und Kapazitaet.


Micha

[Henning Paul]

Post by Michael Baeuerle
Gar nicht? Ist aber egal, Befehle wie READ CAPACITY oder WRITE werden
ohne Medium ja sowieso pauschal abgewiesen. Er kann einfach warten bis
eine Diskette eingelegt wird. Dann gibts eine UNIT ATTENTION condition
und neue Werte fuer Geometrie und Kapazitaet.

Details hier: news:<epilbm$glu$***@online.de>

Gruß
Henning

[Michael Baeuerle]

Post by Michael Baeuerle
Gar nicht? Ist aber egal, Befehle wie READ CAPACITY oder WRITE werden
ohne Medium ja sowieso pauschal abgewiesen. Er kann einfach warten bis
eine Diskette eingelegt wird. Dann gibts eine UNIT ATTENTION condition
und neue Werte fuer Geometrie und Kapazitaet.

Ist ein nettes Teil, so richtig old school mit 8031 und 5380 ...

Allein durch die Seekerei kann er aber z.B. bei 3.5" nicht rausfinden ob
DD oder HD weil beides 80Tracks hat. Da muss er schon noch den Schalter
am Codierloch abfragen oder nach dem Einlegen einer Diskette
verschiedene Bitraten ausprobieren ...


Micha

[Michael Baeuerle]

Post by Manfred Ugubait

Post by Michael Baeuerle
Bist du da ganz sicher? Bisher hatte jede noch so alte Gurke die mir in
die Finger gekommen ist INQUIRY implementiert.
[...]
Was ist es denn fuer eine Platte?

Diese beherrscht tatsächlich kein INQUIRY, genauer gesagt ihr
Controller beherrscht es nicht. Es ist eine MFM-Platte mit ST506-
Interface, die an einem Adaptec ACB4000A-SCSI-Controller hängt.

Ah, ein bridge controller. Ich habe einen Emulex MD21, das sollte so was
aehnliches sein. Der stellt sich aber nicht ganz so zickig an, wird
Adaptec wieder mal seinem Ruf gerecht ;-)

Post by Manfred Ugubait
Leider beherrscht der Controller auch kein "Extended Sense Data
Format" sondern liefert nur 4 Bytes Sense mit afaik
herstellerspezifischen Fehlermeldungen zurück. Bei INQUIRY halt den
Code für "Illegal command".

Hmm, 4 Bytes wuerden genau auf die INQUIRY Daten passen, aber nicht auf
die Sense Daten (jedenfalls in den Formaten wie sie heute ueblich sind).
Da waere dann zwar lediglich peripheral qualifier und device type dabei
(zum Erkennen wuerde aber "LUN connected" + "Type=direct access"
reichen) aber natuerlich keine Vendor/Product Strings. Poste doch mal
die 4Byte Rohdaten.

Was mir gerade noch einfaellt:
Da es ein bridge controller ist unterstuetzt er vermutlich mehrere
Platten und tut sie auf unterschiedliche LUNs mappen. Wenn deine Platte
jetzt nicht LUN0 ist hast du ggf. ein Problem:
Zum einen scannt Linux AFAIK per default nur LUN0. Zum anderen wird bei
SCSI1 die LUN ueber den CDB selektiert, seit SCSI2 macht man das aber
mit einer IDENTIFY message. Letztere wird dein Controller vermutlich
noch nicht verstehen und das LUN Feld im CDB ist heute reserviert und
wird von Linux eventuell nicht mehr ausgefuellt. Muesste man mal naeher
anschauen ...

BTW: Hast du mal probiert mit deinem Tool INQUIRY haendisch an _alle_
LUNs zu schicken ob nicht doch eine davon antwortet?

Post by Manfred Ugubait

Post by Michael Baeuerle
Das ist aber ein starkes Indiz, dass das Problem woanders liegt. Waere
INQUIRY wirklich nicht implementiert, sollte die Platte mit CHECK
CONDITION und Sense key 5 (Illegal request) reagieren und es nicht zu
einem Haenger kommen.

Evtl. kommt die Version des Treibers, die sich aufhängt, mit der
Fehlermeldung nicht klar oder irgendwas mit dem Timing stimmt dort
nicht. Die anderen Versionen hängen ja nicht, finden nur auch nichts.

Wie sollen sie auch ohne INQUIRY? In den "Inquiry data" steht
schliesslich drin ob die angesprochene LUN existiert bzw. unterstuetzt
wird oder nicht. Auch weiss der Host sonst nicht, dass er eine Platte
vor sich hat. Dieser Befehl wird daher wohl von quasi jedem Host
verwendet.

Dazu steht in Byte0/Bit5,6,7 der Inquiry data der "peripheral
qualifier":
000 LUN is connected
001 LUN is supported but not connected
010 Reserved
011 LUN is not supported
1xx Vendor specific

Sollte der Controller wirklich mehrere LUNs unterstuetzen muss er das
eigentlich koennen (darf jedenfalls kein Check condition erzeugen)
selbst wenn die Antwort "vendor specific" ist.

Post by Manfred Ugubait

Post by Michael Baeuerle
MODE SENSE wird von Linux verwendet um den Schreibschutzstatus
auszulesen und muss implementiert sein (obwohl es bis heute nach SCSI
spec optional ist). Fuer die Bestimmung der Groesse wird READ CAPACITY
verwendet, das muss auch implementiert sein.

Also lt. Handbuch kennt der ACB4000 READ CAPACITY [*]. SCSITOOL zeigt
die Plattengröße auch richtig an.
Manfred
[*] weiterhin READ, SEEK, RECEIVE DIAGNOSTIC, TEST UNIT READY, FORMAT
UNIT, WRITE, SEND DIAGNOSTIC, VERIFY, REZERO UNIT, MODE SELECT,
SEARCH DATA EQUAL, REQUEST SENSE, WRITE AND VERIFY, MODE SENSE,
TRANSLATE

Ist also Gott und die Welt implementiert. Wenn Adaptec da wirklich das
vergleichsweise triviale INQUIRY "vergessen" hat, gehoeren sie
rueckwirkend dafuer gesteinigt ;-)


Micha

[Manfred Ugubait]

Post by Michael Baeuerle
Hmm, 4 Bytes wuerden genau auf die INQUIRY Daten passen, aber nicht auf
die Sense Daten (jedenfalls in den Formaten wie sie heute ueblich sind).

Doch, das sind schon Sense-Daten, im "Nonextended Sense Data Format"
gem. SCSI-1. Dabei enthält das erste Byte die Fehlernummer und die
drei weiteren Bytes eine LBA, falls das MSB des ersten Bytes gesetzt
ist.

Post by Michael Baeuerle
Poste doch mal die 4Byte Rohdaten.

Das ist im Regelfall (kein Fehler): 00 00 00 00.

Post by Michael Baeuerle
Da es ein bridge controller ist unterstuetzt er vermutlich mehrere
Platten und tut sie auf unterschiedliche LUNs mappen.

Er unterstützt zwei Platten, meine ist LUN 0.

Post by Michael Baeuerle
Zum anderen wird bei
SCSI1 die LUN ueber den CDB selektiert, seit SCSI2 macht man das aber
mit einer IDENTIFY message.

Das wird laut Handbuch sogar schon vom ACB4000 unterstützt. Ist aber
auch egal, da meine Platte eh LUN 0 ist.

Post by Michael Baeuerle
BTW: Hast du mal probiert mit deinem Tool INQUIRY haendisch an _alle_
LUNs zu schicken ob nicht doch eine davon antwortet?

Habe ich nicht. Aber warum sollte ein Controller, der laut Handbuch
INQUIRY nicht kennt, bei einer nicht belegten LUN plötzlich doch
drauf antworten. Meine Platte ist definitiv LUN 0.

Post by Michael Baeuerle
Wie sollen sie auch ohne INQUIRY?

Manuelle Konfiguration? Das ist es ja, was ich unter Linux suche.
Alternativ: Kann irgendein BSD (für das eine LiveCD existiert) das
vielleicht?

Post by Michael Baeuerle
Ist also Gott und die Welt implementiert. Wenn Adaptec da wirklich das
vergleichsweise triviale INQUIRY "vergessen" hat´

Haben sie. Wie ich ja schon schrieb, geht es tatsächlich nicht, die
Fehlermeldung ist eindeutig ("Illegal command" lt. Handbuch) und
INQUIRY ist auch im Handbuch nicht dokumentiert. Dort ist sonst jedes
unterstützte Kommando in allen Einzelheiten beschrieben.

Manfred

[Michael Baeuerle]

Post by Manfred Ugubait

Post by Michael Baeuerle
Hmm, 4 Bytes wuerden genau auf die INQUIRY Daten passen, aber nicht auf
die Sense Daten (jedenfalls in den Formaten wie sie heute ueblich sind).

Doch, das sind schon Sense-Daten, im "Nonextended Sense Data Format"
gem. SCSI-1.

OK, ich habe keine SCSI1 spec hier und auf T10.org gibts auch keinen
Draft.
Ich wollte es einfach nicht glauben, dass der kein INQUIRY unterstuetzt.

Post by Manfred Ugubait

Post by Michael Baeuerle
[...]
Zum anderen wird bei
SCSI1 die LUN ueber den CDB selektiert, seit SCSI2 macht man das aber
mit einer IDENTIFY message.

Das wird laut Handbuch sogar schon vom ACB4000 unterstützt.

Interessant, dann ist das LUN Feld im CDB offenbar eine noch aeltere
Altlast als ich dachte (womoeglich noch aus SASI Zeiten).

Post by Manfred Ugubait
Ist aber
auch egal, da meine Platte eh LUN 0 ist.

Ist ein Argument, hattest du aber am Anfang nicht geschrieben.

Post by Manfred Ugubait

Post by Michael Baeuerle
[...]
Wie sollen sie auch ohne INQUIRY?

Manuelle Konfiguration? Das ist es ja, was ich unter Linux suche.
Alternativ: Kann irgendein BSD (für das eine LiveCD existiert) das
vielleicht?

NetBSD steuert die Behandlung von SCSI quirks auch ueber die Daten die
INQUIRY liefert. Ueber diese Database geht also nichts. Du koenntest
dort probieren den sd Treiber an das device zu binden indem du den Kern
so in der Art konfigurierst:

sd0 at scsibus0 target 0 lun 0

Ich denke das wird halt nur den sd Treiber interessieren. Laut scsi(4)
bindet aber der midlayer Treiber die devices, d.h. wenn nur sd Bescheid
weiss funktioniert noch nichts. Einen Versuch waere es trotzdem wert ...

Ob es die anderen BSDs besser koennen weiss ich nicht (bezweifle es
aber). Ich denke da wird man genau wie bei Linux selbst Hand anlegen
muessen. Warum solls das auch schon geben wo es kein Mensch ausser dir
braucht ;-), damit kann man sich uebel in den Fuss schiessen.

Wenn ein Q&D Hack reicht koennte man Bus0/ID0/LUN0 mit festen Daten
(Typ0/non-removable + irgendwelche Dummy strings) hart in den midlayer
Treiber compilieren. Auf diese Weise wuerde es wenigstens mit allen
Hostadaptern funktionieren.


Micha