IDE-Laufwerk mit "LUN 1" in 2023 nutzen: wie?
Florian Lohoff
f at zz.de
Wed Aug 23 00:41:38 CEST 2023
Hola,
On Tue, Aug 22, 2023 at 03:56:41PM +0200, Kai 'wusel' Siering wrote:
> > Der Trick damals war, in scsi/scsi_devinfo.c einen Eintrag zu ver-
> > senken, daß der SCSI-Treiber bei dem ATA-Gerät einen LUN-Scan macht.
> > Ich habe das nun beim Debian-6.1er-Kernel aus dem Gedächtnis ver-
> > sucht, leider ohne Erfolg:
>
> Das war vermutlich nie im Mainline-Kernel, ich hab's damals mit dem
> Eintrag im selbstgebauten Kernel zum Laufen bekommen. Evtl. ging's
> auch anders (s. verlinkter Beitrag aus 1999 aus .cz), aber die Optionen
> gibt's auch überwiegend nimmer und der Bookwork-Standard-Kernel zuckt
> leider auch nicht.
Das könnte man immer noch probieren. Die BLISTS da sind ja quirks
für unterschiedliche devices. Ich würde das da mal rein nageln.
> Das befürchte ich auch, daher hatte ich mir eine PCIe-Karte mit Promise-
> Chip und PATA (+ 2x SATA und 2x eSATA (IIRC alternativ)) gekauft und den
> ersten Test damit gemacht — KISS. Leider ohne Erfolg. Und auch auf dem
> 2009er Rechner mag das 2. PD-518E am Onboard-PATA-Port unter Kernel 6.1
> nicht mit LUNs spielen:
Also LUNs sind im SCSI unabdingbar und offensichtlich gabs das ja im
IDE auch und war seit dem libpata ja auch usus das das genutzt wurde.
> > Ich denke du brauchst ein PATA basierendes Board oder ein PCI/PCIe PATA
> > Controller.
> Zuckt leider beides nicht :-(
> CONFIG_SCSI_MULTI_LUN ist 2014 rausgeflogen [2], CONFIG_*_IDE* gibt's
MULTI_LUN war IMHO schon immer supported und notwendig bei SCSI Disc
changern und co. Die CONFIG option ist vieleicht verschwunden weil es
jetzt per default da ist.
> LUN prinzipiell noch drin sein. Fühlt sich aber so an, als ob das für
> IDE rausgeflogen wäre, denn mit dem "BLIST_FORCELUN | BLIST_SINGLELUN"-
> Eintrag klappt's ebensowenig wie ohne :-(
Eigentlich müsste das FORCELUN sein - SINGLELUN verstehe ich nicht. Hat
aber mit scanning nix zu tun.
> Wobei ich mich gerade frage, ob das DVD-RAM-LW nicht auch als /dev/sdX
> auftauchen müßte, um damit DVD-RAMs nutzen zu können? Ist so laaange her ...
Als /dev/srX denke ich
So - ich hab nochmal im libata zeugs gesucht - Das libata/scsi glue
layer supported nur eine LUN.
2604 static unsigned int ata_scsiop_report_luns(struct ata_scsi_args *args, u8 *rbuf)
2605 {
2606 rbuf[3] = 8; /* just one lun, LUN 0, size 8 bytes */
2607
2608 return 0;
2609 }
Und das ist seit anbeginn des Git von 2005 aka Linux-2.6.12-rc2 schon
so.
Also - meine working hypothese - Das hat mit dem alten "ide"
driverset/layer funktioniert - aber nie mit libata/libsata - dem neuen
IDE/SATA layer.
In dem alten IDE layer gab es immer schon eine sonderbehandlung für
ATAPI devices die immer schon durch das scsi layer gezogen wurden.
Deshalb auch hier dieser bootlog von der cz seite:
ide: i82371 PIIX (Triton) on PCI bus 0 function 33
ide0: BM-DMA at 0xd800-0xd807
ide1: BM-DMA at 0xd808-0xd80f
hda: WDC AC26400B, 6149MB w/512kB Cache, CHS=784/255/63, UDMA
hdb: TEAC PD-1 PD-518E, ATAPI CDROM drive - enabling SCSI emulation
^^^
hdb -> alter ide layer
ATAPI overlap supported: No
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
md driver 0.36.3 MAX_MD_DEV=4, MAX_REAL=8
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
^^^^^^^^^
Hier wird der ATAPI scsi emulation basierend auf dem ide layer
angeworfen.
So - und der alte IDE layer ist mit 5.late rausgeflogen. In 4.20 ist
der noch drin. Musst dann nur noch aufpassen das der drin ist
und nicht libata sich den controller schnappt.
Flo
--
Florian Lohoff f at zz.de
Any sufficiently advanced technology is indistinguishable from magic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20230823/17cefd0c/attachment.sig>
More information about the Linux
mailing list