Bug 90631
| Summary: | FireWire Compact Flash card reader unable to handle card change (error status: 0:9 failed to reconnect; or sbp2_scsi_abort) | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Chris Murphy (bugzilla) |
| Component: | IEEE1394 | Assignee: | drivers_ieee1394 |
| Status: | NEW --- | ||
| Severity: | normal | CC: | stefanr |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.18.1-2.fc22.x86_64 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg
lspci journal-3.18.1.txt journal-3.11.10.txt |
||
|
Description
Chris Murphy
2015-01-02 18:37:18 UTC
Created attachment 162331 [details]
dmesg
Created attachment 162341 [details]
lspci
lspci -vvnn (firewire excerpt)
Created attachment 162351 [details]
journal-3.18.1.txt
Reboot with 3.18.1, used journalctl -o short-monotonic -f (attached) while making notes of what I'm doing related to monotonic time. The line numbers below are monotonic time, and apply only to this attached journal.
295 plug-in CF card reader with CF card already in it
335 eject CF card icon in Nautilus
357 physically remove CF card from reader, the reader is still plugged into the FW port
387 insert CF card (Nautilus finds and mounts it)
445 eject CF card in Nautilus
453 physically remove CF card from reader, again reader itself remains connected
461 insert CF card (this time it does not appear in Nautilus) no further user action taken from this point on, I literally walked away from the computer for 10+ minutes.
Created attachment 162361 [details]
journal-3.11.10.txt
Similar results with kernel 3.11.10-300.fc20.x86_64.
According to the GUID of your card reader, it is made by DataFab. I have a different 1394b CF reader (hama Traveldrive CF IEEE 1394b) with which I cannot reproduce the issue, unfortunately. [The hama reader behaves in the following manner: While no card is inserted, all requests are responded to with RCODE_BUSY. When a card is inserted, the reader generates a bus reset, then begins to respond normally. When the card is pulled out, the reader generates a bus reset and returns to respond with RCODE_BUSY again. And so on. This works reasonably well with the Linux driver stack, provided that one waits long enough between removing one card and inserting another different card: The "busy" period needs to be long enough to cause firewire-core to shut down the SBP-2 unit before the next card is inserted.] Regarding your comment 3 (attachment 162351 [details]): Do I understand correctly that the desirable behavior (detect an exchange of cards while the reader remains plugged in) actually worked from 357 to 387, but failed from 453 to 461? If my understanding is correct, do you have a suggestion what was different between the exchange at 357--387 and the one at 453--461? (In reply to Stefan Richter from comment #5) > According to the GUID of your card reader, it is made by DataFab. > > I have a different 1394b CF reader (hama Traveldrive CF IEEE 1394b) with > which I cannot reproduce the issue, unfortunately. > > [The hama reader behaves in the following manner: While no card is > inserted, all requests are responded to with RCODE_BUSY. When a card is > inserted, the reader generates a bus reset, then begins to respond normally. > When the card is pulled out, the reader generates a bus reset and returns to > respond with RCODE_BUSY again. And so on. This works reasonably well with > the Linux driver stack, provided that one waits long enough between removing > one card and inserting another different card: The "busy" period needs to > be long enough to cause firewire-core to shut down the SBP-2 unit before the > next card is inserted.] > > Regarding your comment 3 (attachment 162351 [details]): Do I understand > correctly that the desirable behavior (detect an exchange of cards while the > reader remains plugged in) actually worked from 357 to 387, but failed from > 453 to 461? If my understanding is correct, do you have a suggestion what > was different between the exchange at 357--387 and the one at 453--461? In order: Yes. No. It seems non-deterministic, but mainly it fails and I have to completely disconnect the reader. Reader is a Lexar RW019 Rev B. The same behavior is never reproducible on OS X, i.e. it always works as expected. So I don't know if it's the card reader itself, or maybe something with the particular FireWire hardware in this system that Apple knows something about that we don't know. Please attach /sys/bus/firewire/devices/fw1/config_rom. (This is a binary file. If you prefer you can convert it into an annotated hexdump with a python script called "crpp" from http://me.in-berlin.de/~s5r6/linux1394/utils/, but I can do that conversion too.) Also, when your time permits, please create another kernel log after enabling self-ID packet logging: $ sudo dd of=/sys/module/firewire_ohci/parameters/debug <<< 2 This is supposed to add lines similar to the following ones to the kernel log whenever the FireWire bus is reset: firewire_ohci 0000:12:03.0: 2 selfIDs, generation 12, local node ID ffc1 firewire_ohci 0000:12:03.0: selfID 0: 807f8f80, phy 0 [p..] S400 gc=63 -3..-10W Lc firewire_ohci 0000:12:03.0: selfID 0: 817f8cd2, phy 1 [c-.] S400 gc=63 -3W Lci Best would be such a debug log with incidences not only of unsuccessful card replugs, but also with one or another of the rare successful replugs. |