Bug#370709: xserver-xorg-video-nv: system hang in NVSync() when scrolling programs or terminal windows
On Tue, May 08, 2007 at 09:14:24PM +0200, Brice Goglin wrote:
> Hi,
>
> About a year ago,
Rather about 6 months ago...
> you reported (or replied to) a bug in the Debian BTS
> regarding a system hang in NVSync() when scrolling programs or terminal
> windows. Did any of you guys reproduce this problem recently? With
> Xorg/Etch? If not, I will close this bug in the next weeks.
First a followup of my last post. It seems that setting
XaaNoScanlineCPUToScreenColorExpandFill is not sufficient in reducing lock ups
significantly enough for everyday use. I've tried to regularly test different
settings through normal system reboots in order to close in upon the problem.
I've not finished but it seems the problem is not tied to one or a few
setting(s). Here's my current relevant config settings that *very* rarely
locks up X here (with the last two options being important AFAICR):
Option "XaaNoCPUToScreenColorExpandFill"
Option "XaaNoScanlineCPUToScreenColorExpandFill"
Option "XaaNoScreenToScreenColorExpandFill"
# Option "XaaNoScreenToScreenCopy"
# Option "XaaNoSolidFillRect"
Option "XaaNoSolidFillTrap"
Option "XaaNoSolidTwoPointLine"
Option "XaaNoSolidBresenhamLine"
Option "XaaNoSolidHorVertLine"
Option "XaaNoDashedTwoPointLine"
Option "XaaNoDashedBresenhamLine"
Option "XaaNoMono8x8PatternFillRect"
# Option "XaaNoMono8x8PatternFillTrap"
# Option "XaaNoColor8x8PatternFillRect"
# Option "XaaNoColor8x8PatternFillTrap"
# Option "XaaNoImageWriteRect"
# Option "XaaNoScanlineImageWriteRect"
# Option "XaaNoWriteBitmap"
# Option "XaaNoWritePixmap"
Option "XaaNoPixmapCache"
Option "XaaNoOffscreenPixmaps"
As for the newest software versions, I upgraded all my installed *xorg*
packages to the versions in "testing", and I quickly reproduced the bug(s)
using full acceleration. Five seconds into the first video capture with
"streamer" did lock up X, as did saving a sound sample from "sweep" (always
happens after the save completes but before the progress bar returns to normal,
and doesn't happen everytime).
So I guess we're not finished with this bug, that may be in a more generic
package IMO. Aren't there similar problems with other video cards?
#389080 may also be related to this IMO. When X locks up, it seems to take
*most* CPU cycles for itself: an audio application like ogg123 running in the
background still gets cycles, but not enough, resulting in a small part of
the sound (about 0.2s) regularly (about every second) reaching the sound card.
Maybe there's an important loop in X where tests/workarounds/whatever could
easily be inserted in order to facilitate debugging/lockup breaking?
I'm surprised there's not more feedback given the real annoyance this bug is.
Aren't there any other easy tests we could perform without messing with X
sources?
Reply to: