Nouveau - Aug 2013 - "Stuttering" display, NVA0 chipset.

I'm running xorg-x11-drv-nouveau-1.0.9-1.fc19.x86_64 and xorg-x11-server- 
Xorg-1.14.2-9.fc19.x86_64

On the following chipset, the display suffers from "stuttering":

06:00.0 VGA compatible controller: NVIDIA Corporation GT200b [GeForce GTX  
285] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: Gigabyte Technology Co., Ltd Device 34c9
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+  
Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-  
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 256 bytes
        Interrupt: pin A routed to IRQ 24
        Region 0: Memory at f7000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Region 3: Memory at f8000000 (64-bit, non-prefetchable) [size=32M]
        Region 5: I/O ports at dc00 [size=128]
        Expansion ROM at f6f80000 [disabled] [size=512K]
        Capabilities: <access denied>
        Kernel driver in use: nouveau

[   531.742] (--) NOUVEAU(0): Chipset: "NVIDIA NVA0"

By "stutters" I mean that at random intervals, at least several times
a
minute, the entire display completely freezes, for an interval ranging  
between about quarter of a second, to sometimes as long as 5-6 seconds.

By "freezes" I mean that it just stops updating. No artifacts, just a
frozen
display.

When the display eventually becomes unstuck, it's completely up to date.  
Everything that should be rendered, to that point, is rendered. It's as if  
the framebuffer continues to get updated normally, but the display is not  
being refreshed. Except for the mouse pointer! When the display is not  
refreshing, the mouse pointer continues to be responsive.

Basically, if I'm playing some video, the audio keeps going, the video stops
for 1-6 seconds, then continues running, synchronized with the audio. Or, if  
I'm typing something on the terminal, after the display unsticks itself,  
everything that was typed in the interim, is where it should be. That's the
best way I can describe it.

I see no complaints in /var/log/messages, nor in Xorg.0.log

I have the same kernel, nouveau, and Xorg version running on different  
hardware with an NVC1 chipset, no issues there. That display is smooth as  
butter.

I'm fairly certain that this is a recent regression. I've had this
hardware
for at least three years, and this problem is fairly recent. Can't quite  
recall at which kernel/Xorg/nouveau version this started happening.

I don't think it's a bad DVI cable. If I drop out of X, and to som work
on
the console terminal (VESA framebuffer display only), the display does not  
appear to stutter at all.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130828/2c0eb797/attachment.pgp>

On 28/08/13 23:03, Sam Varshavchik wrote:
> I'm running xorg-x11-drv-nouveau-1.0.9-1.fc19.x86_64 and
> xorg-x11-server-Xorg-1.14.2-9.fc19.x86_64
> 
> On the following chipset, the display suffers from "stuttering":
> 
> 06:00.0 VGA compatible controller: NVIDIA Corporation GT200b [GeForce
> GTX 285] (rev a1) (prog-if 00 [VGA controller])
>        Subsystem: Gigabyte Technology Co., Ltd Device 34c9
>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR+ FastB2B- DisINTx-
>        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>        Latency: 0, Cache Line Size: 256 bytes
>        Interrupt: pin A routed to IRQ 24
>        Region 0: Memory at f7000000 (32-bit, non-prefetchable) [size=16M]
>        Region 1: Memory at d0000000 (64-bit, prefetchable) [size=256M]
>        Region 3: Memory at f8000000 (64-bit, non-prefetchable) [size=32M]
>        Region 5: I/O ports at dc00 [size=128]
>        Expansion ROM at f6f80000 [disabled] [size=512K]
>        Capabilities: <access denied>
>        Kernel driver in use: nouveau
> 
> [   531.742] (--) NOUVEAU(0): Chipset: "NVIDIA NVA0"
> 
> By "stutters" I mean that at random intervals, at least several
times a
> minute, the entire display completely freezes, for an interval ranging
> between about quarter of a second, to sometimes as long as 5-6 seconds.
> 
> By "freezes" I mean that it just stops updating. No artifacts,
just a
> frozen display.
> 
> When the display eventually becomes unstuck, it's completely up to
date.
> Everything that should be rendered, to that point, is rendered. It's as
> if the framebuffer continues to get updated normally, but the display is
> not being refreshed. Except for the mouse pointer! When the display is
> not refreshing, the mouse pointer continues to be responsive.
> 
> Basically, if I'm playing some video, the audio keeps going, the video
> stops for 1-6 seconds, then continues running, synchronized with the
> audio. Or, if I'm typing something on the terminal, after the display
> unsticks itself, everything that was typed in the interim, is where it
> should be. That's the best way I can describe it.
> 
Hello Sam,

To be honest I've experienced something similar although my issue was
caused by the kernel swapping like crazy. There is a memory leak
somewhere on my system that causes X to consume ~800MiB of RES memory
after ~10days.

That said you could try connecting remotely to the system (ssh) and see
what is causing the issue - htop and perf would be some of the tools you
can use.
> I see no complaints in /var/log/messages, nor in Xorg.0.log
> 
When you say "complains" I'm not sure what exactly you are looking
for
or expecting to see. Nouveau kernel Errors and warnings are indicated as
"nouveau E" and "nouveau W" respectively.
In general the output of dmesg is more reliable source of information
than /var/log/messages.
> I have the same kernel, nouveau, and Xorg version running on different
> hardware with an NVC1 chipset, no issues there. That display is smooth
> as butter.
> 
> I'm fairly certain that this is a recent regression. I've had this
> hardware for at least three years, and this problem is fairly recent.
> Can't quite recall at which kernel/Xorg/nouveau version this started
> happening.
> 
How that is a pain, I guess you can try one piece at a time. I seriously
doubt that the X server is responsible, with that said I would suspect
the mesa/gallium driver (nouveau_dri.so) to be related.
> I don't think it's a bad DVI cable. If I drop out of X, and to som
work
> on the console terminal (VESA framebuffer display only), the display
> does not appear to stutter at all.
> 
Hmm AFAIK nouveau kicks out the VESA framebuffer driver.

Cheers
Emil

Emil Velikov writes:
> On 28/08/13 23:03, Sam Varshavchik wrote:
> > I'm running xorg-x11-drv-nouveau-1.0.9-1.fc19.x86_64 and
> > xorg-x11-server-Xorg-1.14.2-9.fc19.x86_64
> >
> > On the following chipset, the display suffers from
"stuttering":
> >
> > 06:00.0 VGA compatible controller: NVIDIA Corporation GT200b [GeForce
> > GTX 285] (rev a1) (prog-if 00 [VGA controller])
> >        Subsystem: Gigabyte Technology Co., Ltd Device 34c9
> >        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > ParErr+ Stepping- SERR+ FastB2B- DisINTx-
> >        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
>TAbort-
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> >        Latency: 0, Cache Line Size: 256 bytes
> >        Interrupt: pin A routed to IRQ 24
> >        Region 0: Memory at f7000000 (32-bit, non-prefetchable)
[size=16M]
> >        Region 1: Memory at d0000000 (64-bit, prefetchable) [size=256M]
> >        Region 3: Memory at f8000000 (64-bit, non-prefetchable)
[size=32M]
> >        Region 5: I/O ports at dc00 [size=128]
> >        Expansion ROM at f6f80000 [disabled] [size=512K]
> >        Capabilities: <access denied>
> >        Kernel driver in use: nouveau
> >
> > [   531.742] (--) NOUVEAU(0): Chipset: "NVIDIA NVA0"
> >
> > By "stutters" I mean that at random intervals, at least
several times a
> > minute, the entire display completely freezes, for an interval ranging
> > between about quarter of a second, to sometimes as long as 5-6
seconds.
> >
> > By "freezes" I mean that it just stops updating. No
artifacts, just a
> > frozen display.
> >
> > When the display eventually becomes unstuck, it's completely up to
date.
> > Everything that should be rendered, to that point, is rendered.
It's as
> > if the framebuffer continues to get updated normally, but the display
is
> > not being refreshed. Except for the mouse pointer! When the display is
> > not refreshing, the mouse pointer continues to be responsive.
> >
> > Basically, if I'm playing some video, the audio keeps going, the
video
> > stops for 1-6 seconds, then continues running, synchronized with the
> > audio. Or, if I'm typing something on the terminal, after the
display
> > unsticks itself, everything that was typed in the interim, is where it
> > should be. That's the best way I can describe it.
> >
> Hello Sam,
>
> To be honest I've experienced something similar although my issue was
> caused by the kernel swapping like crazy. There is a memory leak
> somewhere on my system that causes X to consume ~800MiB of RES memory
> after ~10days.
>
> That said you could try connecting remotely to the system (ssh) and see
> what is causing the issue - htop and perf would be some of the tools you
> can use.
There's no need to connect remotely. The system is running normally. Like I
described, the display only freezes for a few seconds, at the most, then the  
system resumes running normally.

I does look like it's thrashing, and, now that I look at it, I am not  
swapping, 0 swap used. It does look a bit suspicious that gnome-shell is  
using up almost 3 gigs of RAM, and virt-manager another 1.5gb, but I've got
16 gigs, and there's no swap being used..
>
> > I see no complaints in /var/log/messages, nor in Xorg.0.log
> >
> When you say "complains" I'm not sure what exactly you are
looking for
> or expecting to see. Nouveau kernel Errors and warnings are indicated as
> "nouveau E" and "nouveau W" respectively.
> In general the output of dmesg is more reliable source of information
> than /var/log/messages.
I was looking for complaints about lost hardware interrupts, DMA errors,  
stuff like that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130828/143a5d02/attachment.pgp>