What FireWire target devices did you test? According to the first 3 bytes of the GUID (this part is the OUI), it is a device from Buffalo, Inc.
Observations about CurrentDmesg.txt from comment 1:
- There is no message along the lines of "PM: resume of
drv:firewire_ohci dev:0000:09:00.0 complete after ...msecs".
Should there be such a message?
- There is no "Register access failure".
- After PM resume, self ID receive DMA, AT-req DMA, and AR-resp DMA
work fine, which is evident by "rediscovered device fw1" from
firewire-core.
- Ditto, physical DMA and AR-req DMA work, since firewire-sbp2
receives an SBP-2 reconnect status block and six pairs of SBP-2
login and logout status blocks from the target.
So, to me it looks unlikely that there is a controller problem.
More likely to me is that the target firmware is crap since it refuses re-login. The status codes mean:
- Received for the reconnect request ORB:
0:9 = Request complete. Function rejected.
- Received for each logout and login request ORB:
0:4 = Request complete. Access denied.
Of course, there /still/ could be a controller problem because perhaps the physical DMA delivered malformed reconnect or logout or login ORBs to the target. But I think this is highly unlikely.
So far, I don't know what to make of this information.
I was thinking about asking for a debug log with "firewire-ohci debug=3" (logging of AT, AR, and self-ID-R DMA interrupt events), but that would show only a fraction of the picture since most of the SBP-2 communication occurs without CPU interrupts by means of OHCI-1394 physical DMA (something like remote DMA).
What FireWire target devices did you test? According to the first 3 bytes of the GUID (this part is the OUI), it is a device from Buffalo, Inc.
Observations about CurrentDmesg.txt from comment 1:
- There is no message along the lines of "PM: resume of firewire_ ohci dev:0000:09:00.0 complete after ...msecs".
drv:
Should there be such a message?
- There is no "Register access failure".
- After PM resume, self ID receive DMA, AT-req DMA, and AR-resp DMA
work fine, which is evident by "rediscovered device fw1" from
firewire-core.
- Ditto, physical DMA and AR-req DMA work, since firewire-sbp2
receives an SBP-2 reconnect status block and six pairs of SBP-2
login and logout status blocks from the target.
So, to me it looks unlikely that there is a controller problem.
More likely to me is that the target firmware is crap since it refuses re-login. The status codes mean:
- Received for the reconnect request ORB:
0:9 = Request complete. Function rejected.
- Received for each logout and login request ORB:
0:4 = Request complete. Access denied.
Of course, there /still/ could be a controller problem because perhaps the physical DMA delivered malformed reconnect or logout or login ORBs to the target. But I think this is highly unlikely.
So far, I don't know what to make of this information.
I was thinking about asking for a debug log with "firewire-ohci debug=3" (logging of AT, AR, and self-ID-R DMA interrupt events), but that would show only a fraction of the picture since most of the SBP-2 communication occurs without CPU interrupts by means of OHCI-1394 physical DMA (something like remote DMA).