-
-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
USB autosuspend problem: libusb_open returns LIBUSB_ERROR_IO #36
Comments
Hello, I will test your proposed change. Thanks. |
Fixed in abed9df I note that the reader you use is in the "Unsupported or partly supported CCID readers" list Maybe I moved the reader in the unsupported list because the power autosuspend does not work correctly. If I can find such a reader in my reader stock I will try to see if your proposed change make the reader works reliably. |
On my Debian stable system (Linux 4.9.0-3) the USB autosuspend is not enabled. I don't know why.
I also tried to set to "auto". In that case the reader is not suspended, even after 2 seconds. When a card is inserted the red LED is still switched on. When I use od(1) to access the USB device as you did in your example I can see a lot of reader disconect/connect using From your pcscd log I am not sure what your problem is. My interpretation is:
Is my interpretation exact? |
I'm using Arch Linux with the kernel 4.12.8-2, but I don't know if there is any
In my case, I can see both rules executed.
You can also see the default values for autosuspend in the
The device doesn't turn off, but the kernel sets the state to suspended. You can
The monitor loop shows:
The control is set to
The device has been suspended by the kernel, and the red LED is still on. But,
Now the device has a number 11, and after 2 seconds will be suspended again. You
Which, in my system, calls
Then you can see the
And the start of
Which finally calls
So by using
Now you can see the exact same kernel log:
In my case the reader also is usable, even with the You can test it by using a udev rule that sets the time for autosuspend to 0,
Then start the
No, I never need to remove the reader, the
Then in the second try, the
Yes, in conjuntion with my own rule, which overwrites the autosupend parameter, |
I played with my C3PO LTC3x USB reader to reproduce your issue.
So the previous USB device is disconnected and a new USB device is connected as can be seen in pcscd logs:
My interpretation was that you removed the device but it was in fact a reset/re-enumeration by the kernel. Summary:
Do you want me to change something in pcsc-lite and/or libccid? |
The device doesn't seem to work fine when resuming from suspension mode. By preventing autosuspension the device doesn't fail anymore. See github issue LudovicRousseau#36 "USB autosuspend problem: libusb_open returns LIBUSB_ERROR_IO" LudovicRousseau#36
Okay, thanks, that's what I meant. I don't know if you plan to support this buggy old device (and replaced by the v2). But I saw a per specific rule in 92_pcscd_ccid.rules with a special treatment for a Kobil mIDentity device. So maybe it will be useful to add another rule to keep this device from reseting. I created a pull request with the specific rule after the general one. |
OK. I will test your patch and apply it if it works as expected. |
Hello,
I have a C3PO LTC31 SmartCard Reader (0783:0003) which seems to work "fine" after the first error at
libusb_open
:Some investigation reveals that there is some problem with the autosuspend. After 2 seconds of inactivity, the device automatically suspends, as configured by the
power/autosupend
parameter:It can be observed that the state in
power/runtime_status
goes fromactive
tosuspended
.But then, when I try to read from the device, it doesn't respond, and a broken pipe (-EPIPE) error is produced:
From the Kernel documentation:
So it seems that the device doesn't support autosuspend. But the udev rule in 92_pcscd_ccid.rules forces the autosuspend parameter to "auto". Even if I try to overwrite the rule, by writing my own exception like:
It seems that the shell script in
92_pcscd_ccid.rules
, is executed after my own rule, enabling once again the autosuspend:By using the ATTR{power/control}="auto" command instead, it allows other rules to overwrite it's default behavior, (also tests that the file
power/control
exists):Then I can use my own rules to overwrite the autosuspend, and thus fix the problem with my device.
It may be useful to detect if a device allows suspension, and then enable autosuspend. But keeping by default the autosuspend disabled, as it may be somewhat difficult to diagnostic in bogus devices.
The text was updated successfully, but these errors were encountered: