Unable to access a firewire disk

Back at the time of around FreeBSD 7.x or 8.x I was a big fan of firewire disks, because they so much outperformed USB disks.
Now I found one of those data disks and wanted to mount it, in order to see what is on it. I studied firewire(4), fwohci(4), sbp(4) and the likes, and hooked up my external firewire enclosure expecting to see something like da0 showing up eventually. Instead, here is what showed up on my screen.
Code:
root@imac41:~ # pciconf -lv ...
fwohci0@pci0:4:3:0:     class=0x0c0010 rev=0x61 hdr=0x00 vendor=0x11c1 device=0x5811 subvendor=0x11c1 subdevice=0x5811
    vendor     = 'LSI Corporation'
    device     = 'FW322/323 [TrueFire] 1394a Controller'
    class      = serial bus
    subclass   = FireWire
root@imac41:~ # kldload firewire
bwi0: <Broadcom BCM4312 802.11a/b/g Wireless Lan> mem 0xc8100000-0xc8103fff irq 17 at device 0.0 on pci3
bwi0: BBP: id 0x4311, rev 0x1, pkg 0
bwi0: MAC: rev 10
bwi0: PHY: type 2, rev 8, ver 4
bwi0: RF: manu 0x17f, type 0x2050, rev 2
bwi_v3_ucode: could not load firmware image, error 2
bwi0: request firmware bwi_v3_ucode failed
device_attach: bwi0 attach returned 2
fwohci0: <Lucent FW322/323> mem 0xc8000000-0xc8000fff at device 3.0 on pci4
fwohci0: OHCI version 1.0 (ROM=0)
fwohci0: No. of Isochronous channels is 8.
fwohci0: EUI64 00:14:51:ff:fe:bb:76:80
fwohci0: Phy 1394a available S400, 3 ports.
fwohci0: Link S400, max_rec 2048 bytes.
firewire0: <IEEE1394(FireWire) bus> on fwohci0
fwohci0: Initiate bus reset
fwohci0: fwohci_intr_core: BUS reset
root@imac41:~ #
root@imac41:~ # kldload cam
kldload: can't load cam: module already loaded or in kernel
root@imac41:~ #
root@imac41:~ # kldload sbp
sbp0: <SBP-2/SCSI over FireWire> on firewire0
root@imac41:~ #
root@imac41:~ # ### This is when I plug-in and power-on the firewire disk ###
fwohci0: fwohci_intr_core: BUS reset
fwohci0: PhysicalUpperBound register is not implemented.  Physical memory access is limited to the first 4GB
fwohci0: PhysicalUpperBound = 0x00000000
fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=3, CYCLEMASTER mode
firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1)  (me)
firewire0: bus manager 1
fwohci0: fwohci_intr_core: BUS reset
fwohci0: PhysicalUpperBound register is not implemented.  Physical memory access is limited to the first 4GB
fwohci0: PhysicalUpperBound = 0x00000000
fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=4, CYCLEMASTER mode
firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1)  (me)
firewire0: bus manager 1
fwohci0: too many cycles lost, no cycle master present?

There is no da0, and camcontrol devlist shows only my SATA disk.
Did I do something wrong?
 
Since camcontrol devlist shows only my SATA disk, there is no device id to refer camcontrol to. :-(
 
The answers from fernandel and trev suggests that this is not an issue with the firewire subsystem being broken, nor it is a compatibility problem with my particular external drive or the disk in that box.
So I moved the external disk to a generic PC I had access to, which I equipped with a x1 PCIe Firewire-800 add-in card. Booted the FreeBSD-13.0-Release installer memstick and escaped to a shell. I also needed a FW800-to-FW400 cable. Here is what happened, using the same external disk that failed to show up as da0 before.

Code:
HP 8300 Elite CMT with PCIe x1 Firewire-800 add-in card.
FreeBSD 13.0-Release/amd64 (same on i386, and 12.x too)

# pciconf -lv | ...
fwohci0@pci0:3:0:0:     class=0x0c0010 rev=0x01 hdr=0x00 vendor=0x104c device=0x823f subvendor=0x3412 subdevice=0x7856
    vendor     = 'Texas Instruments'
    device     = 'XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express]'
    class      = serial bus
    subclass   = FireWire

#
# kldload firewire
fwohci0: <1394 Open Host Controller Interface> mem 0xf7c04000-0xf7c047ff,0xf7c00000-0xf7c03fff irq 16 at device 0.0 on pci3
fwohci0: OHCI version 1.10 (ROM=1)
fwohci0: No. of Isochronous channels is 8.
fwohci0: EUI64 78:56:34:12:78:56:34:12
fwohci0: invalid speed 7 (fixed to 3).
fwohci0: Phy 1394a available S800, 3 ports.
fwohci0: Link S800, max_rec 4096 bytes.
fwohci0: phy int
firewire0: <IEEE1394(FireWire) bus> on fwohci0
fwohci0: Initiate bus reset
fwohci0: fwohci_intr_core: BUS reset
fwohci0: PhysicalUpperBound register is not implemented.  Physical memory access is limited to the first 4GB
fwohci0: PhysicalUpperBound = 0x00000000
fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode
firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0)  (me)
firewire0: bus manager 0

# kldload cam
kldload: can't load cam: module already loaded or in kernel

# kldload sbp
sbp0: <SBP-2/SCSI over FireWire> on firewire0

#   ## Here is when I connect and turn-on the external firewire disk ...
fwohci0: fwohci_intr_core: BUS reset
fwohci0: PhysicalUpperBound register is not implemented.  Physical memory access is limited to the first 4GB
fwohci0: PhysicalUpperBound = 0x00000000
fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=3, CYCLEMASTER mode
firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1)  (me)
firewire0: bus manager 1
fwohci0: fwohci_intr_core: BUS reset
fwohci0: PhysicalUpperBound register is not implemented.  Physical memory access is limited to the first 4GB
fwohci0: PhysicalUpperBound = 0x00000000
fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=4, CYCLEMASTER mode
firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1)  (me)
firewire0: bus manager 1
firewire0: fw_explore_node: fwdev->speed(S800) decremented due to negotiation
sbp0: sbp_show_sdev_info: sbp0:0:0: ordered:1 type:14 EUI:0030e002e0454647 node:0 speed:2 maxrec:8
sbp0: sbp_show_sdev_info: sbp0:0:0 'OEM' 'OEM ATA Device 00' '000110'
da1 at sbp0 bus 0 scbus4 target 0 lun 0
da1: <OEM OEM ATA Device 0 0110> Fixed Direct Access SPC-2 SCSI device
da1: Serial Number
da1: 50.000MB/s transfers
da1: 239372MB (490234752 512 byte

# exit

So, in this machine, using this firewire controller, everything worked fine as expected.
My suspicion is that what trev bug-reported and what I experienced earlier, is caused by the kind of firewire controller found integrated on these Apple Macs. I am going to add these findings to trev's bug-report. Hopefully support for these firewire controllers can be added to the FreeBSD codebase. This would be particularly interesting in the PPC architecture, as G4 and G5 processor based Macs can still be made useful by running a recent release of FreeBSD/PPC. But equally apply to later model, Intel processor based Macs too.
 
Didn't know Firewire is still a thing.

but as time goes on and USB gets ever better, and wireless, we'll see the eventual demise of FireWire. At the very least, it's on the verge of obsolescence.
 
Didn't know Firewire is still a thing.
That is very likely because it isn't.
Although it was(/is) far more reliable and faster than USB (at the time of FireWire-400 with its actual near 400Mbps, compared to the 480Mbps theoretical limit of USB 2.0), the technology was more complex and more expensive. Most computer users did not need that, and went in favour of the cheap USB. And the market defined the fate of the technology.
The same is happening with Thunderbolt and USB 3.0/3.1/3.2. Even though Thunderbolt is far better, it is only paid for by those very few who really need the services and quality built around it. The masses will be happy with USB 3, which will be mass-produced at a price dirt-cheap (compared to Thunderbolt), so shops will not find it worthwhile to offer Thunderbolt product, thus manufacturers will not find it a good business to produce Thunderbolt products, and then it will be gone.
 
I agree with eternal_noob because I have to used my drive on iMac 11,1 with FreeBSD 2 and 13 but than I swithed to Lenovo Thinkpad 495 which doesn't have firewire port but my drive has also USB and speed on laptop is very good.
 
FireWire is an excellent standard that nobody wanted to pay the licensing fees or the extra 25 cents in silicon for. Thunderbolt is just PCIe on a wire. Both are highly efficient data transfer standards compared to USB's patchwork of nonsense. There's always going to be a demand for this kind of standard, just not as much as USB.

In re FireWire being broken on the Mac, unfortunately I have seen roadmaps where FireWire is slated for removal from the kernel. Even if you find where the bug is, there may be no developer around willing to fix it.
 
I know this is an old thread, but I was able to solve a similar problem today. I had a drive that was connected via a write blocker device through firewire. I wanted to access it from a LiveCD read-only boot.

To activate the firewire, kldload sbp
With firewire activated, you should be able to see the base device via geom disk list
To find the missing zpools, go hunting for partitions. Try to read the partitions zdb -l /dev/DEVICE or zdb -l /dev/DEVICE_WITH_PARTITION_NUMBER
To try to load up a zpool, try one of the partitions found zpool import -d /dev/DEVICE_WITH_PARTITION_NUMBER
The responding zpool message will probably indicate the pool name if you haven't seen it already. You can use that pool name for a second pass at zpool. Like: zpool import -d /dev/DEVICE_WITH_PARTITION_NUMBER -f POOL_NAME

Using this technique, I was able to mount the ZFS drive over firewire through a write blocker.

REF: https://serverfault.com/questions/585228/zfs-import-unable-to-find-any-pools
 
Back
Top