Known Bugs & Limitations in libforensic1394
Introduction
libforensic1394 is a thin wrapper around the platforms native IEEE
1394 stack. As a consequence of this the vast majority of bugs can
be traced back to either faults in the underlying 1394 stack or to
hardware misconfiguration/incompatibility. Where the 1394 stack is
believed to be at fault bug reports have been filed with the
relevant parties.
Platform Agnostic Issues
Timeout required after adding an SBP-2 unit directory
After adding an SBP-2 unit directory to a bus it is necessary to
wait for ~2 seconds before attempting to read/write from a device
on the bus. This is required in order to give devices on the bus
time to respond to the presence of such a directory. (The usual
course of action being to bring down the physical request filter.)
While there are provisions in the specification to determine
precisely when a device has brought down its physical request
filter limitations in Linux/Juju stack pre-2.6.36 prevent
user-space applications from leveraging this.
Multiple SBP-2 unit directories can be added to a bus
Should two or more applications, each using libforensic1394,
enable SBP-2 support then it is possible that multiple SBP-2 unit
directories will appear in the ROM of the host.
As the presence of multiple directories is harmless there are no
plans to prevent such a situation from occurring. Moreover, the
design of modern 1394 stacks would make enforcing the presence of
only one such directory extremely difficult.
Linux/Juju Specific Issues
Asynchronous requests considered harmful
The Juju stack contains one or more race conditions that can
result in kernel-mode GPFs (“General Protection Faults”) when
asynchronous requests are used. Such faults nearly always result
in a kernel panic. The probability of such a fault has found to
depend on both the make/model of the OHCI and the number of
asynchronous requests.
libforensic1394 currently works around this issue by disabling
asynchronous requests under Linux/Juju. This is done by defining
REQUEST_PIPELINE_SZ to be 1 in linux/juju.c.
Further information can be found in the following report:
https://bugzilla.kernel.org/show_bug.cgi?id=18292
Spurious warnings when firewire-sbp2 is loaded
When the firewire-sbp2 module is loaded into the kernel use of
libforensic1394 may result in kernel messages along the lines of:
firewire_sbp2: fw0.0: orb reply timed out, rcode=0x11
If an SBP-2 unit directory is added to the CSR of a local port
the firewire-sbp2 driver is notified and treats it as if it were a
bona fide SBP-2 device. However, since libforensic1394 does not
implement any of the SBP-2 specification the requests from the
driver time out. This causes various warnings to be
generated. Although the presence of the firewire-sbp2 module is
not believed to be harmful the messages can be supressed by
removing it prior to using libforensic1394:
modprobe -r firewire_sbp2
Mac OS X Specific Issues
Opening and closing a device multiple times
Attempting to open a device which has already been opened/closed
can result in a kernel panic. Although the precise cause is
unknown it is believed to be related to several other kernel
panics in the Apple FireWire stack.
Should an application need to open/close a device multiple times
it should do so by re-requesting the device list each time.
Occasional kernel panics under high-load
Under high-load conditions some kernel panics have been observed.
The resulting stack trace is identical to that which can occur
when attempting to open a previously closed device.
Little is known about the precise cause of the problem however it
is believed to be related to the use of asynchronous requests. If
this is the case it may become necessary to disable the use of
asynchronous requests under Mac OS X.
Incomplete CSR for attached devices
There exist some issues with regards to getting the Configuration
Status ROM which can result in the ROM being truncated. The cause
of this is currently unknown; however, it is observed in other
FireWire applications (such as IORegistryExplorer) and hence is
believed to be an IOKit problem.
While this is not normally an issue (the crucial components of the
CSR, such as the GUID, have always been present) applications
which require the complete ROM can read it manually from the
device. The relevant offsets for performing such a read can be
found in csr.h.
Windows targets report Mac OS X hosts as an unidentified device
When connecting a Mac OS X host to an unlocked Windows target the
“New Hardware Wizard” may appear. This is because Mac OS X
advertises support for IPv6 over 1394 (RFC 3146) — a protocol
which Windows does not recognise. This manifests itself as an
“Unknown Device” in the device manager with a hardware ID of
`1394\5E&2`. Although not harmful (libforensic1394 will still
function as expected) it is something of a nuisance. One
workaround to this is to unload the `IOFireWireIP.kext` kernel
module to prevent OS X from advertising support for IPv[4,6] over
1394:
$ sudo kextunload /System/Library/Extensions/IOFireWireIP.kext
It is important to run this before any FireWire devices are
connected to the system. Connecting a device will cause the
retain count for the module to be incremented; making it difficult
to unload the module until the system is restarted. If later
required the module can be reloaded by issuing:
$ sudo kextload /System/Library/Extensions/IOFireWireIP.kext
As Linux/Juju only supports IPv4 over 1394 it is unaffected. (All
recent Windows versions either support IPv4 over 1394 or are
capable of filtering it from the device list.)