Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: 5.13 i915/PAT regression on Brasswell, adding nopat to the kernel
 commandline worksaround this
To:     Christoph Hellwig <hch@lst.de>,
        Peter Zijlstra <peterz@infradead.org>
Cc:     intel-gfx@lists.freedesktop.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        x86@kernel.org
References: <b6b61cf0-5874-f4c0-1fcc-4b3848451c31@redhat.com>
 <YJu4tzXmCJbKp7Fm@hirez.programming.kicks-ass.net>
 <20210512115736.GA10444@lst.de>
From:   Hans de Goede <hdegoede@redhat.com>
Message-ID: <3b178f66-fde6-888a-9a49-ab0d13e944b3@redhat.com>
Date:   Wed, 12 May 2021 14:36:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <20210512115736.GA10444@lst.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi,

On 5/12/21 1:57 PM, Christoph Hellwig wrote:
> On Wed, May 12, 2021 at 01:15:03PM +0200, Peter Zijlstra wrote:
>> IIRC it's because of 74ffa5a3e685 ("mm: add remap_pfn_range_notrack"),
>> which added a sanity check to make sure expectations were met. It turns
>> out they were not.
>>
>> The bug is not new, the warning is. AFAIK the i915 team is aware, but
>> other than that I've not followed.
> 
> 
> The actual culprit is b12d691ea5e0 ("i915: fix remap_io_sg to verify the
> pgprot"), but otherwise agreed.  Someone the i915 maintainers all seem
> to be on vacation as the previous report did not manage to trigger any
> kind of reply.

I can confirm that reverting that commit restores i915 functionality with
5.13-rc1 on the Braswell machine on which I have been testing this.

Regards,

Hans