From owner-freebsd-current Sat Oct 3 23:12:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA17896 for freebsd-current-outgoing; Sat, 3 Oct 1998 23:12:35 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (castles144.castles.com [208.214.165.144]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA17891 for ; Sat, 3 Oct 1998 23:12:32 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id XAA02091; Sat, 3 Oct 1998 23:16:58 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810040616.XAA02091@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: arg@arg1.demon.co.uk (Andrew Gordon), karl@Denninger.Net, current@FreeBSD.ORG Subject: Re: Long SCSI probes (was Re: Long IDE probes?) In-reply-to: Your message of "Sun, 04 Oct 1998 03:04:58 -0000." <199810040304.UAA21515@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Oct 1998 23:16:57 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Note that the SCSI bus is reset before probing; SCSI devices vary wildly > > in their reaction to this. I have a tape drive that, if there is a tape > > in the slot, engages in considerable tape movement (presumably to detect > > the tape format/capacity) - this device requires (pre-CAM) SCSI_DELAY=23 > > to survive rebooting with a tape loaded. Even disc drives vary from > > near-instantaneous to several seconds response time. > > Next stupid question: I assume that part of the adapter POSTing > is a bus reset. > > Why does FreeBSD issue a SCSI bus reset at all? > > > I understand that you would need to wait this long if you issued > a reset, and I understand a reset is necessary to detect newly > plugged "hot plug" devices. However, it seems to me that the use > of a reset following a power on is specious and unnecessary, > even if there might be reason for root to be able to issue such > a command (and thus lock up the box for up to 31 secons). No guarantee that you're following a power-on, and no way to tell what state the various peripherials might be in, or what the previous owner(s) might (or might not) have done to them. Particularly, there's plenty of room for people to have frigged with volatile mode pages, eg. to turn on/off write caching. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message