From: "Guido Günther" <agx@sigxcpu.org>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
patchwork-lst@pengutronix.de, kernel@pengutronix.de,
Russell King <linux+etnaviv@armlinux.org.uk>
Subject: Re: [PATCH 02/10] drm/etnaviv: mmuv2: don't map zero page
Date: Mon, 7 Jan 2019 10:13:24 +0100 [thread overview]
Message-ID: <20190107091324.GA8221@bogon.m.sigxcpu.org> (raw)
In-Reply-To: <1546851052.3580.5.camel@pengutronix.de>
Hi,
On Mon, Jan 07, 2019 at 09:50:52AM +0100, Lucas Stach wrote:
> Hi Guido,
>
> Am Sonntag, den 30.12.2018, 16:49 +0100 schrieb Guido Günther:
> > Hi Lucas,
> > On Wed, Dec 19, 2018 at 03:45:38PM +0100, Lucas Stach wrote:
> > > Keep the page at address 0 as faulting to catch any potential state
> > > setup issues early.
> >
> > This is a nice idea! But applying this and making mesa hit that page
> > leads to the process hanging in D state over here on GC7000:
> >
> > # [ 242.726192] INFO: task kworker/u8:2:37 blocked for more than 120 seconds.
> > [ 242.733010] Not tainted 4.18.0-00129-gce2b21074b41 #504
> > [ 242.738795] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [ 242.746638] kworker/u8:2 D 0 37 2 0x00000028
> > [ 242.752144] Workqueue: events_unbound commit_work
> > [ 242.756860] Call trace:
> > [ 242.759318] __switch_to+0x94/0xd0
> > [ 242.762741] __schedule+0x1c0/0x6b8
> > [ 242.766239] schedule+0x40/0xa8
> > [ 242.769380] schedule_timeout+0x2f0/0x428
> > [ 242.773410] dma_fence_default_wait+0x1cc/0x2b8
> > [ 242.777951] dma_fence_wait_timeout+0x44/0x1b0
> > [ 242.782403] drm_atomic_helper_wait_for_fences+0x48/0x108
> > [ 242.787819] commit_tail+0x30/0x80
> > [ 242.791229] commit_work+0x20/0x30
> > [ 242.794642] process_one_work+0x1ec/0x458
> > [ 242.798659] worker_thread+0x48/0x430
> > [ 242.802331] kthread+0x130/0x138
> > [ 242.805557] ret_from_fork+0x10/0x1c
> >
> > This is in dmesg showing that we hit the first page:
> >
> > [ 65.907388] etnaviv-gpu 38000000.gpu: MMU fault status 0x00000002
> > [ 65.913497] etnaviv-gpu 38000000.gpu: MMU 0 fault addr 0x00000e40
> >
> > Without that patch it's sampling random data from that page but does not hang.
>
> GPU hangs after a MMU fault are expected or more accurately, we
> actively request the GPU to stop by setting the exception bit in the
> page table.
Yeah. I put that in to show that this the cause for the trouble above.
>
> A hanging GPU should trigger the scheduler timeout handler, which then
> makes sure to get the GPU back into a working state. So if things don't
> progress after the fault for you either the timeout handler is buggy on
> GC7000, or the fence signaling is broken somehow. I'll take a look at
> this.
This isn't a top notch linux-next based tree yet so if you're not seeing this
let me forward port our stuff to that and report back again.
Cheers,
-- Guido
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-01-07 9:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-19 14:45 [PATCH 00/10] per-process address spaces for MMUv2 Lucas Stach
2018-12-19 14:45 ` [PATCH 01/10] drm/etnaviv: move job context pointer to etnaviv_gem_submit Lucas Stach
2018-12-28 12:23 ` Christian Gmeiner
2018-12-19 14:45 ` [PATCH 02/10] drm/etnaviv: mmuv2: don't map zero page Lucas Stach
2018-12-30 15:49 ` Guido Günther
2019-01-07 8:50 ` Lucas Stach
2019-01-07 9:13 ` Guido Günther [this message]
2019-01-07 15:02 ` Lucas Stach
2019-04-02 11:38 ` Guido Günther
2019-02-01 7:57 ` Christian Gmeiner
2019-04-02 11:39 ` Guido Günther
2018-12-19 14:45 ` [PATCH 03/10] drm/etnaviv: split out cmdbuf mapping into address space Lucas Stach
2018-12-19 14:45 ` [PATCH 04/10] drm/etnaviv: share a single cmdbuf suballoc region across all GPUs Lucas Stach
2018-12-19 14:45 ` [PATCH 05/10] drm/etnaviv: replace MMU flush marker with flush sequence Lucas Stach
2018-12-19 14:45 ` [PATCH 06/10] drm/etnaviv: rework MMU handling Lucas Stach
2018-12-19 14:45 ` [PATCH 07/10] drm/etnaviv: split out starting of FE idle loop Lucas Stach
2018-12-19 14:45 ` [PATCH 08/10] drm/etnaviv: provide MMU context to etnaviv_gem_mapping_get Lucas Stach
2018-12-19 14:45 ` [PATCH 09/10] drm/etnaviv: implement per-process address spaces on MMUv2 Lucas Stach
2018-12-19 14:45 ` [PATCH 10/10] drm/etnaviv: dump only failing submit Lucas Stach
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=20190107091324.GA8221@bogon.m.sigxcpu.org \
--to=agx@sigxcpu.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=kernel@pengutronix.de \
--cc=l.stach@pengutronix.de \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=patchwork-lst@pengutronix.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;
as well as URLs for NNTP newsgroup(s).