From owner-freebsd-hackers Wed Jan 18 13:47:14 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id NAA25422 for hackers-outgoing; Wed, 18 Jan 1995 13:47:14 -0800 Received: from snoopy.mv.com (snoopy.mv.com [199.125.64.182]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id NAA25393 for ; Wed, 18 Jan 1995 13:47:03 -0800 Received: (from pw@localhost) by snoopy.mv.com (8.6.9/8.6.6) id PAA01134; Wed, 18 Jan 1995 15:32:30 -0500 Date: Wed, 18 Jan 1995 15:32:30 -0500 From: "Paul F. Werkowski" Message-Id: <199501182032.PAA01134@snoopy.mv.com> To: hackers@FreeBSD.org In-reply-to: (julian@tfs.com) Subject: Re: NEC 4xi CDROM - what now? Sender: hackers-owner@FreeBSD.org Precedence: bulk >>>>> "Julian" == Julian Elischer 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: 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: 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: 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