> 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 know this going to sound awful, but you may want to backtrack kernels
until you get it to work (if you used to have it working--I thought you did).
Then diff scsi.c (or more files) and see what really changed. Probably all
you'll get is an output that can be summarized as "Yep, the entire SCSI
code was changed." Not too helpful, but always good to establish a baseline.
[re: steps took]
Very screwy behavior indeed. It seems that you can't get anything to
behave well or at least bad in such a way to draw a viable conclusion. :(
> 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.)
Well, much newer? Probably not. Brand new? Actually, yes. Mine was
physically brand new in terms of packaging and use--yes, spacer and all.
But in terms of years, or age, the bottom of mine says "October 1995".
I got this from a surplus outfit, which, in case anyone else wants one,
and the list doesn't mind a minor plug, can be found at
http://www.compgeeks.com/cgi-bin/details.asp?cat=MultiMedia&sku=205-7405
(I actually, by no means, intend this as a plug. I am simply providing
the reference to where an exact device can be obtained. It's a cute
little unit, I am happy with it and the company, and it's a good price.
Beyond that, I'm just one hacker sharing with another for the purpose
of kernel development. :))
So anyway, yes mine is "brand new out of the box", but in terms
of technology, it's about as old.
On the subject of use and age, however, that's one thing that I thought
would be useful in knowing if you backtracked to a previous kernel under
which it worked. If you get it working correctly under one kernel, but
not another, then it's probably a scientific excursion to determine why.
But if it only "worked a while ago", there's nothing to say it isn't
use-induced failure. :(
> I know introducing another BLIST_LONGERSWITCHTIME or
> whatever is ugly, but ...
Hehe... When it doubt, add a hack-flag. :)
> 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..
Just guessing, but you may have to generate scads of output to deduce
where the problem is, especially if your delay theory is correct. That's
the only way I can think of proving/disproviing it.
Brendan
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
