I have read Chiaki and Eric's discussion of Chiaki's problem and Eric's
[possible] solution, and it is timely that I find myself in a related
boat (and I provide you an almost-as-long description).
My deal is that I recently acquired a SCSI 5-disc changer which is not
on the device_list (formerly known as the blacklist). I now wonder if
this is part of my problem, but let me describe it as it appears to me.
Configuration is a dual Pentium 133 on a Micronics M54Pe motherboard.
This is an old beast, but seems to serve me well so far as a server.
Currently running 2.2.14, but tried 2.2.13 as well. Haven't dived
into experimental, nor backtracked through 2.2.x.
The SCSI controller to which the CD changer is connected is, ironically,
a BusLogic BT-930. I have used the controller for other devices in
the past and even recently a hard disk at the same time as the CD
changer was connected.
The CD changer is a "LA Sound CDX-7405". It has a 5-disc magazine,
and reportedly is a 4x drive. Nifty keen. But no mention of it
in scsi.c as I mentioned.
Here's the problem I experience. Since I boot off of IDE, the SCSI
adapter is probed with a module. So far, I'm doing this manually
so as not to hang my boot-up. So, here goes--I'm doing this as I write
it:
# modprobe BusLogic
In another term, I have 'tail -f /var/log/messages' going:
scsi: ***** BusLogic SCSI Driver Version 2.1.15 of 17 August 1998 *****
scsi: Copyright 1995-1998 by Leonard N. Zubkoff <[EMAIL PROTECTED]>
scsi0: Configuring BusLogic Model BT-930 PCI Ultra SCSI Host Adapter
scsi0: Firmware Version: 5.02, I/O Address: 0xF800, IRQ Channel: 9/Level
scsi0: PCI Bus: 0, Device: 13, Address: 0xFDFFF000, Host Adapter SCSI ID: 7
scsi0: Parity Checking: Enabled, Extended Translation: Enabled
scsi0: Synchronous Negotiation: Ultra, Wide Negotiation: Disabled
scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled
scsi0: Driver Queue Depth: 255, Scatter/Gather Limit: 128 segments
scsi0: Tagged Queue Depth: Automatic, Untagged Queue Depth: 3
scsi0: Error Recovery Strategy: Default, SCSI Bus Reset: Enabled
scsi0: SCSI Bus Termination: Enabled, SCAM: Disabled
scsi0: *** BusLogic BT-930 Initialized Successfully ***
scsi0 : BusLogic BT-930
scsi : 1 host.
Vendor: LASOUND Model: CDX7405 Rev: 3.10
Type: CD-ROM ANSI SCSI revision: 02
Vendor: LASOUND Model: CDX7405 Rev: 3.10
Type: CD-ROM ANSI SCSI revision: 02
Vendor: LASOUND Model: CDX7405 Rev: 3.10
Type: CD-ROM ANSI SCSI revision: 02
Vendor: LASOUND Model: CDX7405 Rev: 3.10
Type: CD-ROM ANSI SCSI revision: 02
Vendor: LASOUND Model: CDX7405 Rev: 3.10
Type: CD-ROM ANSI SCSI revision: 02
>From the looks of things, you'd think everything was cool. But I
don't get the summary of the what type of devices it found. (Don't
you usually get a "Detected removable media at scsi0, channel 0,
id 3, lun 0" kind of message?)
But the problem is that modprobe is still running! Even right now,
and it's been 4 minutes since I executed it. The load is now 0.99
(I assume because one processor is spinning in the kernel trying
to complete the modprobe.) I don't see any more in /var/log/messages.
# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 03 Lun: 00
Vendor: LASOUND Model: CDX7405 Rev: 3.10
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 03 Lun: 01
Vendor: LASOUND Model: CDX7405 Rev: 3.10
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 03 Lun: 02
Vendor: LASOUND Model: CDX7405 Rev: 3.10
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 03 Lun: 03
Vendor: LASOUND Model: CDX7405 Rev: 3.10
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 03 Lun: 04
Vendor: LASOUND Model: CDX7405 Rev: 3.10
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 03 Lun: 06
Vendor: Model: Rev:
Type: <NULL> ANSI SCSI revision: ffffffff
This is very interesting indeed! A 5-slot changer should have 5 luns,
no? And they should be reasonable! That last lun is obviously
bogus, and I wonder if there is a hangup somewhere with it? The last
thing I can try (which will generate an oops), is to try to mount
/dev/scd0 anyway. I don't know if this is wise, but I thought I'd
try it anyway, 'cause the system's not dead yet!
Okay, when I do this, the
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 3, lun 0
Detected scsi CD-ROM sr1 at scsi0, channel 0, id 3, lun 1
Detected scsi CD-ROM sr2 at scsi0, channel 0, id 3, lun 2
Detected scsi CD-ROM sr3 at scsi0, channel 0, id 3, lun 3
Detected scsi CD-ROM sr4 at scsi0, channel 0, id 3, lun 4
shows up in the log like it should. But then I also get
scsi : aborting command due to timeout : pid 14, scsi0, channel 0, id 3, lun 6 Test
Unit Ready c0 00 00 00 00
scsi0: Aborting CCB #106841 to Target 3
scsi0: CCB #106841 to Target 3 Aborted
scsi : aborting command due to timeout : pid 14, scsi0, channel 0, id 3, lun 6 Test
Unit Ready c0 00 00 00 00
scsi0: Aborting CCB #106842 to Target 3
scsi0: CCB #106842 to Target 3 Aborted
scsi : aborting command due to timeout : pid 17, scsi0, channel 0, id 5, lun 0 Test
Unit Ready 00 00 00 00 00
scsi0: Aborting CCB #106846 to Target 5
scsi0: CCB #106846 to Target 5 Aborted
scsi : aborting command due to timeout : pid 18, scsi0, channel 0, id 6, lun 0 Test
Unit Ready 00 00 00 00 00
scsi0: Aborting CCB #106847 to Target 6
SCSI host 0 abort (pid 18) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
scsi0: Resetting BusLogic BT-930 due to Target 6
scsi0: *** BusLogic BT-930 Initialized Successfully ***
wait_on_bh, CPU 0:
irq: 0 [0 0]
bh: 1 [0 1]
<[c010b35d]> <[c01a0c4c]> <[c0140d93]> <[c01a17eb]> <[c01a6c10]> <[c0198c84]>
<5>scsi0: Target 3: Queue Depth 3, Asynchronous
Unable to handle kernel NULL pointer dereference at virtual address 00000003
current->tss.cr3 = 07142000, %cr3 = 07142000
*pde = 00000000
Oops: 0000
CPU: 1
Meanwhile, there is a lot of "ka-chunking" in my changer, and Look! The
modprobe finally finished! At least that's what the /var/log/messages
shows. There's a whole bunch of similar spewage on the console, but it
scrolls way too fast to catch any of it.
I actually, forgot to use '-t iso9660' in my mount command, so the mount
did fail. If I try it again, it says "mount: /dev/scd0 has wrong major
or minor number". So I though let's move to lun 1
# mount -t iso9660 /dev/scd1 /local/cdx01
And this works ! (It didn't last night... Hmmm...)
So I get bold...
# mount -t iso9660 /dev/scd2 /local/cdx02
No log output, here we have a crash: (copied from console)
Kernel panic: scsi_free: Trying to free unused memory
In swapperm task - not syncing
and everything's pretty much dead after that.
Like I said, I got many oops last night the first time I tried.
Incidentally, this kernel is compiled with "Probe all LUNs"
enabled. I tried a kernel with it not enabled, and I could only
mount the first slot--to be expected, since scsi.c doesn't know
this device, I guess.
If more information is needed, I'll do my best. What is the best
course of action to get my changer up and running?
Brendan Miller
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
