Date: Mon, 22 Sep 2003 11:25:06 +0900 From: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> To: Barry Bouwsma <freebsd-misuser@NOSPAM.dyndns.dk> Cc: FreeBSD Firewire Developers <firewire@freebsd.org> Subject: Re: Ext. firewire disk disconnection and persistence of da* entry... Message-ID: <ybsn0cxpnjx.wl@ett.sat.t.u-tokyo.ac.jp> In-Reply-To: <200309201256.h8KCusu53498@Mail.NOSPAM.DynDNS.dK> References: <200309152131.h8FLV2271240@Mail.NOSPAM.DynDNS.dK> <ybsu17ceorb.wl@ett.sat.t.u-tokyo.ac.jp> <200309180452.h8I4qxS58023@Mail.NOSPAM.DynDNS.dK> <200309201256.h8KCusu53498@Mail.NOSPAM.DynDNS.dK>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <IEEE1394(FireWire) bus> on fwohci0 > sbp0: <SBP2/SCSI over firewire> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybsn0cxpnjx.wl>