X-PMC-CI-e-mail-id: 11142
Hi,
A few weeks ago, I mentioned the possibility of
drivers/scsi/scsi_debug.c as a debug tool for simulating a faulty disk
to make the scsi sub-system robust.
I am no kernel hacker and didn't find the good doc on the inner
workins of the SCSI subsystem. So I didn't exactly know where to
start updating this old file for modern kernel.
In order to see how much effort would be needed for the update, I
simply compiled the scsi_debug.c as a module using the same
compilation flags that are used for compiling the tmscsim.o module
(DC390 driver). Then I tried to see how outdated it is by trying to
insert it using insmod.
Of course, I expected a system crash initially.
However, the system kept on running...
# insmod scsi_debug
... a long pause ...
#
The pause is obviously caused by the
excessive number of devices registerd by scsi_debug.
The following is what I observed.
I have BusLogic and Tekram DC390 (supported by tmscsim driver).
---
ishikawa@standard$ ls -l /proc/scsi
total 0
dr-xr-xr-x 5 root root 0 Aug 26 02:47 ./
dr-xr-xr-x 104 root root 0 Aug 26 1999 ../
dr-xr-xr-x 2 root root 0 Aug 26 02:47 BusLogic/
-rw-r--r-- 1 root root 0 Aug 26 02:47 scsi
dr-xr-xr-x 2 root root 0 Aug 26 02:47 scsi_debug/
dr-xr-xr-x 2 root root 0 Aug 26 02:47 tmscsim/
ishikawa@standard$ ls /proc/scsi/scsi_debug
./ 10 12 14 16 18 2 21 4 6 8
../ 11 13 15 17 19 20 3 5 7 9
***Note the large number of (virtual) cards registered above!
ishikawa@standard$ cat /proc/scsi/scsi_debug/2
This driver is not a real scsi driver, but it plays one on TV.
It is very handy for debugging specific problems because you
can simulate a variety of error conditions
ishikawa@standard$ cat /proc/scsi/scsi_debug/21
This driver is not a real scsi driver, but it plays one on TV.
It is very handy for debugging specific problems because you
can simulate a variety of error conditions
*** cat /proc/scsi/scsi shows about 120 (= 20 [adapters] x
6 [targets / adapters] imaginery direct-access devices.
These are, however, removable devices according to the
/var/log/messages log.
I have REAL scsi disk at sda, and at sdb.
The imaginery devices are at sdc, sdd, sde, ...,
sdx, sdy, sdz,
sdaa, sdab, sdac, ..., sday, sdaz,
sdba, sdbb, sdbc, ..., sdby, sdbz,
sdca, sdcb, sdcc, ..., sdcy, sdcz,
sdda, sddb, sddc, ..., sddp, and sddq!!!
Also, there are interesting messages near the end of the
/var/log/messages file after the insertion of scsi_debug.o finished.
"resize_dma_pool" warning seems to indicate we have run out of memory
pools somehow due to the excessive number of imaginery host cards?
...
Aug 26 02:45:41 standard kernel: Detected scsi removable disk sddp at scsi21, channel
0, id 3, lun 0
Aug 26 02:45:41 standard kernel: Vendor: Foo Inc Model: XYZZY Rev: 1
Aug 26 02:45:41 standard kernel: Type: Direct-Access ANSI
SCSI revision: 01
Aug 26 02:45:41 standard kernel: Detected scsi removable disk sddq at scsi21, channel
0, id 4, lun 0
Aug 26 02:45:41 standard kernel: Vendor: Foo Inc Model: XYZZY Rev: 1
Aug 26 02:45:41 standard kernel: Type: Direct-Access ANSI
SCSI revision: 01
Aug 26 02:45:41 standard kernel: Detected scsi removable disk sddr at scsi21, channel
0, id 5, lun 0
Aug 26 02:45:42 standard kernel: scsi::resize_dma_pool: WARNING, dma_sectors=2464,
wanted=27184, scaling
Aug 26 02:45:42 standard kernel: scsi::resize_dma_pool: WARNING, dma_sectors=2464,
wanted=20400, scaling
Aug 26 02:45:42 standard kernel: scsi::resize_dma_pool: WARNING, dma_sectors=2464,
wanted=15312, scaling
Aug 26 02:45:42 standard kernel: scsi::resize_dma_pool: WARNING, dma_sectors=2464,
wanted=11488, scaling
Aug 26 02:45:42 standard kernel: scsi::resize_dma_pool: WARNING, dma_sectors=2464,
wanted=8624, scaling
Aug 26 02:45:42 standard kernel: SCSI device sdc: hdwr sector= 512 bytes. Sectors=
524289 [256 MB] [0.3 GB]
Aug 26 02:45:42 standard kernel: sdc: Write Protect is off
Aug 26 02:45:42 standard kernel: sdc: sdc1 sdc2 sdc3
Aug 26 02:45:42 standard kernel: SCSI device sdd: hdwr sector= 512 bytes. Sectors=
524289 [256 MB] [0.3 GB]
Aug 26 02:45:42 standard kernel: sdd: Write Protect is off
Aug 26 02:45:42 standard kernel: sdd: sdd1 sdd2 sdd3
Aug 26 02:45:43 standard kernel: SCSI device sde: hdwr sector= 512 bytes. Sectors=
524289 [256 MB] [0.3 GB]
Aug 26 02:45:43 standard kernel: sde: Write Protect is off
Aug 26 02:45:43 standard kernel: sde: sde1 sde2 sde3
Aug 26 02:45:43 standard kernel: SCSI device sdf: hdwr sector= 512 bytes. Sectors=
524289 [256 MB] [0.3 GB]
Aug 26 02:45:43 standard kernel: sdf: Write Protect is off
Aug 26 02:45:43 standard kernel: sdf: sdf1 sdf2 sdf3
---
QUESTION/REQUEST
Now my request is this.
Is the strange behavior a correct one that is expected
of the source file, scsi_debug.c?
I think it probably is buggy in the current kenrel environment.
The file seems to be very outdated.
I would like to update scsi_debug.c in the current kernel if I can.
Does anyone care to point me to the right set of `updated' documents
about the CURRENT SCSI subsystem?
Also, more importantly, in experts' opinions, what source file under
"driver/scsi" is the simplest SCSI host card adaptor driver file that
supports module and known to work in 2.2.x. (In other words, what is
the simplest SCSI card to support so that the driver source file is
not cluttered with arcane hardware tidbits and is easy to understand
how to code for module usage, and for working with 2.2.x kernel and
later.)
I would appreciate experts' comments on this request and my
observation.
I put the full message log lines at
http://www.yk.rim.or.jp/~ishikawa/sd-memo.txt
for your reference.
Chiaki Ishikawa wrote:
>
>
> Unless we have SCSI bus monitor or whatever, it is very
> difficult to figure out what goes on at this level, that's for sure.
>
> By the way, I thought that one reason that the SCSI subsystem is not
> robust as it could be is that the relative lack of testing devices
> that will fail reliablely.
> I am not kidding.
>
> In making software robust, sometimes we throw slightly
> errorneous input to see it can handle such faulty input in a graceful
> manner. (The keyword here is "robustness", not "correctness".)
>
> While trying to help the debugging efforts for this particular
> problem,
> I came across a file under drivers/scsi called scsi_debug.c
>
> The first few lines read,
>
> /* $Id: scsi_debug.c,v 1.1 1992/07/24 06:27:38 root Exp root $
> * linux/kernel/scsi_debug.c
> *
> * Copyright (C) 1992 Eric Youngdale
> * Simulate a host adapter with 2 disks attached. Do a lot of checking
> * to make sure that we are not getting blocks mixed up, and panic if
> * anything out of the ordinary is seen.
> */
>
> I wonder if anyone in the know can modify this
> to run under the 2.2.10 kernel and see
> if we can incoporate some random features to simulate
> the "slightly longer than standard RESET pause time" and
> other assorted `slightly' out of spec behavior
> in order to improve the handling of error/abnormal conditions
> of the SCSI system.
> (Being able to use the above file as a module would be certainly a
> plus.)
>
> Obviously, the above file was used to test the SCSI subsystem to
> see if it handles the properly behaving disk without mixing up
> buffers, etc.. Now I think we can use this to simulate a
> faulty disk and see if SCSI subsystem behaves in a graceful manner.
>
> BTW, I suspect that linux IDE/ATAPI drivers DO handle MORE abuse from
> non-complying devices than SCSI drivers today from what I have read in
> the mailing list of ATA/ATAPI standard activities. Why not let SCSI,
> too?
>
>
--
Ishikawa, Chiaki [EMAIL PROTECTED] or
(family name, given name) [EMAIL PROTECTED]
Personal Media Corp. ** Remove .NoSpam at the end before use **
Shinagawa, Tokyo, Japan 142-0051
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
