Alright. Slack 9 (installed fresh again 20 mins ago) will just intermittantly soak up all my Athlon 2500+. After install, I installed the nForce2 drivers, modprobe nvnet (for my eth0), and did adsl-setup ; adsl-start.

Thats the extent of the work since the newest install. It's done this on every install though. I have only been using it like 3 days, but after using Mandrake for a year, I've messed up and had to reinstall Slack several times since I got it

Any suggestions? Hardware list in sig:

If you happen to be using Swaret, it may be the problem, I had this 100% CPU problem while using it, but solved changing it's config file (swaret.conf) and changing DINTERFACE=0 to 1.

Ok. What is swaret, and where is the .conf? I tried whereis, and get nothing, and get: warning: locate: could not open database: /var/lib/slocate/slocate.db: No such file or directory
when trying the 'locate' command.

You will not have swaret unless you installed it yourself, so its not that.
For slocate first time you will need to build the database, updatedb or slocate -u. (its in the man pages)
You might try the top command to see what is hogging your cpu.

good luck
tobyl

run the command "top" and see what is hogging the CPU. If it is a user process that you see over there, you can stop it with "killall -9 processname" or "kill processID"

If you don't see anything in "top" using CPU, yet your cpu is at 100% (used by system processes and such) it would be some kernel code that is causing it, and you'd be lucky if it is a module (if so, "rmmod modulename" , and comment the module name in /etc/rc.d/rc.modules so it wont load in next boot) - try to rmmod all modules and see if the CPU cools down

If you have no modules, and no process in "top" that is using the CPU, yet you are still at 100% , then that would be weird.

Good luck.

I had tried updatedb and got this:
warning: updatedb: could not open database: /var/lib/slocate/slocate.db: No such file or directory

I will try the top command and see if I can catch what is causing it. It only happens a few times per 30 mins for around 1 min at a time. I am working (once again) at compiling a new kernel (2.4.22) from the above guide in hopes that a custom kernel will help. I know it will solve some of the other issues anyway.

Thanks

Using top for awhile, I noticed that kupdated frequently hogs the cpu. It is actually competing with CC1 (which i assume is the compiler) while I recompile my kernel.

Anyone know what kupdated is all about?

Guessing here, but prolly the update daemon for something or other. Are you connected to the internet while this CPU hogging is occuring? If so, perhaps some update program or other is downloading/installing stuff automatically (and most likely in a faulty manner), and thereby is taking up all your CPU (much like Windows Update trying to download stuff over a dial-up connection... *shivers*).



-zsejk

edit: did I mention yet that I was guessing?

Yes, always-on DSL. I saw another process: "ksoftirqd" the last time. Each of these 2 was using around 50% of my cpu. I plan to search around on these, but it will have to wait till I get this kernel compile done successfully

Yeah, my "top" shows those processes too, but mine aren't using *any* CPU. So definitely do a search on what possible things could be causing them to hog the CPU.

-zsejk

bad news then, they are both kernel daemons.

Get latest kernel and recompile. Be sure to set the processor type correct. The problem is probably due to some buggy driver, of things like motherboard or hard drives. What is your HD? Is it a very slow one? Are you doing many reads/writes? Some googling tells me that kupdated will use lots of CPU when doing disk accesses a lot.

Be sure to enable DMA for your disks, as it is not default in slackware installs. You can do it with "hdparm -c1 -d1 /dev/hda" , replace hda with your drive. this enables 32-bit IO and DMA on this particular hard drive. You might want to add this to some boot script so that you have DMA on every time you reboot. (rc.local is fine, I think mine are in rc.S somewhere early on)


Be sure that your drives are using DMA, and then see if this kupdated problem persists. The irq stuff could be related to not using DMA as well.

I enabled DMA like first thing on the first few installs w/ hdparm, then on the next installs I compiled it in the kernel. My drives are pretty quick 7200rpm Maxtors. Only a 2mb cache, but that still nowhere near slow.

I am going to try 2.4.22 since it prob better supports my hardware and we'll see what happens. Pretty aggravating though, cause I really haven't had much time to 'play' with Slack since I been messing with this issue since install. This box is super fast in windows xp and mandrake 9.1 but it acts like an old celeron with Slack. I'm sure after I get the configuration right it will be smokin' with Slack.

This is just pure learning anyway. I already pre-ordered 9.1 so in a few weeks I'll be reinstalling anyway

I believe 'updatedb' needs to be run as root by default if you have not already tried this.

I ran it as root. I don't understand what could be causing that.

mrpdaemon you were right. I didn't realize that the settings would default every time I rebooted. Which /etc/rc.d/ scripts do I need to add this line so I get these settings at boot?

After doing some googling, it seems like a lot of people are having this trouble with the nForce2 chipset, and in most cases it's due to incorrect IDE settings. I have gotten a significant performance increase from playing with these settings a bit.

Before# hdparm /dev/hda = 180mb/s cache, and 2.6mb/s read.
Pretty piss poor...

Then
# hdparm -x66 -d1 -u1 -m16 -c2 /dev/hda
426mb/s cache
23.5mb/s read
A nice improvement. Slack is now totally responsive as it should be. Still need to get the #'s up a bit, but not bad.

I don't remember the default settings, but they were pretty much all 0 or disabled including Ultra DMA and 32 bit transfer.
Here's the current settings provided by the above command:

/dev/hda:
setting 32-bit IO_support flag to 2
setting multcount to 16
setting unmaskirq to 1 (on)
setting using_dma to 1 (on)
setting xfermode to 66 (UltraDMA mode2)
multcount = 16 (on)
IO_support = 2 (16-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)

Hope this helps fellow nForce2 owners
I am going to tweak some more...

Which /etc/rc.d/ scripts do I need to add this line so I get these settings at boot?