From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754948AbdDDQ3o (ORCPT ); Tue, 4 Apr 2017 12:29:44 -0400 Received: from smtp-out-so.shaw.ca ([64.59.136.139]:52937 "EHLO smtp-out-so.shaw.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754780AbdDDQ3n (ORCPT ); Tue, 4 Apr 2017 12:29:43 -0400 X-Authority-Analysis: v=2.2 cv=W+NIbVek c=1 sm=1 tr=0 a=JyAt4amVi6RK7kaaDbhaBA==:117 a=JyAt4amVi6RK7kaaDbhaBA==:17 a=N659UExz7-8A:10 a=AzvcPWV-tVgA:10 a=dNjuFS2lWOHaPT5fkP0A:9 a=pILNOxqGKmIA:10 Subject: Re: AMD IOMMU causing filesystem corruption To: Joerg Roedel References: <5ea65f55-e5eb-11a5-14ab-e721d2f95ed6@sieb.net> <20170403213909.GR7266@8bytes.org> <32afc9d1-a2db-f9dc-bbe0-d894967dc8ad@sieb.net> <935473d9-e75b-c019-0dde-063855067858@sieb.net> <20170404073215.GS7266@8bytes.org> From: Samuel Sieb Cc: Linux Kernel Message-ID: <5838b65d-0f2f-86b1-1041-a28d42fc9881@sieb.net> Date: Tue, 4 Apr 2017 09:29:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170404073215.GS7266@8bytes.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfB2YLPhX6yGCDEYJOrUbDRnGfWFxJAVcs9xtQltU6hYyTl7Pe4BkTbP3xuFJLPOopE89xtalAb4VCQY0wWZpKO494xqLYS/xRgE8WxLnslRYi9DQDB8F /57eOnIlpCVqLn3wIUApu0mwgbWdg8Oe4JsKikEF/gIYFhSuk6kTC4Se3I1aINkN+yp/Ahx7zf4DSsBfNpJMSPlybiK73jCnBQU= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/04/2017 12:32 AM, Joerg Roedel wrote: > On Tue, Apr 04, 2017 at 12:11:31AM -0700, Samuel Sieb wrote: >> Unfortunately, that turned out to be a bit premature. After >> compiling a kernel on it remotely over ssh (not interacting with the >> logged in desktop), a reboot failed with endless completion-wait >> loop timeout messages and after a force poweroff and restart it >> won't boot. The EFI filesystem was even destroyed, probably because >> the kernel installation modified a file on there. > > Yeah, please boot the machine with amd_iommu=off during re-installation > and when you install the modified kernel. And then boot into the patches > kernel with amd_iommu=on (which is the default). > That's what I did. While running with iommu=off, I compiled and installed a 4.11rc kernel with the patch. I rebooted to use that kernel and then compiled and installed a 4.10 kernel with that patch and another unrelated patch. That is what I described above. The filesystem destruction happened while running the 4.11rc kernel with that patch. Is there any way to verify that the patch was actually having any effect? Can I check if ATS is enabled or not? I will have to rebuild the system before I can test again.