High load and extremely unresponsive system

[ChristofferS]

Binary package hint: linux-image-2.6.20-13-generic

Using latest feisty.

I have problems with very high loads which makes my system unresponsive and the disk usage is very heavy.

This problem can be reproduced in two ways:

1) Having firefox open, run aptitude dist-upgrade
2) Copy an ISO file to a USB stick (my laptop is using USB 1.1)

It started one week or so ago. It happened with 2.6.20-12-generic also.

This is a IBM Thinkpad T23 with 256 mb ram.

Some of my log files (like kern.log) are screwed up.

[ChristofferS (ubuntu-curo)]

Couldn't upload the kern.log

cp /var/log/kern.log /tmp/
cp: reading `/var/log/kern.log': Input/output error

Maybe caused by an disk error?

[Mark Reitblatt (mark-reitblatt)]

Please, if you can, attach the output of:
dmesg
lspci -vv
lspci -vvn

That's a rather old laptop. Memory/HDD problems are quite possible. Try running the memcheck app included on the install CD to rule out memory problems.

[ChristofferS (ubuntu-curo)]

I corrected the disk errors by running fsck.

I will try to run my edubuntu 6.10 install to see if it behaves the same way.

[ChristofferS (ubuntu-curo)]

I've run a memcheck, no errors reported.

I've tried to copy files from NTFS and etx3 partitions in edgy. The load was very high also, but that may be caused by using USB 1.1

Anyway, on edgy the system was responsive, with occasional mouse pointer lockups.

So I think the load is not a problem, I just thought it was.

Like I said the problem on feisty is new. I have been running feisty for a long time. It is has been rock solid, until recently.

[Mark Reitblatt (mark-reitblatt)]

I'm going to confirm since this doesn't seem to be caused by faulty HW.

[Marcus Granado (mrc-gran)]

I can confirm this unresponsiveness in feisty under high load.

My system (laptop portege 2010 with 256MB RAM) also starts thrashing without stopping after a few firefox (sometimes only 3 or 4) windows are opened at the same time (e.g.a few slashdot pages), and ps reports firefox using something like 200MB RAM). The mouse stops moving and the GUI stops responding, and I'm unable even to go to tty1 to try to kill processes (tty1+login+bash take half an hour to load - better than waiting forever for gnome-terminal to open). The system grinds to a halt, the only option is hard reset.

This did not happen in Edgy.

As an interesting side node, I did not notice this problem in another laptop with 512MB RAM running feisty.

[ChristofferS (ubuntu-curo)]

I experienced this in Gutsy using the 2.6.22 kernel.

It is hard for me to reproduce but upgrading the system sometimes gets the thrashing started.

[ChristofferS (ubuntu-curo)]

I've compiled a vanilla 2.6.21.5 kernel using the config from edgy 2.6.17. It was compiled in edgy because it failed in gutsy because of this bug - I think.

I installed the new kernel and tried to do a aptitude install openoffice and other packages (just to not overload the system).

I got the following output:

Unpacking replacement python-uno ...
dpkg: error processing /var/cache/apt/archives/python-uno_2.2.1-2ubuntu1_i386.deb (--unpack):
 fork failed: Cannot allocate memory
dpkg: error while cleaning up:
 fork failed: Cannot allocate memory
dpkg: error while cleaning up:
 fork failed: Cannot allocate memory

Can this be related to this bug?

If dpkg is allocating huge amounts of memory, the system will start to swap and become unresponsive.

Since a kernel compile will bring the system down, there is potentially other memory leaks.

[ChristofferS (ubuntu-curo)]

I've found out that my system was running without swap (using 'free').

On a system with 256 MB RAM total, it will result in an unresponsive system pretty quickly.

I think that there is a bug in both the feisty and gutsy kernel: you are allowed to allocate more memory than you have when running without swap.

The vanilla kernel behaves as it should, IMHO.

[Phillip Lougher (phillip-lougher)]

Over-committing memory is normal practice. This is the way the virtual memory subsystem in the kernel works.

The feisty and gutsy kernels should behave no differently to the vanilla kernel (we don't and can't change the behaviour in our kernels).

[ChristofferS (ubuntu-curo)]

The feisty and gutsy kernels are behaving differently than the vanilla kernel.

Using the _vanilla_ kernel:

"Unpacking replacement python-uno ...
dpkg: error processing /var/cache/apt/archives/python-uno_2.2.1-2ubuntu1_i386.deb (--unpack):
 fork failed: Cannot allocate memory"

Using Ubuntu kernels: unresponsive system.

So how can you close this bug?

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.