SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I'm running Slack-current with kernel 2.6.6. Earlier I used to configure everything by myself when compiling the 2.6 kernel and everything worked fine. This time I took the .config file for the 'bareacpi' kernel and used to it to compile the 2.6.6 kernel (Made changes to some sections though). Now the problem is that the mouse movement becomes jerky whenever the cpu utilization goes to the maximum (100%). I can only guess that the mouse interrupts are getting a low priority. I have a Sony Vaio with a synaptics touchpad but mostly use a Logitech usb mouse. The problem comes for both of them. Here is my '/proc/interrupts' file if it can tell something :
okay, I found out another thing. The mouse gets blocked only when the cpu utilization goes to 100% because of disk activity. I wrote a program to go into an infinite loop (which will take the processor usage to 100%) and upon running it there is no problem, the mouse works fine. Is this normal behaviour or I need to change some settings for the disk.
I had a problem similar to this when I first compiled 2.6.x. It had me wondering why people were saying that 2.6 was faster than 2.4. It turned out to be a config file problem because after staring over with a friends config file, it just went away. I also had a similar experience with an nvidia network driver. Everytime I went on the internet I would get 100% cpu usage and the transfer rate was capped by the cpu. Moving to an older nvidia driver (linux 2.4.x) or using the included forcedeth drivers in 2.6.x took care of this.
You probably have to re-enable hdparm -- hard drive tuning tool.
The mouse becomes jumpy because of i/o wait -- load up top in an xterm and do something harddrive intensive, you'll see a column for % taken by Input/Output wait.
hdparm /dev/hda -tT
will give you some handy values for comparing the performance of your drive, and whether it can be tuned more.