From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752614AbbJEPbh (ORCPT ); Mon, 5 Oct 2015 11:31:37 -0400 Received: from smtp208.stejtech.net ([213.136.34.158]:46865 "EHLO smtp208-outgoing.stejtech.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752133AbbJEPbf (ORCPT ); Mon, 5 Oct 2015 11:31:35 -0400 X-Spam-STAY-ID: v=2.0 cv=a8iyBDuF c=1 sm=0 a=uTPAfcG8vWn8BZzD3w/9vw==:17 a=oxFPtraXAAAA:8 a=lgKluCX4IgkA:10 a=5lJygRwiOn0A:10 a=VwQbUJbxAAAA:8 a=yPCof4ZbAAAA:8 a=COG61y6lI4RyAtBVWEEA:9 a=pILNOxqGKmIA:10 a=uqAM_F3fFFOFj-Uo:21 a=gJzVr_1NCenaFNEy:21 a=CB2qr2aZVW1h592tse8A:9 a=QEXdDO2ut3YA:10 Reply-To: Subject: Re: Fwd: SWIOTLB on 32-bit PAE References: <5612356B.7070301@t2data.com> <561254A7.4000805@t2data.com> <20151005142113.GD2256@l.oracle.com> To: Konrad Rzeszutek Wilk CC: , From: Christian Melki Message-ID: <561297D5.8040107@t2data.com> Date: Mon, 5 Oct 2015 17:31:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151005142113.GD2256@l.oracle.com> Content-Type: multipart/mixed; boundary="------------060202010503060805070302" X-Originating-IP: [90.229.146.111] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --------------060202010503060805070302 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Yes. Operator error indeed. Thanks for asking. Included is the same patch with the SoB. On 10/05/2015 04:21 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Oct 05, 2015 at 12:44:55PM +0200, Christian Melki wrote: >> Joerg, >> >> I already sent the patch for Kconfig change to the list. >> But I discovered something even more disturbing which I mailed Konrad about. >> With the change my machine does not hang any more, but instead corrupts data >> which is written. The data however is readable on the machine which >> corrupted it, unreadable on the other machine without the patch. I don't >> understand what is going on. I have never encountered "selective" file >> corruption of fs on different machines. The fs itself checks out cleanly >> with badblock control (ext4). I fail to understand what is happening. > > And I believe this ended up being an operator error? > > With the patch you sent, you didn't include your SoB > (Signed-off-By). I would like to include your patch but I cannot > with your SoB. It is matter of reading to Documentation/SubmittingPatches > and just consenting to the Certificate in there. > > If you are uncomfortable with that - that is OK, I can make this > patch myself (a one liner :-)) but I figured it owuld be nice > for you to have all the credit. >> >> Regards, >> Christian >> >> -------- Forwarded Message -------- >> Subject: SWIOTLB on 32-bit PAE >> Date: Mon, 5 Oct 2015 10:31:39 +0200 >> From: Christian Melki >> To: linux-kernel@vger.kernel.org >> CC: konrad.wilk@oracle.com >> >> 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 >> >> >> > >> 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 >> > --------------060202010503060805070302 Content-Type: text/plain; charset="UTF-8"; name="swiotlb.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="swiotlb.patch" 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 Signed-off-by: Christian Melki --------------060202010503060805070302--