lkml.org 
[lkml]   [1997]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subject2.1.57 glitches
Date
From
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

\
 
 \ /
  Last update: 2005-03-22 13:40    [from the cache]
©2003-2011 Jasper Spaans