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

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.

If it's merely a question of where to change the polling interval from 
the default (automatically in the kernel or by userspace), that also 
doesn't seem like a terribly important choice.  Certainly a udev rule or 
hwdb entry is a lot easier to maintain than special-case code in the 
kernel.

One question though, if this works to fix the undesired ejects,
will an actual eject (using e.g. the eject utility as say
"sudo eject /dev/sda") still be seen as an eject by the kindle
after this ?

It should be.  Maybe Matthias will try it and let us know.

Because that is actually kind of important for everyone using their
Kindle with Calibre, breaking that would not be good.

Of course.

Alan Stern