SHM issues with the nvidia driver and beryl

[Gnusix]

Hi there,

I haver a GeForce 7300 Go (laptop card). I've been playing with beryl for a long time. Right now I'm experiencing the same problems described in this thread :

http://www.nvnews.net/vbulletin/showthread.php?t=91882

My keyboard doesn't respond anymore. I can move my mouse (but the pointer doesn't change (if move over a clickable area the hand doesn't show at all). Switching to text terminal impossible. If I log in via ssh from another machine I can see Xorg eating all the cpu it can get (luckly the laptop is a core duo).

Tailing the /var/log/Xorg.log file shows some bursts of this message :

(EE) NVIDIA(0) : Failed to attach to shared memory segment #id_segment

That suggested me to increase shmall and shmmax. As the first is in pages (of 4kb) and the second in bytes, the max values I tried were :

kern.ipc.shmall=262144
kern.ipc.shmmax=1073741824

I thought that increasing won't solve the problem. I tried both xorg-server 1.2.0.2 and 1.2.99 RC3, they didn't solve the problem, Xorg keeps eating cpu at will.

As a bonus, I compiled 9631 version of the driver. Telling init to go single user, allowed me to remove 9755 module and plugin 9631 kernel module. When removing the newest one, a message was logged telling me some memory leaks caused by the module where found :

Jun 24 13:37:39 portatil kernel: nvidia0: detached
Jun 24 13:37:39 portatil kernel: Warning: memory type nvidia leaked
memory on destroy (95 allocations, 2427200 bytes leaked).[/

Perharps this is related. Right now with 9631 from ports "seems" work.

Any idea will be appreciated. Is this fixed with the newest version ? (I think I tried and it failed too but I'm not quite sure).

Greets

[zander]

Please generate and attach an nvidia-bug-report.log file, as well as instructions on how to reproduce this problem (or these problems) reliably.

[Gnusix]

I tried to restore my previous config to the 9746 module and libs with the 'right' xorg which causes the problem. An so It happened ! Attached is the log file you requested.

There are two problems :

1.- Memory leaks. When removing both 9746 and 9631 the kernel informs
that the module didn't freed some allocation it made.

2.- Xorg and beryl eating all the cpu they can get. With 1.2.99 version
of xorg-server (xorg-server-snap in the port tree) the one that goes mad is
the Xorg proces, which must be killed by root. With the stable version of
the xorg server is beryl the one which is hungry. In this case Xorg logged
this to the Xorg.log file :

(EE) NVIDIA(0): Failed to attach to shared memory segment 655467.

Sometimes I had seen this messages many times. It happens as soon as I start using beryl (one minute or two are needed to cause the problem).

have very big figures for both shmall and shmmax (taking into account that shmall is in pages and shmmax in bytes), to prevent this problem :

kern.ipc.shmall: 262144
kern.ipc.shmmax: 1073741824

I'm reverting my config to 9631. Then I'll try to change some configs I have in min and inform of my results.

Greets

[Gnusix]

I forgot to tell that the system was built from ports. I'm posting here my /etc/make.conf, perharps the gcc flags may be of your interest.

CFLAGS=-O2 -pipe -march=prescott -funroll-loops
CPUTYPE=prescott
NO_SENDMAIL=true
PERL_VER=5.8.8
PERL_VERSION=5.8.8
X11BASE=/usr/local
LIBPCAP_OVERWRITE_BASE=yes
WITH_NVIDIA_GL=yes
WANT_PGSQL_VER=82
WITHOUT_MOZILLA=yes
WITH_KDE=yes
WITH_CUPS=yes
WITH_ICONS=KDE
XORG_UPGRADE=yes
# added by use.perl 2007-06-22 23:29:22
PERL_VER=5.8.8
PERL_VERSION=5.8.8

When it started to fail, I was using more flags in the CFLAGS variable. As soon as I thought that could the problem, I started rebuilding the whole system with this options. In both cases it happened.

And well, testing with 9631 module and libs from the port system rendered the same behaviour. It took more time, but finally it happened again. My Xorg.0.log.old shows this :

(EE) NVIDIA(0): Failed to attach to shared memory segment 14549034.


Nothing special needed to trigger the problem. In this case beryl was using one core. I was able to connect from another system and kill it. Do you want me to try anything special ? May be compiling without march or such ?
Tried to change options in beryl but didn't helped (reading the forum I found may people telling to change the render path, etc ... Tried all combinations without success).

Greets

[Gnusix]

More things. Until now I was using a patch to solve beryl update problems. I'm attaching the patch. It just forces an screen update in both whenever a damage event happens, both partial or full screen. That patch gives you frames per second, instead of seconds per frame (this is, It was extremely slow, no one else is having this problem?).

So I have done the following :

0.- cvsup the port tree (removing that patch).
1.- Rebuild in force mode x11/xorg via portmanager (portmanager x11/xorg -f -l)
2.- Rebuild beryl ( portmanager x11-wm/beryl -l -f).

Everything goes sloooow. No shm problems, because It hadn't got enough time (i think). With the patch I happended inmediatly. Perharps you can reproduce the problem with this patch (it must be applied from the work/beryl-core directory, "patch -p0 < patch-display" . Got to rename it to .gz, it is not compressed)

Any idea ? I'm desesperate.

[flz]

Up?

Is this being worked on?

[AaronP]

Hi flz,

Please try adding
kern.ipc.shmseg=512
to /boot/loader.conf.

[muhkuh]

We ran into the same issue when using a lot of frame buffer objects in our code (>36). We also had to increase kern.ipc.shmmni to 512 in /boot/loader.conf. IMHO it would be a good idea to add this to the FAQ or Common Problems section in the driver's readme.