Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Fresh Debian install unresponsive, maxing out cpu

Status
Not open for further replies.

frumpus

Programmer
Aug 1, 2005
113
US
I have installed Debian 5.0.4 (lenny) from the CD ISO (disk 1) onto a slightly older Dell desktop box, (2.8Ghz, 1GB ram, 2GB swap.)

Something is causing it to hang and I'm not Linux savvy enough to know where to begin troubleshooting. It takes forever and ever to load GNOME, and during that it gives me the following error:

Code:
There was an error starting the GNOME Settings Daemon

Some things such as themes, sounds or background settings 
may not work correctly.

The last error message was:

Did not receive a reply. Possible causes include: The remote 
application did not send a reply, the message bus security 
policy blocked the reply, the reply timeout expired, or the 
network connection was broken.

GNOME will still try to restart the Settings Daemon next 
time you log in.

I can get the system monitor to eventually come up, and it tells me the CPU is maxed out. When I view the processes the only one it shows as using the CPU is the system monitor itself, which is using about 50%. All other processes are sleeping. (I can use 'ps' from a root console but I don't really know how to interpret what I am seeing there.)

This started on a fresh install on a machine that had never been connected to the network. It seems to run fine in single user mode, so I have since used that to connect it to the network and run apt-get update, which ran fine but has done nothing to solve my problem.

Any advice on troubleshooting this? Should I remove GNOME and try a different GUI? Can I start bringing up processes one at a time in single user mode until I figure out which one is causing the problem? If so, how would I do that?

Any advice would be appreciated, tia.
 
You might have a look at the output of dmesg, it may show you errors occurring during boot and where the system is hanging up. If you open up a terminal window in Gnome, you'll be able to scroll around the dmesg output.

There are various log files available in /var/log/ that may be of some help.

This error seems somewhat familiar. If you find a succinct error message in dmesg, try a Google search on the exact error message. I'm sure someone has had a similar experience.

 
Thanks.

I have gone through tons of logs. dmesg looks pretty clean but I've found a couple of errors in other logs and researched them and fixed them. This has prevented the errors from returning in the logs but has done nothing to alleviate my original problem.
 
Is it just GNOME that is slow, or the system in general? Try booting it without any GUI by editing the kernel command-line and adding a "3" to the end to boot to run-level 3 (i.e. everything but the GUI). I've not used Debian much, but it probably uses GRUB as a boot loader, in which case use 'e' to edit the kernel command line and add the "3" to the end of the "kernel" line.

Once you've logged in you can use top to examine the system performance and identify any busy processes.

If everything works fine up to that point, switching GUIs would probably be a good idea... someone with Debian experience (or the Debian documentation) may be able to advise the proper way to do that.

Annihilannic.
 
Gnome should not be that slow on a 2.8 GHz machine.

Is it still slow after it finally booting up?

Unless you really need the Stable release for a production server, you might try just upgrading to Testing (Squeeze).

You could try restarting gnome-settings-daemon from a command line interface.



 
It remains slow until I kill GNOME. I have removed gdm completely and it runs fine now. Going to keep my fingers crossed and install KDE.
 
Had the same exact problem with KDE and open suse 11.2.
Once i killed KDE, cpu returned to 7% and i was on a xeon 5500


CCNP
 
Yeah KDE is no better.

After digging through the log files further I'm thinking there is a problem with the video card driver.

I'm seeing a lot of errors like the following in /var/log/Xorg.0.log:

AIGLX: 3D driver claims to not support visual 0x26

which led me here:


which lists all kinds of bugs and similar problems with intel chipset video cards.

Unfortunately, the bug/bugs do not seem to be getting fixed. :-/

There was one piece of advice, which was to place

Option "AccelMethod" "XAA"

in the Device section of /etc/X11/xorg.conf. I did that and KDE will load and run, but it is still extremely laggy and now gives me a new error:

Sound server fatal error: cpu overload, aborting

Which leads me to more bug reports relating to ALSA from 4 years ago that claim to be fixed but don't seem to be for me.

I just wanted to set up a Linux box for learning purposes and so far all I have learned is that it sucks and I hate it :-/
 
I would again suggest to consider upgrading to testing or unstable to get the newer kernel and drivers that might be available.

This is the 32 bit version?
 
Perhaps also worth trying switching to XFree86 instead of Xorg if it's an option on Debian?

Annihilannic.
 
@ pentode, I am assuming this is the 32 bit version. It was the only iso available for the i386 platform. While this is not a critical production server, it IS a precursor test bed for one. (We are migrating our primary production server from VMS.) So, I would like to stick to the stable distribution if at all possible.

I have isolated the process that is killing my CPU, it is artsd and there are multiple copies of it running. Sound is not crucial to me on this machine so I am looking into getting artsd out of the boot process. It would be nice to have sound back at some point, but that's pretty far down on my list of priorities.
 
Ironically, the reason I wanted to stick with the stable release was so I could focus on the things I needed to do and not get distracted by exactly this kind of problem. :-(
 
The proprietary drivers are the most troublesome part of Linux systems. Video, sound, and wireless. For a server application, sound is probably not necessary.

And a lot of people don't use a GUI at all with a server box, so the video issues are reduced. But I agree they can be a PITA.

The stable release is not updated to reflect new hardware that keeps coming out. The testing version will become the new stable version in the not-too-distant future, so it seems reasonable to use for a test machine. It may well have the same problems, but you can check the versions of the software in question to see the difference between stable and testing.

You may also want to look here for additional drivers:


You also modify your sources list to include "non-free" and "contrib" which will give you access to packages that do not meet the (very) strict Debian standards for "free" software.
 
All the hardware on this machine is at least 5 years old :-/
 
I'd still recommend adding contrib and non-free to your sources list.
 
I will try that. Do I just run an update after that or do I need to go looking for specific packages?
 
Current status:

I tried disabling the integrated audio and adding a pci soundcard. Same problems, artsd ran dozens of processes and killed the cpu. Now I have removed the pci card, leaving the integrated sound disabled and things are better, but not good. artsd is under control running only 1 process and not really using the cpu at all, but Xorg is using 50 - 60% of it and things are still pretty unbearable.

My understanding is that this is generally a video card issue, so I have added an ATI card in the AGP slot BUT there doesn't seem to be a way to completely disable the integrated chip. All i can do is make the agp card the primary display. So it seems the driver for the integrated chip still loads and my life still sucks.

Is there a way in Linux to prevent that device from loading?
 
generaly to stop a driver loading you add a blacklist file for the device in the /etc/modprobe.d directory
something like

Code:
blacklist [name of driver]

the tricky part is identifying the name of the driver that is causing the problem
 
any suggestions where I would go looking for that?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top