Hello, first of all, I apologize if this is a settled issue. I looked
through the linux-scsi archives, and couldn't find any mention of this.
Here's the short story: I have a serial port device that uses SCSI as the
transport. Specifically, this is a Central Data SCSI Terminal Server.
(Now Digi International: http://digi.com/digi.cfm?p=631874.pi.prd.00000049)
It correctly calls itself a type 9 scsi device (communications). When the
kernel boots, both the scsi code and the scsi dma code complain since they
don't recognize this type of device:
(there are 3 STSs here: one Motorola OEM device, and 2 Central Data STSs,
each device uses LUNs 0 and 1)
scsi0 : ncr53c8xx - version 3.2a-2
scsi : 1 host.
ncr53c875-0: command processing resumed
Vendor: QUANTUM Model: XP32275W Rev: LXY4
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
scsi: unknown type 9
Vendor: MOTOROLA Model: STS-S16P Rev: V4.1
Type: Communications ANSI SCSI revision: 02
ncr53c875-0-<2,*>: asynchronous.
scsi: unknown type 9
Vendor: MOTOROLA Model: STS-S16P Rev: V4.1
Type: Communications ANSI SCSI revision: 02
scsi: unknown type 9
Vendor: CenData Model: ST-1620 Rev: V5.7
Type: Communications ANSI SCSI revision: 02
ncr53c875-0-<3,*>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 15)
scsi: unknown type 9
Vendor: CenData Model: ST-1620 Rev: V5.7
Type: Communications ANSI SCSI revision: 02
scsi: unknown type 9
Vendor: CenData Model: ST-1620 Rev: V5.7
Type: Communications ANSI SCSI revision: 02
ncr53c875-0-<4,*>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 15)
scsi: unknown type 9
Vendor: CenData Model: ST-1620 Rev: V5.7
Type: Communications ANSI SCSI revision: 02
ncr53c875-0-<0,0>: tagged command queue depth set to 8
resize_dma_pool: unknown device type 9
resize_dma_pool: unknown device type 9
resize_dma_pool: unknown device type 9
resize_dma_pool: unknown device type 9
resize_dma_pool: unknown device type 9
resize_dma_pool: unknown device type 9
ncr53c875-0-<0,*>: WIDE SCSI (16 bit) enabled.
ncr53c875-0-<0,*>: FAST-20 WIDE SCSI 40.0 MB/s (50 ns, offset 16)
SCSI device sda: hdwr sector= 512 bytes. Sectors= 4445380 [2170 MB] [2.2 GB]
sda: sda1 sda2 < sda5 >
>From looking through the linux kernel code, I notice that in
include/scsi/scsi.h, "TYPE_COMM" is not specified. However, in
drivers/scsi/tmscsim.h and advansys.c, it is. No device appears to
actually USE these defines, and in scsi.c, the 9th type in
"scsi_device_types" IS written in as "Communications".
Therefore, I'd conclude that the missing definition in include/scsi/scsi.h
is simply just the case that no one has or uses these devices, especially
since the "scsi_devices_types" array is populated with the information,
I'd argue that "TYPE_COMM" *should* be included in scsi.h.
Anyway, I'd like to propose the following patch so that the scsi code and
the dma pool code don't complain about an "unknown device". The only
concern I have here is whether there is some specific size of dma memory
we should be allocating for this kind of device. Currently with my
minimal use of the sg driver, the default dma size appears to be just
fine.
--
Cornelius "Kees" Cook [EMAIL PROTECTED]
Sr. Systems Engineer Counterpoint Networking, Inc.
diff -uNr linux-2.4.0-test5/drivers/scsi/scsi_dma.c
linux-2.4.0-test5-kees/drivers/scsi/scsi_dma.c
--- linux-2.4.0-test5/drivers/scsi/scsi_dma.c Fri Mar 10 17:24:02 2000
+++ linux-2.4.0-test5-kees/drivers/scsi/scsi_dma.c Sat Aug 5 17:50:49 2000
@@ -260,6 +260,7 @@
new_dma_sectors += (2048 >> 9) *
SDpnt->queue_depth;
} else if (SDpnt->type == TYPE_SCANNER ||
SDpnt->type == TYPE_PROCESSOR ||
+ SDpnt->type == TYPE_COMM ||
SDpnt->type == TYPE_MEDIUM_CHANGER ||
SDpnt->type == TYPE_ENCLOSURE) {
new_dma_sectors += (4096 >> 9) * SDpnt->queue_depth;
diff -uNr linux-2.4.0-test5/drivers/scsi/scsi_scan.c
linux-2.4.0-test5-kees/drivers/scsi/scsi_scan.c
--- linux-2.4.0-test5/drivers/scsi/scsi_scan.c Wed Jul 19 00:26:13 2000
+++ linux-2.4.0-test5-kees/drivers/scsi/scsi_scan.c Sat Aug 5 17:49:58 2000
@@ -578,6 +578,7 @@
case TYPE_SCANNER:
case TYPE_MEDIUM_CHANGER:
case TYPE_ENCLOSURE:
+ case TYPE_COMM:
SDpnt->writeable = 1;
break;
case TYPE_WORM:
diff -uNr linux-2.4.0-test5/drivers/scsi/tmscsim.h
linux-2.4.0-test5-kees/drivers/scsi/tmscsim.h
--- linux-2.4.0-test5/drivers/scsi/tmscsim.h Fri Apr 21 18:08:45 2000
+++ linux-2.4.0-test5-kees/drivers/scsi/tmscsim.h Sat Aug 5 17:52:22 2000
@@ -442,7 +442,6 @@
/* see include/scsi/scsi.h for the rest */
#define TYPE_PRINTER 0x02 /* Printer device */
-#define TYPE_COMM 0x09 /* Communications device */
/*
** Inquiry flag definitions (Inq data byte 7)
diff -uNr linux-2.4.0-test5/include/scsi/scsi.h
linux-2.4.0-test5-kees/include/scsi/scsi.h
--- linux-2.4.0-test5/include/scsi/scsi.h Mon Dec 13 00:55:54 1999
+++ linux-2.4.0-test5-kees/include/scsi/scsi.h Sat Aug 5 18:02:31 2000
@@ -137,6 +137,7 @@
#define TYPE_MOD 0x07 /* Magneto-optical disk -
* - treated as TYPE_DISK */
#define TYPE_MEDIUM_CHANGER 0x08
+#define TYPE_COMM 0x09 /* Communications device */
#define TYPE_ENCLOSURE 0x0d /* Enclosure Services Device */
#define TYPE_NO_LUN 0x7f
diff -uNr linux-2.4.0-test5/CREDITS linux-2.4.0-test5-kees/CREDITS
--- linux-2.4.0-test5/CREDITS Wed Jul 26 12:38:23 2000
+++ linux-2.4.0-test5-kees/CREDITS Sat Aug 5 17:58:19 2000
@@ -507,6 +507,14 @@
D: Assorted sched/mm titbits
S: Oxfordshire, UK.
+N: Kees Cook
+E: [EMAIL PROTECTED]
+W: http://outflux.net/
+P: 1024D/17063E6D 9FA3 C49C 23C9 D1BC 2E30 1975 1FFF 4BA9 1706 3E6D
+D: Minor updates to SCSI code for the Communications type
+S: (ask for current address)
+S: USA
+
N: Alan Cox
W: http://roadrunner.swansea.linux.org.uk/alan.shtml
E: [EMAIL PROTECTED]
