Yes, I know I shouldn't gripe about this, because this is the MM kernel, and it is unstable by nature. But since I upgraded, I have been getting random slowdowns, during which everything I do becomes "choppy" - the cursor moves in a jerky fashion, words appear more slowly than they are typed, and the system, in general, displays symptoms of its CPU being busy with something huge that I don't know about. Once a random slowdown has occured, the only way to stop it is to reboot the computer.
Right now, I am going to have to downgrade to the previous MM kernel. I can't use the stock kernel, because its via82xx driver doesn't let you change the Master or PCM volume. Also, the stock kernel is getting old and probably insecure.
Perhaps I shouldn't gripe, but - and please don't flame me for saying this - the stock kernel badly needs to be updated more often. Either that or we need a viable alternative kernel in the repos, because the MM kernel is a bit unstable for desktop use, and completely out for workstations and servers.
Although I don't personally use the arch packaged kernel, I do notice that the releases are very slow to respond to the new W.X.Y.Z kernel versioning model. As of now, the kernel in the arch repos is 22.214.171.124 , and the latest out is 126.96.36.199 ...and that's just the vanilla kernel. It wouldn't kill us to have the very latest kernel as often as possible.
The suggestion box only accepts patches.
What bugs the hell out of me is that -as is a security and bugfix oriented patchset. Why bother switching to it if you ain't gonna update the kernel?
Okay, this bug is fixed in the new MM kernel, or seems to be at least.
Actually I have same thing with stock 188.8.131.52 and 184.108.40.206 kernels.
In my case I don't know for sure if it has something to do with new kernel or with my new computer (I swiched from P3-600MHz to P4-Celeron-2Ghz)
Also I noticed that it has something to do with USB modules (I can only load ehci, if i try uhci or ohci it usualy hangs)
Another issue I have is that sometimes I can not swich to consoles (Ctrl+Alt+F[1..6]). This has probably has something to do with
intelfb: Cannot reserve FB region. Trying to free nonexistent resource <80000000-8007ffff> Trying to free nonexistent resource <88000000-8fffffff>
I have an onboard i810 video (8Mb shared memory) it looks ok on boot, in console after boot, but after I start X...can not go back to text mode.
I'll try MM kernel and let you know if it's better.
Eh? There isn't a stock 220.127.116.11 kernel... You mean one you compiled yourself?
There is one in testing repo...
I know... it's testing repo, no warranty... but it worked before.
Well, kernel26mm is a little better..but still after some time it becomes unusable.
Right now i'm running 2.4.29 :cry: I don't have GLX, USB, SOUND and so on... but at least i can work...
One thing I saw is before completly lock the system kswapd0 was eating 100% of CPU.
Maybe someone can find something about this... :?:
kswapd0 was eating 100% of CPU
Yeah, I'm having the same issues now. It's weird, it seems to happen when I'm doing stuff like sftping over a load of files or recording some audio. It doesn't happen with the stock Arch kernel, but with the MM, it happens inevitably (I guess the time depends on when I do enough to fill up my 1 gig of RAM). Any insights anyone? dp?
Due to lack of response, I think I'll start a new thread about this later today with some more info. I've done some further investigation that I can elaborate on a little here.
So like I said, I don't experience the same problems on my system when using the vanilla Arch kernel. I can do 'cat /dev/hda > /dev/null' to stimulate and test the problem. Yep, everytime I do it with MM, kswapd0 loses its mind, and the insanity lasts well after I end the cat test. CPU usage stays up to 100%, but nothing ever actually enters into swap. Does no one else running the MM kernel have this problem? I can't imagine what would cause it.
I also removed the nvidia driver from my system so that I would have a "non-tainted" kernel. Experienced the same issue. I also booted up in single-user mode and I had the same problems when I used the cat test.
So, does anyone have any insight. It'd be great if we could get a few more people testing their kernel to see if it's a problem for them that they just haven't noticed yet. To start it, just run top in one terminal, and run cat /dev/hda > /dev/null in another. If kswapd0 goes bananas when all your physical memory has been touched, then you'll know your kernel has the problem.
Anyway, thanks for any feedback that you could offer.
Turn off your swap partition.
Swap is old and useless anyway. Unless you happen to be doing something taxing on the system like video or audio editing where it needs the extra space, but for most systems these days which have plenty of ram, swap is practically obsolete.
Besides, dont complain about the mainline kernel not being updated often, its *really* not hard to cd into /var/abs/kernel/kernel26/ change 1 number, and then makepkg.
And its not like it takes long either, a kernel compile on my computer takes 15 minutes with the Arch config, 7 with my own config. I have a 1.4ghz centrino based lappy, so anything newer will be even quicker.
I appreciate your feedback, but you sound a little brusque in your message and I'm not sure what to make of it.
I am doing audio editing, but it's true that 1 gig of ram may be enough to take care of my needs, so I'll look into disabling swap.
I wasn't complaining about the updates to the kernel, but you may be responding to someone else.
I used to compile my own kernels with gentoo, but I've been sticking with the packaged kernels to be consistent with the Arch system.
So, I downloaded the sources and compiled my own up to date MM kernel, and it does't seem to have the same "kswapd0 run amok" problem that the Arch MM kernel has. I guess it could be anything in there doing it. I know that the Arch kernels have a lot of stuff turned on by default that I didn't turn on in my kernel.
As a side note, I did try disabling swap on the Arch MM kernel and that didn't seem to fix the problem. Yeah, it said in top that I had 0 swap, but as soon as my physical memory was all paged out, kswapd0 start chewing up my cpu. Weird.
Thanks for the advice.