Am 10.03.21 um 22:46 schrieb Alan Stern:
On Wed, Mar 10, 2021 at 09:56:04PM +0100, Matthias Schwarzott wrote:
What happens if you set the value to 1000 before running the test?
I tested different values. At 1000 it still disconnects. At lower values it
no longer does this.
I tested 200 up to 900. Even 900 ms is good enough to keep it connected.
Btw. it is not a USB disconnect, but it just seems to plays medium ejected.
Out of interest I called "sg_start -v -l /dev/sde" after one of the failing
experiments. That made the Kindle go back to connected state.
To me the above experiments show that enough TEST UNIT READY commands are
needed in the 2 s after a SYNCHRONIZE CACHE.
So you have found the solution to your problem. Congratulations!
Thank you for your support.
For longterm I think it should work automatically.
Some options I can think of (ordered by my preference):
1. Kernel sends one or more TEST UNIT READY commands after every
SYNCHRONIZE CACHE to a Kindle device. Regardless of triggered by kernel
or by some user code via ioctl.
2. Kernel automatically chooses a low enough value for events_poll_msecs
if it detects kindle.
3. udev rule is added that matches the Kindle and sets events_poll_msecs.
3a) SUBSYSTEM=="block", ACTION=="add", ENV{DEVTYPE}=="disk",
ATTRS{product}=="Amazon Kindle", ATTR{events_poll_msecs}="900"
3b) SUBSYSTEM=="block", ACTION=="add", ENV{DEVTYPE}=="disk",
ATTRS{idVendor}=="1949", ATTRS{idProduct}=="0004",
ATTR{events_poll_msecs}="900"
4. Kernel sends one or more TEST UNIT READY commands after every
SYNCHRONIZE CACHE to a device (without matching).
I guess options 1 and 2 require a new entry in unusual_devs together
with a (new?) quirk.
Option 3 requires to get a new rule into udev.
And option 4 is ugly as it changes behaviour for usb-storage or scsi
disk device.
I would prefer option 1 or 2.
Do you know how high the overhead of having more TEST UNIT READY
commands is? (=How much better option 1 is compared to option 2?)
Matthias
