From owner-freebsd-firewire@FreeBSD.ORG Mon Sep 15 14:31:48 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 5EE6A16A4BF for ; Mon, 15 Sep 2003 14:31:48 -0700 (PDT) Received: from nospam.dyndns.dk (c-180-196-86.ka.dial.de.ignite.net [62.180.196.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id A098543F3F for ; Mon, 15 Sep 2003 14:31:24 -0700 (PDT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NetScum.dyndns.dk [2002:3eb4:c456:0:220:afff:fed4:dbcb])h8FLV2Q71241verified NO) for ; Mon, 15 Sep 2003 23:31:03 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from root@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id h8FLV2271240; Mon, 15 Sep 2003 23:31:02 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Mon, 15 Sep 2003 23:31:02 +0200 (CEST) Message-Id: <200309152131.h8FLV2271240@Mail.NOSPAM.DynDNS.dK> From: Barry Bouwsma To: FreeBSD Firewire Developers Subject: 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: Mon, 15 Sep 2003 21:31:48 -0000 [NOTE: IPv6-only e-mail above, so you probably want to drop me from the recipients and just send to the list, which I'll read later, as I'm not always online -- else remove just the hostname part to reveal an IPv4-aware e-mail for me that may well timeout and bounce. Sorry.] Hello firewire types; I've been stuck with 09.Dec.2003 kernel source (mostly RELENG_4) that I've hacked to get working with an external Maxtor USB2/Firewire 250GB drive. Recently I got back online and updated to RELENG_4 source from early Sep, that I've checked against my drive to see if my hacks are still needed. As a side note, it seems my drive is not consistently recognized upon connection, but I'll ignore that for now, as every second or third try seems to work -- my hacks caused it to be recognized every time, even if the hacks were completely wrong. My first question concerns disconnecting the drive after it's been recognized. It appears with the RELENG_4 code that once the drive has been identified and attached to, say, da0, that da0 never disappears when the drive is detached, leading to any attempts to access da0 after disconnect to hang eternally (or at least until the drive is re-attached), at least with my year-old codebase (haven't banged heavily on the more recent kernel codes). I added the following in my hacks in order to detach da0 (or whatever) anytime the firewire drive is disconnected, in order to avoid hanging at any attempts to mount/access it: --- /usr/local/system/src/sys/dev/firewire/sbp.c Fri Aug 22 09:46:58 2003 +++ /usr/local/source-hacks/sys/dev/firewire/sbp.c Tue Sep 2 18:08:55 2003 @@ -730,6 +730,11 @@ } sdev->status = SBP_DEV_RETRY; sbp_abort_all_ocbs(sdev, CAM_SCSI_BUS_RESET); + +/* XXXX HACK .... don't we want to detach the target here???!??? */ + printf(" So... calling sbp_cam_detach_target\n"); + sbp_cam_detach_target(target); + break; case SBP_DEV_PROBE: case SBP_DEV_TOATTACH: There's probably a good reason NOT to do this; would someone care to enlighten me as to what it would be, given the alternative of hanging attempts to access the device under my old RELENG_4 ? Thanks, Barry Bouwsma (PS: I'll see about syncing the rest of my hacks against the latest code to see what more is needed to get my drive working reliably, and sending that info Real Soon Now[tm] ... but it'll take a while to catch up on the last nine months of changes)