Re: Computer locking up on heavy disk IO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux