Problem rendering windows on KDE

S

Symbiosis

Hi all,

I have an strange problem with the KDE desktop. I met the problem on 4.10.3 and 4.10.5. 4.10.3 was installed by binary packages from PC-BSD and exonetric.net repositories[ ](both of them had the same problem). 4.10.5 was compiled by myself through the ports system, again with the same problem.

The problem is that when I open more than six application (more or less) the next one is not rendering ok. If I close some of the applications that were running, then the new application opens ok.

The problem appears with only one application that opens a lot of window. For example, if in Kontact I open some windows to send emails, some windows for adding contacts and so on, when I have some of them opened, the next one will be displayed like the image that appears on the URL.

The problem is a bit difficult to explain so I attach (on the URL) an image where you can see how the application is displayed when KDE cannot render it fine. The window is open file from the VLC application. As you can see, the files don't appear correctly, the letters on the left are wrong, the bottom bar doesn't appear and so on.

http://198.211.117.228/kde_problem.png

Does anybody have some idea about what could be happening? Or could somebody confirm that they have the same problem?

Thanks a lot.

My freebsd FreeBSD version is 9.1-STABLE FreeBSD 9.1-STABLE #6 r248560 AMD64.

Thanks a lot.

Best regards.
 
Could somebody at least confirm if this behavior is normal or not on FreeBSD? The installation was a new installation in all cases (well, really it was uninstall of all ports an then reinstall them again). My computer has 8 GB of memory so I discard problems with not enough RAM (and this behavior appears without load on the computer).

Thanks a lot.

Best regards
 
Hmm, I do not have this problem and never had. What graphic card are you using? And what driver? Does this only happen to QT applications? So what about GTK applications?
 
Hi,

I check now that Firefox works fine while other applications (KDE applications) don't work fine. Firefox uses this library, so should be GTK: libgtk-x11-2.0.so.0

My graphics card is:

Code: 
vendor     = 'nVidia Corporation'
device     = 'GF108 [GeForce GT 430]'

and the driver I use is nvidia-driver-310.44_1.

Could it be a problem with the QT library instead of the KDE desktop?

Thanks a lot.

Best regards.
 
Greetings,

I'm experiencing difficulties with KDE4, as well. In my case, I was using it primarily for k3b. My WM is xfce4. I was using KDE3 and k3b without issues. But during my last upgrade, I was informed that KDE3, and QT3 were slated for removal (unmaintained). So, given that there was a KDE4 equivalent of k3b, I just went ahead, and upgraded to KDE4 with k3b from QT4. But that's when I also experienced issues much the same as you. I too am using the nVidia blob

Code: 
NVIDIA Corporation G70 [GeForce 7800 GT] / Driver  304.88

I had no issue with KDE, and the nVidia blob, while using KDE3, and QT3. So I'm not sure what to think.

What happens when you perform a CTL+ALT+F1? Do you see any QT/Xorg/KDE messages? Especially, just after getting a "garbled" window?

I see the following:
Code: 
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x0

Best wishes.

--chris
 
Hi,

I've checked that when the application fails I get a lot of errors like you:

Code: 
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x0
And the first error before all these lines appears is this one:

Code: 
QNativeImage: Unable to attach to shared memory segment.

So it seems that the problem belong to this method.

I have 8 GB of RAM memory and 4 GB of swap so it would be strange that I don't have enough memory to open okular.

At the moment of the error I had opened Firefox, konsole with 3 tabs, amarok, kontact, dolphin, VLC with music and some instance of okular until the error appears (with 2-3 instances the error appears).

If the application opens fine, then I only get this output:

Code: 
[CMD]okular a.pdf [/CMD]
okular(9433)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(9433)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(9433)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(9433)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(9433)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:

Best regards.
 
Hi all,

It seems that I solved this problem changing this value:

Code: 
kern.ipc.shmall

To make a test I changed it from 32768 to 65536 and now I can open more windows without the problem.

I don't know if change this value is dangerous or not. Maybe this is a very "conservative value" and is too small but I'm not sure about that. In theory, this value is for Total amount of shared memory available (bytes or pages) so I think it's not dangerous but maybe if I set to a big value it can cause performance problems.

Anyway, Chris_H, could you check if changing this value solves your problem too?

Thanks a lot.

Best regards.
 
Crap. My apologies. I forgot to mention that I had also tweaked these settings. I can't remember whether I found the reference in the forums here, or on the mailing list. But someone experiencing these problems said that changing the settings to:
Code: 
kern.ipc.shmmni=1024
kern.ipc.shmseg=1024
kern.ipc.shmall=32768
in loader.conf(5) fixed it for them. So I started by changing to: kern.ipc.shmall=32768, and bouncing the box. But discovering there was no appreciable difference, I went on to add the other two. About 20-30 seconds after starting X, the system froze, then rebooted.

I'll take a chance, and try the setting you posted, and report back here, my experience. Thanks for the reply.

P.S. I maybe should have mentioned; 64 GB of RAM on this system.

--chris
 
Greetings,

I added
Code: 
kern.ipc.shmall=65536
to loader.conf(5). Bounced the machine, and started X. These are my results:

First start: first open. Resize the box/window untill all looked normal/correct: after resize. Attempt to resize to any other size:after resize #2. So it looks like I'm out of luck. The console (CTRL+ALT+F1) returns the following:
Code: 
QNativeImage: Unable to attach to shared memory segment
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x0

Any other thoughts?

Best wishes.

--chris
 
Hi,

These are my other values for kern.ipc.shm that I've modified:

Code: 
kern.ipc.shmseg: 16384
kern.ipc.shmmni: 16384

But my problem was solved when I modified the value on the previous post, not these ones.

Anyway, maybe your problems resides in your amount of memory. 64 MB maybe are insufficient for executing this application (I've read in some forums that the minimum requirement for KDE is 512 MB, but this information doesn't come from KDE's official site).

Best regards.
 
cpu82 said:
These increases are documented in /usr/ports/UPDATING:
Code: 
20120527:
  AFFECTS: users of x11-toolkits/qt4-gui
  AUTHOR: kde@FreeBSD.org

  Qt started using the raster graphics system engine, which relies on
  shared memory. Be sure to check pkg-message.

Try to set a higher value to kern.ipc.shmall:
Code: 
# sysctl -w kern.ipc.shmall=131072
Click to expand...

Greetings @cpu82, and thank you for the reply.

Well, I modified the settings in loader.conf(5) to 131072, and bounced the box. Sadly, it is, as it was. On the upside; it is at least usable. But I can only size the window/box to one size. I might also add; increasing the size of kern.ipc.shmall to 65536, or 131072, seemed to make X a little less "snappy". But only noticeably, not anything that I would complain about.

Oh. as to:
Code: 
20120527:
  AFFECTS: users of x11-toolkits/qt4-gui
  AUTHOR: kde@FreeBSD.org

  Qt started using the raster graphics system engine, which relies on
  shared memory. Be sure to check pkg-message.
I religiously monitor UPDATING. In fact, I posted a question to stable-freebsd@, asking what the ideal settings are for kern.ipc.shm*. But did not receive a definitive reply. Just saying. :)

Thanks again @cpu82.

--chris
 
Last edited by a moderator:
D'OH! I think I'm an idiot! This just in... Performing the following: sysctl kern.ipc revealed the following:
Code: 
kern.ipc.shmall: 8192
kern.ipc.shmseg: 128
kern.ipc.shmmni: 192
kern.ipc.shmmin: 1
kern.ipc.shmmax: 33554432
Which isn't what I passed to loader.conf(5). Then it hit me; while I can pass these settings to sysctl(8) directly. If I'm going to use a .conf, I need to use /etc/sysctl.conf(5)! :p So, I'll add the settings there, and report back.

Thanks, and sorry.

--chris
 
Woo Hoo!

It all works exactly as intended. I used the settings that @Symbiosis initially recommended: 65536.

@@cpu82: Is there any penalty using the larger setting (kern.ipc.shmall=131072) you recommended?

+1 to both of you. Thanks!

--chris
 
Last edited by a moderator:
Hi @Chris_H,

Note that the limit on kern.ipc.shmmax is RAM + swap. The maximum number of pages (normally 4096 bytes) available for shared memory (shmall) is measured in pages and one page size is the value of PAGE_SIZE.

To check what is the page size:
Code: 
[CMD]% getconf PAGE_SIZE[/CMD]
 4096

or alternative way:
Code: 
[CMD]% sysctl hw.pagesize[/CMD]
hw.pagesize: 4096

To print the description of parameters:
Code: 
[CMD]% sysctl -d -a | grep -E "shmall|shmmax"[/CMD]
kern.ipc.shmall: Maximum number of pages available for shared memory
kern.ipc.shmmax: Maximum shared memory segment size

According to my values of parameters:
Code: 
[CMD]% sysctl -a | grep -E "shmall|shmmax"[/CMD]
kern.ipc.shmall: 131072
kern.ipc.shmmax: 536870912

which means 131072*4096=512 MB and 512 MB, respectively.

You might also want to configure your kernel to lock shared memory into RAM and prevent it from being paged out to swap. This can be accomplished using the kern.ipc.shm_use_phys parameter. This feature allows the kernel to remove a great deal of internal memory management page-tracking overhead at the cost of wiring the shared memory into core.

I strongly recommend you read the following article on the subject.
 
Last edited by a moderator:
Greetings, @cpu82.

Thank you very much for taking the time to spell it out so clearly. Thanks also, for the article -- a great read.

I haven't looked at IPC since back in the 3.2-4.2 days. When I was building kernels for 486's, 586's, and early Pentiums. It was a lot more critical, back then. But I think I want to make myself more familiar with it again.

Thanks, again.

--chris
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top