Douglas Gilbert wrote:
> The attached patch builds on top of the one Eric posted
>a few days ago for lk 2.4.1 . As well as Eric's changes
>this patch:
> - puts the above lun check in:
> mid-level, sd, st, osst, sg, sr (sr_ioctl + sr_vendor)
> - implements the lun 0 scsi_level inheritance discussed
> above during scanning
> - has no CRs :-)
>
Sidenote: maybe someone should modify `patch' to add
an option to ignore the CR in the context matching.
>It builds and is running on my machine but I don't have
>any devices with lun > 0 so I would be grateful if others
>would test it. Implementing 64 bit luns would be quite
>messy (I see CAM3 uses an array of 2 (32 bit) integers).
I removed the original patch that was posted
a few days ago,
and applied the ey2 patch.
I then compiled the kerenel and booted my PC with
Nakamichi MBR-7 (7 luns), and
a Matsushita CD/PD combo drive (2 luns) on
Tekram DC390 SCSI host card.
It seems that there is no problem with
this configuration:
All the luns were recognized.
No visible error/warning message in dmesg or
syslog files.
(Except that there is a slight
problem. I have been using devfs for about a week..
Is it possible that
/dev/scsi/host1/bus0/target5/lun0/generic
exists BEFORE
/dev/scsi/host1/bus0/target5/lun0/cd
(This is CD/PD combo.)
I tried the filename completion against the said
lun device name. Somehow bash only recognized
the name `generic' and automatically complete it.
I am using sg and generic must be the name that refers to it.
Oh well, this is more like devfs issue rather than the SCSI
driver problem.
Happy Hacking,
Chiaki Ishikawa
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
