[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Thu Aug 9 08:24:41 PDT 2012
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #116 from Alexandre Demers <alexandre.f.demers at gmail.com> 2012-08-09 15:24:41 UTC ---
(In reply to comment #113)
> (In reply to comment #112)
> > (In reply to comment #111)
> > > (In reply to comment #110)
> > > > I just pushed a minor bugfix to mesa master, that in conjunction with Jeromes
> > > > kernel patch should eliminate the last VA issues.
> > > >
> > > > Please retest it again.
> > > >
> > > > Christian.
> > >
> > > You must be refering to commit 8c44e5a144009a03c20befa6468d19d41c802795. Do I
> > > still need to apply your previous patch also (attachment 65093 [details] [review] [review] [review])? I'll try it
> > > tonight, but it may take a bit more complicated to reproduce, I'll have to play
> > > for a while until it does or doesn't trigger the last reported vm error.
> >
> > Well, I tested it with your previous patch on top of
> > 68bccc40f55aee7f4af8eb64b15a95f0b49d6a17 and it was not working properly.
> > First, I had to modify your patch to apply on top of latest git. After applying
> > it, compiling and installing, I rebooted and I was unable to load the logging
> > screen. I removed the patch, rebuilt a clean mesa from
> > 68bccc40f55aee7f4af8eb64b15a95f0b49d6a17, installed and relaunched Xorg and...
> > I was able to log in. So I'm now testing latest mesa
> > (68bccc40f55aee7f4af8eb64b15a95f0b49d6a17) with kernel 3.6-rc1 + Jerome's
> > patch. I should be able to tell you soon if it works. Meanwhile, if I should
> > have applied something different, let me know.
> >
> > To Jerome: I could test your [PATCH] drm/radeon: delay virtual address
> > destruction to bo destruction. But first, I want to make sure Christian's patch
> > does what it should do.
>
> Bug still there with latest mesa git (without your previous patch as explained
> previously).
> Aug 9 01:03:29 Xander kernel: [13308.165749] radeon 0000:01:00.0: offset
> 0x400000 is in reserved area 0x800000
> Aug 9 01:03:29 Xander kernel: [13308.232245] radeon 0000:01:00.0: bo
> ffff880223646400 va 0x02B00000 conflict with (bo ffff8801e3edc400
>
> Locked and reset without any notice.
Two things I've noticed:
1- the error points directly at "offset 0x400000 is in reserved area 0x800000"
since I applied Christian's and Jerome's patches, which is a different error
from errors before patches.
2- the error only happens after a while, when switching between windows (under
Gnome 3 in that case). I had to alt+tab and show my whole desktop (top left
corner) many times before it happened. I played with my desktop all night long.
So, it's like if the pointer keeps increasing until it reaches its limit.
Either we are not releasing correctly previous addresses (or we are forgetting
some on the way)or we are unaware of every released addresses, in both cases
pushing us forward until we hit a wall.
And if someone could explain me what this message/addresses means, I'd
appreciate it. How is it possible that an offset of 0x400000 ends up in a
reserved area allocated at 0x800000? We must not be offsetting from 0
obviously.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the dri-devel
mailing list