ACPI: Check _PSS invalidation when BIOS report _PSS with all 0x80000000

PATCH In review [email protected] 6 participants 6 messages Nov 21, 2008 – Mar 13, 2009 ACPI

lore

Share & tools

lore

[email protected]

author

2008-11-21 03:08 UTC #0 lore raw

PATCH 1/1 ACPI: Check _PSS invalidation when BIOS report _PSS with all 0x80000000

Subject: Check _PSS invalidation when BIOS report _PSS with 0x80000000

When cpu frequencey scaling disable,some BIOS report _PSS with all 0x80000000.
If kernel treat this case as valid, the kernel will boot crash when load cpufreq govenors.

So in order to cover more buggy BIOSs, the patch just check _PSS core frequencey invalidtion.

Signed-off-by Youquan, Song <[email protected]>

Signed-off-by Pallipadi, Venkatesh <[email protected]>

---

--- linux-2.6-tip-orignal/drivers/acpi/processor_perflib.c 2008-11-20
12:25:05.000000000 -0500
+++ linux-2.6-tip/drivers/acpi/processor_perflib.c 2008-11-20
12:23:57.000000000 -0500
@@ -50,6 +50,7 @@
#define ACPI_PROCESSOR_CLASS "processor"
#define ACPI_PROCESSOR_FILE_PERFORMANCE "performance"
#define _COMPONENT ACPI_PROCESSOR_COMPONENT
+#define ACPI_PROCESSOR_PSS_INVALID 0x80000000
ACPI_MODULE_NAME("processor_perflib");

static DEFINE_MUTEX(performance_mutex);
@@ -324,6 +325,14 @@
kfree(pr->performance->states); goto end;
}
+
+ if (px->core_frequency == ACPI_PROCESSOR_PSS_INVALID) {
+ printk(KERN_ERR PREFIX
+ "P-states disabled in the BIOS\n");
+ result = -EFAULT;
+ kfree(pr->performance->states);
+ goto end;
+ }
}

end:

Andrew Morton

2008-11-21 23:08 UTC #1 lore raw

Quoted 10 lines · On Thu, 20 Nov 2008 19:08:36 -0800 (PST) [email protected] wrote:

Subject: Check _PSS invalidation when BIOS report _PSS with 0x80000000
When cpu frequencey scaling disable,some BIOS report _PSS with all 0x80000000.
If kernel treat this case as valid, the kernel will boot crash when load cpufreq govenors.
So in order to cover more buggy BIOSs, the patch just check _PSS core frequencey invalidtion.

It's unclear how many machines this will affect, and what the effects of not having the patch are upon those machines. That is useful information for people who are deciding whcih kernel versions this patch should be merged into.

Do you think this fix is needed in 2.6.28? 2.6.27.x? 2.6.26.x? etc?

Quoted 5 lines

--- linux-2.6-tip-orignal/drivers/acpi/processor_perflib.c 2008-11-20
12:25:05.000000000 -0500
+++ linux-2.6-tip/drivers/acpi/processor_perflib.c 2008-11-20
12:23:57.000000000 -0500

Your email client is wordwrapping the text, btw.

Quoted 23 lines

(quoted diff) +9 -0

@@ -50,6 +50,7 @@
 #define ACPI_PROCESSOR_CLASS		"processor"
 #define ACPI_PROCESSOR_FILE_PERFORMANCE	"performance"
 #define _COMPONENT		ACPI_PROCESSOR_COMPONENT
+#define ACPI_PROCESSOR_PSS_INVALID	0x80000000
 ACPI_MODULE_NAME("processor_perflib");
 
 static DEFINE_MUTEX(performance_mutex);

@@ -324,6 +325,14 @@
 			kfree(pr->performance->states);
 			goto end;
 		}
+
+		if (px->core_frequency == ACPI_PROCESSOR_PSS_INVALID) {
+			printk(KERN_ERR PREFIX
+				    "P-states disabled in the BIOS\n");
+			result = -EFAULT;
+			kfree(pr->performance->states);
+			goto end;
+		}
 	}
 
       end:

Youquan,Song

2008-11-24 15:15 UTC #2 lore raw

Quoted 10 lines · Andrew Morton

Quoted 7 lines · On Thu, 20 Nov 2008 19:08:36 -0800 (PST) [email protected] wrote:
Subject: Check _PSS invalidation when BIOS report _PSS with 0x80000000
When cpu frequencey scaling disable,some BIOS report _PSS with all 0x80000000.
If kernel treat this case as valid, the kernel will boot crash when load cpufreq govenors.

Quoted 8 lines

Quoted 3 lines
So in order to cover more buggy BIOSs, the patch just check _PSS core frequencey invalidtion.
It's unclear how many machines this will affect, and what the effects of not having the patch are upon those machines. That is useful information for people who are deciding whcih kernel versions this patch should be merged into.

I meet 2 machines that if the P-states is disabled in BIOS, the kernel will boot crash at loading cpufreq_userspace governor because kernel consider that P-states validate. I know there are some other machines also exist this bug.

Quoted 3 lines

Do you think this fix is needed in 2.6.28? 2.6.27.x? 2.6.26.x? etc?

I know that the bug exists in kernel as old as 2.6.18 and also exits on 2.6.28, 2.6.27 etc.

Quoted 33 lines

Quoted 5 lines

--- linux-2.6-tip-orignal/drivers/acpi/processor_perflib.c 2008-11-20
12:25:05.000000000 -0500
+++ linux-2.6-tip/drivers/acpi/processor_perflib.c 2008-11-20
12:23:57.000000000 -0500

Your email client is wordwrapping the text, btw.

Quoted 23 lines

(quoted diff) +9 -0

@@ -50,6 +50,7 @@
 #define ACPI_PROCESSOR_CLASS		"processor"
 #define ACPI_PROCESSOR_FILE_PERFORMANCE	"performance"
 #define _COMPONENT		ACPI_PROCESSOR_COMPONENT
+#define ACPI_PROCESSOR_PSS_INVALID	0x80000000
 ACPI_MODULE_NAME("processor_perflib");
 
 static DEFINE_MUTEX(performance_mutex);

@@ -324,6 +325,14 @@
 			kfree(pr->performance->states);
 			goto end;
 		}
+
+		if (px->core_frequency == ACPI_PROCESSOR_PSS_INVALID) {
+			printk(KERN_ERR PREFIX
+				    "P-states disabled in the BIOS\n");
+			result = -EFAULT;
+			kfree(pr->performance->states);
+			goto end;
+		}
 	}
 
       end:

Len Brown

reviewer

2008-12-12 05:37 UTC #3 lore raw

Quoted 20 lines · Youquan,Song

Quoted 10 lines · Andrew Morton
Quoted 7 lines · On Thu, 20 Nov 2008 19:08:36 -0800 (PST) [email protected] wrote:
Subject: Check _PSS invalidation when BIOS report _PSS with 0x80000000
When cpu frequencey scaling disable,some BIOS report _PSS with all 0x80000000.
If kernel treat this case as valid, the kernel will boot crash when load cpufreq govenors.
Quoted 8 lines
Quoted 3 lines
So in order to cover more buggy BIOSs, the patch just check _PSS core frequencey invalidtion.
It's unclear how many machines this will affect, and what the effects of not having the patch are upon those machines. That is useful information for people who are deciding whcih kernel versions this patch should be merged into.

Quoted 4 lines

I meet 2 machines that if the P-states is disabled in BIOS, the kernel will boot crash at loading cpufreq_userspace governor because kernel consider that P-states validate. I know there are some other machines also exist this bug.

What does _PPC say when P-states are disabled on these machines? If it is disabling the _PSS, maybe we should not be looking at the _PSS?

This would be a good patch if 0x80000000 were actually documented in the ACPI spec as disabling P-states, but it isn't.

Can you open a bugzilla and attach the acpidump output for the two failing machines? Are those machines shipped with P-states enabled by default, or disabled by default?

Also, how, exactly, do we crash when we see these values?

Quoted 5 lines

Quoted 2 lines
Do you think this fix is needed in 2.6.28? 2.6.27.x? 2.6.26.x? etc?
I know that the bug exists in kernel as old as 2.6.18 and also exits on 2.6.28, 2.6.27 etc.

So we've been exposed to this BIOS bug for more than 10 releases and the world has not ended. Unless we're about to be exposed to a raft of new machines with this BIOS issue, and they have P-states disabled by default, I'd say this workaround in not urgent.

Signature · 1 line

Len Brown, Intel Open Source Technology Center

Woody Suwalski

2009-03-12 13:22 UTC #4 lore raw

Quoted 47 lines · Len Brown

Quoted 22 lines · Youquan,Song
Quoted 11 lines · Andrew Morton
Quoted 7 lines · On Thu, 20 Nov 2008 19:08:36 -0800 (PST) [email protected] wrote:
Subject: Check _PSS invalidation when BIOS report _PSS with 0x80000000
When cpu frequencey scaling disable,some BIOS report _PSS with all 0x80000000.
If kernel treat this case as valid, the kernel will boot crash when load cpufreq govenors.
Quoted 9 lines
Quoted 4 lines
So in order to cover more buggy BIOSs, the patch just check _PSS core frequencey invalidtion.
It's unclear how many machines this will affect, and what the effects of not having the patch are upon those machines. That is useful information for people who are deciding whcih kernel versions this patch should be merged into.
Quoted 5 lines
I meet 2 machines that if the P-states is disabled in BIOS, the kernel will boot crash at loading cpufreq_userspace governor because kernel consider that P-states validate. I know there are some other machines also exist this bug.
What does _PPC say when P-states are disabled on these machines? If it is disabling the _PSS, maybe we should not be looking at the _PSS?
This would be a good patch if 0x80000000 were actually documented in the ACPI spec as disabling P-states, but it isn't.
Can you open a bugzilla and attach the acpidump output for the two failing machines? Are those machines shipped with P-states enabled by default, or disabled by default?
Also, how, exactly, do we crash when we see these values?
Quoted 3 lines
Quoted 3 lines
Do you think this fix is needed in 2.6.28? 2.6.27.x? 2.6.26.x? etc?

Quoted 10 lines

Quoted 3 lines
I know that the bug exists in kernel as old as 2.6.18 and also exits on 2.6.28, 2.6.27 etc.
So we've been exposed to this BIOS bug for more than 10 releases and the world has not ended. Unless we're about to be exposed to a raft of new machines with this BIOS issue, and they have P-states disabled by default, I'd say this workaround in not urgent.

On Dell Latitude E4300 and E4600 I had to add processor.nocst=1
Otherwise system will become disfunctional after modprobing processor, typically on start of X or on exit from X... Do not have any of the systems on hand, but if useful can provide dmesg dump...
I have not tried with 2.6.28 or earlier, so can not say if this is a regression or not.

Woody

Signature · 1 line

Woody Suwalski, Xandros, Ottawa, Canada, 1-613-842-3498 x414

Zhang Rui

2009-03-13 02:15 UTC #5 lore raw

this seems like a different problem.

Quoted 2 lines

Quoted 1 line
On Dell Latitude E4300 and E4600 I had to add processor.nocst=1

please attach the lspci of these laptops.

Quoted 2 lines

Otherwise system will become disfunctional after modprobing processor, typically on start of X or on exit from X...

please use nocst to start X, and attach the /etc/X11/xorg.conf and /var/log/Xorg.0.log after X is started.

thanks,
rui

Quoted 7 lines

Do not have any of the systems on hand, but if useful can provide dmesg dump...
I have not tried with 2.6.28 or earlier, so can not say if this is a regression or not.
Woody