From owner-freebsd-firewire@FreeBSD.ORG Mon Sep 29 21:04:25 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 4E2AB16A4B3 for ; Mon, 29 Sep 2003 21:04:25 -0700 (PDT) Received: from is2.mh.itc.u-tokyo.ac.jp (is2.mh.itc.u-tokyo.ac.jp [133.11.205.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E72643FF3 for ; Mon, 29 Sep 2003 21:04:23 -0700 (PDT) (envelope-from simokawa@sat.t.u-tokyo.ac.jp) Received: from is2.mh.itc.u-tokyo.ac.jp (is2.mh.itc.u-tokyo.ac.jp [127.0.0.1]) by is2.mh.itc.u-tokyo.ac.jp (Postfix) with ESMTP id D0749378412 for ; Tue, 30 Sep 2003 13:04:20 +0900 (JST) Received: from mailhosting.itc.u-tokyo.ac.jp (IDENT:mirapoint@mailhosting.itc.u-tokyo.ac.jp [133.11.205.3]) h8U44DQj011943; Tue, 30 Sep 2003 13:04:13 +0900 Received: from ett.sat.t.u-tokyo.ac.jp (ett.sat.t.u-tokyo.ac.jp [133.11.135.3])3.3.5-GR) with ESMTP id AKP87400; Tue, 30 Sep 2003 13:04:00 +0900 (JST) Date: Tue, 30 Sep 2003 13:04:00 +0900 Message-ID: From: Hidetoshi Shimokawa To: Barry Bouwsma In-Reply-To: <200309300307.h8U37PW12960@Mail.NOSPAM.DynDNS.dK> References: <200309152131.h8FLV2271240@Mail.NOSPAM.DynDNS.dK> <200309180452.h8I4qxS58023@Mail.NOSPAM.DynDNS.dK> <200309201256.h8KCusu53498@Mail.NOSPAM.DynDNS.dK> <200309300307.h8U37PW12960@Mail.NOSPAM.DynDNS.dK> User-Agent: Wanderlust/2.11.0 (Wonderwall) REMI/1.14.3 (Matsudai) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.4 (patch 8) (Honest Recruiter) (i386--freebsd) X-Face: OE([KxWyJI0r[R~S/>7ia}SJ)i%a,$-9%7{*yihQk|]gl}2p#"oXmX/fT}Bn7: #j7i14gu$jgR\S*&C3R/pJX Subject: Re: (none) 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: Tue, 30 Sep 2003 04:04:25 -0000 At Tue, 30 Sep 2003 05:07:25 +0200 (CEST), Barry Bouwsma 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 > kernel proper, for unattended operation where a crash/reboot or power > failure is possible and I have no chance to correct things by hand. > This means, no unplug/re-plug, and no `fwcontrol' ... > > Now that I see that the recent 4.9-PRERELEASE codes support the drive > with no need for my hacks, apart from the observation that the drive > does not seem to be CAM-scanned at boot -- at least as a kernel module > with 4.5-era tools -- I'll see how things work with a kernel built > including firewire/sbp support, rather than modules. Did you chage SCSI_DELAY from the default 15sec? /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html