From owner-freebsd-firewire@FreeBSD.ORG Tue Nov 4 20:50:16 2003 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB73716A4CE for ; Tue, 4 Nov 2003 20:50:16 -0800 (PST) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (B7774.b.pppool.de [213.7.119.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 662FF43F93 for ; Tue, 4 Nov 2003 20:49:50 -0800 (PST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk (NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk [2002:d507:7774:0:200:c0ff:fefc:19aa]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id hA54nXg89212 verified NO) for ; Wed, 5 Nov 2003 05:49:35 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost)hA54nX155005; Wed, 5 Nov 2003 05:49:33 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Wed, 5 Nov 2003 05:49:33 +0100 (CET) Message-Id: <200311050449.hA54nX155005@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk> X-Authentication-Warning: NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk: beer set sender to bounce@NOSPAM.dyndns.dk using -f From: Barry Bouwsma To: FreeBSD Firewire Developers References: <200309152131.h8FLV2271240@Mail.NOSPAM.DynDNS.dK> <200309180452.h8I4qxS58023@Mail.NOSPAM.DynDNS.dK> <200309201256.h8KCusu53498@Mail.NOSPAM.DynDNS.dK> Subject: Re: (none) was: Re: Ext. firewire disk disconnection and persistence of da* entry... X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Vendors pre-release coordination List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2003 04:50:16 -0000 [sorry for the delay; I've been away and mostly offline. Drop me from the list of recipients and I'll catch the archives Real Soon Now] You wrote: > > What I am looking for, is that the firewire drive is made available > > as da0 at boot, ideally with support in kernel modules instead of the > Did you chage SCSI_DELAY from the default 15sec? Ah, very good observation. Yes, I did, when a normal SCSI drive gave me no problems with a much lower value. Increasing the value to 8 seconds gave one time when a timeout was recorded; otherwise, the drive was mostly detected fine. I backed out the change I thought I needed to make to get things to work. Just as a note, there was a time when I got nothing but timeouts. I then rebuilt the kernel with SCSI_DELAY increasing up to and including 15 seconds, with no change. Until I disconnected and reconnected the drive; then it worked fine, even with a 5 second SCSI_DELAY, thereafter. I'm back down to a 5 second SCSI_DELAY, without my hacks (I think), and it works. So, sorry about the false alarm, and this for the archives, in case someone else seems to have problems, to double-check the value of SCSI_DELAY. Thanks for the pointer, sorry for the delay in this response, and sorry for all the noise I created already. Barry Bouwsma