Brendan Miller wrote:
> > There is 8)
> >
> > BLIST_MAX5LUN
> >
> > Used for:
> > {"REGAL", "CDC-4X", "*", BLIST_MAX5LUN | BLIST_SINGLELUN},
>
> --
>
> > Yes. Look at REGAL again - the flags they use are both SINGLELUN and
> > 5LUNS. This is exactly the same set of flags that you need to be using.
>
> Okay, well I added
>
> {"LASOUND","CDX7405","3.10", BLIST_MAX5LUN | BLIST_SINGLELUN},
>
All right, I checked my scsi setup again and saw to it that
scsi.c (2.2.14) has Nakamichi MBR-7 blacklisted as expected for a quite long
time
so far.
I re-checked the operation of my MBR changer.
I did
/dev/scd0 is a different SCSI on different SCSI bus (controlled by
BusLogic.)
/dev/scd[1-7] is the 7 drives in Nakamichi changer (controlled by AMD scsi
chip driven by tmscsim driver.)
/dev/scd1 contains the Sun Free Solaris 7 Japanese edition (Lots of
directories/files).
/dev/scd2 contains a CD that came with a Unix magazine (many tar files from
GNU
project.)
I did the following.
mount /dev/scd1 /mnt1
mount /dev/scd2 /mnt2
Step 1
ls -lR /mnt1 (in one window), and after a few seconds
ls -lR /mnt2 (in another window).
This time they seem to finish (however, I was wrong. The listing was
incomplete
obviously.)
Step 2
Surprised that the ls processes seemed to finish this time around,
I tried to see if the CDs were correctly read and tried to produce errors by
running this.
find /mnt1 -type f -print | xargs egrep -i test (in one window)
and thendid
ls -lR /mnt2 (in another window).
Then I noticed that the find .. | xargs egrep ... ended with I/O error.
Somehow the file on the Solaris could not be read.
more that_file_on_cd produced nothing.
(It looks that the memory buffer contained an empty file data and
it got stuck that way)
I unmonted /mnt1 and remounted, and ran
ls -lR /mnt1
this time, the listing took much longer than in Step 1, and I realized
that the ls in Step1 probably didn't finish completely, but somehow
cut short without showing all the files!
I now did
ls -lR /mnt2
and was surprised to find that the listing ONLY showed the top most directory
entry
and finish there!!
I umounted /mnt2 and mounted it again. "ls -lR /mnt2" now showed
(hopefull) all the directories/files.
Now, it occurred to me that Brendan's CD is much newer than mine.
His must be a brand new one (with spacer in the unit).
Mine is almost 5 years old or older. (Not sure exactly.)
I checked the drivers/scsi/scsi.h but could not deduce immediately
how much time will be inserted between the time a LUN
is accessed after another differnt LUN is used in a device
that has BLIST_SINGLELUN bit set.
I am thinking that in the ever-lasting quest for better performance
out of linux kernel and scsi subsystem, maybe extra slack time
that was unintentionally staying in the code has been removed
in the latest versions of the kernel
and this lack of extra dormant time might be biting
this old SCSI changer of mine and the read error (or some
type of SCSI errors?) ensued.
(Come to think of it, I have absolutely NO idea what the SCSI
standard has to say about this. )
This is just a theory.
But given that the increasing the timeout value to something like 30 seconds
in a few revision back fixed the problem of ever-lasting reset in the face
of bad block handling (some old SCSI disks tend to take a long time which
was longer than the previous timeout value.), I feel that
this explanation might have some merit.
I know introducing another BLIST_LONGERSWITCHTIME or
whatever is ugly, but ...
Any hint in figuring out the slack time, i.e., the minimum dormant time
between the two consecutive accesses to different LUNs in
BLIST_SINGLELUN device ? (The while loop seems to look for
the available command block in scsi.c doesn't seem to insert no such delay.
The current scheme in 2.2.14 is just to not to return an available command
block if a different LUN is supposedly processing a command.
(Once the previous command on the different LUN is finished,
a command block would be returned immediately if inquired.
Maybe the laterst versions of the kernel became so efficient
[or the scheduling of pending commands changed in a certain way]
the re-inquiry now takes very fast immediatly after the completion of the
previous command on a different LUN without the unspecified, but probably
necessary delay. Maybe in the older kernel versions,
there was an unintended delay that made my changer's LUN change
mechanism and firmware happy.
So maybe for a single LUN device if the
last accessed LUN is the different one (Oh, we need to remember this?)
we can simply insert some delay somewhere (the higher the level
is desirable, I think.).
Just a wild guess...
Since my set up is SCSI only once it boots up, detailed logging
at the low-level part of scsi system results in a very voluminous output,
I feel uncomfortable doing it. (Well, I guess by deleting all the
old log files, I can probably let the /var partition have more free space.)
If someone needs such info, I can try the verbose logging
and/or re-checking the operation by connecting the changer to Buslogic card,
etc..
Happy Hacking
Chiaki Ishikawa
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
