Date: Tue, 30 Sep 2003 05:07:25 +0200 (CEST) From: Barry Bouwsma <freebsd-misuser@remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> To: FreeBSD Firewire Developers <firewire@freebsd.org> Cc: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> Subject: Re: Ext. firewire disk disconnection and persistence of da* entry... Message-ID: <200309300307.h8U37PW12960@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> <ybsn0cxpnjx.wl@ett.sat.t.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
[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: <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=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: <Maxtor 5000XT v1.00.00 0000> 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: <Maxtor 5000XT v1.00.00 0000> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200309300307.h8U37PW12960>