2014/1/17 Johannes Stezenbach <js@xxxxxxxxx>: > I cannot reproduce the issue, just finished my weekly backup > to LUKS USB3 disk with unpatched linux-3.12.7. It seems the > patches are awaiting feedback before the can go to stable, > since you seem to be able to reproduce it easily it would be > cool if you could test. Maybe test with the first patch > only to see if it fixes the endless error loop, then confirm > the second patch fixes the error. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733907#25 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733826#69 Hi Johannes, during the debugging process, I happen to figure out why you cannot re-produce the bug - The bug only hits when you write directly to the mapped LUKS block device, id est `mkfs` or `dd` against /dev/mapper/luks-foo. In my tests, writing directly to the mapped LUKS block device will trigger the bug (as I wrote in previous mails - crazy loop of error messages). However, if I write into a mounted ext4 on that device, the bug will not hit. I did not test with other filesystems, but ext4 seems able to do some "sorting", avoiding this bug from happening. The patches, they both do their jobs: the first does not fix the bug but "Too many fragments" error messages are limited to just one line. The second patch does fix the bug, great. I can see it changes two more lines in xhci.c. What's its advantage over just changing "64" to "256" in xhci.h (suggestion by David, which works as well)? I've attached the dmesg output when writing to LUKS mapped device under kernel patched with first patch. We can see there is now only one line of "Too many fragements" error, and the writing process does not lock up. It just failed and exited happily. After applying the second patch, everything works fine, no more error messages, no more lock-ups, and the data just get to the place. I did not try applying two patches at the same time, because it's late in my timezone... Good night. -- Sascha Weaver
Attachment:
xhci-patched-1.dmesg
Description: Binary data
