dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/radeon: fix VM page table setup on SI
Date: Fri, 29 Jun 2012 18:14:31 +0200	[thread overview]
Message-ID: <1340986471.3562.223.camel@thor.local> (raw)
In-Reply-To: <CAH3drwbhViYWEYXr3tAuW9FiGmTUUcLuagH=PrnvJzcB5VthdA@mail.gmail.com>

On Fre, 2012-06-29 at 11:28 -0400, Jerome Glisse wrote: 
> On Fri, Jun 29, 2012 at 11:23 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
> > On Fri, Jun 29, 2012 at 10:49 AM, Michel Dänzer <michel@daenzer.net> wrote:
> >> On Don, 2012-06-28 at 17:53 -0400, alexdeucher@gmail.com wrote:
> >>> From: Alex Deucher <alexander.deucher@amd.com>
> >>>
> >>> Cayman and trinity allow for variable sized VM page
> >>> tables, but SI requires that all page tables be the
> >>> same size.  The current code assumes variablely sized
> >>> VM page tables so SI may end up with part of each page
> >>> table overlapping with other memory which could end
> >>> up being interpreted by the VM hw as garbage.
> >>>
> >>> Change the code to better accomodate SI.  Allocate enough
> >>> space for at least 2 full page tables and always set
> >>> last_pfn to max_pfn on SI so each VM is backed by a full
> >>> page table.  This limits us to only 2 VMs active at any
> >>> given time on SI.  This will be rectified and the code can
> >>> be reunified once we move to two level page tables.
> >>>
> >>> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> >>
> >> This change breaks the radeonsi driver for me. egltri_screen (the
> >> 'golden' test for radeonsi at least basically working) locks up the
> >> GPU.
> >>
> >> I don't have any details about the lockup yet, as the GPU reset attempt
> >> hangs the machine. Any ideas offhand what radeonsi might be doing wrong?
> >
> > Maybe trying to access an unmapped page that happened to work by
> > accident before and now causes a fault in the VM which halts the MC?

Indeed, looks like it:

radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x000FF01B
radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0202400C

Oddly, while I have seen similar errors before (so at 
least some access to unmapped pages was caught even before your patch),
I hadn't noticed them for a while with egltri_screen...


Anyway, some more experimentation shows that it doesn't happen if I skip
the clear, and it still happens when doing only a clear. I'll look into
what might be wrong with the clears next week.


> Yeah only thing i can think of, can you get dump of various mc fault
> reg after lockup ?

Did you have any particular registers in mind?


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer

  reply	other threads:[~2012-06-29 16:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-28 21:53 [PATCH] drm/radeon: fix VM page table setup on SI alexdeucher
2012-06-28 23:05 ` Jerome Glisse
2012-06-29 14:49 ` Michel Dänzer
2012-06-29 15:23   ` Alex Deucher
2012-06-29 15:28     ` Jerome Glisse
2012-06-29 16:14       ` Michel Dänzer [this message]
2012-06-29 18:07         ` Jerome Glisse
2012-07-17 11:28           ` Michel Dänzer

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=1340986471.3562.223.camel@thor.local \
    --to=michel@daenzer.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=j.glisse@gmail.com \
    /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