From owner-freebsd-hackers  Tue Jan 17 17:32:17 1995
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA02559 for hackers-outgoing; Tue, 17 Jan 1995 17:32:17 -0800
Received: from tfs.com (mailhub.tfs.com [140.145.250.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id RAA02553 for <hackers@FreeBSD.org>; Tue, 17 Jan 1995 17:32:15 -0800
Received: by tfs.com (smail3.1.28.1) 
Message-Id: <m0rUPFG-0003w7C@TFS.COM>
From: julian@tfs.com (Julian Elischer)
Subject: Re: NEC 4xi CDROM - what now?
To: pw@snoopy.MV.COM (Paul F. Werkowski)
Date: Tue, 17 Jan 1995 17:31:33 -0800 (PST)
Cc: hackers@FreeBSD.org
In-Reply-To: <199501172356.SAA00485@snoopy.mv.com> from "Paul F. Werkowski" at Jan 17, 95 06:56:45 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1500      
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> 
> 
> 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.
possibly it's not at LUN 0?
maybe you need to probe some other LUN..
WHERE does the corel stuff find it?


> 
> I am certain as can be that termination is correct etc. Does anyone
> out there have any experience with this NEC drive? Are they inventing
> yet a new sub/super-set of "standard" SCSI?

they did for their other drives.. why stop now? :)

> What happened to the 'scsi' program on 1.1.5.1 that at least attempted
> to dicker with the devices a  bit?

It got left out by mistake.. (as did st(1))
it still compiles if you can get the sources..
I just added it to my source tree (makefile and all) and it works fine.
if you can find the ID and LUN of the device, you may be able to use the
scsi(1) program to specifically probe it into existence.. The code in the
kernel will only probe LUN 0 unless something exists on 0 and indicates there
may be other LUNs as well.

> 
> Paul
> 
> 
>