From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Ilia Mirkin <imirkin@alum.mit.edu>, Mike Galbraith <efault@gmx.de>
Cc: nouveau <nouveau@lists.freedesktop.org>,
"Michel Dänzer" <michel@daenzer.net>,
LKML <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Ben Skeggs" <bskeggs@redhat.com>,
"Tobias Klausmann" <tobias.johannes.klausmann@mni.thm.de>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152
Date: Tue, 2 Jan 2018 10:43:48 +0100 [thread overview]
Message-ID: <0d1f7796-adc3-70ab-c47c-a949ea0c14db@gmail.com> (raw)
In-Reply-To: <CAKb7Uvjw0rP4u-zw1rRfwH1BRWFj9nwDVv8dPJY=oYS1DgjTBw@mail.gmail.com>
Am 01.01.2018 um 19:08 schrieb Ilia Mirkin:
> On Sun, Dec 31, 2017 at 3:53 PM, Mike Galbraith <efault@gmx.de> wrote:
>> On Sun, 2017-12-31 at 13:27 -0500, Ilia Mirkin wrote:
>>> On Tue, Dec 19, 2017 at 8:45 AM, Christian König
>>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>>> Am 19.12.2017 um 11:39 schrieb Michel Dänzer:
>>>>> On 2017-12-19 11:37 AM, Michel Dänzer wrote:
>>>>>> On 2017-12-18 08:01 PM, Tobias Klausmann wrote:
>>>>>>> On 12/18/17 7:06 PM, Mike Galbraith wrote:
>>>>>>>> Greetings,
>>>>>>>>
>>>>>>>> Kernel bound workloads seem to trigger the below for whatever reason.
>>>>>>>> I only see this when beating up NFS. There was a kworker wakeup
>>>>>>>> latency issue, but with a bandaid applied to fix that up, I can still
>>>>>>>> trigger this.
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> i have seen this one as well with my system, but i could not find an
>>>>>>> easy way to trigger it for bisecting purpose. If you can trigger it
>>>>>>> conveniently, a bisect would be nice!
>>>>>> I'm seeing this (with the amdgpu and radeon drivers) when restic takes a
>>>>>> backup, creating memory pressure. I happen to have just finished
>>>>>> bisecting, the result is:
>>>>>>
>>>>>> 648bc3574716400acc06f99915815f80d9563783 is the first bad commit
>>>>>> commit 648bc3574716400acc06f99915815f80d9563783
>>>>>> Author: Christian König <christian.koenig@amd.com>
>>>>>> Date: Thu Jul 6 09:59:43 2017 +0200
>>>>>>
>>>>>> drm/ttm: add transparent huge page support for DMA allocations v2
>>>>>>
>>>>>> Try to allocate huge pages when it makes sense.
>>>>>>
>>>>>> v2: fix comment and use ifdef
>>>>>>
>>>>>>
>>>>> BTW, I haven't noticed any bad effects other than the dmesg splats, so
>>>>> maybe it's just noise about transient failures for which there is a
>>>>> proper fallback in place.
>>>>
>>>> Yeah, I think that is exactly what happens here.
>>>>
>>>> We try to allocate a huge page, but fail and so fall back to using multiple
>>>> 4k pages instead.
>>>>
>>>> Going to send out a patch to suppress the warning.
>>> Hi Christian,
>>>
>>> Did you ever send out such a patch? I didn't see one on the list, but
>>> perhaps I missed it. One definitely hasn't made it upstream yet. (I
>>> just hit the issue myself with Linus's tree from last night.)
>> Actually, that wants a bit more methinks, because while the stack dump
>> goes away, you still get spammed, it just comes in smaller chunks.
> OK, well this has to either be fixed or reverted. Right now it's
> complaining all the time for me after like a day of uptime.
I've already send out a patch to Konrad Rzeszutek Wilk and he wanted to
queue that up.
But there is another warning I'm currently working on, just didn't had
time to during the holidays.
Regards,
Christian.
prev parent reply other threads:[~2018-01-02 9:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-18 18:06 Mike Galbraith
2017-12-18 19:01 ` Tobias Klausmann
2017-12-18 19:12 ` Mike Galbraith
2017-12-19 10:37 ` Michel Dänzer
2017-12-19 10:39 ` Michel Dänzer
2017-12-19 13:45 ` Christian König
2017-12-31 18:27 ` Ilia Mirkin
2017-12-31 20:53 ` Mike Galbraith
2018-01-01 18:08 ` Ilia Mirkin
2018-01-02 9:43 ` Christian König [this message]
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=0d1f7796-adc3-70ab-c47c-a949ea0c14db@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=bskeggs@redhat.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=efault@gmx.de \
--cc=imirkin@alum.mit.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=michel@daenzer.net \
--cc=nouveau@lists.freedesktop.org \
--cc=tobias.johannes.klausmann@mni.thm.de \
/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
Powered by JetHome