From owner-freebsd-firewire@FreeBSD.ORG Sun Sep 21 19:25:11 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 DB4EC16A4B3 for ; Sun, 21 Sep 2003 19:25:11 -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 1EFFD43F3F for ; Sun, 21 Sep 2003 19:25:10 -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 A1307378374 for ; Mon, 22 Sep 2003 11:25:08 +0900 (JST) Received: from mailhosting.itc.u-tokyo.ac.jp (IDENT:mirapoint@mailhosting.itc.u-tokyo.ac.jp [133.11.205.3]) h8M2P811004564; Mon, 22 Sep 2003 11:25:08 +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 AKL25729; Mon, 22 Sep 2003 11:25:07 +0900 (JST) Date: Mon, 22 Sep 2003 11:25:06 +0900 Message-ID: From: Hidetoshi Shimokawa To: Barry Bouwsma In-Reply-To: <200309201256.h8KCusu53498@Mail.NOSPAM.DynDNS.dK> References: <200309152131.h8FLV2271240@Mail.NOSPAM.DynDNS.dK> <200309180452.h8I4qxS58023@Mail.NOSPAM.DynDNS.dK> <200309201256.h8KCusu53498@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: 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, 22 Sep 2003 02:25:12 -0000 At Sat, 20 Sep 2003 14:56:54 +0200 (CEST), Barry Bouwsma wrote: > Okay, I checked -- When the drive is attached before booting into a kernel > from sources about 01.Sep (two patches applied -- the detach patch I gave > earlier, plus one to eliminate the tons of debug messages with verbose > booting), it is not attached as a da0 drive. If I unplug it and then > reconnect it, it then is made available as da0, and apparently repeated > dis-/re-connects all make it reappear -- at least with my detach patch. > (Hmm, have I tried mounting it? Ummm...) How about 'fwcontrol -r' instead of unplug/plunging? > Following significant parts of the 4.9-PRERELEASE dmesg, I'm also giving > selected parts from my 4.7 kernel from 09.Dec with hacks to log some debug > info and reliably find and attach (though probably incorrectly) the drive, > if any of my debug info would be of help. (FYI, I also needed to do some > hacking to get NetBSD-current of the same date to recognize the drive though > I didn't succeed in getting it mounted successfully.) > > Here's the dmesg, drive attached before boot, 4.9-beginning-of-September: > > fwohci0: vendor=1033, dev=e7 > fwohci0: <1394 Open Host Controller Interface> mem 0xdf800000-0xdf800fff irq 9 at device 9.0 on pci0 > using shared irq9. > fwohci0: OHCI version 1.10 (ROM=1) > fwohci0: No. of Isochronous channel is 4. > fwohci0: EUI64 00:00:4c:02:08:00:5e:45 > fwohci0: resetting OHCI...done (loop=0) > fwohci0: fwphy_rddata: 0x2 loop=1, retry=0 > fwohci0: fwphy_rddata: 0x3 loop=1, retry=0 > fwohci0: Phy 1394a available S400, 2 ports. > fwohci0: fwphy_rddata: 0x5 loop=1, retry=0 > fwohci0: Enable 1394a Enhancements > fwohci0: fwphy_rddata: 0x5 loop=1, retry=0 > fwohci0: fwphy_rddata: 0x2 loop=1, retry=0 > fwohci0: fwphy_rddata: 0x4 loop=1, retry=0 > fwohci0: fwphy_rddata: 0x4 loop=1, retry=0 > fwohci0: fwphy_rddata: 0x4 loop=1, retry=0 > fwohci0: Link S400, max_rec 2048 bytes. > fwohci0: BUS_OPT 0xf800a002 -> 0xf800a002 > fwohci0: fwohci_set_intr: 1 > firewire0: on fwohci0 > sbp0: on firewire0 > sbp_attach (cold=1) > fwohci0: Initiate bus reset > fwohci0: fwphy_rddata: 0x1 loop=1, retry=0 > fwohci0: fwphy_rddata: 0x1 loop=1, retry=0 > fwohci0: BUS reset > sbp_post_busreset > fwohci0: node_id=0xc800ffc1, gen=1, CYCLEMASTER mode > firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) > fwohci0: fw_set_bus_manager: 1->1 (loop=0) > firewire0: bus manager 1 (me) > fwohci0: maxdesc: 2 > fwohci0: start AT DMA status=0 > [ snip ... ] > fwohci0: BUS reset Do you remember what causes this BUS reset? I suspect this bus reset is initiated by the HDD after turned-on. What happens if you plug the HDD after the HDD has already spined up? > sbp_post_busreset > fwohci0: node_id=0xc800ffc1, gen=2, CYCLEMASTER mode > fw_xfer_done: pending > firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) > fwohci0: fw_set_bus_manager: 1->1 (loop=0) > firewire0: bus manager 1 (me) > fwohci0: start AT DMA status=11 > [ snip ... ] > firewire0: New S400 device ID:0010b920003dbcb3 > sbp_post_explore (sbp_cold=2) > sbp_post_explore: EUI:0010b920003dbcb3 attached > target 0 lun 0 found > sbp0:0:0 ordered:1 type:14 EUI:0010b920003dbcb3 node:0 speed:2 maxrec:0 new! > sbp0:0:0 'Maxtor' '5000XT v1.00.00' '010000' > fw_attach_dev: 1 pending handlers called > [ snip ... ] > sbp0:0:0 LOGIN > sbp: alloc 1 xfer > fwohci0: maxdesc: 3 > sbp0:0:0 login: len 16, ID 0, cmd 0000fffff0100000, recon_hold 0 > sbp0:0:0 sbp_busy_timeout > sbp0:0:0 sbp_agent_reset > sbp0:0:0 sbp_do_attach hmm, we should call sbp_cam_scan_target() here... /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html From owner-freebsd-firewire@FreeBSD.ORG Wed Sep 24 09:38:44 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 B086416A4B3 for ; Wed, 24 Sep 2003 09:38:44 -0700 (PDT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (B76a1.pppool.de [213.7.118.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3FA24400F for ; Wed, 24 Sep 2003 09:38:04 -0700 (PDT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:d507:76a1:0:220:afff:fed4:dbcb]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id h8OGb2402806 verified NO) for ; Wed, 24 Sep 2003 18:37:06 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id h8OGb1J02805; Wed, 24 Sep 2003 18:37:01 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Wed, 24 Sep 2003 18:37:01 +0200 (CEST) Message-Id: <200309241637.h8OGb1J02805@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma To: FreeBSD Firewire Folks Subject: More about boot-time firewire device detection... 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, 24 Sep 2003 16:38:44 -0000 [drop hostname part of above IPv6-only address if you want to mail me via IPv4, or better, drop my address entirely and I'll read the list archives] Hello hello hello. I wrote earlier that my Firewire/USB external drive was only found after boot followed by detach/reattach with the latest (recent) firewire codes, and an unneeded patch to detach the CAM layer at detach. Well, I've moved to a different machine, using the same cards, to allow me to panic and poweroff to juggle hardware without inconveniencing other long-running programs. This machine had only a 4.5-RC kernel, now 4.9PRE, an unknown userland from around the same time, and I'm trying to use the latest kernel modules. None of my patch hacks have been applied. I wrote that the latest firewire/sbp codes failed to find an attached drive at boot, when loaded from loader.conf. This may still be true, I'm going to check Real Soon Now. Yes, it's true. Details follow. However, if *after* boot I kldload sbp/firewire with the drive attached, it appears to detect the drive fine and make it available for mounting, as desired. No need to detach/reattach the cable. Here is part of the dmesg at boot with auto-load by loader.conf: [snip; verbose boot lost firewire-related messages prior to this] node0: explore addr=0x400 Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682080 OUTL ST2 ALL ALL 12 00000000 02682100 8412:7cd0 RUN,ACTIVE, ack pend(12) 0x00800540 0xffc0ffff 0xf0000400 0x00000000 fw_rcv: unknown response tcode=6 src=0xffc0 tl=0x2 rt=1 data=0xc9354404 try ad-hoc work around!! node0: callback addr=0x400 node0: explore addr=0x40c Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682100 OUTL ST2 ALL ALL 12 00000000 02682180 8412:7d19 RUN,ACTIVE, ack pend(12) 0x00800940 0xffc0ffff 0xf000040c 0x00000000 node0: callback addr=0x40c node0: explore addr=0x410 [ very large snip .... ] node0: callback addr=0x50c node0: explore addr=0x510 Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682700 OUTL ST2 ALL ALL 12 00000000 02682780 8412:9b39 RUN,ACTIVE, ack pend(12) 0x00803940 0xffc0ffff 0xf0000510 0x00000000 node0: callback addr=0x510 bus_explore done sbp_post_explore (sbp_cold=2) sbp_post_explore: EUI:0010b920003dbcb3 attached target 0 lun 0 found sbp0:0:0 ordered:1 type:14 EUI:0010b920003dbcb3 node:0 speed:2 maxrec:0 new! sbp0:0:0 'Maxtor' '5000XT v1.00.00' '010000' Mounting root from ufs:/dev/ad0s1a ad0s1: type 0xa5, start 63, end = 2503871, size 2503809 : OK start_init: trying /sbin/init sbp0:0:0 LOGIN sbp: alloc 1 xfer fwohci0: maxdesc: 3 dbdump err ch = 0 cmd = 0x026827a1 sbp0:0:0 login: len 16, ID 0, cmd 0000fffff0100000, recon_hold 0 sbp0:0:0 sbp_busy_timeout Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682800 OUTL ST2 ALL ALL 16 00000000 02682880 8412:dbb7 RUN,ACTIVE, ack pend(12) 0x00824100 0xffc0ffff 0xf0000210 0x0f000002 sbp0:0:0 sbp_agent_reset Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682880 OUTL ST2 ALL ALL 16 00000000 02682900 8412:dbe8 RUN,ACTIVE, ack pend(12) 0x00824500 0xffc0ffff 0xf0100004 0x0f000000 sbp0:0:0 sbp_do_attach It never goes any further than this, until I physically detach and re-attach the cable. Then, with a new boot, auto-loaded sbp/firewire kernel modules: [ very big snip, here it's not made available at boot: ... ] node0: callback addr=0x510 bus_explore done sbp_post_explore (sbp_cold=2) sbp_post_explore: EUI:0010b920003dbcb3 attached target 0 lun 0 found sbp0:0:0 ordered:1 type:14 EUI:0010b920003dbcb3 node:0 speed:2 maxrec:0 new! sbp0:0:0 'Maxtor' '5000XT v1.00.00' '010000' Mounting root from ufs:/dev/ad0s1a ad0s1: type 0xa5, start 63, end = 2503871, size 2503809 : OK start_init: trying /sbin/init sbp0:0:0 LOGIN sbp: alloc 1 xfer fwohci0: maxdesc: 3 dbdump err ch = 0 cmd = 0x02682821 sbp0:0:0 login: len 16, ID 0, cmd 0000fffff0100000, recon_hold 0 sbp0:0:0 sbp_busy_timeout Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682880 OUTL ST2 ALL ALL 16 00000000 02682900 8412:2b0d RUN,ACTIVE, ack pend(12) 0x00824100 0xffc0ffff 0xf0000210 0x0f000002 sbp0:0:0 sbp_agent_reset Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682900 OUTL ST2 ALL ALL 16 00000000 02682980 8412:2b3c RUN,ACTIVE, ack pend(12) 0x00824500 0xffc0ffff 0xf0100004 0x0f000000 sbp0:0:0 sbp_do_attach [ then I disconnect it ...] fwohci0: BUS reset sbp_post_busreset fwohci0: node_id=0xc800ffc0, gen=3, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) fwohci0: fw_set_bus_manager: 0->0 (loop=0) firewire0: bus manager 0 (me) send phy_config root_node=-1 gap_count=5 fwohci0: start AT DMA status=12 Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682980 OUTL ST2 ALL ALL 12 00000000 02682a00 8411:3b95 RUN,ACTIVE, ack complete(11) 0x000000e0 0x00450000 0xffbaffff 0x00000000 bus_explore done sbp_post_explore (sbp_cold=1) sbp_post_explore: EUI:0010b920003dbcb3 not attached, state=3. sbp0:0:0 lost target fwohci0: BUS reset sbp_post_busreset fwohci0: node_id=0x8800ffc0, gen=5, non CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 0 (me) fwohci0: fw_set_bus_manager: 0->0 (loop=0) firewire0: root node is not cycle master capable firewire0: bus manager 0 (me) send phy_config root_node=0 gap_count=5 fwohci0: start AT DMA status=11 Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682a00 OUTL ST2 ALL ALL 12 00000000 02682a80 8411:be5c RUN,ACTIVE, ack complete(11) 0x000000e0 0x00c50000 0xff3affff 0x00000000 node1: explore addr=0x400 Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682a80 OUTL ST2 ALL ALL 12 00000000 02682b00 8412:c6b2 RUN,ACTIVE, ack pend(12) 0x00804940 0xffc1ffff 0xf0000400 0x00000000 node1: callback addr=0x400 node1: explore addr=0x40c Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682b00 OUTL ST2 ALL ALL 12 00000000 02682b80 8412:c6e8 RUN,ACTIVE, ack pend(12) 0x00804d40 0xffc1ffff 0xf000040c 0x00000000 node1: callback addr=0x40c node1: explore addr=0x410 Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682b80 OUTL ST2 ALL ALL 12 00000000 02682c00 8412:c71f RUN,ACTIVE, ack pend(12) 0x00805140 0xffc1ffff 0xf0000410 0x00000000 node1: callback addr=0x410 node1: eui64 is zero. bus_explore done sbp_post_explore (sbp_cold=0) sbp_post_explore: EUI:0010b920003dbcb3 not attached, state=3. [ and I reconnect it ... ] fwohci0: BUS reset sbp_post_busreset fwohci0: node_id=0xc800ffc1, gen=6, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) fwohci0: fw_set_bus_manager: 1->1 (loop=0) firewire0: bus manager 1 (me) send phy_config root_node=1 gap_count=5 fwohci0: start AT DMA status=12 Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682c00 OUTL ST2 ALL ALL 12 00000000 02682c80 8411:d66d RUN,ACTIVE, ack complete(11) 0x000000e0 0x01c50000 0xfe3affff 0x00000000 node0: explore addr=0x400 Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682c80 OUTL ST2 ALL ALL 12 00000000 02682d00 8412:de23 RUN,ACTIVE, ack pend(12) 0x00805540 0xffc0ffff 0xf0000400 0x00000000 node0: callback addr=0x400 node0: explore addr=0x40c Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682d00 OUTL ST2 ALL ALL 12 00000000 02682d80 8412:de59 RUN,ACTIVE, ack pend(12) 0x00805940 0xffc0ffff 0xf000040c 0x00000000 node0: callback addr=0x40c node0: explore addr=0x410 Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682d80 OUTL ST2 ALL ALL 12 00000000 02682e00 8412:de8e RUN,ACTIVE, ack pend(12) 0x00805d40 0xffc0ffff 0xf0000410 0x00000000 node0: callback addr=0x410 node0: explore addr=0x400 Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682e00 OUTL ST2 ALL ALL 12 00000000 02682e80 8412:dec5 RUN,ACTIVE, ack pend(12) 0x00806140 0xffc0ffff 0xf0000400 0x00000000 node0: callback addr=0x400 bus_explore done sbp_post_explore (sbp_cold=0) sbp_post_explore: EUI:0010b920003dbcb3 attached sbp0:0:0 ordered:1 type:14 EUI:0010b920003dbcb3 node:0 speed:2 maxrec:0 sbp0:0:0 'Maxtor' '5000XT v1.00.00' '010000' sbp0:0:0 RECONNECT dbdump err ch = 0 cmd = 0x02682ea1 sbp0:0:0 reconnect failed sbp0:0:0 LOGIN dbdump err ch = 0 cmd = 0x02682f21 sbp0:0:0 login: len 16, ID 0, cmd 0000fffff0100000, recon_hold 0 sbp0:0:0 sbp_busy_timeout Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02682f80 OUTL ST2 ALL ALL 16 00000000 02683000 8412:1f31 RUN,ACTIVE, ack pend(12) 0x00826d00 0xffc0ffff 0xf0000210 0x0f000002 sbp0:0:0 sbp_agent_reset Current DB 0 ch = 0 Current OP KEY INT BR len Addr Depend Stat: Cnt 02683000 OUTL ST2 ALL ALL 16 00000000 02683080 8412:2022 RUN,ACTIVE, ack pend(12) 0x00827100 0xffc0ffff 0xf0100004 0x0f000000 sbp0:0:0 sbp_do_attach sbp0:0:0 sbp_cam_scan_target dbdump err ch = 0 cmd = 0x026830a1 dbdump err ch = 0 cmd = 0x02683121 sbp0:0:0 XPT_SCSI_IO: cmd: 1a 00 0a 00 14 00 00 00 00 00, flags: 0x40, 6b cmd/20b data/32b sense sbp0:0:0 SCSI status 2 sfmt 0 valid 0 key 5 code 24 qlfr 0 len 3 (probe0:sbp0:0:0:0): MODE SENSE(06). CDB: 1a 0 a 0 14 0 (probe0:sbp0:0:0:0): ILLEGAL REQUEST asc:24,0 (probe0:sbp0:0:0:0): Invalid field in CDB dbdump err ch = 0 cmd = 0x026831a1 dbdump err ch = 0 cmd = 0x02683221 pass0 at sbp0 bus 0 target 0 lun 0 pass0: Fixed Simplified Direct Access SCSI-4 device pass0: Serial Number A80A06AE pass0: 50.000MB/s transfers, Tagged Queueing Enabled Creating DISK da0 sbp0:0:0 sbp_cam_scan_lun not sent yet tl=21 da0 at sbp0 bus 0 target 0 lun 0 da0: Fixed Simplified Direct Access SCSI-4 device da0: Serial Number A80A06AE da0: 50.000MB/s transfers, Tagged Queueing Enabled da0: 239371MB (490232832 512 byte sectors: 255H 63S/T 30515C) dbdump err ch = 0 cmd = 0x026832a1 already rcvd dbdump err ch = 0 cmd = 0x02683321 dbdump err ch = 0 cmd = 0x026833a1 [snip normal operation of said drive] Now I've turned my attention to a second card, which had given me problems before. It's a combination USB2/Firewire card, with a VIA6306 chip (mentioned a few times in the firewire source files). A side note, this combination card is a source of problems for me. It appears that I can successfully load USB modules with it (hacked, as there seems to be an overcurrent problem), or perhaps firewire modules, but as soon as I try to load the other functionality, the machine hangs (on my development machine I can get into the debugger and see it's in a doreti or doreti_foo) -- likewise at booting that never gets very far when auto-loaded, most of the time. I have sometimes had some success getting into NetBSD or FreeBSD-current, but at least NetBSD wedges solid soon after. The combi-card often does not even see the EUI of the device. Instead, it spits out: firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) fwohci0: fw_set_bus_manager: 1->1 (loop=0) firewire0: bus manager 1 (me) send phy_config root_node=1 gap_count=5 fwohci0: maxdesc: 2 fwohci0: start AT DMA status=0 node0: explore addr=0x400 sbp0: on firewire0 sbp_attach (cold=0) sbp_post_explore (sbp_cold=1) firewire0: split transaction timeout dst=0xffc0 tl=0x1 state=2 ^^^^^^^^^^^^^^^^^^^^^^^^^ node0: callback addr=0x400 node0: resp=60 addr=0x400 fw_xfer_free FWXF_START bus_explore done sbp_post_explore (sbp_cold=0) probe failed for 1 node Then nothing happens at any bus event. This is with the modules loaded after boot by hand. However, this could just be a hardware problem, on this ten-year-old PC. For when I moved the card to a different slot, and/or removed/exchanged the ethernet card, and/or removed the sound card, now it does find the attached drive, although it still needs a physical detach/attach after boot to give me the drive as da0. I haven't yet loaded the usb modules with the functioning firewire, to see if it still wedges the machine. Maybe later. Thanks, Barry Bouwsma