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?
Yours -S -- Simen Thoresen, Dolphin ICS