Date: Wed, 18 Jan 1995 15:32:30 -0500 From: "Paul F. Werkowski" <pw@snoopy.MV.COM> To: hackers@FreeBSD.org Subject: Re: NEC 4xi CDROM - what now? Message-ID: <199501182032.PAA01134@snoopy.mv.com> In-Reply-To: <m0rUPFG-0003w7C@TFS.COM> (julian@tfs.com)
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Julian" == Julian Elischer <julian@tfs.com> writes:
>>
>>
>> Greetings, I have now a NEC 4Xi CDROM drive plugged into my
>> FreeBSD 2.0 / Adapetec 1740A system. The problem is that the
>> drive does not show up in the boot probe although everything
>> else on the bus does as usual. I now have SCSI_DELAY=30 in
>> config with no good results. Funny thing is that even the DOS
>> SCSI driver doesn't report this thing - even though it also
>> sees the other SCSI things. Even funnier is that a Corel
>> package scanscsi.exe DOES see the stupid thing at the correct
>> SCSI ID. The cute little diagnostic screen built into the drive
>> things everything is in order.
Julian> possibly it's not at LUN 0? maybe you need to probe some
Julian> other LUN.. WHERE does the corel stuff find it?
Corel finds it at targ 2 - all luns - that is when it finds it
at all. The thing is seen only sometimes under conditions yet to
be discovered. Also, the drive wants to swallow/eject a disk only
sometimes. Thinking the drive was broken, I have returned same
only to find that a new one has the same symptoms.
Tying to get somewhere, I enabled SCSIDEBUG on targ 2 and got
this result at probe.
...
ahb0: reading board settings, int=11
ahb0 at 0x4000-0x4fff irq 11 on eisa
ahb0 targ 0 lun 0: type 0(direct) fixed SCSI2
ahb0 targ 0 lun 0: <MICROP 2210-09MQ1001901HQ30>
sd0: 1008MB (2065250 total sec), 2372 cyl, 9 head, 96 sec, bytes/sec 512
probe0(ahb0:2:0): scsi_cmd
probe0(ahb0:2:0): ahb_scsi_cmd
probe0(ahb0:2:0): ahb_done
probe0(ahb0:2:0): scsi_done
probe0(ahb0:2:0): command: 0,0,0,0,0,0-[0 bytes]
probe0(ahb0:2:0): scsi_cmd
probe0(ahb0:2:0): ahb_scsi_cmd
probe0(ahb0:2:0): ahb_done
probe0(ahb0:2:0): scsi_done
probe0(ahb0:2:0): command: 12,0,0,0,2c,0-[44 bytes]
------------------------------
000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
032: 00 00 00 00 00 00 00 00 00 00 00 00
------------------------------
probe0(ahb0:2:0): ahb_scsi_cmd
probe0(ahb0:2:0): ahb_done
probe0(ahb0:2:0): scsi_done
probe0(ahb0:2:0): command: 12,0,0,0,2c,0-[44 bytes]
------------------------------
000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
032: 00 00 00 00 00 00 00 00 00 00 00 00
------------------------------
probe0(ahb0:2:0): ahb_scsi_cmd
probe0(ahb0:2:0): ahb_done
probe0(ahb0:2:0): scsi_done
probe0(ahb0:2:0): command: 12,0,0,0,2c,0-[44 bytes]
------------------------------
000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
032: 00 00 00 00 00 00 00 00 00 00 00 00
------------------------------
ahb0 targ 4 lun 0: type 1(sequential) removable SCSI1
ahb0 targ 4 lun 0: <WangDAT Model 1300 02.4>
st0: WangDAT model 1300 is a known rogue
st0: density code 0x13, drive empty
ahb0 targ 5 lun 0: type 5(readonly) removable SCSI1
ahb0 targ 5 lun 0: <DEC RRD40 TM DEC280E>
cd0(ahb0:5:0): not ready
cd0: could not get size
cd0: drive empty
aha0 not found at 0x330
...
Doing same with targ 5 shows a similar display except the 44 byte
message has non-zero data in it. Does this mean the NEC is
sending back a zero-filled message? Curiously, the Corel scanscsi
program waits a lot longer on the NEC target before giving up
than on truly empty slots. It is like there is something there
but just not enough.
>> What happened to the 'scsi' program on 1.1.5.1 that at least
>> attempted to dicker with the devices a bit?
Julian> It got left out by mistake.. (as did st(1)) it still
Julian> compiles if you can get the sources.. I just added it to
Julian> my source tree (makefile and all) and it works fine. if
Julian> you can find the ID and LUN of the device, you may be able
Julian> to use the scsi(1) program to specifically probe it into
Julian> existence.. The code in the kernel will only probe LUN 0
Julian> unless something exists on 0 and indicates there may be
Julian> other LUNs as well.
I will attempt to revive that code and see what I can find.
Thanks for the tip.
Paul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501182032.PAA01134>