speedstep-ich and ich5, [speedstep]

I hope I make no mistake now. I started a thread with Dominik a couple of weeks ago but not in this mailing list. Now I'm back from vacation and will continue troubleshooting. Thanks for understanding.

I tried this patch (http://marc.theaimsgroup.com/?l=acpi4linux&m=107684287525298&w=2) with no success. The module won't load. I'm not sure that the mistake is using kernel 2.6.8-rc3 instaed of rc2?

modprobe acpi
FATAL: Error inserting acpi (/lib/modules/2.6.8-rc3-bk1/kernel/arch/i386/kernel/cpu/cpufreq/acpi.ko): No such device

---
Christian Heimanns
[email protected]

### Pinguine können nicht fliegen
- Pinguine stürzen auch nicht ab! ###

Hope you had a good vacation!

Did you use the patch at that location, or the one I sent you [which is more up to date]? If it's the latter, I might have made an error in some way or other in "updating" the patch...

Just to make sure: the error doesn't appear without the patch?

Dominik

Compiling takes a while ;-)
Without the patch the kernelmodule acpi.ko loads without problems. I'm waiting for new orders :-)

---
Christian Heimanns
[email protected]

### Pinguine können nicht fliegen
- Pinguine stürzen auch nicht ab! ###

Sorry for the effort you have to get cpufreq to work on your notebook.

oh yes, the patch contained a brown paper bag bug. This new version is also tested by me, so maybe it helps now.

Thanks,
Dominik

[Follow-up to http://marc.theaimsgroup.com/?l=acpi4linux&m=107684287525298&w=2
and
which were the last tries of getting this right last February, and FIXME]

Notify SMM of cpufreq

Often, the BIOS changes the CPU frequency if a notebook is (dis)connected from its AC adapter. This interferes with a) an user setting the CPU frequency and b) kernel timing code which needs to know loops_per_jiffy, cpu_khz etc.

So, ACPI 2.0 offers a method to disable such BIOS changes -- writing a value contained in the FADT (pstate_cnt) to the smi_cmd port. This patch utilizes this method by doing this write in processor.c.

However, most current notebooks only offer 1.0 ACPI tables, where the pstate_cnt entry is marked as "reserved". Unless ACPI is in strict mode, the value in this "reserved" field is used as well, but a warning is printed.

So, when is the BIOS notified? When should it be notified? The ACPI specification doesn't say much about it. This patch does it if either of the following cpufreq drivers is pretty much done with a successful registration:

- acpi
- powernow-k7 [if either it is blacklisted or acpi_force is used]
- powernow-k8 [if the preferred DSDT method is used -- normally, it is...]
- speedstep-centrino [if the preferred DSDT method is used -- normally, it is...]

There's a small problem with the whole pstate_cnt approach: if there is a pyhsical[*] platform limit, it might be necessary to adjust the CPU frequency to avoid serious problems. Unless the BIOS is notified the kernel is aware of _PPC, the BIOS will likely do such adjustments on its own. As it is notified now that the OS is handling P-States, it might be that the BIOS won't handle such serious limits -- but if the cpufreq driver is "rmmod'ed" in between, it won't be handled. This is a serious error, but it will _also_ happen on _any_ OS if:
a) the pstate_cnt is written to the BIOS
b) the system locks up hard afterwards so that even IRQs are not handled any more
c) the physical platform limit event occurs

So, both the cpufreq driver and the acpi processor module are "locked" (i.e. rmmod won't work any more) if the BIOS contains a _PPC entry, and acpi_processor_notify_smm() is called.

[*] not the "we-want-to-have-X-hours-of-battery-time-in-that-test" type of platform limits...

 arch/i386/kernel/cpu/cpufreq/acpi.c               |    4 -
 arch/i386/kernel/cpu/cpufreq/powernow-k7.c        |    3
 arch/i386/kernel/cpu/cpufreq/powernow-k8.c        |    4 +
 arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c |    3
 drivers/acpi/processor.c                          |   87 +++++++++++++++++++---
 drivers/acpi/tables/tbconvrt.c                    |   10 ++
 include/acpi/actbl.h                              |    2
 include/acpi/processor.h                          |    4 +
 8 files changed, 106 insertions(+), 11 deletions(-)

diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/acpi.c linux/arch/i386/kernel/cpu/cpufreq/acpi.c
@@ -335,7 +335,9 @@
 	if (result) {
 		goto err_freqfree;
 	}
-		
+
+	/* notify BIOS that we exist */
+	acpi_processor_notify_smm(THIS_MODULE);
 
 	printk(KERN_INFO "cpufreq: CPU%u - ACPI performance management activated.\n",
 	       cpu);

diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c
@@ -400,6 +400,9 @@
 	powernow_table[i].frequency = CPUFREQ_TABLE_END;
 	powernow_table[i].index = 0;
 
+	/* notify BIOS that we exist */
+	acpi_processor_notify_smm(THIS_MODULE);
+
 	return 0;
 
 err2:

diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k8.c linux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
@@ -768,6 +768,10 @@
 	data->numps = data->acpi_data.state_count;
 	print_basics(data);
 	powernow_k8_acpi_pst_values(data, 0);
+
+	/* notify BIOS that we exist */
+	acpi_processor_notify_smm(THIS_MODULE);
+
 	return 0;
 
 err_out_mem:

diff -ruN linux-original/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c linux/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
@@ -423,6 +423,9 @@
 			centrino_model->op_points[i].frequency = CPUFREQ_ENTRY_INVALID;
 	}
 
+	/* notify BIOS that we exist */
+	acpi_processor_notify_smm(THIS_MODULE);
+
 	return 0;
 
  err_kfree_all:

diff -ruN linux-original/drivers/acpi/tables/tbconvrt.c linux/drivers/acpi/tables/tbconvrt.c
@@ -50,6 +50,8 @@
 	 ACPI_MODULE_NAME    ("tbconvrt")
 
 
+u8 acpi_fadt_is_v1;
+
 /*******************************************************************************
  *
  * FUNCTION:    acpi_tb_get_table_count

@@ -212,6 +214,7 @@
 
 	/* ACPI 1.0 FACS */
 	/* The BIOS stored FADT should agree with Revision 1.0 */
+	acpi_fadt_is_v1 = 1;
 
 	/*
 	 * Copy the table header and the common part of the tables.

@@ -240,9 +243,12 @@
 	/*
 	 * Processor Performance State Control. This is the value OSPM writes to
 	 * the SMI_CMD register to assume processor performance state control
-	 * responsibility. There isn't any equivalence in 1.0, leave it zeroed.
+	 * responsibility. There isn't any equivalence in 1.0, but as many 1.x
+	 * ACPI tables contain _PCT and _PSS we also keep this value, unless
+	 * acpi_strict is set.
 	 */
-	local_fadt->pstate_cnt = 0;
+	if (acpi_strict)
+		local_fadt->pstate_cnt = 0;
 
 	/*
 	 * Support for the _CST object and C States change notification.

diff -ruN linux-original/include/acpi/actbl.h linux/include/acpi/actbl.h
@@ -343,5 +343,7 @@
 #include "actbl1.h"   /* Acpi 1.0 table definitions */
 #include "actbl2.h"   /* Acpi 2.0 table definitions */
 
+extern u8 acpi_fadt_is_v1; /* is set to 1 if FADT is revision 1,
+			    * needed for certain workarounds */
 
 #endif /* __ACTBL_H__ */

diff -ruN linux-original/include/acpi/processor.h linux/include/acpi/processor.h
@@ -140,4 +140,8 @@
 	struct acpi_processor_performance * performance,
 	unsigned int cpu);
 
+/* note: this locks both the calling module and the processor module
+         if a _PPC object exists, rmmod is disallowed then */
+int acpi_processor_notify_smm(struct module *calling_module);
+
 #endif

_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq

Hmm.... I've compiled kernel-2.6.8-rc3-bk3 with your new version but no changes for me. I'm able to 'modprobe acpi' now, but I still cannot change the frequencies when connected to the power supply. If running on battery it is possible. Is it possible that this is purposed by the manufacturer?

The output of dmesg tells me nothing new:
cpufreq: CPU0 - ACPI performance management activated.
cpufreq: *P0: 3059 MHz, 0 mW, 500 uS
cpufreq: P1: 1019 MHz, 0 mW, 500 uS

I still have the feeling that there is something wrong with the implementation of hyperthreading(HT). I mentioned a time ago that I use my notebook with HT diabled in the BIOS and no SMP support in the kernel. With HT enabled and SMP + HT support in the kernel my notebook will freeze randomly. Don't ask me why....

But ACPI tells me a little difference when I enable/disable HT support in the BIOS:
HT enabled: ACPI: Processor [CPU0] (supports C1, 8 throttling states) HT disabled: ACPI: Processor [CPU0] (supports C1 C2, 8 throttling states)

Throttling works fine as far as I know under both conditions. When HT is disabled CPU power management seems also to work (switching between C1 and C2). I've also checked the INTEL documentation (25302804.pdf), Mobile Intel(R) Pentium(R) 4 Processor with 533 MHz System Bus Datasheet. Is it possibele that the CPU reports as a Mobile CPU but doesn't support frequency and voltage scaling? I won't open the notebook to do a 100 percent check what kind of CPU really is build in....

I appreciate your support and help
thanks,

Christian

---
Christian Heimanns
[email protected]

### Pinguine können nicht fliegen
- Pinguine stürzen auch nicht ab! ###

It might be, though it wouldn't really make sense. After all, you don't want an overheating notebook or a noisy notebook even when you have access to AC power.

... and the P1 state really tells us that some BIOS writer made a mistake:
it will be, most likely, the SL77P CPU which supports 3.06 GHz and 1.60 GHz as speeds, but not 1.019 MHz [that'd be a strange multiplier, 1.912 ... won't say that it's technically impossible, but nobody will do it that way.]

Don't ask me, either. Don't have HT or SMP hardware myself, and it is most likely not related to cpufreq.

No surprise here; power management becomes complicated in the SMP (even HT) case. And as some legacy OSes have trouble with some variants, P-States are usually disabled if HT is enabled...

Doubt it. Check 25317607.pdf instead, table 2 on page 8 contains your CPU, I guess...

Back to the original problem: pstate_cnt doesn't work, disabling irqs doesn't work... I'm running out of ideas at the moment. Hopefully new ideas will appear soon... in the meantime, could you send a lspci [no additional options needed] again, please?

Thanks,
Dominik

No problem, see attachement please.

Christian

---
Christian Heimanns
[email protected]

### Pinguine können nicht fliegen
- Pinguine stürzen auch nicht ab! ###

00:00.0 Host bridge: Intel Corp. 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02) 00:01.0 PCI bridge: Intel Corp. 82865G/PE/P PCI to AGP Controller (rev 02)
00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 (rev 02) 00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2 (rev 02) 00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02) 00:1d.3 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4 (rev 02) 00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB/ER Hub interface to PCI Bridge (rev c2) 00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100 Storage Controller (rev 02) 00:1f.3 SMBus: Intel Corp. 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) 00:1f.6 Modem: Intel Corp. 82801EB/ER (ICH5/ICH5R) AC'97 Modem Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 032c (rev a1) 03:04.0 CardBus bridge: Texas Instruments: Unknown device ac8e
03:04.1 CardBus bridge: Texas Instruments: Unknown device ac8e
03:04.2 FireWire (IEEE 1394): Texas Instruments: Unknown device 802e
03:04.3 Unknown mass storage controller: Texas Instruments: Unknown device ac8f
03:05.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 03:06.0 Network controller: Harris Semiconductor D-Links DWL-g650 A1 (rev 01)

processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Mobile Intel(R) Pentium(R) 4 CPU 3.06GHz
stepping : 9
cpu MHz : 3059.208
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
bogomips : 6062.08

_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq

What we haven't looked at yet is the raw DSDT output. Can you run the DSDT and/or SSDTs through "iasl -d", please? You'll need the pmtools and the iasl compiler and disassembler, and they're available at http://acpi.sf.net

acpidmp > acpidmp.txt
acpixtract SSDT acpidmp.txt > SSDT
iasl -d SSDT
cat SSDT.dsl

for the SSDT, and s/SSDT/DSDT for the DSDT.

Thanks,
Dominik

O.K.

The file is empty, no SSDT !?

Works just for DSDT

Please see attached files. In the past I tried to fix my DSDT table. I did the following:
cat /proc/acpi/dsdt > dsdt.dat
./iasl -d dsdt.dat
./iasl -tc dsdt.dsl
I'm able to fix some of the errors, see attached file.
Then I compiled a new kernel with the ACPI-DSDT-patch available from
http://gaugusch.at/kernel.shtml. But there are no differences for me discernible.

Thank you,

---
Christian Heimanns
[email protected]

### Pinguine können nicht fliegen
- Pinguine stürzen auch nicht ab! ###

_______________________________________________
Cpufreq mailing list
[email protected]
http://www.linux.org.uk/mailman/listinfo/cpufreq

This is sooo strange:

...

...

the frequency and "control" value which needs to be written to a BIOS port so that a frequency transition occurs are saved in a "non-volatile storage", and by executing the CPU-init method

they're saved in the appropriate fields inside the _PSS package:

... and I doubt that _either_ the values found in the non-volatile storage, or the propagation of these values to _PSS is broken:

a) Does anybody know whether there a way to read out the current _PSS in a different OS?
b) What's the best method to directly access the non-volatile storage area mentioned above to read out the P0FQ to P1CT values?

Thanks,
Dominik