I have discovered a regression between linux-2.4.20-8 (Redhat 9) and
linux-2.6.0-test4. I have not tried any other versions of linux-2.6.0-testX
or 2.5.x.
How to reproduce the problem:
1. Running GNOME on linux-2.6.0-test4, open two gnome-terminals.
2. In the first gnome-terminal, run "ls -R /" or "ls -R /dev" (you won't
have to wait as long :-).
3. In the second gnome-terminal, simply run "ls" (or just opening a
gnome-terminal window will sometimes cause the same problem).
Actual Results:
The ls in the first gnome-terminal will usually freeze. Neither CTRL+C nor
CTRL+Z will kill the ls process. The gnome-terminal itself is NOT frozen.
Its window menus are still responsive.
Expected Results:
ls should not freeze. The same steps on linux-2.4.20-8 (Redhat 9) do not
freeze ls. Running "ls -R /dev" on linux-2.6.0-test4 before starting X or
GNOME does not freeze ls either. So the problem seems to have something to
do with multiple interactive GNOME processes..?
chris
On Sun, 7 Sep 2003 11:37:31 -0700, Chris Peterson wrote:
> I have discovered a regression between linux-2.4.20-8 (Redhat 9) and
> linux-2.6.0-test4. I have not tried any other versions of linux-2.6.0-testX
> or 2.5.x.
>
> How to reproduce the problem:
> 1. Running GNOME on linux-2.6.0-test4, open two gnome-terminals.
> 2. In the first gnome-terminal, run "ls -R /" or "ls -R /dev" (you won't
> have to wait as long :-).
> 3. In the second gnome-terminal, simply run "ls" (or just opening a
> gnome-terminal window will sometimes cause the same problem).
>
> Actual Results:
> The ls in the first gnome-terminal will usually freeze. Neither CTRL+C nor
> CTRL+Z will kill the ls process. The gnome-terminal itself is NOT frozen.
> Its window menus are still responsive.
>
If you reset the terminal via the menu, the terminal will unfreeze (until
the next freeze).
Grab the RPMs from Severn for gnome-terminal and vte. It will slow down
the terminal I/O and avoid the problem. I'm not entirely sure whether
this is a fix or just avoiding the problem with more computation (I'm
running on a 300 MHz notebook), but I can now do a "make menuconfig".
-Paul
thanks, Paul. I grabbed the new gnome-terminal and vte RPMs and they seem to
fix the problem.
chris
----- Original Message -----
From: "Paul Dickson" <[email protected]>
To: "Chris Peterson" <[email protected]>
Cc: <[email protected]>
Sent: Sunday, September 07, 2003 3:10 PM
Subject: Re: [PROBLEM] "ls -R" freezes when using gnome-terminal on
linux-2.6.0-test4
> On Sun, 7 Sep 2003 11:37:31 -0700, Chris Peterson wrote:
>
> > I have discovered a regression between linux-2.4.20-8 (Redhat 9) and
> > linux-2.6.0-test4. I have not tried any other versions of
linux-2.6.0-testX
> > or 2.5.x.
> >
> > How to reproduce the problem:
> > 1. Running GNOME on linux-2.6.0-test4, open two gnome-terminals.
> > 2. In the first gnome-terminal, run "ls -R /" or "ls -R /dev" (you won't
> > have to wait as long :-).
> > 3. In the second gnome-terminal, simply run "ls" (or just opening a
> > gnome-terminal window will sometimes cause the same problem).
> >
> > Actual Results:
> > The ls in the first gnome-terminal will usually freeze. Neither CTRL+C
nor
> > CTRL+Z will kill the ls process. The gnome-terminal itself is NOT
frozen.
> > Its window menus are still responsive.
> >
>
> If you reset the terminal via the menu, the terminal will unfreeze (until
> the next freeze).
>
> Grab the RPMs from Severn for gnome-terminal and vte. It will slow down
> the terminal I/O and avoid the problem. I'm not entirely sure whether
> this is a fix or just avoiding the problem with more computation (I'm
> running on a 300 MHz notebook), but I can now do a "make menuconfig".
>
> -Paul
>
>