Brendan Miller wrote:
> Can you say "remove shipping spacer before using"????
>
> ...
>
>
> Now to the fun stuff. It turned out that a shipping spacer had gotten
> wedged at the back of the magazine cavity, thus preventing it from
> accessing slots 4 and 5. All is well now.
>
Congratulations.
> >From /var/log/messages:
>
> kernel: sr0: scsi3-mmc drive: 0x/0x caddy
> kernel: sr1: scsi3-mmc drive: 0x/0x caddy
> kernel: sr2: scsi3-mmc drive: 0x/0x caddy
> kernel: sr3: scsi3-mmc drive: 0x/0x caddy
> kernel: sr4: scsi3-mmc drive: 0x/0x caddy
It may not be a big deal, but a CD drive (not the Nakamichi changer
) shows this on my PC.
kernel: sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda tray
Please note 24x/24x as opposed to 0x/0x.
The same drive was listed as 0x/0x with the older kernel. I think the
CD drive detection code or something need polishing.
(I was wondering what this 0x/0x was until the upgrade to a later
kernel suddenly produced 24x/24x and cd/rw xa/form2 cdda tray
followed this number. Maybe the information is passed in
vendor proprietary format?)
>
> And all is well. :)
>
> Now to reproduce Chiaki's double-dd activity...
Great!
>
>
> 1) I started by doing 'ls -lR' on each of /local/cdx01 .. /local/cdx05
> by themselves (one at a time). It's a little slow on disk 3, but
> that's okay.
>
> TEST PASSED.
>
Hmm...
>
> 2) Instead of dd straight from /dev/scd0, I am going to use
>
> # tar -cvf - /local/cdx01 | dd of=/dev/null
>
> I have had problems on many systems trying to dd straight from
> the CD device. This "tar | dd" command has the same desired
> effect of reading all the data off the disk--I just do it through
> the filesystem. If you "> /dev/null" from the output of tar,
> it somehow short-circuits and throws the data away without actually
> reading it. So I make sure I copy it using dd to /dev/null.
>
> TEST PASSED.
>
> (In the middle of this, some funky 'find | sort' cron job took off,
> so loads were 2.2... Kind of interesting to watch. Well, when the
> find | sort got to /local/..., you can guess what it did--put the
> tar | dd on hold, and scanned through all five disks to look for
> whatever it was looking for. Meanwhile the tar | dd is still
> running, so every five seconds, the changer swaps out the disk that
> find was workign on and swaps the first disk back in to give tar
> a few cycles. Back and forth... The tar output continued to
> proceed, albeit at a slow pace. I finally got tired of watching
> this pathetic action, so I killed the find. Then the first disk
> was restored, and the tar | dd continued to completion. Unexpected
> activity, but the scsi system stayed true through the whole thing.)
Good.
>
>
> 3) Okay, now two at once:
>
> # tar -cvf - /local/cdx02 | dd of=/dev/null (in one term)
> # tar -cvf - /local/cdx03 | dd of=/dev/null (in another term)
>
> TEST PASSED.
>
> (I actually aborted these tests with ctrl-c before they actually
> read the entire disc. This would have taken forever. Based on the
> several minutes of this test that it did run and the previous
> "accidental" find in the middle of my tar, I am confident that
> with this drive, with this host adapter, with this kernel, on this
> machine, I can simultaneous access two (or more) discs in the
> changer without "bogus" results (either from the scsi layer or
> flat-out kernel panics).)
Great. This was exactly how my setup worked with slightly earlier kernel 2.2.x.
>
>
> 4) Finally, Chiaki's more-exact scenario. To do this, I unmounted
> everything since I figured I was doing direct device reading...
>
> # dd if=/dev/scd0 of=/dev/null (in one term)
> # dd if=/dev/scd1 of=/dev/null (in another term)
>
> So far, so good--switchee, switchee... It's interesting that
> the drive is spending so much time switching the discs that dd
> never registers in 'top', but it all seems to work.
>
> Sending each one a ctrl-c shows:
>
> krypton:~ # dd if=/dev/scd0 of=/dev/null
> 708+0 records in
> 708+0 records out
>
> krypton:~ # dd if=/dev/scd1 of=/dev/null
> 772+0 records in
> 772+0 records out
>
> (Again, these were done in two different telnet sessions.)
>
> So now it looks like it's only my LUN-detection problem (with that
> absent LUN #5 (as it should be), and the null LUN #6). What's
> the recommendation here?
>
Now I have a big question now.
Did you test the drive WITHOUT blacklisting the
device or WITH blacklisting ?
If you did it WITHOUT blacklisting and succeed, I need
to dig into the scsi code and check if the meaning of the flag
is somehow treated in a reverse manner or whatever.
In any case, good to hear that a similar CD changer drive
works as expected.
>And Eric, I don't think I'll put that shipping spacer back in to
> test that kernel panic again. :)
Well :-)
Happy Hacking
Chiaki Ishikawa
>
> Brendan
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
