On Wed, 8 Sep 1999, ishikawa wrote:
> I take that this means the scsi_debug.c code under drivers/scsi.
> Is there a newer version or hacked up version of scsi_debug other
> than the one currently in 2.2.12 release?
> As part of my debugging efforts, I tried to tinker
> with this code and see if I could use it as a module.
> The system didn't crash, but I saw too many devices inserted after
> "insmod scsi_debug". Anyway, good to hear that scsi_debug could be used
> as dummy host adaptor for debugging purposes.
You need to "configure" the thing. The reason it was behaving
this way was that the last person to use it configured it to simulate
20 hosts with 6 disks each (for a total of 120 disks). Obviously to
test the support for using multiple major numbers for scsi disks.
To "configure" it, you edit the source. Sorry, but the thing
really serves as kind of a plugboard so that you can simulate different
conditions. I have used it in the past to simulate user reported error
conditions, error handling, etc, etc. It can simulate having bad blocks,
it can simulate having lockups. With a little imagination, you can
simulate most anything.
It would be theoretically possible to have it allocate a few MB of
ram, and use that for backing storage. In this way you could put a
filesystem on it and challenge the thing a bit more.
> Oh, I was trying to see if we could get the
> scsi mid-level layer or the error handling code a little more robust
> during error handling (MEDIUM ERROR and such) and since
> we can't simulate these errors in a predictiable manner,
> I thought maybe hacking scsi_debug.c and let it simulate the
> error conditions might be a good idea.
This can easily be done - I would recommend doing it in the
user-space simulator. You can step through it in the debugger and see
exactly how the code behaves (the error handler threads really do work).
The scsi_debug simulator can trivially be programmed to return a spurious
MEDIUM_ERROR. There is already code in there (commented out) to simulate
a spurious medium change (mainly to make sure that the partition tables
are properly re-read.
The other advantage of the user-space approach is that
recompile/reboot cycles are very short. I did some of the actual coding
and debugging on a laptop while I was on some rather long plane flights.
In reference to the user-space simulator - it is a real hack. I
had to scab together something not unlike a non-preemtive pthreads
scheduler so that error handling threads, bottom half handlers, and
bdflush would all run correctly when they were schedulable. In addition,
memory management is pretty fragile - seemingly minor changes to the
memory manager break the thing, and then I have to hack it back together
again. The only reason I wrote the thing is that it is so incredibly
useful to be able to step through the entirety of the scsi code in a
debugger.
If people like the idea of a user-space simulator enough to want
to develop the idea further, I would suggest that the right way to do it
is to define the user-space simulator as a new architecture type, and in
arch/i386sim/boot it would simply create a shared library. The actual
user-space executable that exercises the thing could call in at the
appropriate places to do whatever it wanted, but I suspect that it would
be a whole lot easier to maintain.
Like I said, it would be trivial for me to dig out the sources for
what I have from my laptop and put it on my web site. Given the scabbed
up way you build the thing, I would probably also include pre-built
binaries to help get people started.
-Eric
> In any case, I would be happy to see the
> SCSI code cleanup taking place anyway.
> Once the code is more readable,
> other wrappers and such can be contemplated
> with better understanding of (or easier to understand)
> SCSI code.
>
>
> Eric Youngdale wrote:
>
> >
> >
> > For more information and a link to the patches, see
> > http://www.andante.org/scsi_queue.html.
> >
> > There is a lot to absorb - if the web site doesn't explain it, I
> > will be happy to go into more detail.
> >
> > Note- I don't read linux-kernel. Replies to either linux-scsi or
> > to me directly via email.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
