NV50: xv fullscreen issues

NV50: xv fullscreen issues

[Daniel Eklöf]

Hi,

I've been trying out nouveau for a while now and I must say I'm impressed. Performance in KDE4 in general seems better than the nvidia blob; way to go!

There are a couple of annoyances though:

XV in fullscreen doesn't work. I'm running in composite mode, and non fullscreen video works well enough. Going fullscreen in e.g gmplayer gives me:

[ws] Error in display. -0.005 ct: -0.000  25/ 25 30% 23%  0.8% 3 6                                                        
[ws]  Error code: 8 ( BadMatch (invalid parameter attributes) )                                                           
[ws]  Request code: 140                                                                                                   
[ws]  Minor code: 19                                                                                                      
[ws]  Modules: flip_page

xine crashes in a similar way. mplayer (non GUI version) doesn't crash, but all I get is a black screen with "BadMatch" errors spamming the console.

The BadMatch is from nv50_xv.c:54

       if (exaGetPixmapOffset(ppix) < pNv->EXADriverPtr->offScreenBase)
                return FALSE;

commenting out those lines stops the players from crashing, but I still get just a black screen.

After having crashed gmplayer (with the code lines above re-enabled), I also notice that screen updates are a bit shaky - sometimes the screen isn't updated until I press a key or move the mouse (e.g. typing 'ls' doesn't list any files until I press another key, web pages aren't displayed until I move the mouse and so on). At this point, I sometimes also see an unusually high CPU load from X (around 75%). Sometimes X freezes, sometimes not.

One more odd thing is that I don't get any interrupts on the NV50 during "normal use" (as reported by /proc/interrupts). I sometimes get an interrupt storm when starting X, then nothing. I sometimes see a number of interrupts after having crashed gmplayer when trying to play a video fullscreen. But other than that, no interrupts what so ever.

One last question, and this may not even be nouveau related since I also see this with the nv driver (so please feel free to yell RTFM! or just ignore it :) ). If I start X as a non-root user, it choses 1280x1024 as default resolution (the panel's native resolution is 1680x1050). I dont't see this in KDM, or when starting as root (so, I can for example start kdm in the correct resolution, but then when I log in, as non-root, the resolution is changed to 1280x1024). It doesn't seem to matter what I set in xorg.conf. The EDID output does report 1680x1050, and xrandr also sees it. In fact, just opening the "Display" settings in KDE's control panel causes a switch to 1680x1050. Needless to say, the binary nvidia driver doesn't have this problem.

Random system info:

Linux tiny 2.6.28 #1 SMP Thu Dec 25 12:45:15 CET 2008 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux

01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600 GTS (rev a1) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Device 8241
        Flags: bus master, fast devsel, latency 0, IRQ 18
        Memory at d2000000 (32-bit, non-prefetchable) [size=16M]
        Memory at c0000000 (64-bit, prefetchable) [size=256M]
        Memory at d0000000 (64-bit, non-prefetchable) [size=32M]
        I/O ports at a000 [size=128]
        Expansion ROM at d3000000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 2
        Capabilities: [68] MSI: Mask- 64bit+ Count=1/1 Enable-
        Capabilities: [78] Express Endpoint, MSI 00
        Capabilities: [100] Virtual Channel <?>
        Capabilities: [128] Power Budgeting <?>
        Capabilities: [600] Vendor Specific Information <?>

Using latest git libdrm and nouveau sources, xorg-7.4 (server-1.5.3). If there's any other info you need, just let me know.

Regards,
Daniel Eklöf

Re: NV50: xv fullscreen issues

[Ben Skeggs]

On 12/26/08, Daniel Eklöf <daniel-pl05T3eHY++zQB+pC5nmwQ@public.gmane.org> wrote:
> Hi,
>
> I've been trying out nouveau for a while now and I must say I'm impressed.
> Performance in KDE4 in general seems better than the nvidia blob; way to go!
>
> There are a couple of annoyances though:
>
> XV in fullscreen doesn't work. I'm running in composite mode, and non
> fullscreen video works well enough. Going fullscreen in e.g gmplayer gives
> me:
>
> [ws] Error in display. -0.005 ct: -0.000  25/ 25 30% 23%  0.8% 3 6
>
> [ws]  Error code: 8 ( BadMatch (invalid parameter attributes) )
>
> [ws]  Request code: 140
>
> [ws]  Minor code: 19
>
> [ws]  Modules: flip_page
>
> xine crashes in a similar way. mplayer (non GUI version) doesn't crash, but
> all I get is a black screen with "BadMatch" errors spamming the console.
>
> The BadMatch is from nv50_xv.c:54
>
>        if (exaGetPixmapOffset(ppix) < pNv->EXADriverPtr->offScreenBase)
>                 return FALSE;
>
> commenting out those lines stops the players from crashing, but I still get
> just a black screen.
I'm typing this from a mobile phone so answers will be brief sorry!
Your composite manager is probably unredirecting fullscreen windows.
We can't currently render directly to the scanout buffer with the 3D
engine, which is what the above code checks for.

> After having crashed gmplayer (with the code lines above re-enabled), I also
> notice that screen updates are a bit shaky - sometimes the screen isn't
> updated until I press a key or move the mouse (e.g. typing 'ls' doesn't list
> any files until I press another key, web pages aren't displayed until I move
> the mouse and so on). At this point, I sometimes also see an unusually high
> CPU load from X (around 75%). Sometimes X freezes, sometimes not.
I don't see this on my systems, but i'll look into it when i'm back in action.

>
> One more odd thing is that I don't get any interrupts on the NV50 during
> "normal use" (as reported by /proc/interrupts). I sometimes get an interrupt
> storm when starting X, then nothing. I sometimes see a number of interrupts
> after having crashed gmplayer when trying to play a video fullscreen. But
> other than that, no interrupts what so ever.
Completely normal, we don't currently make use of interrupts from the
gpu save for error reporting.

>
> One last question, and this may not even be nouveau related since I also see
> this with the nv driver (so please feel free to yell RTFM! or just ignore it
> :) ). If I start X as a non-root user, it choses 1280x1024 as default
> resolution (the panel's native resolution is 1680x1050). I dont't see this
> in KDM, or when starting as root (so, I can for example start kdm in the
> correct resolution, but then when I log in, as non-root, the resolution is
> changed to 1280x1024). It doesn't seem to matter what I set in xorg.conf.
> The EDID output does report 1680x1050, and xrandr also sees it. In fact,
> just opening the "Display" settings in KDE's control panel causes a switch
> to 1680x1050. Needless to say, the binary nvidia driver doesn't have this
> problem.
>
> Random system info:
>
> Linux tiny 2.6.28 #1 SMP Thu Dec 25 12:45:15 CET 2008 x86_64 AMD Athlon(tm)
> 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux
>
> 01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600 GTS (rev
> a1) (prog-if 00 [VGA controller])
>         Subsystem: ASUSTeK Computer Inc. Device 8241
>         Flags: bus master, fast devsel, latency 0, IRQ 18
>         Memory at d2000000 (32-bit, non-prefetchable) [size=16M]
>         Memory at c0000000 (64-bit, prefetchable) [size=256M]
>         Memory at d0000000 (64-bit, non-prefetchable) [size=32M]
>         I/O ports at a000 [size=128]
>         Expansion ROM at d3000000 [disabled] [size=128K]
>         Capabilities: [60] Power Management version 2
>         Capabilities: [68] MSI: Mask- 64bit+ Count=1/1 Enable-
>         Capabilities: [78] Express Endpoint, MSI 00
>         Capabilities: [100] Virtual Channel <?>
>         Capabilities: [128] Power Budgeting <?>
>         Capabilities: [600] Vendor Specific Information <?>
>
> Using latest git libdrm and nouveau sources, xorg-7.4 (server-1.5.3). If
> there's any other info you need, just let me know.
>
> Regards,
> Daniel Eklöf
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>

Re: NV50: xv fullscreen issues

[Daniel Eklöf]

> On 12/26/08, Daniel Eklöf <daniel-pl05T3eHY++zQB+pC5nmwQ@public.gmane.org> wrote:
> > Hi,
> >
> > I've been trying out nouveau for a while now and I must say I'm
> > impressed. Performance in KDE4 in general seems better than the nvidia
> > blob; way to go!
> >
> > There are a couple of annoyances though:
> >
> > XV in fullscreen doesn't work. I'm running in composite mode, and non
> > fullscreen video works well enough. Going fullscreen in e.g gmplayer
> > gives me:
> >
> > [ws] Error in display. -0.005 ct: -0.000  25/ 25 30% 23%  0.8% 3 6
> >
> > [ws]  Error code: 8 ( BadMatch (invalid parameter attributes) )
> >
> > [ws]  Request code: 140
> >
> > [ws]  Minor code: 19
> >
> > [ws]  Modules: flip_page
> >
> > xine crashes in a similar way. mplayer (non GUI version) doesn't crash,
> > but all I get is a black screen with "BadMatch" errors spamming the
> > console.
> >
> > The BadMatch is from nv50_xv.c:54
> >
> >        if (exaGetPixmapOffset(ppix) < pNv->EXADriverPtr->offScreenBase)
> >                 return FALSE;
> >
> > commenting out those lines stops the players from crashing, but I still
> > get just a black screen.
>
> I'm typing this from a mobile phone so answers will be brief sorry!

No problem! I'm grateful for any kind of answers :)

> Your composite manager is probably unredirecting fullscreen windows.
> We can't currently render directly to the scanout buffer with the 3D
> engine, which is what the above code checks for.

Ok, good to know, thanks.

> > After having crashed gmplayer (with the code lines above re-enabled), I
> > also notice that screen updates are a bit shaky - sometimes the screen
> > isn't updated until I press a key or move the mouse (e.g. typing 'ls'
> > doesn't list any files until I press another key, web pages aren't
> > displayed until I move the mouse and so on). At this point, I sometimes
> > also see an unusually high CPU load from X (around 75%). Sometimes X
> > freezes, sometimes not.
>
> I don't see this on my systems, but i'll look into it when i'm back in
> action.

After some more testing, I can say for sure that this isn't really related to 
the xv fullscreen issue. xv in fullscreen was just a way to trigger it. I'm 
not sure exactly what triggers it though - starting certain GUI programs 
triggers it, while other programs do not. In any case, I'm pretty sure the 
high CPU load is always there when I see the screen update issue. When this 
happens, X is stuck inside nouveau_dma_wait:

(gdb) bt
#0  0x00007f63f5f18df8 in nouveau_dma_wait (userchan=<value optimized out>, 
size=2) at nouveau_dma.c:88
#1  0x00007f63f5f4f01d in nouveau_dma_begin (userchan=0x241aaf0, 
grobj=0x241a900, method=4916, size=1,
    file=0x7f63f5f5b630 "NV50EXAPrepareComposite", line=695) at 
nouveau_dma.h:118
#2  0x00007f63f5f509b0 in NV50EXAPrepareComposite (op=<value optimized out>, 
pspict=0x3eb9210, pmpict=0x3bad6c0, pdpict=0x3543430,
    pspix=0x2f21de0, pmpix=0x522f4c0, pdpix=0x5a39230) at nv50_exa.c:695
#3  0x00007f63f457de6a in ?? () from /usr/lib64/X11/modules//libexa.so
#4  0x00007f63f457f097 in exaComposite () from 
/usr/lib64/X11/modules//libexa.so
#5  0x000000000053029f in ?? ()
#6  0x000000000051f0ad in ?? ()
#7  0x0000000000447ef6 in Dispatch ()
#8  0x000000000042d82d in main ()

On a side note, out of curiousity I took a look at the dma_wait code; and I 
found myself wondering if the CHECK_TIMEOUT macro is really ok. My 
understanding is that it tries to avoid an expensive gettimeofday (or similar) 
in the normal case where the DMA doesn't timeout. It does this by first 
incrementing a counter, and only checks the actual time after the counter has 
reached a certain value.

Two things about this:

1) the counter goes all the way up to 0xffffffff. This took ~25s on my laptop 
and ~13s on my main. As a comparison, the DMA timeout value is 2s

2) It doesn't assign a value to t_start until after the counter has reached 
0xffffffff. Again, I guess this is to avoid an expensive gettimeofday. 
However, it also means that the actual timeout value now is the time it takes 
to increment the counter _plus_ the DMA timeout value.

This may all be by design, but it did strike me as a bit suspiouses.

> > One more odd thing is that I don't get any interrupts on the NV50 during
> > "normal use" (as reported by /proc/interrupts). I sometimes get an
> > interrupt storm when starting X, then nothing. I sometimes see a number
> > of interrupts after having crashed gmplayer when trying to play a video
> > fullscreen. But other than that, no interrupts what so ever.
>
> Completely normal, we don't currently make use of interrupts from the
> gpu save for error reporting.

Ok, I thought it may be something like that. The nvidia blob does generate 
interrupts occasionally, so I guess I was expecting nouveau to behave in a 
similar way.

> > One last question, and this may not even be nouveau related since I also
> > see this with the nv driver (so please feel free to yell RTFM! or just
> > ignore it
> >
> > :) ). If I start X as a non-root user, it choses 1280x1024 as default
> >
> > resolution (the panel's native resolution is 1680x1050). I dont't see
> > this in KDM, or when starting as root (so, I can for example start kdm in
> > the correct resolution, but then when I log in, as non-root, the
> > resolution is changed to 1280x1024). It doesn't seem to matter what I set
> > in xorg.conf. The EDID output does report 1680x1050, and xrandr also sees
> > it. In fact, just opening the "Display" settings in KDE's control panel
> > causes a switch to 1680x1050. Needless to say, the binary nvidia driver
> > doesn't have this problem.
> >
> > Random system info:
> >
> > Linux tiny 2.6.28 #1 SMP Thu Dec 25 12:45:15 CET 2008 x86_64 AMD
> > Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux
> >
> > 01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600 GTS
> > (rev a1) (prog-if 00 [VGA controller])
> >         Subsystem: ASUSTeK Computer Inc. Device 8241
> >         Flags: bus master, fast devsel, latency 0, IRQ 18
> >         Memory at d2000000 (32-bit, non-prefetchable) [size=16M]
> >         Memory at c0000000 (64-bit, prefetchable) [size=256M]
> >         Memory at d0000000 (64-bit, non-prefetchable) [size=32M]
> >         I/O ports at a000 [size=128]
> >         Expansion ROM at d3000000 [disabled] [size=128K]
> >         Capabilities: [60] Power Management version 2
> >         Capabilities: [68] MSI: Mask- 64bit+ Count=1/1 Enable-
> >         Capabilities: [78] Express Endpoint, MSI 00
> >         Capabilities: [100] Virtual Channel <?>
> >         Capabilities: [128] Power Budgeting <?>
> >         Capabilities: [600] Vendor Specific Information <?>
> >
> > Using latest git libdrm and nouveau sources, xorg-7.4 (server-1.5.3). If
> > there's any other info you need, just let me know.
> >
> > Regards,
> > Daniel Eklöf
> > _______________________________________________
> > Nouveau mailing list
> > Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> > http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: NV50: xv fullscreen issues

[Maarten Maathuis]

On 12/27/2008 12:36 PM, Daniel Eklöf wrote:
>> On 12/26/08, Daniel Eklöf<daniel-pl05T3eHY++zQB+pC5nmwQ@public.gmane.org>  wrote:
>>      
>>> Hi,
>>>
>>> I've been trying out nouveau for a while now and I must say I'm
>>> impressed. Performance in KDE4 in general seems better than the nvidia
>>> blob; way to go!
>>>
>>> There are a couple of annoyances though:
>>>
>>> XV in fullscreen doesn't work. I'm running in composite mode, and non
>>> fullscreen video works well enough. Going fullscreen in e.g gmplayer
>>> gives me:
>>>
>>> [ws] Error in display. -0.005 ct: -0.000  25/ 25 30% 23%  0.8% 3 6
>>>
>>> [ws]  Error code: 8 ( BadMatch (invalid parameter attributes) )
>>>
>>> [ws]  Request code: 140
>>>
>>> [ws]  Minor code: 19
>>>
>>> [ws]  Modules: flip_page
>>>
>>> xine crashes in a similar way. mplayer (non GUI version) doesn't crash,
>>> but all I get is a black screen with "BadMatch" errors spamming the
>>> console.
>>>
>>> The BadMatch is from nv50_xv.c:54
>>>
>>>         if (exaGetPixmapOffset(ppix)<  pNv->EXADriverPtr->offScreenBase)
>>>                  return FALSE;
>>>
>>> commenting out those lines stops the players from crashing, but I still
>>> get just a black screen.
>>>        
>> I'm typing this from a mobile phone so answers will be brief sorry!
>>      
>
> No problem! I'm grateful for any kind of answers :)
>
>    
>> Your composite manager is probably unredirecting fullscreen windows.
>> We can't currently render directly to the scanout buffer with the 3D
>> engine, which is what the above code checks for.
>>      
>
> Ok, good to know, thanks.
>
>    
>>> After having crashed gmplayer (with the code lines above re-enabled), I
>>> also notice that screen updates are a bit shaky - sometimes the screen
>>> isn't updated until I press a key or move the mouse (e.g. typing 'ls'
>>> doesn't list any files until I press another key, web pages aren't
>>> displayed until I move the mouse and so on). At this point, I sometimes
>>> also see an unusually high CPU load from X (around 75%). Sometimes X
>>> freezes, sometimes not.
>>>        
>> I don't see this on my systems, but i'll look into it when i'm back in
>> action.
>>      
>
> After some more testing, I can say for sure that this isn't really related to
> the xv fullscreen issue. xv in fullscreen was just a way to trigger it. I'm
> not sure exactly what triggers it though - starting certain GUI programs
> triggers it, while other programs do not. In any case, I'm pretty sure the
> high CPU load is always there when I see the screen update issue. When this
> happens, X is stuck inside nouveau_dma_wait:
>
> (gdb) bt
> #0  0x00007f63f5f18df8 in nouveau_dma_wait (userchan=<value optimized out>,
> size=2) at nouveau_dma.c:88
> #1  0x00007f63f5f4f01d in nouveau_dma_begin (userchan=0x241aaf0,
> grobj=0x241a900, method=4916, size=1,
>      file=0x7f63f5f5b630 "NV50EXAPrepareComposite", line=695) at
> nouveau_dma.h:118
> #2  0x00007f63f5f509b0 in NV50EXAPrepareComposite (op=<value optimized out>,
> pspict=0x3eb9210, pmpict=0x3bad6c0, pdpict=0x3543430,
>      pspix=0x2f21de0, pmpix=0x522f4c0, pdpix=0x5a39230) at nv50_exa.c:695
> #3  0x00007f63f457de6a in ?? () from /usr/lib64/X11/modules//libexa.so
> #4  0x00007f63f457f097 in exaComposite () from
> /usr/lib64/X11/modules//libexa.so
> #5  0x000000000053029f in ?? ()
> #6  0x000000000051f0ad in ?? ()
> #7  0x0000000000447ef6 in Dispatch ()
> #8  0x000000000042d82d in main ()
>
> On a side note, out of curiousity I took a look at the dma_wait code; and I
> found myself wondering if the CHECK_TIMEOUT macro is really ok. My
> understanding is that it tries to avoid an expensive gettimeofday (or similar)
> in the normal case where the DMA doesn't timeout. It does this by first
> incrementing a counter, and only checks the actual time after the counter has
> reached a certain value.
>
> Two things about this:
>
> 1) the counter goes all the way up to 0xffffffff. This took ~25s on my laptop
> and ~13s on my main. As a comparison, the DMA timeout value is 2s
>
> 2) It doesn't assign a value to t_start until after the counter has reached
> 0xffffffff. Again, I guess this is to avoid an expensive gettimeofday.
> However, it also means that the actual timeout value now is the time it takes
> to increment the counter _plus_ the DMA timeout value.
>
> This may all be by design, but it did strike me as a bit suspiouses.
>    

I made that change for one simple reason, to easily expose that dma wait 
is happening. I'll have a look at it soon'ish again and make changes 
where necessary. Thanks for pointing that out, I hadn't realised that 
the counter takes that long.

>    
>>> One more odd thing is that I don't get any interrupts on the NV50 during
>>> "normal use" (as reported by /proc/interrupts). I sometimes get an
>>> interrupt storm when starting X, then nothing. I sometimes see a number
>>> of interrupts after having crashed gmplayer when trying to play a video
>>> fullscreen. But other than that, no interrupts what so ever.
>>>        
>> Completely normal, we don't currently make use of interrupts from the
>> gpu save for error reporting.
>>      
>
> Ok, I thought it may be something like that. The nvidia blob does generate
> interrupts occasionally, so I guess I was expecting nouveau to behave in a
> similar way.
>
>    
>>> One last question, and this may not even be nouveau related since I also
>>> see this with the nv driver (so please feel free to yell RTFM! or just
>>> ignore it
>>>
>>> :) ). If I start X as a non-root user, it choses 1280x1024 as default
>>>
>>> resolution (the panel's native resolution is 1680x1050). I dont't see
>>> this in KDM, or when starting as root (so, I can for example start kdm in
>>> the correct resolution, but then when I log in, as non-root, the
>>> resolution is changed to 1280x1024). It doesn't seem to matter what I set
>>> in xorg.conf. The EDID output does report 1680x1050, and xrandr also sees
>>> it. In fact, just opening the "Display" settings in KDE's control panel
>>> causes a switch to 1680x1050. Needless to say, the binary nvidia driver
>>> doesn't have this problem.
>>>
>>> Random system info:
>>>
>>> Linux tiny 2.6.28 #1 SMP Thu Dec 25 12:45:15 CET 2008 x86_64 AMD
>>> Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux
>>>
>>> 01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600 GTS
>>> (rev a1) (prog-if 00 [VGA controller])
>>>          Subsystem: ASUSTeK Computer Inc. Device 8241
>>>          Flags: bus master, fast devsel, latency 0, IRQ 18
>>>          Memory at d2000000 (32-bit, non-prefetchable) [size=16M]
>>>          Memory at c0000000 (64-bit, prefetchable) [size=256M]
>>>          Memory at d0000000 (64-bit, non-prefetchable) [size=32M]
>>>          I/O ports at a000 [size=128]
>>>          Expansion ROM at d3000000 [disabled] [size=128K]
>>>          Capabilities: [60] Power Management version 2
>>>          Capabilities: [68] MSI: Mask- 64bit+ Count=1/1 Enable-
>>>          Capabilities: [78] Express Endpoint, MSI 00
>>>          Capabilities: [100] Virtual Channel<?>
>>>          Capabilities: [128] Power Budgeting<?>
>>>          Capabilities: [600] Vendor Specific Information<?>
>>>
>>> Using latest git libdrm and nouveau sources, xorg-7.4 (server-1.5.3). If
>>> there's any other info you need, just let me know.
>>>
>>> Regards,
>>> Daniel Eklöf
>>> _______________________________________________
>>> Nouveau mailing list
>>> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>>> http://lists.freedesktop.org/mailman/listinfo/nouveau
>>>        
>
> _______________________________________________
> Nouveau mailing list
> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>    

Re: NV50: xv fullscreen issues

[Daniel Eklöf]

> > > After having crashed gmplayer (with the code lines above re-enabled), I
> > > also notice that screen updates are a bit shaky - sometimes the screen
> > > isn't updated until I press a key or move the mouse (e.g. typing 'ls'
> > > doesn't list any files until I press another key, web pages aren't
> > > displayed until I move the mouse and so on). At this point, I sometimes
> > > also see an unusually high CPU load from X (around 75%). Sometimes X
> > > freezes, sometimes not.
> >
> > I don't see this on my systems, but i'll look into it when i'm back in
> > action.
>
> After some more testing, I can say for sure that this isn't really related
> to the xv fullscreen issue. xv in fullscreen was just a way to trigger it.
> I'm not sure exactly what triggers it though - starting certain GUI
> programs triggers it, while other programs do not. In any case, I'm pretty
> sure the high CPU load is always there when I see the screen update issue.
> When this happens, X is stuck inside nouveau_dma_wait:
>
> (gdb) bt
> #0  0x00007f63f5f18df8 in nouveau_dma_wait (userchan=<value optimized out>,
> size=2) at nouveau_dma.c:88
> #1  0x00007f63f5f4f01d in nouveau_dma_begin (userchan=0x241aaf0,
> grobj=0x241a900, method=4916, size=1,
>     file=0x7f63f5f5b630 "NV50EXAPrepareComposite", line=695) at
> nouveau_dma.h:118
> #2  0x00007f63f5f509b0 in NV50EXAPrepareComposite (op=<value optimized
> out>, pspict=0x3eb9210, pmpict=0x3bad6c0, pdpict=0x3543430,
>     pspix=0x2f21de0, pmpix=0x522f4c0, pdpix=0x5a39230) at nv50_exa.c:695
> #3  0x00007f63f457de6a in ?? () from /usr/lib64/X11/modules//libexa.so
> #4  0x00007f63f457f097 in exaComposite () from
> /usr/lib64/X11/modules//libexa.so
> #5  0x000000000053029f in ?? ()
> #6  0x000000000051f0ad in ?? ()
> #7  0x0000000000447ef6 in Dispatch ()
> #8  0x000000000042d82d in main ()
>

Oh, and I almost forgot; the logs are full (as in ~500M in two days) of 

Dec 26 18:29:47 tiny [drm] PGRAPH_ERROR - nSource: 
PROTECTION_ERROR,x00000000:0x000003ec
Dec 26 18:29:47 tiny [drm] PGRAPH_ERROR - nSource: PROTECTION_ERROR, nStatus:
Dec 26 18:29:47 tiny [drm] PGRAPH_ERROR - Ch 2/0 Class 0x502d Mthd 0x08dc Data 
0x00000000:0x000003ec
Dec 26 18:29:47 tiny [drm] PGRAPH_ERROR - nSource: PROTECTION_ERROR, nStatus:
Dec 26 18:29:47 tiny [drm] PGRAPH_ERROR - Ch 2/0 Class 0x502d Mthd 0x08dc Data 
0x00000000:0x000003ec
Dec 26 18:29:47 tiny [drm] PGRAPH_ERROR - nSource: PROTECTION_ERROR, nStatus:
Dec 26 18:29:47 tiny [drm] PGRAPH_ERROR - Ch 2/0 Class 0x502d Mthd 0x08dc Data 
0x00000000:0x000003ec