Re: [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache

From: Matthias Schwarzott <zzam@gentoo.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net,
	hirofumi@mail.parknet.co.jp
Subject: Re: [usb-storage] Re: Amazon Kindle disconnect after Synchronize Cache
Date: Thu, 11 Mar 2021 07:05:00 +0100	[thread overview]
Message-ID: <841a9a54-78ee-ffaa-fc3c-12defcf43b36@gentoo.org> (raw)
In-Reply-To: <20210310214648.GA236329@rowland.harvard.edu>

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