Messages in this thread | | | Subject | 2.1.57 glitches | Date | Sat, 27 Sep 1997 07:04:07 -0500 (CDT) | From | kwrohrer@enteract ... |
| |
I don't seem to have a growing number of lockd's per se, but I do get one by the time xdm fires up and I log in, thus giving me a permanent minimum load average of one. I do see a change from "interruptible_ sleep_on" to "sleep_on" in fs/lockd/clntlock.c in the recent past; the code looks like it's only trying to wake up every 30 * HZ (30 seconds?) and somehow either this is happening way too often (but the corresponding CPU load doesn't happen; rc5client runs as fast as usual) or this is a red herring...
New quirk: the first time I did a "ps aux | grep lockd", I got the one lockd and the grep. Subsequent times (and subsequent "ps aux | grep grep" attempts) I get no trace of the grep process. I'm not sure if that's a bug, but it is weird. Something going zippier once it gets cached, I suppose...
Also, this kernel gives me the ip_queue_glue out of memory errors which I haven't seen in quite some time, on a 32 meg machine with only 10Base2 ethernet (copying ~1.5-3 meg files to NFS, with some smaller reads coming back)... I was doing some stuff with big directories, though, and /proc/sys/vm/freepages says a mere 64 96 128, so it could just be unreaped dcache stuff and general kernel bloat.
Lastly, when I reboot this kernel, the root filesystem is not cleanly unmounted and two "deleted inodes with zero dtime" errors show up on the following fsck. Shutting down early in the boot process avoids this, as does booting 2.1.29; I'm guessing the two files are the syslog and wtmp, but I could be completely wrong; nothing looks out of place with the shutdown. My init is sysvinit 2.64 with a Red Hat setup I've kept largely intact, fwiw.
Keith
| |