Opening Kindle devices in Calibre will cause a disconnect from Linux LTS 4.19.51+ onwards

Bug #1834641 reported by cryzed on 2019-06-28
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
calibre
Undecided
Unassigned

Bug Description

Please check this issue here: https://bugzilla.kernel.org/show_bug.cgi?id=203973

To summarize, a change to the VFAT handling in the Linux kernel introduced in 4.19.51 for the Linux LTS release (I'm not sure in which version it was introduced in the mainline kernel), will cause the Kindle to disconnect when issuing a sync. In practice this means when "opening" the Kindle in Calibre and inspecting the files, this sync command will be issued and the Kindle will immediately disconnect, effectively preventing usage with Calibre. I've had this issue for a few Linux releases now and finally realized that it was a change in the Kernel -- I'm not sure why more people aren't reporting this.

As suggested by Ogawa Hirofumi, you might want to contact the UDisk developers and request the "nobarrier" option to be put on the whitelist, so Calibre can request this option when mounting the device to prevent this behavior.

cryzed (cryzed) on 2019-06-28
summary: Opening Kindle devices in Calibre will cause a disconnect from Linux LTS
- 4.19.50+ onwards
+ 4.19.51+ onwards

I use Linux as my daily driver with a Kindle PaperWhite, running
kernel 5.1.9 and see no disconnects. The analysis in that bug report
makes no sense.

1) nobarrier is a really bad idea, it means applications cannot rely on
fsync() anymore, so there is no way to guarantee that data is actually
written to the disk. In particular this means you *have* to unmount the
disk before disconnecting the cable. And any database or similar software
running on a nobarrier fs will lead to data corruption.

2) If nobarrier is indeed the only way forward (which I highly doubt,
but...) then it should be done system wide. Otherwise depending on
whether the device is mounted by calibre or something else, you will get
different behavior, which is just chaos.

Since no one else has reported this issue and I cannot replicate it
either, I am guessing it is something specific to your system. I suggest
trying to update your Kindle firmware to the latest, also (although I
dont think this should matter) try a different USB cable and port (for
instance USB 2 vs 3 or a different USB hub).

cryzed (cryzed) wrote :

I did change the USB cables already, and also the ports, even the devices (Voyage). I'm not sure what else it could be at this point. I'm using Arch Linux up-to-date with KDE Plasma (if a DE-specific mounting mechanism is somehow relevant, although I think it's just UDisk, really). The Kindle (Kindle Oasis 2) is updated to the latest firmware as well.

cryzed (cryzed) wrote :

To elaborate slightly, all the cables/ports are working perfectly fine in 4.19.50, but not in 4.19.51.

cryzed (cryzed) wrote :

Your kernel is too old: the next version 5.1.10 will introduce this change. Maybe test that one first?

Kovid Goyal (kovid) wrote :

Well when I have a moment, I will upgrade the kernel and try.

Kovid Goyal (kovid) wrote :

And if the bug is indeed that a FSYNC followed by no activity causes the
Kindle to disconnect, then the fix is simple, the kernel should ensure
it sends some harmless keep-alive type command after the FSYNC. Hell, if
that is indeed the case, then I can probably have calibre touch a file
on the device after every fsync to work around this issue. nobarrier is
not going to happen however.

cryzed (cryzed) wrote :

Yes, don't misunderstand me, I'm not some advocate of nobarrier -- I simply want to use Calibre because I love it, and unfortunately it has stopped working for me. Whatever solution you come up with -- as long as it works -- is totally fine with me. I realize the drawbacks of nobarrier.

Fixed in branch master. The fix will be in the next release. calibre is usually released every alternate Friday.

 status fixreleased

Changed in calibre:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers