Re: speedstep-ich and ich5, [speedstep]

Re: speedstep-ich and ich5, [speedstep]

[Christian Heimanns]

Hello Dominik

Here are some news:
Today I've written a mail to Medion where I asked for a new BIOS. But I 
have just a slight hope to get one. I will see and wait.

I changed two settings (self-explanatory) in the BIOS:
QuickBoot Mode = Disabled
Boot-time Diagnostic Screen = Enabled
Now I can see the following boot message from the BIOS directly after 
power on my notebook:

***********************************************************************
*                                                                     *
* An incompatibility between the system and CPU FSB has been detected.*
* You have installed a faster CPU into a system incapable of running  *
* it as fast as the CPU is capable of.                                *
*                                                                     *
* This CPU is not running at it's peak performance                    *
*                                                                     *
***********************************************************************

Maybe this is related to our problem? Meanwhile I guess that WindowsXP 
has the same problem, but I'm not able to verify it reliable.

cu,

-- 
---
Christian Heimanns
heimanns@versanet.de

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

Re: speedstep-ich and ich5, [speedstep]

[Dominik Brodowski]

On Tue, Aug 17, 2004 at 09:33:44PM +0200, Christian Heimanns wrote:
> Hello Dominik
> 
> Here are some news:
> Today I've written a mail to Medion where I asked for a new BIOS. But I 
> have just a slight hope to get one. I will see and wait.
> 
> I changed two settings (self-explanatory) in the BIOS:
> QuickBoot Mode = Disabled
> Boot-time Diagnostic Screen = Enabled
> Now I can see the following boot message from the BIOS directly after 
> power on my notebook:
> 
> ***********************************************************************
> *                                                                     *
> * An incompatibility between the system and CPU FSB has been detected.*
> * You have installed a faster CPU into a system incapable of running  *
> * it as fast as the CPU is capable of.                                *
> *                                                                     *
> * This CPU is not running at it's peak performance                    *
> *                                                                     *
> ***********************************************************************
> 
> Maybe this is related to our problem?

This is very likely relate to our problem -- it basically tells us "the BIOS
isn't really aware of the CPU and doesn't know how to handle it". Amazing
the notebook got selled this way... So, any news from MEDION?

	Dominik

Re: speedstep-ich and ich5, [speedstep]

[Christian Heimanns]

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.

Dominik Brodowski wrote:
 >>Please find attached my acpi_pdump.report.tar.bz2 file. It includes two
 >>files with the dmesg information running on ac and battery (no
 >>differences).
 >
 > Hm. So it seems to be the BIOS which doesn't like being told to switch
 > frequencies once on AC power.
 >
 >
 >>Tomorrow I go on a two weeks vacation with my family to Turkey. No
 >>computers I promised. When I'm back I will post to the cpufreq mailing
 >>list if you agree.
 >
 >
 > Please do so -- and I hope you had a fine vacation! Just got an idea 
what
 > might be the cause of the problem -- could you try out the attached 
patch,
 > please?

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
heimanns@versanet.de

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

Re: speedstep-ich and ich5, [speedstep]

[Dominik Brodowski]

On Sat, Aug 07, 2004 at 03:00:34PM +0200, Christian Heimanns wrote:
> 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.

Hope you had a good vacation!

> I tried this patch 
> (http://marc.theaimsgroup.com/?l=acpi4linux&m=107684287525298&w=2

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...

>) 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

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

	Dominik

Re: speedstep-ich and ich5, [speedstep]

[Christian Heimanns]

>>) 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
> 
> 
> Just to make sure: the error doesn't appear without the patch?
> 

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


-- 
---
Christian Heimanns
heimanns@versanet.de

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

Re: speedstep-ich and ich5, [speedstep]

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

On Sat, Aug 07, 2004 at 04:40:01PM +0200, Christian Heimanns wrote:
> 
> >>) 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
> >
> >
> >Just to make sure: the error doesn't appear without the patch?
> >
> 
> Compiling takes a while ;-)

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

> Without the patch the kernelmodule acpi.ko loads without problems. I'm 
> waiting for new orders :-)

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


[-- Attachment #2: cpufreq-2.6.8-rc3-acpi_notify_smm --]
[-- Type: text/plain, Size: 11304 bytes --]

[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...

Signed-off-by: Dominik Brodowski <linux@brodo.de>

 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
--- linux-original/arch/i386/kernel/cpu/cpufreq/acpi.c	2004-08-05 17:45:13.000000000 +0200
+++ linux/arch/i386/kernel/cpu/cpufreq/acpi.c	2004-08-08 18:31:12.591798016 +0200
@@ -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
--- linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k7.c	2004-08-05 17:45:13.000000000 +0200
+++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c	2004-08-08 18:31:12.595797408 +0200
@@ -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
--- linux-original/arch/i386/kernel/cpu/cpufreq/powernow-k8.c	2004-08-05 17:45:13.000000000 +0200
+++ linux/arch/i386/kernel/cpu/cpufreq/powernow-k8.c	2004-08-08 18:31:12.596797256 +0200
@@ -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
--- linux-original/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c	2004-08-06 21:56:12.000000000 +0200
+++ linux/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c	2004-08-08 18:31:12.761772176 +0200
@@ -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/processor.c linux/drivers/acpi/processor.c
--- linux-original/drivers/acpi/processor.c	2004-08-05 17:41:40.000000000 +0200
+++ linux/drivers/acpi/processor.c	2004-08-08 18:31:12.818763512 +0200
@@ -759,7 +759,10 @@
  * policy is adjusted accordingly.
  */
 
-static int acpi_processor_ppc_is_init = 0;
+#define PPC_REGISTERED   1
+#define PPC_IN_USE       2
+
+static int acpi_processor_ppc_status = 0;
 
 static int acpi_processor_ppc_notifier(struct notifier_block *nb, 
 	unsigned long event,
@@ -817,6 +820,10 @@
 	 * (e.g. 0 = states 0..n; 1 = states 1..n; etc.
 	 */
 	status = acpi_evaluate_integer(pr->handle, "_PPC", NULL, &ppc);
+
+	if (status != AE_NOT_FOUND)
+		acpi_processor_ppc_status |= PPC_IN_USE;
+
 	if(ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
 		ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Error evaluating _PPC\n"));
 		return_VALUE(-ENODEV);
@@ -841,17 +848,17 @@
 
 static void acpi_processor_ppc_init(void) {
 	if (!cpufreq_register_notifier(&acpi_ppc_notifier_block, CPUFREQ_POLICY_NOTIFIER))
-		acpi_processor_ppc_is_init = 1;
+		acpi_processor_ppc_status |= PPC_REGISTERED;
 	else
 		printk(KERN_DEBUG "Warning: Processor Platform Limit not supported.\n");
 }
 
 
 static void acpi_processor_ppc_exit(void) {
-	if (acpi_processor_ppc_is_init)
+	if (acpi_processor_ppc_status & PPC_REGISTERED)
 		cpufreq_unregister_notifier(&acpi_ppc_notifier_block, CPUFREQ_POLICY_NOTIFIER);
 
-	acpi_processor_ppc_is_init = 0;
+	acpi_processor_ppc_status &= ~PPC_REGISTERED;
 }
 
 /*
@@ -1072,6 +1079,73 @@
 }
 
 
+int acpi_processor_notify_smm(struct module *calling_module) {
+	acpi_status		status;
+	static int		is_done = 0;
+
+	ACPI_FUNCTION_TRACE("acpi_processor_notify_smm");
+
+	if (!(acpi_processor_ppc_status & PPC_REGISTERED))
+		return_VALUE(-EBUSY);
+
+	if (!try_module_get(calling_module))
+		return_VALUE(-EINVAL);
+
+	/* is_done is set to negative if an error occured,
+	 * and to postitive if _no_ error occured, but SMM
+	 * was already notified. This avoids double notification
+	 * which might lead to unexpected results...
+	 */
+	if (is_done > 0) {
+		module_put(calling_module);
+		return_VALUE(0);
+	}
+	else if (is_done < 0) {
+		module_put(calling_module);
+		return_VALUE(is_done);
+	}
+
+	is_done = -EIO;
+
+	/* Can't write pstate_cnt to smi_cmd if either value is zero */
+	if ((!acpi_fadt.smi_cmd) ||
+	    (!acpi_fadt.pstate_cnt)) {
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+			"No SMI port or pstate_cnt\n"));
+		module_put(calling_module);
+		return_VALUE(0);
+	}
+
+	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Writing pstate_cnt [0x%x] to smi_cmd [0x%x]\n", acpi_fadt.pstate_cnt, acpi_fadt.smi_cmd));
+
+	/* FADT v1 doesn't support pstate_cnt, many BIOS vendors use
+	 * it anyway, so we need to support it... */
+	if (acpi_fadt_is_v1) {
+		ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Using v1.0 FADT reserved value for pstate_cnt\n"));
+	}
+
+	status = acpi_os_write_port (acpi_fadt.smi_cmd,
+				     (u32) acpi_fadt.pstate_cnt, 8);
+	if (ACPI_FAILURE (status)) {
+		ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
+				  "Failed to write pstate_cnt [0x%x] to "
+				  "smi_cmd [0x%x]\n", acpi_fadt.pstate_cnt, acpi_fadt.smi_cmd));
+		module_put(calling_module);
+		return_VALUE(status);
+	}
+
+	/* Success. If there's no _PPC, we need to fear nothing, so
+	 * we can allow the cpufreq driver to be rmmod'ed. */
+	is_done = 1;
+
+	if (!(acpi_processor_ppc_status & PPC_IN_USE))
+		module_put(calling_module);
+
+	return_VALUE(0);
+}
+EXPORT_SYMBOL(acpi_processor_notify_smm);
+
+
 #ifdef CONFIG_X86_ACPI_CPUFREQ_PROC_INTF
 /* /proc/acpi/processor/../performance interface (DEPRECATED) */
 
@@ -1228,7 +1302,7 @@
 
 	ACPI_FUNCTION_TRACE("acpi_processor_register_performance");
 
-	if (!acpi_processor_ppc_is_init)
+	if (!(acpi_processor_ppc_status & PPC_REGISTERED))
 		return_VALUE(-EINVAL);
 
 	down(&performance_sem);
@@ -1269,9 +1343,6 @@
 
 	ACPI_FUNCTION_TRACE("acpi_processor_unregister_performance");
 
-	if (!acpi_processor_ppc_is_init)
-		return_VOID;
-
 	down(&performance_sem);
 
 	pr = processors[cpu];
diff -ruN linux-original/drivers/acpi/tables/tbconvrt.c linux/drivers/acpi/tables/tbconvrt.c
--- linux-original/drivers/acpi/tables/tbconvrt.c	2004-08-05 17:43:25.000000000 +0200
+++ linux/drivers/acpi/tables/tbconvrt.c	2004-08-08 18:31:12.931746336 +0200
@@ -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
--- linux-original/include/acpi/actbl.h	2004-08-05 17:41:46.000000000 +0200
+++ linux/include/acpi/actbl.h	2004-08-08 18:31:12.986737976 +0200
@@ -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
--- linux-original/include/acpi/processor.h	2004-08-05 17:41:46.000000000 +0200
+++ linux/include/acpi/processor.h	2004-08-08 18:31:12.986737976 +0200
@@ -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

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

Re: speedstep-ich and ich5, [speedstep]

[Christian Heimanns]

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

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
heimanns@versanet.de

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

Re: speedstep-ich and ich5, [speedstep]

[Dominik Brodowski]

On Sun, Aug 08, 2004 at 11:49:55PM +0200, Christian Heimanns wrote:
> >oh yes, the patch contained a brown paper bag bug. This new version is
> >also tested by me, so maybe it helps now.
> 
> 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?

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.

> 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

... 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.]

> 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....
Don't ask me, either. Don't have HT or SMP hardware myself, and it is most
likely not related to cpufreq.

> 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).

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...

> 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?

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

Re: speedstep-ich and ich5, [speedstep]

[Christian Heimanns]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

Dominik Brodowski wrote:

> 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?

No problem, see attachement please.

Christian

-- 
---
Christian Heimanns
heimanns@versanet.de

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

[-- Attachment #2: lspci.txt --]
[-- Type: text/plain, Size: 1638 bytes --]

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)

[-- Attachment #3: cpuinfo.txt --]
[-- Type: text/plain, Size: 443 bytes --]

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


[-- Attachment #4: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

Re: speedstep-ich and ich5, [speedstep]

[Dominik Brodowski]

On Tue, Aug 10, 2004 at 06:56:12PM +0200, Christian Heimanns wrote:
> Dominik Brodowski wrote:
> 
> >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?
> 
> No problem, see attachement please.
> 
> Christian

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

Re: speedstep-ich and ich5, [speedstep]

[Christian Heimanns]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

Dominik Brodowski wrote:

> 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
O.K.
> acpixtract SSDT acpidmp.txt > SSDT
The file is empty, no SSDT !?
> iasl -d SSDT
> cat SSDT.dsl

> for the SSDT, and s/SSDT/DSDT for the DSDT.
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
heimanns@versanet.de

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


[-- Attachment #2: files.tar.bz2 --]
[-- Type: application/x-bzip, Size: 33522 bytes --]

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq

Re: speedstep-ich and ich5, [speedstep]

[Dominik Brodowski]

This is sooo strange:

>     OperationRegion (MNVS, SystemMemory, 0x1FF7A000, 0x1000)
>     Field (MNVS, AnyAcc, Lock, Preserve)
>     {
...
>         Offset (0xF20), 
>         P0FQ,   16, 
>         P0PW,   16, 
>         P0CT,   16, 
>         P1FQ,   16, 
>         P1PW,   16, 
>         P1CT,   16, 
...

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

>     Scope (_PR)
>     {
>         Processor (CPU0, 0x00, 0x00001010, 0x06)
>         {
>             Method (_INI, 0, NotSerialized)
>             {
>                 Store (\P0FQ, Index (DerefOf (Index (_PSS, 0x00)), 0x00))
>                 Store (\P0PW, Index (DerefOf (Index (_PSS, 0x00)), 0x01))
>                 Store (\P0CT, Index (DerefOf (Index (_PSS, 0x00)), 0x04))
>                 Store (\P1FQ, Index (DerefOf (Index (_PSS, 0x01)), 0x00))
>                 Store (\P1PW, Index (DerefOf (Index (_PSS, 0x01)), 0x01))
>                 Store (\P1CT, Index (DerefOf (Index (_PSS, 0x01)), 0x04))
>             }

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

>             Name (_PSS, Package (0x02)
>             {
>                 Package (0x06)
>                 {
>                     0x00, 
>                     0x00, 
>                     0x01F4, 
>                     0x00, 
>                     0x00, 
>                     0x00
>                 }, 
> 
>                 Package (0x06)
>                 {
>                     0x00, 
>                     0x00, 
>                     0x01F4, 
>                     0x00, 
>                     0x00, 
>                     0x01
>                 }
>             })
>         }
>     }
> 

... 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