Can you say "remove shipping spacer before using"????
I feel so dumb. Well, I'm sure we all do stupid stuff. My kudos to
the linux-scsi list for not first asking me "Did you remove the
shipping spacer? Did you plug it in? Did you set the drive
termination right? Are you a total SCSI moron?" :) I have now
done all those things, and despite this blunder, I profess to be
somewhat knowledgeable about SCSI.
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.
Fromm my "command window":
krypton:~ # modprobe BusLogic
krypton:~ # mount /local/cdx05
krypton:~ # mount /local/cdx04
krypton:~ # mount /local/cdx03
krypton:~ # mount /local/cdx02
krypton:~ # mount /local/cdx01
krypton:~ # df -k
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/hda2 249855 40593 196360 17% /
/dev/hda1 60415 3186 54005 6% /boot
/dev/hda4 153480 21 145244 0% /tmp
/dev/hdb1 249823 25638 211285 11% /var
/dev/hdb2 1745533 832194 823123 50% /usr
/dev/scd4 666214 666214 0 100% /local/cdx05
/dev/scd3 659542 659542 0 100% /local/cdx04
/dev/scd2 511484 511484 0 100% /local/cdx03
/dev/scd1 644468 644468 0 100% /local/cdx02
/dev/scd0 593624 593624 0 100% /local/cdx01
>From /var/log/messages:
kernel: scsi: ***** BusLogic SCSI Driver Version 2.1.15 of 17 August 1998 *****
kernel: scsi: Copyright 1995-1998 by Leonard N. Zubkoff <[EMAIL PROTECTED]>
kernel: scsi0: Configuring BusLogic Model BT-930 PCI Ultra SCSI Host Adapter
kernel: scsi0: Firmware Version: 5.02, I/O Address: 0xF800, IRQ Channel: 9/Level
kernel: scsi0: PCI Bus: 0, Device: 13, Address: 0xFDFFF000, Host Adapter SCSI ID: 7
kernel: scsi0: Parity Checking: Enabled, Extended Translation: Enabled
kernel: scsi0: Synchronous Negotiation: Ultra, Wide Negotiation: Disabled
kernel: scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled
kernel: scsi0: Driver Queue Depth: 255, Scatter/Gather Limit: 128 segments
kernel: scsi0: Tagged Queue Depth: Automatic, Untagged Queue Depth: 3
kernel: scsi0: Error Recovery Strategy: Default, SCSI Bus Reset: Enabled
kernel: scsi0: SCSI Bus Termination: Enabled, SCAM: Disabled
kernel: scsi0: *** BusLogic BT-930 Initialized Successfully ***
kernel: scsi0 : BusLogic BT-930
kernel: scsi : 1 host.
kernel: Vendor: LASOUND Model: CDX7405 Rev: 3.10
kernel: Type: CD-ROM ANSI SCSI revision: 02
kernel: Vendor: LASOUND Model: CDX7405 Rev: 3.10
kernel: Type: CD-ROM ANSI SCSI revision: 02
kernel: Vendor: LASOUND Model: CDX7405 Rev: 3.10
kernel: Type: CD-ROM ANSI SCSI revision: 02
kernel: Vendor: LASOUND Model: CDX7405 Rev: 3.10
kernel: Type: CD-ROM ANSI SCSI revision: 02
kernel: Vendor: LASOUND Model: CDX7405 Rev: 3.10
kernel: Type: CD-ROM ANSI SCSI revision: 02
kernel: scsi0: Target 3: Queue Depth 3, Synchronous at 3.33 MB/sec, offset 8
kernel: Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
kernel: Detected scsi CD-ROM sr1 at scsi0, channel 0, id 3, lun 1
kernel: Detected scsi CD-ROM sr2 at scsi0, channel 0, id 3, lun 2
kernel: Detected scsi CD-ROM sr3 at scsi0, channel 0, id 3, lun 3
kernel: Detected scsi CD-ROM sr4 at scsi0, channel 0, id 3, lun 4
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
And all is well. :)
Now to reproduce Chiaki's double-dd activity...
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.
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.)
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).)
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?
And Eric, I don't think I'll put that shipping spacer back in to
test that kernel panic again. :)
Brendan
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
