On Mon, 2006-07-10 at 22:08 +0200, Simen Thoresen wrote: > Hi all, > > I think I've spotted a few stupidities (bugs) in the current version of > kernel-utils (kernel-utils-2.4-13.1.80). I'm sure these are all propagated > from upstream, but I hope someone could have a quick look to verify this and > see if we either can push complaints upwards, or provide local fixes. > > The kernel-utils package provides several 'kernel-type' functions - > readahead and readahead_early and also the cpuspeed have a few problems; > > readahead 'reads ahead' (stats to copy to cache for speedy access?) the > files found in /etc/readahead.files. While most of these files are various > images and common binaries, some are libraries which have been replaced by > newer versions, thereby reducing the usefulness of readahead. > > Readahead.early uses a different file (/etc/readahead.early.files) to cache > useful system libraries, including a few kernel modules - for the > 2.6.3-2.1.238.2 kernel. > > Both readahead and readahead.early are installed as disabled. chkconfig > lists them as 'off' in all runlevels. > > Worse, cpuspeed. > This is from an Athlon64 system, so it is possible that this behavior is > different on non powernow-k8 systems. > > On the CentOS4-x86_64 kernels, the cpuspeed-drivers are built into the > kernel. Here, cpu speed-management works, as the > /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver -file exists (tested for > in /etc/init.d/cpuspeed). On CentOS4-i386, the powernow-k8-module is not > built into the kernel, so the above test fails, and the cpuspeed startscript > exits. > > There seems to be a plan for this. The /etc/cpuspeed.conf file can specify a > DRIVER variable, but no attempt is made to insmod this, so even if this is > set, cpuspeed still fails. A simple fix is to check for the presence of the > above /sys entry, and if that is missing, modprobe $DRIVER. Without this, > cpuspeed will never work on my systems. > Does it work elsewhere? cpuspeed does work for powernow enabled AMD machines. I don't disagree with any of your posts ... however, we will continue to publish these RPMS exactly as they are released upstream. I personally recommend that read ahead and read ahead early is turned off ... and also cpuspeed unless you have a laptop and it works for you. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060712/ef8a67a0/attachment-0005.sig>