From owner-freebsd-scsi Sun Jul 13 00:52:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA10159 for freebsd-scsi-outgoing; Sun, 13 Jul 1997 00:52:04 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA10148 for ; Sun, 13 Jul 1997 00:52:00 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0wnJMx-0002CJ-00; Sun, 13 Jul 1997 00:46:59 -0700 Date: Sun, 13 Jul 1997 00:46:58 -0700 (PDT) From: Tom Samplonius To: "Jin Guojun[ITG]" cc: asami@cs.berkeley.edu, crb@Glue.umd.edu, freebsd-scsi@freebsd.org Subject: Re: NCR SCSI controllers In-Reply-To: <199707130403.VAA24519@george.lbl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 12 Jul 1997, Jin Guojun[ITG] wrote: > } Not a problem. I used 11 disks on a 3940UW, and was able to max out > }both channels. With drives being able to sustain 7MB writing, this is > }getting easier to do. > > When you say to sustain 7MB writing, do you mean using a single disk? I guess. Of course. > Because I can get 15MB writing over three disks via single NCR SCSI channel That isn't very fast. > (just wide, not ultra-wide). So, 3940UW supposes to have 30MB in writing and > 35MB in reading. This will be seen in NCR-875 when the driver is ready (S.E). Huh? 3940UW performance is related to the drive performance. If the drives are willing, you will be able max the channels. In fact, I was able to do this on a 3940UW (actually worked out 39MB/s). I have no idea where this 30MB writing, and 35MB reading stuff is coming from. It is misinformation. I believe it was just one person's results on one array. Given the right disk array, you will easily max the both channels of a 3940UW. > Otherwise, the 7MB writing rate sounds not right. > > -Jin > > > Tom From owner-freebsd-scsi Sun Jul 13 09:03:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA25022 for freebsd-scsi-outgoing; Sun, 13 Jul 1997 09:03:37 -0700 (PDT) Received: from pluto.plutotech.com (root@[206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA25014 for ; Sun, 13 Jul 1997 09:03:33 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id JAA25833; Sun, 13 Jul 1997 09:55:38 -0600 (MDT) Message-Id: <199707131555.JAA25833@pluto.plutotech.com> To: dg@root.com cc: Simon Shapiro , filo@yahoo.com, freebsd-SCSI@FreeBSD.ORG Subject: Re: problems with reboot In-reply-to: Your message of "Sat, 12 Jul 1997 04:13:14 PDT." <199707121113.EAA15976@implode.root.com> Date: Sun, 13 Jul 1997 09:55:37 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>There is an issue with FreeBSD shutdown not waiting for the DPt to flush >>caches as it should. > > Should be easy to fix by adding a shutdown routine to the driver that waits >for the flushes to complete. > >-DG > >David Greenman >Core-team/Principal Architect, The FreeBSD Project If we're not waiting for the last close to complete, that is a bug that should be fixed. I believe that Simon added a syncronize cache command into sdclose which should address the DPT issue so long as it actually gets performed and we wait for it to complete. The syncronize cache command may be required for other disk devices as well, and a generic solution is always better than a controller specific one. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sun Jul 13 09:29:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA26401 for freebsd-scsi-outgoing; Sun, 13 Jul 1997 09:29:52 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA26394 for ; Sun, 13 Jul 1997 09:29:49 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0wnRS4-0002Ny-00; Sun, 13 Jul 1997 09:24:48 -0700 Date: Sun, 13 Jul 1997 09:24:47 -0700 (PDT) From: Tom Samplonius To: freebsd-scsi@freebsd.org Subject: DPT storage manager? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk How and what are people using to configure a DPT controller in regards to configure the array, RAID level, hot spare, etc? Is there a storage manager that runs in FreeBSD, from a floppy? Or, are people just booting DOS from a temporary partition configure the array, and install FreeBSD over top of it? Tom From owner-freebsd-scsi Sun Jul 13 10:03:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA28424 for freebsd-scsi-outgoing; Sun, 13 Jul 1997 10:03:08 -0700 (PDT) Received: from cais.cais.com (root@cais.com [199.0.216.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA28418 for ; Sun, 13 Jul 1997 10:03:02 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [205.252.122.1]) by cais.cais.com (8.8.5/CJKv1.99-CAIS) with SMTP id MAA25612; Sun, 13 Jul 1997 12:49:02 -0400 (EDT) Received: from Journey2.mat.net (journey2.mat.net [205.252.122.116]) by earth.mat.net (8.6.12/8.6.12) with SMTP id MAA14637; Sun, 13 Jul 1997 12:49:00 -0400 Date: Sun, 13 Jul 1997 12:49:09 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: Simon Shapiro cc: freebsd-SCSI@FreeBSD.ORG, filo@yahoo.com, dg@root.com Subject: Re: problems with reboot In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 12 Jul 1997, Simon Shapiro wrote: > > Hi Chuck Robey; On 12-Jul-97 you wrote: > > ... > > > Is this always safe? I've had some instances where a umount call simply > > hung, and never returned. I think they were either nfs or msdos mounts > > that gave this trouble, but the umount call could not be kill'ed, and > > making shutdown wait? Would halt still work, as an emergency measure? > > I know the FSs that were hung wouldn't be closed, but at least my ufs FSs > > would be clean. > > Network Failure system is a special case (i AM being nice :-); > It is supposedly stateless and the mount is a client and thus not governing > physical I/O. a shutdown can (should) probably force a umount. Even on a > local system, a forced umount is OK. It is a FS issue. But if the fs > layer calls a function that by definition blocks, it is ``none of the > caller's business'' how/what the callee does and how long it takes. > To assume anything on the nature if a callee's internals is not a good > idea. Here we have a live exapmple (why it is a bad idea). I *think* the nfs failure was when I was learning how to correctly set up a 3C503 for NFS. Before I got that right, while experimenting, the second action on an mount going thru the 3C503 would hang, and a forcible umount would hang too. That was OK, I could just shut down the machine. I'm not sure here ... if your proposed fix would work on shutdown only, but allow a halt or reboot under emergency conditions, then I'm in agreement, and adding hooks to shutdown is a great path to take; if not, then you can see my objection here, right? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-scsi Sun Jul 13 13:56:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA07133 for freebsd-scsi-outgoing; Sun, 13 Jul 1997 13:56:06 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA07128 for ; Sun, 13 Jul 1997 13:56:04 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA08394; Sun, 13 Jul 1997 13:27:05 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd008374; Sun Jul 13 20:26:58 1997 Date: Sun, 13 Jul 1997 13:24:44 -0700 (PDT) From: Julian Elischer To: "Justin T. Gibbs" cc: dg@root.com, Simon Shapiro , filo@yahoo.com, freebsd-SCSI@FreeBSD.ORG Subject: Re: problems with reboot In-Reply-To: <199707131555.JAA25833@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 13 Jul 1997, Justin T. Gibbs wrote: > >>There is an issue with FreeBSD shutdown not waiting for the DPt to flush > >>caches as it should. > > > > Should be easy to fix by adding a shutdown routine to the driver that waits > >for the flushes to complete. > > > >-DG > > Simon, do man 9 at_shutdown Add a call to this and on reboot your driver can be called to do some cleaning up.. From owner-freebsd-scsi Sun Jul 13 16:47:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA13525 for freebsd-scsi-outgoing; Sun, 13 Jul 1997 16:47:31 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA13518 for ; Sun, 13 Jul 1997 16:47:26 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id QAA00548; Sun, 13 Jul 1997 16:47:49 -0700 (PDT) Message-Id: <199707132347.QAA00548@implode.root.com> To: "Justin T. Gibbs" cc: Simon Shapiro , filo@yahoo.com, freebsd-SCSI@FreeBSD.ORG Subject: Re: problems with reboot In-reply-to: Your message of "Sun, 13 Jul 1997 09:55:37 MDT." <199707131555.JAA25833@pluto.plutotech.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 13 Jul 1997 16:47:48 -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>>There is an issue with FreeBSD shutdown not waiting for the DPt to flush >>>caches as it should. >> >> Should be easy to fix by adding a shutdown routine to the driver that waits >>for the flushes to complete. >> >>-DG >> >>David Greenman >>Core-team/Principal Architect, The FreeBSD Project > >If we're not waiting for the last close to complete, that is a bug >that should be fixed. I believe that Simon added a syncronize >cache command into sdclose which should address the DPT issue so >long as it actually gets performed and we wait for it to complete. >The syncronize cache command may be required for other disk devices >as well, and a generic solution is always better than a controller >specific one. The shutdown code waits for all buffers to be flushed, but the code has no way of knowing if the controller actually committed the data to disk. If a disk controller indicates I/O completion/success before the data is actually written to disk, then it seems to me that forcing the cache flush would be a controller specific operation. Yes? -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-scsi Sun Jul 13 17:39:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA16520 for freebsd-scsi-outgoing; Sun, 13 Jul 1997 17:39:59 -0700 (PDT) Received: from pluto.plutotech.com (root@[206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA16515 for ; Sun, 13 Jul 1997 17:39:57 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id SAA02750; Sun, 13 Jul 1997 18:37:52 -0600 (MDT) Message-Id: <199707140037.SAA02750@pluto.plutotech.com> To: dg@root.com cc: Simon Shapiro , filo@yahoo.com, freebsd-SCSI@FreeBSD.ORG Subject: Re: problems with reboot In-reply-to: Your message of "Sun, 13 Jul 1997 16:47:48 PDT." <199707132347.QAA00548@implode.root.com> Date: Sun, 13 Jul 1997 18:37:52 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The shutdown code waits for all buffers to be flushed, but the code has no >way of knowing if the controller actually committed the data to disk. If a >disk controller indicates I/O completion/success before the data is actually >written to disk, then it seems to me that forcing the cache flush would be a controller specific operation. Yes? In this case, the DPT emulates "a giant disk" and responds to the same commands that disks do. Lots of disks return successful completion status on I/O that is still in there cache. So, even if there wasn't a controller cache to worry about, you'd still want to ensure that the cache on the disks is flushed before turning off the system. That's why the SCSI spec gives you the synchronize cache command. We should be issueing this on final close to all disks (the new CAM code does) which will handle normal disks as well as RAID controllers like the DPT that emulate disks. So, no controller specific operation is needed. It turns out that the DPT also flushes it's cache on the "allow media removal command" which the current code does on final close, but I don't think that we should assume that this works in all cases. Using that command on a device that doesn't report itself as removable is also a little bogus. As David F. has pointed out, the last close is happening and we are waiting for it to complete, the only problem is that the timeout is much too short for the "prevent/allow media removal" command. The CAM code does some handwavy calculation based on the size of the target disk so that if you have a multi-gigabyte "emulated disk", the timeout will be larger than for a 4gig "normal disk". It uses an explicit sync cache command though while keeping the media locking command timeouts short (the unlock happens after the sync cache). >-DG > >David Greenman >Core-team/Principal Architect, The FreeBSD Project -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Mon Jul 14 08:24:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA26654 for freebsd-scsi-outgoing; Mon, 14 Jul 1997 08:24:15 -0700 (PDT) Received: from mail.nacamar.de (mail.nacamar.de [194.162.162.200]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA26642 for ; Mon, 14 Jul 1997 08:24:09 -0700 (PDT) Received: from newsfeed (newsfeed.nacamar.de [194.162.162.196]) by mail.nacamar.de (8.8.6/8.8.5) with SMTP id RAA14436 for ; Mon, 14 Jul 1997 17:24:08 +0200 (CEST) Message-Id: <3.0.1.32.19970714172339.00907db0@mail.nacamar.de> X-Sender: freebsd@mail.nacamar.de X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 14 Jul 1997 17:23:39 +0200 To: scsi@freebsd.org From: Michael Beckmann Subject: MO drive and media with 1024 byte/sector Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi folks, I had posted this to hardware@freebsd.org the other day. Has anyone gotten a Sony SMO 544 drive to work properly under FreeBSD ? I have not yet succeeded in making a filesystem on it. For example: test: {46} disklabel -rwB od0 auto test: {47} newfs /dev/rod0c newfs: ioctl (GDINFO): Invalid argument newfs: /dev/rod0c: can't read disk label; disk type must be specified This is a 2.2-970703-RELENG system. dmesg says: (ahc0:6:0): "SONY SMO-F541+3 1.13" type 7 removable SCSI 2 od0(ahc0:6:0): Optical 1243MB (1273011 1024 byte sectors) I wonder if it would be possible to low-level format the media to 512 bytes/sector. Or can I get FreeBSD to use 1024 bytes/sector formatted media ? It looks as if the format were the problem. I am using 2.6 GB media from Maxell (1.3 GB per side). Thanks, Michael From owner-freebsd-scsi Mon Jul 14 12:23:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA09137 for freebsd-scsi-outgoing; Mon, 14 Jul 1997 12:23:24 -0700 (PDT) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA09132 for ; Mon, 14 Jul 1997 12:23:19 -0700 (PDT) Received: by iafnl.es.iaf.nl with UUCP id AA21997 (5.67b/IDA-1.5 for scsi@FreeBSD.ORG); Mon, 14 Jul 1997 21:23:25 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id UAA01104; Mon, 14 Jul 1997 20:25:19 +0200 (MET DST) From: Wilko Bulte Message-Id: <199707141825.UAA01104@yedi.iaf.nl> Subject: Re: MO drive and media with 1024 byte/sector To: beckmann@nacamar.net (Michael Beckmann) Date: Mon, 14 Jul 1997 20:25:18 +0200 (MET DST) Cc: scsi@FreeBSD.ORG In-Reply-To: <3.0.1.32.19970714172339.00907db0@mail.nacamar.de> from "Michael Beckmann" at Jul 14, 97 05:23:39 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Michael Beckmann wrote... > I had posted this to hardware@freebsd.org the other day. Has anyone gotten > a Sony SMO 544 drive to work properly under FreeBSD ? I have not yet > succeeded in making a filesystem on it. For example: > > test: {46} disklabel -rwB od0 auto > test: {47} newfs /dev/rod0c > newfs: ioctl (GDINFO): Invalid argument > newfs: /dev/rod0c: can't read disk label; disk type must be specified > > This is a 2.2-970703-RELENG system. > > dmesg says: > > (ahc0:6:0): "SONY SMO-F541+3 1.13" type 7 removable SCSI 2 > od0(ahc0:6:0): Optical 1243MB (1273011 1024 byte sectors) > > I wonder if it would be possible to low-level format the media to 512 > bytes/sector. Or can I get FreeBSD to use 1024 bytes/sector formatted media > ? It looks as if the format were the problem. I am using 2.6 GB media from > Maxell (1.3 GB per side). To the best of my knowledge the disks are hard sectored. I've seen media with 512 and 1024 bytes/sector. Maybe you can borrow a 512 byte/sec disk? My DEC RWZ01 (600~ Mb) works just fine with FreeBSD. It is set to emulate a type 0 (? ; at least direct access device) so that I can handle it with the sd driver just like a normal magnetic disk. The RWZ01 is a Sony-something MO with different firmware. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-scsi Mon Jul 14 19:54:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA00755 for freebsd-scsi-outgoing; Mon, 14 Jul 1997 19:54:31 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA00747 for ; Mon, 14 Jul 1997 19:54:27 -0700 (PDT) Received: (qmail 5662 invoked by uid 1000); 15 Jul 1997 02:54:38 -0000 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199707131555.JAA25833@pluto.plutotech.com> Date: Sun, 13 Jul 1997 14:01:42 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: "Justin T. Gibbs" Subject: Re: problems with reboot Cc: freebsd-SCSI@FreeBSD.ORG, filo@yahoo.com, dg@root.com Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Justin T. Gibbs; On 13-Jul-97 you wrote: > >>There is an issue with FreeBSD shutdown not waiting for the DPt to > flush > >>caches as it should. > > > > Should be easy to fix by adding a shutdown routine to the driver that > waits > >for the flushes to complete. > > > >-DG > > > >David Greenman > >Core-team/Principal Architect, The FreeBSD Project > > If we're not waiting for the last close to complete, that is a bug > that should be fixed. I believe that Simon added a syncronize > cache command into sdclose which should address the DPT issue so > long as it actually gets performed and we wait for it to complete. > The syncronize cache command may be required for other disk devices > as well, and a generic solution is always better than a controller > specific one. I belive this discussion is a bit out of sync; * The curent SCSI layer (sd.c in particular) is doing the right thing: It issues a ``PREVENT MEDIA REMOVAL'' SCSI command on open, and ``ALLOW MEDIA REMOVAL'' on close. It waits for these tom complete before returning. * The DPT firmware does the right thing by enabling caches (within the constraints put by its configuration) on the indicated device(s) on ``PREVENT...'' and disabling and flushing on ``ALLOW...''. It also blocks until such activities are done. * It appears that the shutdown procedure does a umount -a and that umount issues a close to sd.c... * I confused the issue (while trying to help some early DPt adopters), by introducing a timeout mechanism of my own in the DPT driver. This OPTIONAL and DANGEROUS option can timeout the ``ALLOW...'' command. If you have this option enabled, and shutd down immediately after (or during) very heavy disk write activity, the caches may not have a chance to flush. * Use these DPT options only if I ask you to. Under normal operation there is absolutely NO NEED to timeout the DPT. Ever. The reason we use this option is that, under certain hardware configurations, the DPT will send a completion to the driver and the driver will not see it. In this case, and in this case only, do we timeout the command, so that we can have the system not hang, waiting for an event that will never happen. * I further confused the issue by ASKING ``Does the /sbin/reboot command umount or not?'' I then added that, if memory does not fail me, UnixWare equivalent of /sbin/reboot does not and indeed can cause this sort of failure. BTW, most other O/S do NOT issue the ``PREVENT/ALLOW...'' pairs on open/close and then have to do all manners of ugly thins to get out of the mess. FreeBSD is the first I know which solved this problem so elegantly (at a perormance cost to open-sort-I/O-close sequences). Hope this helps. Simon From owner-freebsd-scsi Mon Jul 14 19:54:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA00778 for freebsd-scsi-outgoing; Mon, 14 Jul 1997 19:54:35 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA00748 for ; Mon, 14 Jul 1997 19:54:28 -0700 (PDT) Received: (qmail 5668 invoked by uid 1000); 15 Jul 1997 02:54:38 -0000 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 13 Jul 1997 14:18:53 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Chuck Robey Subject: Re: problems with reboot Cc: dg@root.com, filo@yahoo.com, freebsd-SCSI@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Chuck Robey; On 13-Jul-97 you wrote: > I'm not sure here ... if your proposed fix would work on shutdown only, > but allow a halt or reboot under emergency conditions, then I'm in > agreement, and adding hooks to shutdown is a great path to take; if not, > then you can see my objection here, right? I don't think i am proposing any fix. Just soliciting clarification; If FreeBSD shutdown umounts and umount blocks until the close to sd.c returns (which appears to be a true statement), then there is nothing t change. If /sbin/reboot does not issue umount, but shutdown does (elsewhere, BEFORE executing /sbin/reboot :-), then all we need is to remind ourselves that it is bad manners to /sbin/reboot a system. Especially if there is a DPT and there is heavy I/O going on. DPT Cache Flushing Policy: * Every n milliseconds (default = 125) of idleness, caches start flushing. They are not invalidated though. * Caches can be turned into either write-back (default), write-through or OFF. * The amount of cache devoted to read-ahead, and the largest single I/O block cachable are also tunable. * The amount, block size and type of cache on the DISKS is also tunable. These parametes are tunable from dptmgr (DOS). Future releases (soon) of our FreeBSD driver will support IOCTL and /dev/dpt ASCII interfaces to these functions, as well as array builds, repairs, monitoring, and other such things. The SCO version of dptmgr will be ported to FreeBSD. Probably NOT in source. Simon From owner-freebsd-scsi Mon Jul 14 19:54:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA00785 for freebsd-scsi-outgoing; Mon, 14 Jul 1997 19:54:35 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA00749 for ; Mon, 14 Jul 1997 19:54:28 -0700 (PDT) Received: (qmail 5674 invoked by uid 1000); 15 Jul 1997 02:54:38 -0000 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 13 Jul 1997 15:18:27 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Julian Elischer Subject: Re: problems with reboot Cc: freebsd-SCSI@FreeBSD.ORG, filo@yahoo.com, dg@root.com, "Justin T.Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Julian Elischer; On 13-Jul-97 you wrote: > > > On Sun, 13 Jul 1997, Justin T. Gibbs wrote: > > > >>There is an issue with FreeBSD shutdown not waiting for the DPt to > flush > > >>caches as it should. > > > > > > Should be easy to fix by adding a shutdown routine to the driver > that waits > > >for the flushes to complete. > > > > > >-DG > > > > Simon, > do > man 9 at_shutdown > Add a call to this and on reboot your driver can be called to do some > cleaning up.. Excellent! Watch out for these in version 1.1.9 of the DPT driver. Should i just add them or #ifdef on a config option? The driver is already: text data bss dec hex 3040 80 592 3712 e80 dpt_control.o 1728 32 64 1824 720 dpt_pci.o 15408 160 48 15616 3d00 dpt_scsi.o Boot Floppy concerns... Simon From owner-freebsd-scsi Mon Jul 14 19:54:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA00801 for freebsd-scsi-outgoing; Mon, 14 Jul 1997 19:54:47 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA00796 for ; Mon, 14 Jul 1997 19:54:37 -0700 (PDT) Received: (qmail 5687 invoked by uid 1000); 15 Jul 1997 02:54:39 -0000 Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199707140037.SAA02750@pluto.plutotech.com> Date: Sun, 13 Jul 1997 20:34:18 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: "Justin T. Gibbs" Subject: Re: problems with reboot Cc: freebsd-SCSI@FreeBSD.ORG, filo@yahoo.com, dg@root.com Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Justin T. Gibbs; On 14-Jul-97 you wrote: > > The shutdown code waits for all buffers to be flushed, but the code > has no > >way of knowing if the controller actually committed the data to disk. If > a > >disk controller indicates I/O completion/success before the data is > actually > >written to disk, then it seems to me that forcing the cache flush would > be > a controller specific operation. Yes? > > In this case, the DPT emulates "a giant disk" and responds to the same > commands that disks do. Lots of disks return successful completion > status on I/O that is still in there cache. So, even if there wasn't > a controller cache to worry about, you'd still want to ensure that the > cache on the disks is flushed before turning off the system. That's > why the SCSI spec gives you the synchronize cache command. We should > be issueing this on final close to all disks (the new CAM code does) > which will handle normal disks as well as RAID controllers like the DPT > that emulate disks. So, no controller specific operation is needed. Most disks we are dealing with have one megabyte of memory on the drive. I would classify DPT's response to (and the existance of) ``...MEDIA REMOVAL..' to luck more than anything else. To comply with MEDIA REMOVAL command, a device must flush his caches. But justin's choice is the correct one. > It turns out that the DPT also flushes it's cache on the "allow > media removal command" which the current code does on final close, > but I don't think that we should assume that this works in all > cases. Using that command on a device that doesn't report itself > as removable is also a little bogus. It is a questionable practie to use MEDIA REMOVAL and correct to use FLUSH CACHE. My first reaction to FreeBSD use of MEDIA REMOVAL was: ``Huh?''. turns out to be a good thing :-) BTW, FreeBSD today, issues TEST DEVICE READY before an INQUIRY in conjunction with the PREVENT MEDIA REMOVAL upon open. This is fine except it is backwards to the standard. Especially where SCSI I devices are concerned. For example, it will promptly hang most CD-R devices when you ask them to do TEST READY on LUN other than zero. Disabling LUN handling works but akin to remove an infected organ. It sure cures the infection but can leave you physically chalenged. > As David F. has pointed out, the last close is happening and we are > waiting for it to complete, the only problem is that the timeout is > much too short for the "prevent/allow media removal" command. The > CAM code does some handwavy calculation based on the size of the > target disk so that if you have a multi-gigabyte "emulated disk", > the timeout will be larger than for a 4gig "normal disk". It uses > an explicit sync cache command though while keeping the media locking > command timeouts short (the unlock happens after the sync cache). The DPT driver logic for timeout is based on the caseload in the controller. It is just as hand waving and just as prone to failure. My opinion on timeouts is that they should do what we do today; Provide the HBA with a value and let it decide what to do with it. Simon From owner-freebsd-scsi Mon Jul 14 20:55:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA02573 for freebsd-scsi-outgoing; Mon, 14 Jul 1997 20:55:18 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA02567 for ; Mon, 14 Jul 1997 20:55:15 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0wnyco-0005ti-00; Mon, 14 Jul 1997 20:50:06 -0700 Date: Mon, 14 Jul 1997 20:50:05 -0700 (PDT) From: Tom Samplonius To: Simon Shapiro cc: freebsd-SCSI@freebsd.org Subject: Re: problems with reboot In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 13 Jul 1997, Simon Shapiro wrote: > These parametes are tunable from dptmgr (DOS). Future releases (soon) of > our FreeBSD driver will support IOCTL and /dev/dpt ASCII interfaces to > these functions, as well as array builds, repairs, monitoring, and other > such things. The SCO version of dptmgr will be ported to FreeBSD. > Probably NOT in source. I have a DPT PM334UW. I having trouble getting the Win95 storage manager to work properly. After building the RAID-5 array from 5 x 4GB drives, and restarting the storage manager doesn't see the previous built array! I received the bare board version of this product (not by choice!), so I don't have docs or any software, except for what I can get off of www.dpt.com. What is the recommended way of building an array so it reconizable by FreeBSD? Right now when I boot, FreeBSD just sees 5 x 4GB disks, and allows me to partition them, rather (as I'm presuming anyhow), a 16GB virtual disk. Is the Win95 or DOS storage manager preferred? Is sendero-ppp.i-connect.net/crash/dptmgr-floppy1.raw supposed to be some kind of single disk boot manager? How is it supposed to be used? > Simon > > Tom From owner-freebsd-scsi Tue Jul 15 01:02:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA13593 for freebsd-scsi-outgoing; Tue, 15 Jul 1997 01:02:38 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA13551 for ; Tue, 15 Jul 1997 01:02:18 -0700 (PDT) Received: (qmail 9379 invoked by uid 1000); 15 Jul 1997 08:02:11 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 15 Jul 1997 01:02:11 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Tom Samplonius Subject: Re: problems with reboot Cc: freebsd-SCSI@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Tom Samplonius; On 15-Jul-97 you wrote: > > On Sun, 13 Jul 1997, Simon Shapiro wrote: > > > These parametes are tunable from dptmgr (DOS). Future releases (soon) > of > > our FreeBSD driver will support IOCTL and /dev/dpt ASCII interfaces to > > these functions, as well as array builds, repairs, monitoring, and > other > > such things. The SCO version of dptmgr will be ported to FreeBSD. > > Probably NOT in source. > > I have a DPT PM334UW. I having trouble getting the Win95 storage > manager to work properly. After building the RAID-5 array from 5 x 4GB > drives, and restarting the storage manager doesn't see the previous built > array! I received the bare board version of this product (not by > choice!), so I don't have docs or any software, except for what I can get > off of www.dpt.com. First get the latest firmware and dptmgr (DOS) floppy from either DPT or (slow) from sendero-ppp.i-connect.net, or from (faster) ftp.i-connect.net. The patches on ftp.i.... are old. Get them form sendero. > What is the recommended way of building an array so it reconizable by > FreeBSD? Right now when I boot, FreeBSD just sees 5 x 4GB disks, and > allows me to partition them, rather (as I'm presuming anyhow), a 16GB > virtual disk. Is the Win95 or DOS storage manager preferred? I think I posted this one way or another, but here is a summary, again: * If you have multiple channels, spread drives, of SAME attributes, across ALL busses. * Boot Doze * dptmgr/fw0 (will tell dptmgr you do not want to rely on O/S RAID) * Choose BSDi as na OS, or Linux. in the Initial Install... * Format ALL the drives (MTBF of an array is Disk-MTBS/No-of-disks!!) * Alt-V (switch to RAID view) * Alt-C (create new RAID array) * Fill form with RAID type, stripe size (think small :-), etc. * Tab to lowest drive on lowest bus * Space-Bar (to select drive) * Alt-I (to include in new array) * Tab to lowest drive on next bus * Space-Bar, Alt-I * Repeat in this manner until you run out of drives. * If possible, leave an unused drive. * Alt-D (Done) * Alt (to activate menu bar) * Tab to File pull down * Set System Parameters (it warns and warns) * Black flag on array icon will turn blue and drives get a white flag. * Wait for flags to be GONE (a good time to take a lunch break or go to bed. You can select the array icon, give it a name, look at the bits go by... * If you left a spare drive, visit it (tab to icon, press ENTER) and make it Hot Spare. It will get a Red Cross Icon, become invisible to the O/S and do absolutely nothing until another drive fails. * Exit, reboot and enjoy. The O/S will have no clue, except some drive that is simply too big. > Is sendero-ppp.i-connect.net/crash/dptmgr-floppy1.raw supposed to be > some kind of single disk boot manager? How is it supposed to be used? it is the most current (I hope) first disk in the DPt package. Goes hand in hand with the firmware I have there too. See above for directions. They were typed from memory, so no warranty, expressed or implied apply :-) Simon From owner-freebsd-scsi Tue Jul 15 03:55:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA20672 for freebsd-scsi-outgoing; Tue, 15 Jul 1997 03:55:02 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA20654 for ; Tue, 15 Jul 1997 03:54:52 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id UAA16854; Tue, 15 Jul 1997 20:50:23 +1000 Date: Tue, 15 Jul 1997 20:50:23 +1000 From: Bruce Evans Message-Id: <199707151050.UAA16854@godzilla.zeta.org.au> To: gibbs@plutotech.com, Shimon@i-Connect.Net Subject: Re: problems with reboot Cc: dg@root.com, filo@yahoo.com, freebsd-SCSI@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >* It appears that the shutdown procedure does a umount -a and that umount > issues a close to sd.c... Open swap devices prevent the last close in some cases. >* I further confused the issue by ASKING ``Does the /sbin/reboot command > umount or not?'' I then added that, if memory does not fail me, UnixWare > equivalent of /sbin/reboot does not and indeed can cause this sort of > failure. BTW, most other O/S do NOT issue the ``PREVENT/ALLOW...'' pairs It does for clean shutdowns only. If syncing all busy buffers succeeds, then all file systems are unmounted. Otherwise, file systems are not unmounted. Summary: this doesn't work quite right yet. Bruce From owner-freebsd-scsi Tue Jul 15 10:20:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA11529 for freebsd-scsi-outgoing; Tue, 15 Jul 1997 10:20:49 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA11524 for ; Tue, 15 Jul 1997 10:20:45 -0700 (PDT) Received: (qmail 21982 invoked by uid 1000); 15 Jul 1997 17:20:58 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199707151050.UAA16854@godzilla.zeta.org.au> Date: Tue, 15 Jul 1997 10:20:57 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Bruce Evans Subject: Re: problems with reboot Cc: freebsd-SCSI@FreeBSD.ORG, filo@yahoo.com, dg@root.com, gibbs@plutotech.com Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Bruce Evans; On 15-Jul-97 you wrote: > >* It appears that the shutdown procedure does a umount -a and that > umount issues a close to sd.c... > > Open swap devices prevent the last close in some cases. This needs fixing, then. > >* I further confused the issue by ASKING ``Does the /sbin/reboot > command > > umount or not?'' I then added that, if memory does not fail me, > UnixWare > > equivalent of /sbin/reboot does not and indeed can cause this sort of > > failure. BTW, most other O/S do NOT issue the ``PREVENT/ALLOW...'' > pairs > > It does for clean shutdowns only. If syncing all busy buffers succeeds, > then all file systems are unmounted. Otherwise, file systems are not > unmounted. > > Summary: this doesn't work quite right yet. DPT Users: Beware! :-) One idea (which vilotes the warranty on the cards); solder (carefully!!!) a 20 pin DIP socket over the 10 LED's on the board (holes are provided) and extend the LED array out t o the front. Do not kell power before your see the idle pattern. Simon From owner-freebsd-scsi Fri Jul 18 13:58:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA15624 for freebsd-scsi-outgoing; Fri, 18 Jul 1997 13:58:32 -0700 (PDT) Received: from prozac.neuron.net (prozac.neuron.net [165.254.1.213]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA15459; Fri, 18 Jul 1997 13:54:58 -0700 (PDT) Received: (from amir@localhost) by prozac.neuron.net (8.8.6/8.6.12) id QAA16387; Fri, 18 Jul 1997 16:54:26 -0400 (EDT) Message-ID: <19970718165426.63437@neuron.net> Date: Fri, 18 Jul 1997 16:54:26 -0400 From: "Amir Y. Rosenblatt" To: freebsd-stable@freebsd.org, freebsd-scsi@freebsd.org Subject: [2.2.2] Probelms with scsi tape and disk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I upgraded to 2.2.2-stable a couple weeks ago from 2.2.1 (via cvsup'ing the full source tree, and then doing the upgrade as per the instructions in the FreeBSD Manual) and since then I've not been able to write anything to my SCSI tape drive. I was able to do restores of dumped stuff but I can;t tar or dump to the tape now. I just attempted a tar and here's what came up in /var/log/messages: ----- Jul 18 16:45:22 prozac /kernel: sd0(ahc0:1:0): SCB 0x0 - timed out in dataout phase, SCSISIGI == 0x4 Jul 18 16:45:22 prozac /kernel: SEQADDR = 0x124 SCSISEQ = 0x12 SSTAT0 = 0x0 SSTAT1 = 0x2 Jul 18 16:45:22 prozac /kernel: st0(ahc0:3:0): abort message in message buffer Jul 18 16:45:22 prozac /kernel: sd0(ahc0:1:0): SCB 0x3 timedout while recovery in progress Jul 18 16:45:22 prozac /kernel: st0(ahc0:3:0): SCB 2 - Abort Completed. Jul 18 16:45:22 prozac /kernel: st0(ahc0:3:0): no longer in timeout Jul 18 16:47:02 prozac /kernel: st0(ahc0:3:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jul 18 16:47:02 prozac /kernel: SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jul 18 16:47:02 prozac /kernel: st0(ahc0:3:0): SCB 2: Immediate reset. Flags = 0x1 Jul 18 16:47:02 prozac /kernel: ahc0: Issued Channel A Bus Reset. 1 SCBs aborted Jul 18 16:47:02 prozac /kernel: Clearing bus reset Jul 18 16:47:02 prozac /kernel: Clearing 'in-reset' flag Jul 18 16:47:02 prozac /kernel: st0(ahc0:3:0): no longer in timeout Jul 18 16:47:12 prozac /kernel: sd0(ahc0:1:0): UNIT ATTENTION asc:29,0 Jul 18 16:47:12 prozac /kernel: sd0(ahc0:1:0): Power on, reset, or bus device reset occurred field replaceable unit: 1 Jul 18 16:47:12 prozac /kernel: , retries:4 ----- The machine's config is as follows: Tyan Dual PPro motherboard (with a single PPro200 on it) 96 meg of RAM Adaptec 2940UW SCSI host adapter Maxtor 4 gig IDE disk a pair of Seagate ST32550W Fast/Wise scsi disks HP SureStore 6000 tapedrive (I think it's the 6000 -- it's the 4 gig DDS-2 OEM internal DAT drive) 3Com 3c509B-TP ethernet card Number 9 "Imagine 128" 4 meg video card It should be noted that the tar that resulted in the above syslog spew was NOT being done from sd0 -- it was being done from wd0 (the IDE disk, which is currently serving as my boot disk). This has only started happening since the 2.2.2 upgrade. Any ideas? -Amir -- / \ Bite marks in the naugahide. | Amir Y. Rosenblatt /<@>\ - Red Meat | amir@neuron.net / \ FNORD | http://www.neuron.net/~amir _/_______\____________________________________|____________________________ From owner-freebsd-scsi Fri Jul 18 21:13:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA04987 for freebsd-scsi-outgoing; Fri, 18 Jul 1997 21:13:46 -0700 (PDT) Received: from giga.bga.com (root@giga.realtime.net [205.238.128.46]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA04973 for ; Fri, 18 Jul 1997 21:13:39 -0700 (PDT) Received: from urchin.bga.com (khym@urchin.realtime.net [205.238.128.41]) by giga.bga.com (8.6.5/8.6.12) with ESMTP id XAA08476 for ; Fri, 18 Jul 1997 23:13:37 -0500 Received: from localhost (khym@localhost) by urchin.bga.com (8.6.12/8.6.10) with SMTP id XAA17294 for ; Fri, 18 Jul 1997 23:13:36 -0500 X-Authentication-Warning: urchin.bga.com: khym owned process doing -bs Date: Fri, 18 Jul 1997 23:13:35 -0500 (CDT) From: Dave Huang To: freebsd-scsi@freebsd.org Subject: Disk activity light on Asus SC875 doesn't work Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi there... I just got an Asus SC875 card (53c875 chip), and it seems to be running great so far... except for one weird thing: the activity LED doesn't work when in NetBSD. However, in MSDOS, Win95, and WinNT, it works just fine. I did notice that the light stays on solid at the OS-BS boot selector menu, and I know there's no disk activity going on at that time. Does this card have a software-controlled LED or something? That'd be kinda strange :) (kinda like the software-controllable power LED on Amigas :) Any ideas? And yeah, I know this is a FreeBSD list, not NetBSD, but NetBSD uses the FreeBSD driver, and Stefan Esser is here too :) But I did also boot a 3.0-970618-SNAP floppy, and saw the same thing. TIA! -- Name: Dave Huang | Mammal, mammal / their names are called / INet: khym@bga.com | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 21 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++ From owner-freebsd-scsi Fri Jul 18 22:12:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA07422 for freebsd-scsi-outgoing; Fri, 18 Jul 1997 22:12:25 -0700 (PDT) Received: from oneway.com (oneway.com [198.80.68.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA07403; Fri, 18 Jul 1997 22:12:21 -0700 (PDT) Received: from oneway.com (oneway.com [198.80.68.27]) by oneway.com (8.8.5/8.8.3) with SMTP id AAA20763; Sat, 19 Jul 1997 00:06:15 -0500 (CDT) Date: Sat, 19 Jul 1997 00:06:15 -0500 (CDT) From: Jay Kuri To: freebsd-scsi@freebsd.org, questions@freebsd.org Subject: help: wiring down scsi devices doesn't work Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Good evening, I have been trying, to no avail, to wire down a particular target device to pt0. Although config gives me no errors, and the kernel rebuilds fine, it does not wire down the device... and instead reports it (a scsi scanner) as uk0. In order for a hard-wired scsi device to work, do all devices need to be wired down? Any help with this problem would be appreciated... Thanks in advance, Jay below is the relavent portion of my kernel config: --snip-- controller ahc0 controller aic0 at isa? port 0x140 bio irq 11 vector aicintr controller scbus0 at ahc0 # Single bus device controller scbus1 at aic0 # Single bus device device pt0 at scbus0 target 4 unit 0 # SCSI processor type device ch0 #SCSI media changers device sd0 #SCSI disks device st0 #SCSI tapes device cd0 #SCSI CD-ROMs device od0 #SCSI optical disk --- Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers.