So, I wrote a generator for ctxprogs on NV50, NV84, NV86, NV92, NV94, NV96,
NV98. Atm it's only tested with NV86 and I'd like to see if it works for all
the other cards, especially NV50. NVAx support is still missing due to some
differences, but should be coming soon. Address is
http://0x04.net
http://bugs.freedesktop.org/show_bug.cgi?id=25754
Summary: Nouveau - GPU Lockup on 2.6.33-rc1
Product: xorg
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: critical
Priority:
http://bugs.freedesktop.org/show_bug.cgi?id=24996
Francisco Jerez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Mon, 2009-12-21 at 23:00 +0100, Marcin Slusarz wrote:
> struct fb_fillrect->color is not a color, but index into pseudo_palette array
>
Thanks, applied to git.
Ben.
> Signed-off-by: Marcin Slusarz
> ---
> drivers/gpu/drm/nouveau/nv50_fbcon.c |3 ++-
> 1 files changed, 2 insertions(+), 1
On Mon, 2009-12-21 at 14:44 +0100, Maarten Maathuis wrote:
> This should also avoid being able to dma into ramin, which was the
> primary concern darktama had about this patch. Actually this could
> already be done on the user channel, because the vm contained all the
> vram pages. Makes me wonder
struct fb_fillrect->color is not a color, but index into pseudo_palette array
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nv50_fbcon.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_fbcon.c
b/drivers/gpu/drm/nouveau/nv50_fbc
http://bugs.freedesktop.org/show_bug.cgi?id=24996
--- Comment #28 from Maarten Maathuis 2009-12-21
12:00:45 PST ---
nv43_tvdac_load_2.patch seems to work on a nv43, didn't test with tvout
connected.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
---
nouveau/nouveau_bo.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/nouveau/nouveau_bo.c b/nouveau/nouveau_bo.c
index 10cc8a6..9d584a3 100644
--- a/nouveau/nouveau_bo.c
+++ b/nouveau/nouveau_bo.c
@@ -444,8 +444,10 @@ nouveau_bo_map_range(struct nouveau_bo *bo, uint
On Mon, Dec 21, 2009 at 8:48 AM, Maarten Maathuis wrote:
> On Mon, Dec 21, 2009 at 11:25 AM, Christoph Bumiller
> wrote:
>> On 12/20/2009 04:46 PM, Maarten Maathuis wrote:
>>> - This avoids problematic "reloc'ed while mapped" messages and
>>> some associated corruption as well.
>>> - Also add one
- unreference pushbuf objects on channel destruction
Index: nouveau/nouveau_pushbuf.c
===
--- nouveau/nouveau_pushbuf.c (wersja 32082)
+++ nouveau/nouveau_pushbuf.c (kopia robocza)
@@ -262,6 +262,12 @@
return 0;
}
+void
- unreference state objects so that buffer objects are unreferenced and
eventually destroyed
- free channel at screen's destruction
Index: nv50/nv50_screen.c
===
--- nv50/nv50_screen.c (wersja 32083)
+++ nv50/nv50_screen.c (kopia r
On Mon, Dec 21, 2009 at 11:25 AM, Christoph Bumiller
wrote:
> On 12/20/2009 04:46 PM, Maarten Maathuis wrote:
>> - This avoids problematic "reloc'ed while mapped" messages and
>> some associated corruption as well.
>> - Also add one nouveau_bo_unmap() in the vbo code that wasn't present.
> I didn'
This should also avoid being able to dma into ramin, which was the
primary concern darktama had about this patch. Actually this could
already be done on the user channel, because the vm contained all the
vram pages. Makes me wonder why we weren't overwriting ramin
sometimes.
On Mon, Dec 21, 2009 a
- Use the "direct" objects that previously only the kernel fifo had.
- This avoids corruption on some buffer moves.
- Prevent dma access to ramin, we never use dma there anyway and it's an
exploit waiting to happen.
Signed-off-by: Maarten Maathuis
---
drivers/gpu/drm/nouveau/nouveau_bo.c |
On 12/20/2009 04:46 PM, Maarten Maathuis wrote:
> - This avoids problematic "reloc'ed while mapped" messages and
> some associated corruption as well.
> - Also add one nouveau_bo_unmap() in the vbo code that wasn't present.
I didn't think nouveau_bo_unmap was necessary if the map failed.
As far as
Krzysztof Smiechowicz pisze:
> Hi,
>
> I'm trying to find a place where objects held in
> nv40_context->state.hw[] and nv40_screen->state[] are being unreferenced
> during pipe_context destruction.
>
> Currently I'm observing that these objects are not unreferenced and
> since they hold refere
16 matches
Mail list logo
