Messages in this thread |  | | From | "Post, Mark K" <> | Subject | Linux 2.2.17 Not Recognizing all LUNs on a CD Tower | Date | Mon, 9 Oct 2000 13:01:19 -0400 |
| |
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/
|  |