----- Original Message -----
From: "Brendan Miller" <[EMAIL PROTECTED]>
To: "ishikawa" <[EMAIL PROTECTED]>
Cc: "LINUX SCSI" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, January 18, 2000 11:52 PM
Subject: Another multi-lun CD changer (was: ... simultaneous access problem)
>
> 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!
Interesting. The bus scan is still taking place - it is probably poking
at unit 7 here. The fact that it has printed out the result for 6 is quite
odd - it indicates that the thing actually did return somewhat intelligent
data for LUN 6, but it did the right thing for lun 5. This thing probably
has some buggy firmware. Anyways, moving on....
> 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
The single lun thing won't help you at this level. It is serially
poking at the devices one at a time to learn more about them. Offhand I am
guessing that the firmware for the thing is slowing going insane. For
testing purposes, you might add the max_scsi_luns=5 boot parameter - this
will prevent it from probing logical units 5, 6 and 7.
> 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
Probably the error handling code going nuts. You need to take the
kernel addresses and work back to function names and offsets.
> 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
Yow. That should never happen. Does this happen right away? If this
comes up again (and repeatably) you could turn up logging to infinity and
you will get a lot more details about the last thing that happened with
success.
> 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?
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
