Re: Scheduling linux-2.6.16 2.6.16-17
On Sat, 15 Jul 2006 13:15:04 +0200, Mattia Dongili wrote:
> On Sat, Jul 15, 2006 at 12:26:48PM +0200, Martin Michlmayr wrote:
>> * Bastian Blank <waldi@debian.org> [2006-07-15 02:17]:
>> > > thanks to Martin who added all pending 2.6.16 minor releases, we should
>> > > now upload the package as soon as possible, to have the local root hole
>> > > fixed in the testing kernel - 2.6.15 is vulnerable too.
>> > We need to integrate 18b0bbd8ca6d3cb90425aa0d77b99a762c6d6de3, but I
>> > think we will see at least 2.6.17.5 today.
>>
>> I've applied 2.6.16.25 and the "Relax /proc fix a bit" patch to the
>> 2.6.16 tree.
>
> may I also suggest 436fe7b8b4a5016ef1fcb32bff77bde84003e15d ?
>
> description is:
> [CPUFREQ] Make powernow-k7 work on SMP kernels.
> Even though powernow-k7 doesn't work in SMP environments,
> it can work on an SMP configured kernel if there's only
> one CPU present, however recalibrate_cpu_khz was returning
> -EINVAL on such kernels, so we failed to init the cpufreq driver.
>
> Current k7 kernels are being built with SMP=y so they don't allow
> powernow-k7 being loaded on non-SMP on UP systems.
> A similar fix has been in Ubuntu kernels since February.
> The same patch is probably useful for 2.6.16 too.
I can't use the Debian 2.6.17 k7 kernels because powernow-k7 is broken.
It's the same modprobe error message as discussed here:
<http://lists.debian.org/debian-italian/2006/07/msg00108.html>
My notebook can just shut itself off when running on batteries with max
frequency using 100% cpu so a working powernow-k7 module is critical.
Since the Debian 2.6.16 (tested up to -16) k7 kernels work and the Debian
2.6.17 (-1 and -3) k7 kernels don't can you please first apply this patch
to 2.6.17 kernel source. I can then let you know whether new 2.6.17
kernels are usable. Please don't accidentally break Debian's 2.6.16 kernel
source until 2.6.17 is at least a usable alternative.
My notebook is a single processor Compaq Presario 900 series with a
Mobile AMD Athlon(tm) XP 1800+. Even with the fatal modprobe powernow-k7
message with linux-image-2.6.17-1-k7 (version 2.6.17-3) the CPU is
correctly recognised:
modprobe powernow-k7
FATAL: Error inserting powernow_k7
(/lib/modules/2.6.17-1-k7/kernel/arch/i386/kernel/cpu/cpufreq/powernow-k7.ko):
No such device
...dmesg reports:
powernow: PowerNOW! Technology present. Can scale: frequency and voltage.
...and bootup /var/log/kern.log reports:
powernow: PowerNOW! Technology present. Can scale: frequency and voltage.
Detected 1523.982 MHz processor.
powernow: SGTC: 13333
powernow: Minimum speed 530 MHz. Maximum speed 1523 MHz.
Could the underscore in the message "Error inserting powernow_k7" be an
important detail? The name of the module is powernow-k7, not powernow_k7.
I have downloaded and differenced these parts of linux-source-2.6.16
(2.6.16-16) and linux-source-2.6.17 (2.6.17-3). powernow-k7.c appears to
be functionally identical:
diff -u linux-source-2.6.16/arch/i386/kernel/cpu/cpufreq/powernow-k7.c /usr/src/linux-source-2.6.17/arch/i386/kernel/cpu/cpufreq/powernow-k7.c
--- linux-source-2.6.16/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2006-03-20 17:53:29.000000000 +1200
+++ /usr/src/linux-source-2.6.17/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2006-06-18 13:49:35.000000000 +1200
@@ -199,8 +199,8 @@
powernow_table[j].index |= (vid << 8); /* upper 8 bits */
dprintk (" FID: 0x%x (%d.%dx [%dMHz]) "
- "VID: 0x%x (%d.%03dV)\n", fid, fid_codes[fid] / 10,
- fid_codes[fid] % 10, speed/1000, vid,
+ "VID: 0x%x (%d.%03dV)\n", fid, fid_codes[fid] / 10,
+ fid_codes[fid] % 10, speed/1000, vid,
mobile_vid_table[vid]/1000,
mobile_vid_table[vid]%1000);
}
@@ -368,8 +368,8 @@
}
dprintk (" FID: 0x%x (%d.%dx [%dMHz]) "
- "VID: 0x%x (%d.%03dV)\n", fid, fid_codes[fid] / 10,
- fid_codes[fid] % 10, speed/1000, vid,
+ "VID: 0x%x (%d.%03dV)\n", fid, fid_codes[fid] / 10,
+ fid_codes[fid] % 10, speed/1000, vid,
mobile_vid_table[vid]/1000,
mobile_vid_table[vid]%1000);
@@ -460,7 +460,7 @@
(maxfid==pst->maxfid) && (startvid==pst->startvid))
{
dprintk ("PST:%d (@%p)\n", i, pst);
- dprintk (" cpuid: 0x%x fsb: %d maxFID: 0x%x startvid: 0x%x\n",
+ dprintk (" cpuid: 0x%x fsb: %d maxFID: 0x%x startvid: 0x%x\n",
pst->cpuid, pst->fsbspeed, pst->maxfid, pst->startvid);
ret = get_ranges ((char *) pst + sizeof (struct pst_s));
diff -s linux-source-2.6.16/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c /usr/src/linux-source-2.6.17/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
Files linux-source-2.6.16/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c and /usr/src/linux-source-2.6.17/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c are identical
There's one difference in amd.c:
diff -u linux-source-2.6.16/arch/i386/kernel/cpu/amd.c /usr/src/linux-source-2.6.17/arch/i386/kernel/cpu/amd.c
--- linux-source-2.6.16/arch/i386/kernel/cpu/amd.c 2006-07-09 04:03:31.000000000 +1200
+++ /usr/src/linux-source-2.6.17/arch/i386/kernel/cpu/amd.c 2006-06-18 13:49:35.000000000 +1200
@@ -214,8 +214,6 @@
if (cpuid_eax(0x80000000) >= 0x80000008) {
c->x86_max_cores = (cpuid_ecx(0x80000008) & 0xff) + 1;
- if (c->x86_max_cores & (c->x86_max_cores - 1))
- c->x86_max_cores = 1;
}
if (cpuid_eax(0x80000000) >= 0x80000007) {
Regards,
Adam
Reply to: