[nzlug] OO.o & X.org --> @#$%&

[Nick 'Zaf' Clifford]

2 cents worth (if that)....

I have a similar problem, which I've just assumed is timeouts on files.
(with linux) I often mount windows shares everywhere, open docs, etc.
OpenOffice, when I goto the file menu, often freezes all of X, much like
you describe. (Local PC totally ineffective, but can move mouse, can
remote into PC). I've always assumed its timeouts on those mount points
from the Recent docs menu. Oh, only difference with mine, is if I wait
two minutes (very painful to do), it comes right.

If it turns out your problem is something else, please let me know, as
I'd love to solve it on my end

Only thing I can think of is to strace the OOo process went it jams (eg
remote in, strace -p <pid>) and see what its waiting on).

Nick


Guy K. Kloss wrote:
> Hi,
>
> maybe someone here on the list can offer a hint into what direction to venture 
> in order to solve this problem.
>
> I'm running here on a box running (K)Ubuntu Feisty, with an nVidia Corporation 
> NV43 [GeForce 6600] and the nVidia X.org driver (1.0.9755+2.6.20.5-16.29) in 
> a dual screen set up (one flat panel with DVI, one CRT on VGA cable). The set 
> up is on a Core 2 duo w/ 2 GB RAM.
>
> Now the effect: Every now and then, but only when working with OO.o, the X 
> session semi-freezes. "Semi" in the way that I can still move the mouse 
> cursor and see all the current desktop's content, but it moves non-smoothly, 
> and all mouse and keyboard actions are effectless. Opening an ssh session 
> from a remote box at least lets me analyse what's going on. X.org consumes 
> 100% of the CPU it's running on. Killing OO.o does not do anything. As the X 
> session is frozen all the OO.o windows stay put still with the mouse movable. 
> Only killing X.org resolved the issue, also taking down all other 
> applications.
>
> Introspection into /var/log/Xorg.0.log, /var/log/syslog and /var/log/messages 
> don't reveal any further insight.
>
> Any tipps, hints, suggestions?
>
> Guy
>
>