Linux 2.2.17 Not Recognizing all LUNs on a CD Tower

From: Post, Mark K (mark.post@eds.com)
Date: Mon Oct 09 2000 - 12:01:19 EST


At work we recently acquired a used SCSI CD Tower from somewhere else
in the company. I want to hook this up to my Slackware Linux system,
but I'm having a problem with it. It's being detected by the system,
but only partially. There is also a CDR drive on the SCSI chain that
is being detected properly, and works well. The CDR is target id 1,
and the tower is target id 2.

The unit has a label on the back that says "Procom Technology CDT7-4X
Plus". When the SCSI module (advansys.o) is loaded, it tells me that
the tower is a "CMD TEC, Model SCEA-2000, Rev A6Z, type (31) Unknown"
dmesg additionally shows "ANSI SCSI revision: 01 CCS" for the device.
This is from the CMD Technology SCSI interface card in the tower that
is used to convert the multiple SCSI target ids for the CDROMs to LUNs
on the external SCSI chain.

I specified in my kernel parameters that all LUNs should be probed,
but I'm only seeing LUN 0 reported. I tried looking all over the
Procom web site, but nothing jumped out at me as to what might be
wrong. The SCSI card inside the PC itself was shipped to us from the
other department along with the tower, so I have to believe it was
working for them (most likely on a Windows system). That card is a
SIIG i540, and is set to target id 7. The card is supposed to
support multiple LUNs.

I looked at the code in drivers/scsi/scsi.c, and tried adding the
tower to the device_list table with a flag value of BLIST_FORCELUN,
but that didn't fix it either. I then added a bunch of printk
statements to try and figure out what was happening, but I don't
really understand what I'm seeing.

When the scan_scsis_single routine runs, I see this for LUN 0:

scsi_do_cmd (host = 0, channel = 0 target = 2, buffer =c009e400, bufflen =
256, done = c481c50c, timeout = 600, retries = 5)
command : 00 00 00 00 00 00 00 00 02 00
internal_cmnd (host = 0, channel = 0, target = 2, command = c009e645, buffer
= c009e400,
bufflen = 256, done = c481c50c)
queuecommand : routine at c482e5ec
scan_scsis_done(c01df000, 000000)
scsi: scan_scsis_single id 2 lun 0. Return code 0x00000000
Driverbyte=0x00(DRIVER_OK,SUGGEST_OK) Hostbyte=0x00(DID_OK)
scsi: performing INQUIRY
scsi_do_cmd (host = 0, channel = 0 target = 2, buffer =c009e400, bufflen =
256, done = c481c50c, timeout = 200, retries = 3)
command : 12 00 00 00 ff 00 00 00 02 00
internal_cmnd (host = 0, channel = 0, target = 2, command = c009e645, buffer
= c009e400,
bufflen = 256, done = c481c50c)
queuecommand : routine at c482e5ec
leaving internal_cmnd()
Leaving scsi_do_cmd()
scan_scsis_done(c01df000, 000000)
scsi: INQUIRY successful with code 0x0
        ---> At this point, a printk shows the value of scsi_result[0]=63.
scsi: unknown type 31
  Vendor: CMD TEC Model: SCEA-2000 Rev: A6Z
  Type: Unknown ANSI SCSI revision: 01 CCS

Then scan_scsis_single looks at LUN 1, which would be the first CDROM
in the tower...

scsi_do_cmd (host = 0, channel = 0 target = 2, buffer =c009e400, bufflen =
256, done = c481c50c, timeout = 600, retries = 5)
command : 00 20 00 00 00 00 00 00 02 00
internal_cmnd (host = 0, channel = 0, target = 2, command = c009e645, buffer
= c009e400,
bufflen = 256, done = c481c50c)
queuecommand : routine at c482e5ec
scan_scsis_done(c01df000, 000000)
scsi: scan_scsis_single id 2 lun 1. Return code 0x00000000
Driverbyte=0x00(DRIVER_OK,SUGGEST_OK) Hostbyte=0x00(DID_OK)
        ---> This would appear to be goodness, all zeros. ??
scsi: performing INQUIRY
scsi_do_cmd (host = 0, channel = 0 target = 2, buffer =c009e400, bufflen =
256, done = c481c50c, timeout = 200, retries = 3)
command : 12 20 00 00 ff 00 00 00 02 00
internal_cmnd (host = 0, channel = 0, target = 2, command = c009e645, buffer
= c009e400,
bufflen = 256, done = c481c50c)
queuecommand : routine at c482e5ec
scan_scsis_done(c01df000, 000000)
scsi: INQUIRY successful with code 0x0
        ---> At this point, a printk shows the value of scsi_result[0]=127
        ---> which apparently says that LUN 1 doesn't really exist, so quit.

So, does anyone have any idea
1. What a SCSI type of 31 is, and what should it really be for this
   type of device?
2. Why I'm getting a scsi_result[0]=127 on LUN 1 (and all following
   LUNs if I force the code to continue by ignoring the result)?
3. What I can do about this?

If anyone needs more information, I will do whatever is necessary to
gather it for you.

Thanks in advance for any and all help.

Mark Post
Electronic Data Systems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:12 EST