From owner-freebsd-firewire@FreeBSD.ORG Mon Sep 29 20:25:49 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 2761F16A4B3 for ; Mon, 29 Sep 2003 20:25:49 -0700 (PDT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (B77d2.pppool.de [213.7.119.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD07444032 for ; Mon, 29 Sep 2003 20:25:23 -0700 (PDT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:d507:77d2:0:220:afff:fed4:dbcb]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id h8U37Qp12961 verified NO); Tue, 30 Sep 2003 05:07:42 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id h8U37PW12960; Tue, 30 Sep 2003 05:07:25 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Tue, 30 Sep 2003 05:07:25 +0200 (CEST) Message-Id: <200309300307.h8U37PW12960@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 Developers References: <200309152131.h8FLV2271240@Mail.NOSPAM.DynDNS.dK> <200309180452.h8I4qxS58023@Mail.NOSPAM.DynDNS.dK> <200309201256.h8KCusu53498@Mail.NOSPAM.DynDNS.dK> cc: Hidetoshi Shimokawa 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: Tue, 30 Sep 2003 03:25:49 -0000 [Drop hostname part of IPv6-only address above to obtain IPv4-capable e-mail, or best drop me from the recipients and I'll catch up from the archives] Sorry for the late reply; I've been offline... And apologies if any of my messages have crossed paths with your replies for this reason. On Mon, 22 Sep 2003 11:25:06 +0900, Hidetoshi Shimokawa wrote: > > 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 > > How about 'fwcontrol -r' instead of unplug/plunging? Heh. I may have recent 4.9 kernel, but the userland on this machine is still 4.5-RC... :-) So no `fwcontrol' here just yet... What I am looking for, is that the firewire drive is made available as da0 at boot, ideally with support in kernel modules instead of the kernel proper, for unattended operation where a crash/reboot or power failure is possible and I have no chance to correct things by hand. This means, no unplug/re-plug, and no `fwcontrol' ... Now that I see that the recent 4.9-PRERELEASE codes support the drive with no need for my hacks, apart from the observation that the drive does not seem to be CAM-scanned at boot -- at least as a kernel module with 4.5-era tools -- I'll see how things work with a kernel built including firewire/sbp support, rather than modules. The result is -- also with kernel support for sbp/firewire, the drive again does not appear at boot as da0. > > fwohci0: maxdesc: 2 > > fwohci0: start AT DMA status=0 > > [ snip ... ] > > fwohci0: BUS reset > > Do you remember what causes this BUS reset? This is as part of normal boot, with non-firewire kernel messages cut out. I did nothing at this time; the drive was connected and ready, and the modules were loaded before boot. > 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? In truth, the machine has been rebooted many times while the disk has been running non-stop. So you never see the case where the disk has been connected but not powered-on, although today I did this (boot, then connect disk, then power-on disk) and this time, I needed to do nothing to make the drive appear for use as da0. The dmesg I showed was in fact for a spinning drive connected before boot. This is true for all dmesg's I provide. > > [ 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... Yes, that is what is apparently not happening when the kernel modules are pre-loaded for firewire support at boot. Looking at the code and a bit earlier in the message you quoted, sbp_cold at this point is 2, then gets decreased to 1, and if it is > 0, `return' is called, rather than sbp_scan_dev. 1045 /* 1046 * Let CAM scan the bus if we are in the boot process. 1047 * XXX xpt_scan_bus cannot detect LUN larger than 0 1048 * if LUN 0 doesn't exists. 1049 */ 1050 if (sbp_cold > 0) { 1051 sdev->status = SBP_DEV_ATTACHED; 1052 return; 1053 } 1054 1055 sbp_scan_dev(sdev); 1056 return; 1057 } I can think of two possibilities -- first, that the value of sbp_cold is not being set correctly at cold boot (it's initialized as 1, then at cold boot gets incremented to 2). Second, that perhaps line 1052 above should not be there, and after the status gets set ATTACHED, the sbp_scan_dev() routine should be called. I'm not sure which is right. Just for fun, I tried a hack based on the second idea above, and commented out line 1052 shown. Now as a kernel module, the device is presented to me as da0 at boot when already attached and running. Yay! Of course, my hack could be wrong, especially if instead I should have fudged the value of sbp_cold. I also added a debug line to indicate that (sbp_cold > 0) which you will see below, to show me what is happening. Here's the dmesg from a successful reboot (only sbp debug messages logged): [...] firewire0: on fwohci0 sbp0: on firewire0 sbp_attach (cold=1) fwohci0: Initiate bus reset fwohci0: fwphy_rddata: 0x1 loop=0, 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) [ 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' 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 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 sbp_cold is 1; setting status ATTACHED sbp0:0:0 sbp_cam_scan_target 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 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 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) Thanks, Barry Bouwsma From owner-freebsd-firewire@FreeBSD.ORG Mon Sep 29 21:04:25 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 4E2AB16A4B3 for ; Mon, 29 Sep 2003 21:04:25 -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 5E72643FF3 for ; Mon, 29 Sep 2003 21:04:23 -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 D0749378412 for ; Tue, 30 Sep 2003 13:04:20 +0900 (JST) Received: from mailhosting.itc.u-tokyo.ac.jp (IDENT:mirapoint@mailhosting.itc.u-tokyo.ac.jp [133.11.205.3]) h8U44DQj011943; Tue, 30 Sep 2003 13:04:13 +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 AKP87400; Tue, 30 Sep 2003 13:04:00 +0900 (JST) Date: Tue, 30 Sep 2003 13:04:00 +0900 Message-ID: From: Hidetoshi Shimokawa To: Barry Bouwsma In-Reply-To: <200309300307.h8U37PW12960@Mail.NOSPAM.DynDNS.dK> References: <200309152131.h8FLV2271240@Mail.NOSPAM.DynDNS.dK> <200309180452.h8I4qxS58023@Mail.NOSPAM.DynDNS.dK> <200309201256.h8KCusu53498@Mail.NOSPAM.DynDNS.dK> <200309300307.h8U37PW12960@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: (none) 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: Tue, 30 Sep 2003 04:04:25 -0000 At Tue, 30 Sep 2003 05:07:25 +0200 (CEST), Barry Bouwsma wrote: > What I am looking for, is that the firewire drive is made available > as da0 at boot, ideally with support in kernel modules instead of the > kernel proper, for unattended operation where a crash/reboot or power > failure is possible and I have no chance to correct things by hand. > This means, no unplug/re-plug, and no `fwcontrol' ... > > Now that I see that the recent 4.9-PRERELEASE codes support the drive > with no need for my hacks, apart from the observation that the drive > does not seem to be CAM-scanned at boot -- at least as a kernel module > with 4.5-era tools -- I'll see how things work with a kernel built > including firewire/sbp support, rather than modules. Did you chage SCSI_DELAY from the default 15sec? /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html