icfb locking up KDE in RHEL4

N

Nicolas

Guest
I wonder if some of you have encountered this problem:

When the CIW is 'busy' (Virtuoso is doing something, or some skill is
running), the KDE desktop locks up. The currently maximized windows
are the only things that respond. Everything else such as desktop
switching, KDE menus, Icons, buttons become unresponsive.

An easy way to reproduce the problem is to:
1) start icfb in KDE
2) in the CIW, enter a command that locks up the CIW, such as:
sh("xterm")
3) try invoking any KDE functionality
Click to expand...
 
On Oct 30, 9:40 pm, Nicolas <nicolasperr...@gmail.com> wrote:
I wonder if some of you have encountered this problem:

When the CIW is 'busy' (Virtuoso is doing something, or some skill is
running), the KDE desktop locks up. The currently maximized windows
are the only things that respond. Everything else such as desktop
switching, KDE menus, Icons, buttons become unresponsive.

An easy way to reproduce the problem is to:
1) start icfb in KDE
2) in the CIW, enter a command that locks up the CIW, such as:> sh("xterm")

3) try invoking any KDE functionality
Click to expand...
Set your Focus stealing prevention level to low or none in Control
Center->Desktop->Window Behavior | Advanced, and the problems go avay.
I verified that setting to Extreme actually cause the behavior you
mention.

@Cadence: Put this in a FAQ in case it hasn't been done yet.

--
Svenn
 
On Oct 31, 8:29 am, Svenn Are Bjerkem <svenn.bjer...@googlemail.com>
wrote:
On Oct 30, 9:40 pm, Nicolas <nicolasperr...@gmail.com> wrote:

I wonder if some of you have encountered this problem:

When the CIW is 'busy' (Virtuoso is doing something, or some skill is
running), the KDE desktop locks up. The currently maximized windows
are the only things that respond. Everything else such as desktop
switching, KDE menus, Icons, buttons become unresponsive.

An easy way to reproduce the problem is to:
1) start icfb in KDE
2) in the CIW, enter a command that locks up the CIW, such as:> sh("xterm")

3) try invoking any KDE functionality

Set your Focus stealing prevention level to low or none in Control
Center->Desktop->Window Behavior | Advanced, and the problems go avay.
I verified that setting to Extreme actually cause the behavior you
mention.

@Cadence: Put this in a FAQ in case it hasn't been done yet.

--
Svenn
Click to expand...
Hi Svenn,

I know the problem you are talking about with "Focus stealing
prevention Level". Unfortunately, the problem I am invoking in this
thread is a different one.
We encountered the "Focus stealing prevention Level" problem in RHEL3,
and initially we found that setting it to "none" did help. We also
found out that "Focus stealing prevention Level" can be left on, and
another solution is to set "Focus Policy" to "Focus Strictly Under
Mouse" or "Focus Under Mouse". Not everyone is happy with this focus
policy, but most Unix die hards prefers one of those.

I tried turning off "Focus stealing prevention Level" to solve my
current problem, and it did not fix it. My problem seems to be
environment variable related since not all users are experiencing the
issue.

Nicolas
 
On Tue, 30 Oct 2007, Nicolas wrote:

When the CIW is 'busy' (Virtuoso is doing something, or some skill is
running), the KDE desktop locks up. The currently maximized windows
are the only things that respond. Everything else such as desktop
switching, KDE menus, Icons, buttons become unresponsive.
Click to expand...
I have noticed this as well. However, in my case, it only happens as icfb
is loading. Once I get the splash screen, I lose KDE functionality
(except for already opened terminal windows) until I get control in the
CIW. If Virtuoso is "thinking" (ie loading a cell), I do not lose KDE
control.
 
On Oct 31, 2:12 pm, Nicolas <nicolasperr...@gmail.com> wrote:
On Oct 31, 8:29 am, Svenn Are Bjerkem <svenn.bjer...@googlemail.com
wrote:



On Oct 30, 9:40 pm, Nicolas <nicolasperr...@gmail.com> wrote:

I wonder if some of you have encountered this problem:

When the CIW is 'busy' (Virtuoso is doing something, or some skill is
running), the KDE desktop locks up. The currently maximized windows
are the only things that respond. Everything else such as desktop
switching, KDE menus, Icons, buttons become unresponsive.

An easy way to reproduce the problem is to:
1) start icfb in KDE
2) in the CIW, enter a command that locks up the CIW, such as:> sh("xterm")

3) try invoking any KDE functionality

Set your Focus stealing prevention level to low or none in Control
Center->Desktop->Window Behavior | Advanced, and the problems go avay.
I verified that setting to Extreme actually cause the behavior you
mention.

@Cadence: Put this in a FAQ in case it hasn't been done yet.

--
Svenn

Hi Svenn,

I know the problem you are talking about with "Focus stealing
prevention Level". Unfortunately, the problem I am invoking in this
thread is a different one.
We encountered the "Focus stealing prevention Level" problem in RHEL3,
and initially we found that setting it to "none" did help. We also
found out that "Focus stealing prevention Level" can be left on, and
another solution is to set "Focus Policy" to "Focus Strictly Under
Mouse" or "Focus Under Mouse". Not everyone is happy with this focus
policy, but most Unix die hards prefers one of those.

I tried turning off "Focus stealing prevention Level" to solve my
current problem, and it did not fix it. My problem seems to be
environment variable related since not all users are experiencing the
issue.
Click to expand...
When you mention environment variables, I had this problem with a
different EDA tool (not Cadence) on the console with that program.
Since I use nx from a laptop for normal use, I haven't experimented
more with that. The app died on unicode characters used in the GUI
when running on the console so I went back to nx, and it worked. I
have an almost vanilla RHEL4 installed with no company customization.

Sorry, but I think my latin ends here. No further ideas at the moment.
--
Svenn
 
Nicolas wrote:
I wonder if some of you have encountered this problem:

When the CIW is 'busy' (Virtuoso is doing something, or some skill is
running), the KDE desktop locks up. The currently maximized windows
are the only things that respond. Everything else such as desktop
switching, KDE menus, Icons, buttons become unresponsive.

An easy way to reproduce the problem is to:
1) start icfb in KDE
2) in the CIW, enter a command that locks up the CIW, such as:
sh("xterm")
3) try invoking any KDE functionality

I found that kde is too expensive to run with icfb. Too many processes.
Click to expand...
I do a top and get a system load of almost 2.0.
I switched to using TWM as my window manager, one of the oldest GUI's
and smallest. Only one process, no frills. I've not had any more
unexpected problems with icfb. I only use icfb, thunderbird, firefox,
xterms and emacs, so all the bells and whistles of kde are useless baggage.
Btw now my system load, when icfb is running in twm is always less than
1.01 most all the time. I do regression testing, so most of my cells
have < 10 rectangles.
 
On Oct 31, 7:12 pm, Billy Patton <bpat...@ti.com> wrote:
Nicolas wrote:
I wonder if some of you have encountered this problem:

When the CIW is 'busy' (Virtuoso is doing something, or some skill is
running), the KDE desktop locks up. The currently maximized windows
are the only things that respond. Everything else such as desktop
switching, KDE menus, Icons, buttons become unresponsive.

An easy way to reproduce the problem is to:
1) start icfb in KDE
2) in the CIW, enter a command that locks up the CIW, such as:
sh("xterm")
3) try invoking any KDE functionality

I found that kde is too expensive to run with icfb. Too many processes.
I do a top and get a system load of almost 2.0.
I switched to using TWM as my window manager, one of the oldest GUI's
and smallest. Only one process, no frills. I've not had any more
unexpected problems with icfb. I only use icfb, thunderbird, firefox,
xterms and emacs, so all the bells and whistles of kde are useless baggage.
Btw now my system load, when icfb is running in twm is always less than
1.01 most all the time. I do regression testing, so most of my cells
have < 10 rectangles.
Click to expand...
Would be nice to know what hardware you are running on.

I worked with twm, CDE and fwvm earlier, and there is a reason why I
now use KDE. Taste is always an individual thing, but when Cadence
start throwing windows at you it is nice to have some more
functionality to send them to the back and getting them back to the
front. RHEL4 comes default with Gnome, and I see my colleagues
searching desperately to find that terminal window where they started
icfb, where is that vim session again ... I guess it is all a matter
of how you want to work, and how much time you want to spend when you
try to customize the work environment. Several former colleagues
worked with openWindows, on Sun, happily using textedit and console
tool, long after it was mothballed by Sun.
--
Svenn
 
On Wed, 31 Oct 2007 13:12:39 -0500, Billy Patton <bpatton@ti.com> wrote:

Nicolas wrote:
I wonder if some of you have encountered this problem:

When the CIW is 'busy' (Virtuoso is doing something, or some skill is
running), the KDE desktop locks up. The currently maximized windows
are the only things that respond. Everything else such as desktop
switching, KDE menus, Icons, buttons become unresponsive.

An easy way to reproduce the problem is to:
1) start icfb in KDE
2) in the CIW, enter a command that locks up the CIW, such as:
sh("xterm")
3) try invoking any KDE functionality

I found that kde is too expensive to run with icfb. Too many processes.
I do a top and get a system load of almost 2.0.
I switched to using TWM as my window manager, one of the oldest GUI's
and smallest. Only one process, no frills. I've not had any more
unexpected problems with icfb. I only use icfb, thunderbird, firefox,
xterms and emacs, so all the bells and whistles of kde are useless baggage.
Btw now my system load, when icfb is running in twm is always less than
1.01 most all the time. I do regression testing, so most of my cells
have < 10 rectangles.
Click to expand...
That's quite surprising. I wonder if your display driver is set up properly.
That's often the thing that causes performance problems.

I use KDE all the time, without the problems you're describing (currently
on RHEL4).

Regards,

Andrew.
--
Andrew Beckett
Senior Solution Architect
Cadence Design Systems, UK.
 
This problem only seems to happen on a handful of hosts. For some
users it does not happen on any host.
If anyone has HP xw4200 or xw4400 workstations, and use the nvidia
driver, could you please post your xorg.conf files for RHEL4?
I have a feeling the problem resides in that file.
Nicolas
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top