Bug 36090

Also experienced with:

01:00.0 VGA compatible controller: nVidia Corporation NV34GL [Quadro FX 500/600 PCI] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: nVidia Corporation Device 01ba
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Expansion ROM at fd000000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel driver in use: nouveau
        Kernel modules: nouveau

Could you retest with a newer kernel/DDX? This feels like the sort of thing that probably got fixed over the past couple of years.

Note to the NV49 user, there's currently a bug in 3.11-rcX that will cause nouveau to crash on start (for nv49 and nv4e). Either use 3.10, the nouveau/master tree, or cherry pick http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=42f186b6af54b82dcee926a35440b74dbabe1623 (this will hopefully make the final 3.11 release).

Thanks for your suggestion, but I can no longer call me owner of such a card and therefore am unable to test this.

No response to retest request in a month. Closing as invalid.

Problem still exists with:

# uname -a
Linux panda.opentext.com 3.10.12-100.fc18.i686 #1 SMP Mon Sep 16 13:25:43 UTC 2013 i686 i686 i386 GNU/Linux

VGA compatible controller: NVIDIA Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1) (prog-if 00 [VGA controller])

Let me know if you need more information.

Adam

Are you on a recent version of the ddx? (xf86-video-nouveau) Also, what card do you have (G72M means nothing to me... what does nouveau say as the "Chipset" in dmesg)?

I'm not sure how to answer your question about the ddx... is this what you mean?

rpm -qa |grep -i nouveau
xorg-x11-drv-nouveau-1.0.7-1.fc18.i686

Re: the card, dmidecode suggests it is:

Quadro NVS 110M

Let me know if you need more.

Thanks,

Adam

dmesg | grep -i chipset

sounds like your ddx is new enough though.

Can you provide detailed repro steps? I'm not even sure how to enable visual bell.

#dmesg | grep -i chipset
[    1.887251] nouveau  [  DEVICE][0000:01:00.0] Chipset: G72 (NV46)

Reproduction:

You can fire up an xterm with -vb to request the visual bell.  You can also use control + middle-mouse-button to bring up a menu which allows you to enable/disable the visual bell.

Let me know if you need more.

Thanks,

Adam

Hmmm... FWIW I couldn't reproduce any oddness with a NV42 card, kernel 3.11, and xf86-video-nouveau 1.0.9 both with and without xcompmgr running. Without a compositor, it _is_ a bit on the slow side, but like a half-second, nothing like the 3s delay mentioned in the original description.

Anything else odd about your setup?

Interesting.  So, I'm a Fedora (currently v18) user.  I created a stock account, logged in to a standard Gnome environment, and fired up an xterm with visual bell running, and it doesn't have the same problem.  In fact, I couldn't even SEE a visual bell. Odd.  All I could tell was that the audible bell went away when I enabled the visual bell.

Now, that's not my usual scenario. My usual is using fvwm2 as my window manager.  And while it might take a second or so for the visual bell to run on a reasonable sized xterm, when I full-screen it, it really does take multiple seconds to complete.  Running xcompmgr didn't speed that up, but instead of the bell visually progressing up/down the screeen (watching each line draw) it drew it all at once, then waited, then removed it all at once.  Same (or, at least, similar) delay, but visually different.

Note that whatever is going right/wrong didn't used to happen using the nvidia provided driver.  I've been using the nouveau driver, and am happy to do so, but it does have this one interesting downside.

Interesting fact.  If I run the program, "screen", it changes things somehow.  I'm not sure how... but all of a sudden the visual bell becomes reasonable again.  Exiting back out of screen reverts to the undesired behaviour.

I hope that helps.

Adam

OK, by increasing the terminal size, I do indeed see that the visual bell is really rather slow. During that time, X is using up 100% CPU, so it's probably something highly unoptimal happening in the DDX.

It seems like almost all of that CPU time is going into fbSolid() from libfb, but sadly perf isn't telling me where it's getting called from for some reason. I'll try to look into it later, but wanted to record this observation in case I don't get to it.

Looking into EXA a bit, there's a EXASolid impl shared by all pre-nv50 cards. One of the things it apparently doesn't handle are 32-bit visuals with solid draws that include a fancy "op", which I assume the visual bell would, like xor or whatever. I have a hard time believing this restriction holds, so I'm going to try removing it on some cards I have (at some point).

If you guys want to play around with it, I'm talking about the

		if (ppix->drawable.bitsPerPixel == 32)
			return FALSE;

in NV04EXASetROP. Something causing NV04EXAPrepareSolid to return false would definitely explain the fallback to fbSolid.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/16.