Am 10.03.21 um 22:46 schrieb Alan Stern:

On Wed, Mar 10, 2021 at 09:56:04PM +0100, Matthias Schwarzott wrote:

quoted

quoted

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