[gentoo-sparc] kernel-2.6.15-r4 (gentoo-sources-2.6.15-r4) stability and SB1000

[Ferris McCormick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have been running this kernel for about a week on an SB1000-SMP (1x900, 
1x750) (sparc64) system and on a U60-SMP(2x450) system.  I have just begun 
a test on U2(2x400) system.  So far, on SB1000 and U60, this kernel seems 
as stable as anything we have seen.  On U2, it is too early to tell, but 
since NO 2.6.xx kernel has been stable on U1/U2 systems, I do not hold out 
much hope there.

The reason for any sort of note mentioning this is the kernel's execution 
characteristics on SB1000.  Here there seems to be a good 
news/you-might-want-a-local-mod news situation.
1.  Good news:  For me, at any rate, up until now programs (occasionally 
gcc, but also the build of dev-lisp/sbcl-0.9.9 always, sometimes xterm) 
sometimes failed with unpredictable BUS errors, SegFaults, and similar.
(Frequency was about once a day or so).  I have not seen this at all for a 
week, now, sbcl-0.9.9 builds fine, etc.

2.  Not so good news:  With this version of the kernel, kenvctrld is very 
intrusive.  Well, so what and what is it, anyway?  kenvctrld is a kernel 
module which periodically (literally) takes the system's temperature at a 
couple spots, and if necessary kicks up the fan speed to keep the CPUs 
from melting (and slows fans back down once temperature is lowered, or 
eventually shuts the system down if things get worse).  To be fair to this 
kernel, I do not think kenvctrld actually managed to run with previous 
kernels, but with this series, it has been restructured and is most 
certainly does run.

It runs every five seconds.  It takes 2 seconds with one CPU running at 
100% in the system to actually read the sensors.  So, with a 2-CPU system, 
40% of CPU0 is dedicated to figuring out how hot the system is.

Well, that is pretty extreme.  But wait!  There's more!  If your system 
happens to be doing some actual work (like compiling something), and if 
you happen to be doing interactive work using X besides, then during this 
2-out-of-every-five second interval, your display gets little or no 
service.  (E.g., you have things like a 2-second type-ahead on the 
keyboard, you move your mouse and nothing happens, things like xosview 
stop.  You get the idea).

There are two ways to make this a little better.  First, you can build 
kenvctrld as a module (CONFIG_BBC_I2C=m) and not load it.  Then kenvctrld 
does not run and the fans always run at top speed.  If your system is in a 
different room from you, this might be tolerable.  If it isn't, with this 
option you will go deaf.

Second, you can play with the polling interval.  In the source module
drivers/sbus/char/bbc_envctrld.c, there is this definition for the polling 
interval:
#define POLL_INTERVAL     (5 * 1000)
With this definition, you lose about 40% of one CPU (CPU0).  I have found 
that I can tolerate
#define POLL_INTERVAL     (5 * 1000 * 18)
which changes the interval to 90 seconds.  This seems too long, but if I 
am correct about earlier kernels, it is better than the "never run" we had 
earlier.  (Or, it could be that earlier kernels did take that 2 seconds 
out of every five without killing interactive performance while doing so.)

Hope this is useful,
Regards,
Ferris
- --
Ferris McCormick (P44646, MI) <fmccor@g.o>
Developer, Gentoo Linux (Devrel, Sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD69xTQa6M3+I///cRAlo8AKCxwsDRvF/O8Hy8oJWIDvDMXfHUdgCgtBRo
5Nir5e0eVpzjcXesW1K/JS8=
=Bmb2
-----END PGP SIGNATURE-----
-- 
gentoo-sparc@g.o mailing list