Re: Everyone's a captain on a calm sea...

Matti Aarnio (matti.aarnio@sonera.fi)
Mon, 31 May 1999 14:01:38 +0300


On Sun, May 30, 1999 at 08:11:23PM -0700, Ted Rolle wrote:
> Well, it's been a well-known problem since as far back as RH 4.2.
> It has persisted all this time -- I checked on #linux and others
> confirmed it.
>
> Is there a 'back door' to get a terminal session? What about Alt-SysRq?
>
> My own systems have all been i486+. The lockup seems to occur at random
> times when Netscape is up. There is constant disk activity during the
> problem; response is slow -- 30 seconds for the cursor to move after
> the mouse has moved -- sometimes.

Ah, now this sounds familiar. You are running out of memory,
and that horrendous sluggishnes is due to swapping to disk.

You need more of physical memory, and/or swap space.

But like Alan said, telling your CURRENT kernel version would
also help at solving this. What is the one you are running ?
What kind of disk system you have ? (IDE/ATAPI, SCSI/...)
What distribution are you using ? Have you customized anything ?

If kernel 2.2.5/whatever at RedHat 6.0 (for example) is having
these same problems, then the kernel core coders really need to
know about it! If 2.0.* behaves badly, *shrug*...

Anyway, at the situation of userspace process growing until
"free" reported space is gone also from swap, the SYSTEMS should
not deadlock all by itself.

> What information should I gather when the problem recurs? I _may_ have a
> set of data that can reproduce the problem -- it is a message of my wife's
> on usa.net that locked it up twice.

At an xterm, do repeatedly run "free" program while trying to
get that problem message with your current method. Do note
the amounts of "free" during that time. Do they go to zero ?

Then (after recovering from the hangup) Try to use some different
(non-GUI) POP email client by which you can pull the messages out
of your ISP to your local disk. (I use mutt )

If the message is *large*, systems reading everything into
memory (like NetScape Communicator does) will require MASSIVE
amounts of physical ram to produce any decent performance,
and a plenty of swap to work at all.

> I realize that this a "something's wrong, please fix it" request, but it
> points to a long-standing problem: that of ending a rogue program.
> Perhaps someone else can provide more information.

/Matti Aarnio

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/