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:
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?
>
> --- 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.
> @@ -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:
On Fri, Nov 21, 2008 at 03:08:39PM -0800, Andrew Morton wrote:
> 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.
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.
>
> 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.
> >
> > --- 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.
>
> > @@ -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:
>
>
On Mon, 24 Nov 2008, Youquan,Song wrote:
> On Fri, Nov 21, 2008 at 03:08:39PM -0800, Andrew Morton wrote:
> > 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.
>
> 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?
> > 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.
--
Len Brown, Intel Open Source Technology Center
Len Brown wrote:
> On Mon, 24 Nov 2008, Youquan,Song wrote:
>
>
>> On Fri, Nov 21, 2008 at 03:08:39PM -0800, Andrew Morton wrote:
>>
>>> 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.
>>>
>> 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?
>
>
>>> 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.
>
>
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
--
Woody Suwalski, Xandros, Ottawa, Canada, 1-613-842-3498 x414
this seems like a different problem.
> >
> On Dell Latitude E4300 and E4600 I had to add processor.nocst=1
please attach the lspci of these laptops.
> 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
> 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
>