From: Christian Melki <christian.melki@t2data.com>
To: <linux-kernel@vger.kernel.org>
Cc: <konrad.wilk@oracle.com>
Subject: SWIOTLB on 32-bit PAE
Date: Mon, 5 Oct 2015 10:31:39 +0200 [thread overview]
Message-ID: <5612356B.7070301@t2data.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]
Hi,
I discovered that my 32-bit PAE 4.2.0 kernel (no IOMMU code) would hang
when writing to my USB disk. The kernel spews million(-ish messages per
sec) to syslog, effectively "hanging" userspace with my kernel.
Oct 2 14:33:06 voodoochild kernel: [ 223.287447] nommu_map_sg:
overflow 25dcac000+1024 of device mask ffffffff
Oct 2 14:33:06 voodoochild kernel: [ 223.287448] nommu_map_sg:
overflow 25dcac000+1024 of device mask ffffffff
Oct 2 14:33:06 voodoochild kernel: [ 223.287449] nommu_map_sg:
overflow 25dcac000+1024 of device mask ffffffff
... etc ...
In my kernel config I noticed that SWIOTLB was not on. It seems SWIOTLB
is provided for 64-bit and 32-bit with IOMMU/AGPGART code. But if I
compiled the kernel with PAE and no IOMMU and no other GART code, I
would not get SWIOTLB. I'd like to think that SWIOTLB should be selected
for 32-bit PAE as default.
I have attached a oneliner patch which does that.
The patch works for me. The issue where the kernel more or less runs
endless bashing of (nommu_?)map_sg when failing is another problem I
guess. I expected the kernel/drivers to have some more graceful
handling, but I know to little about this area to have a proper opinion.
Regards,
Christian
[-- Attachment #2: swiotlb.patch --]
[-- Type: text/x-patch, Size: 481 bytes --]
diff -urN linux-4.2.orig/arch/x86/Kconfig linux-4.2/arch/x86/Kconfig
--- linux-4.2.orig/arch/x86/Kconfig 2015-10-05 08:56:58.933313678 +0200
+++ linux-4.2/arch/x86/Kconfig 2015-10-05 09:00:00.916306025 +0200
@@ -1282,6 +1282,7 @@
config X86_PAE
bool "PAE (Physical Address Extension) Support"
depends on X86_32 && !HIGHMEM4G
+ select SWIOTLB
---help---
PAE is required for NX support, and furthermore enables
larger swapspace support for non-overcommit purposes. It
next reply other threads:[~2015-10-05 8:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 8:31 Christian Melki [this message]
[not found] ` <561254A7.4000805@t2data.com>
2015-10-05 14:21 ` Fwd: SWIOTLB on 32-bit PAE Konrad Rzeszutek Wilk
2015-10-05 15:31 ` Christian Melki
2015-10-07 19:45 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5612356B.7070301@t2data.com \
--to=christian.melki@t2data.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).