Hi,

On 3/16/21 6:04 PM, Alan Stern wrote:

On Tue, Mar 16, 2021 at 05:43:34PM +0100, Hans de Goede wrote:

quoted

Hi,

On 3/16/21 5:26 PM, Alan Stern wrote:

quoted

On Tue, Mar 16, 2021 at 06:26:30AM +0100, Matthias Schwarzott wrote:

quoted

I implemented solution 3b. This is the pullrequest for udev (systemd
repository):

	https://github.com/systemd/systemd/pull/19002

Now Lennart asks if udev is the best place for such hacks/work-arounds?

Well, I implemented it as suggested by Alan (see above). This was the
simplest of the considered alternatives. Different quirks in kernel has been
considered, but are more effort to be implemented.

Lennart probably isn't aware how the usb-storage driver works.  It does 
not create commands on its own; it merely sends the commands that it 
gets from higher SCSI layers.

It may be possible to modify the SCSI core, to make it send a TEST UNIT 
READY command immediately following any SYNCHRONIZE CACHE to a Kindle.

However, there may be an easier solution.  usb-storage does indeed send 
a command of its own, REQUEST SENSE, to get error data when a command 
fails.  The patch below will make it do the same thing whenever it sends 
a SYNCHRONIZE CACHE to a Kindle, failure or not.

The only question is whether the Kindle will regard REQUEST SENSE as a 
sufficient indication that it shouldn't do an eject.  The only way to 
find out is by testing the patch.

Alan Stern

Thank you for this patch, yes if this works it would IMHO be
a much better solution then the udev rule.

I think it would be mildly better, but not a whole lot.  Since the 
Kindle describes itself as having removable media, the kernel normally 
probes it periodically to make sure the media remains present.  The 
default probing interval is 2 seconds.  Reducing it to 0.9 seconds 
doesn't represent an exorbitant additional load IMO -- especially since 
Kindles don't tend to spend huge amounts of time connected to computers.

Ah, I did not know that the default polling interval was that low(ish),
given that the default indeed is already that low, then changing it to
0.8 seconds would not be a big change.  And we probably have a lot of
lower hanging fruit for unnecessary wakeups then that.

Regards,

Hans