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: >> 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. 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
