Okay, maybe a little less strange: Only one of the two disks seems to be affected, and swiotlb=131072 does not actually help. Summarized: There's two USB 3 disks with same size, swapping cables does not do anything, plugging the bad disk into a USB 2 port does not help. Writing much data through cryptsetup onto the bad disk locks up the computer, all other combinations do not, in particular: 1) Writing much data to the bad disk without cryptsetup. 2) Writing much data to the other disk, with or without cryptsetup. Sorry for the wrong conclusions in the last email. -------- Forwarded Message -------- Subject: Re: Computer locking up on heavy disk IO Date: Wed, 2 Aug 2017 00:19:38 +0200 From: heinrich5991@xxxxxxxxx To: dm-crypt@xxxxxxxx On 08/01/17 22:47, Michael Kjörling wrote: > On 1 Aug 2017 22:22 +0200, from heinrich5991@xxxxxxxxx: >> Aug 01 22:05:27 kernel: ata_piix 0000:00:1f.2: swiotlb buffer is full (sz: 61440 bytes) >> Aug 01 22:05:27 kernel: ata_piix 0000:00:1f.2: DMA: Out of SW-IOMMU space for 61440 bytes > > I think that's the key. Don't know why it'd only affect usage through > dm-crypt, though. > > [1] isn't about the exact same issue (that's someone getting very > similar errors with a network card) but suggests booting with > iommu=force or even iommu=off causes the errors to go away. It'll > likely kill performance, but it seems like a good test. If the system > is stable with such a configuration, one might expect that the drive > itself doesn't have any problems with the usage. iommu=force seems to keep similar issues, i.e. I still see error messages like that in dmesg when performing a lot of disk IO through a device mounted by cryptsetup. iommu=off stops the computer from booting, displaying a lot of disk errors instead. > Also, there seem to be lots of reports that this happens with kernels > 3.8.0 and newer, but that 3.7.x and earlier don't exhibit the same > problem and [2] says a fix for another similar issue may be in 3.8.3 > or possibly (as per [3]) 3.8.4. Which of course prompts the question: > what kernel version are you running? And while you're at it, you might > also tell us which cryptsetup version you're running; while I really > doubt this is cryptsetup related, that piece of information can hardly > hurt. $ uname -a Linux <hostname> 4.11.9-1-ARCH #1 SMP PREEMPT Wed Jul 5 18:23:08 CEST 2017 x86_64 GNU/Linux $ cryptsetup --version cryptsetup 1.7.5 > And [4] suggests increasing the swiotlb size using the swiotlb=N > kernel parameter, where N apparently is the number of 2 KiB blocks to > allocate (65536 for 128 MB, 131072 for 256 MB). That feels like a > stopgap measure, though, even more so than disabling IOMMU, but if all > else fails... Unfortunately, it's exactly this "stopgap measure" that apparantly makes the issue go away completely. I set swiotlb=131072 and afterwards, the pv /dev/zero > /dev/mapper/dbX_wipe worked without problems. > [1]: https://bbs.archlinux.org/viewtopic.php?pid=650269#p650269 > > [2]: https://forum.siduction.org/index.php?topic=3272.msg27986#msg27986 > > [3]: https://forum.siduction.org/index.php?topic=3272.msg28451#msg28451 > > [4]: https://www.spinics.net/lists/linux-ide/msg25119.html > Thank you for your help so far! :) _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
