|Barry Bouwsma||Sep 15, 2003 2:31 pm|
|Hidetoshi Shimokawa||Sep 16, 2003 8:29 am|
|Barry Bouwsma||Sep 17, 2003 10:09 pm|
|Barry Bouwsma||Sep 20, 2003 6:00 am|
|Hidetoshi Shimokawa||Sep 21, 2003 7:25 pm|
|Barry Bouwsma||Sep 29, 2003 8:26 pm|
|Hidetoshi Shimokawa||Sep 29, 2003 9:04 pm|
|Barry Bouwsma||Nov 4, 2003 8:50 pm|
|Subject:||Ext. firewire disk disconnection and persistence of da* entry...|
|From:||Hidetoshi Shimokawa (simo...@sat.t.u-tokyo.ac.jp)|
|Date:||Sep 21, 2003 7:25:21 pm|
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...