Comment 8 for bug 881688

Revision history for this message
Stefan Richter (stefan-r-ubz) wrote :

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).