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