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: > > On Tue, Mar 16, 2021 at 06:26:30AM +0100, Matthias Schwarzott wrote: > >> 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