Ext. firewire disk disconnection and persistence of da* entry...

[Barry Bouwsma]

[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)