Kernel 3.13.0-06058-g2d08cd0 displays following errors on the console:
ACPI: \_PR_.CPU4: failed to get CPU APIC ID.
ACPI: \_PR_.CPU5: failed to get CPU APIC ID.
ACPI: \_PR_.CPU6: failed to get CPU APIC ID.
ACPI: \_PR_.CPU7: failed to get CPU APIC ID.
I don't have CPUs 4..7! Error messages regarding not existing
CPUs should not be displayed.
kernel 3.13.0-05617-g3aacd62 and before did'nt show this messages.
This is a regression. I never saw this messages before.
Processor model: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
$ cat /proc/cpuinfo | grep processor
processor : 0
processor : 1
processor : 2
processor : 3
Jörg
On Saturday, January 25, 2014 11:03:09 AM Jörg Otte wrote:
> Kernel 3.13.0-06058-g2d08cd0 displays following errors on the console:
>
> ACPI: \_PR_.CPU4: failed to get CPU APIC ID.
> ACPI: \_PR_.CPU5: failed to get CPU APIC ID.
> ACPI: \_PR_.CPU6: failed to get CPU APIC ID.
> ACPI: \_PR_.CPU7: failed to get CPU APIC ID.
>
> I don't have CPUs 4..7! Error messages regarding not existing
> CPUs should not be displayed.
> kernel 3.13.0-05617-g3aacd62 and before did'nt show this messages.
>
> This is a regression. I never saw this messages before.
Does your system show any other suspicious symptoms or are you worried about
those messages only?
Rafael
On Saturday, January 25, 2014 02:53:24 PM Rafael J. Wysocki wrote:
> On Saturday, January 25, 2014 11:03:09 AM Jörg Otte wrote:
> > Kernel 3.13.0-06058-g2d08cd0 displays following errors on the console:
> >
> > ACPI: \_PR_.CPU4: failed to get CPU APIC ID.
> > ACPI: \_PR_.CPU5: failed to get CPU APIC ID.
> > ACPI: \_PR_.CPU6: failed to get CPU APIC ID.
> > ACPI: \_PR_.CPU7: failed to get CPU APIC ID.
> >
> > I don't have CPUs 4..7! Error messages regarding not existing
> > CPUs should not be displayed.
> > kernel 3.13.0-05617-g3aacd62 and before did'nt show this messages.
> >
> > This is a regression. I never saw this messages before.
>
> Does your system show any other suspicious symptoms or are you worried about
> those messages only?
Gerry, this is your commit b981513f806d (ACPI / scan: bail out early if failed
to parse APIC ID for CPU). Apparently, the BIOS has room for 4 CPUs more than
there actually are in the system. Maybe we can reduce the log level of those
messages to avoid ringing bells unnecessarily?
Rafael
On Sat, 25 Jan 2014, Rafael J. Wysocki wrote:
> On Saturday, January 25, 2014 02:53:24 PM Rafael J. Wysocki wrote:
> > On Saturday, January 25, 2014 11:03:09 AM J?rg Otte wrote:
> > > Kernel 3.13.0-06058-g2d08cd0 displays following errors on the console:
> > >
> > > ACPI: \_PR_.CPU4: failed to get CPU APIC ID.
> > > ACPI: \_PR_.CPU5: failed to get CPU APIC ID.
> > > ACPI: \_PR_.CPU6: failed to get CPU APIC ID.
> > > ACPI: \_PR_.CPU7: failed to get CPU APIC ID.
> > >
> > > I don't have CPUs 4..7! Error messages regarding not existing
> > > CPUs should not be displayed.
> > > kernel 3.13.0-05617-g3aacd62 and before did'nt show this messages.
> > >
> > > This is a regression. I never saw this messages before.
> >
> > Does your system show any other suspicious symptoms or are you worried about
> > those messages only?
>
> Gerry, this is your commit b981513f806d (ACPI / scan: bail out early if failed
> to parse APIC ID for CPU). Apparently, the BIOS has room for 4 CPUs more than
> there actually are in the system. Maybe we can reduce the log level of those
> messages to avoid ringing bells unnecessarily?
It is standard practice (at least in SuperMicro boxes, but I've also seen it
elsewhere) for the BIOS to have ACPI tables mentioning all cores supported
by the biggest core-count CPU topology possible by the motherboard. The
cores you don't have are reported as if they were hotpluggable but absent,
even if they will *never* show up at runtime. Meh.
So yes, such warnings will get annoying *very* quickly.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
2014-01-25 Rafael J. Wysocki <[email protected]>:
> On Saturday, January 25, 2014 11:03:09 AM Jörg Otte wrote:
>> Kernel 3.13.0-06058-g2d08cd0 displays following errors on the console:
>>
>> ACPI: \_PR_.CPU4: failed to get CPU APIC ID.
>> ACPI: \_PR_.CPU5: failed to get CPU APIC ID.
>> ACPI: \_PR_.CPU6: failed to get CPU APIC ID.
>> ACPI: \_PR_.CPU7: failed to get CPU APIC ID.
>>
>> I don't have CPUs 4..7! Error messages regarding not existing
>> CPUs should not be displayed.
>> kernel 3.13.0-05617-g3aacd62 and before did'nt show this messages.
>>
>> This is a regression. I never saw this messages before.
>
> Does your system show any other suspicious symptoms or are you worried about
> those messages only?
>
> Rafael
>
what's looking badly is this:
ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_]
(20131218/hwxface-580)
ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_]
(20131218/hwxface-580)
and this:
acpi PNP0A08:00: _OSC: OS supports [ASPM ClockPM Segments MSI]
\_SB_.PCI0:_OSC invalid UUID
_OSC request data:1 1e 0
acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM
but these messages are not new.
Jörg
On Saturday, January 25, 2014 05:32:19 PM Jörg Otte wrote:
> 2014-01-25 Rafael J. Wysocki <[email protected]>:
> > On Saturday, January 25, 2014 11:03:09 AM Jörg Otte wrote:
> >> Kernel 3.13.0-06058-g2d08cd0 displays following errors on the console:
> >>
> >> ACPI: \_PR_.CPU4: failed to get CPU APIC ID.
> >> ACPI: \_PR_.CPU5: failed to get CPU APIC ID.
> >> ACPI: \_PR_.CPU6: failed to get CPU APIC ID.
> >> ACPI: \_PR_.CPU7: failed to get CPU APIC ID.
> >>
> >> I don't have CPUs 4..7! Error messages regarding not existing
> >> CPUs should not be displayed.
> >> kernel 3.13.0-05617-g3aacd62 and before did'nt show this messages.
> >>
> >> This is a regression. I never saw this messages before.
> >
> > Does your system show any other suspicious symptoms or are you worried about
> > those messages only?
> >
> > Rafael
> >
>
> what's looking badly is this:
>
> ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_]
> (20131218/hwxface-580)
> ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_]
> (20131218/hwxface-580)
That means your BIOS doesn't support system sleep states S1 and S2, but we
should be able to suppress those messages I think.
> and this:
>
> acpi PNP0A08:00: _OSC: OS supports [ASPM ClockPM Segments MSI]
> \_SB_.PCI0:_OSC invalid UUID
> _OSC request data:1 1e 0
> acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM
That means the BIOS doesn't want to grant the kernel control of extended
PCIe features on your system.
> but these messages are not new.
They indicate things that are not supported by the BIOS, but I agree that the
messages are a bit cryptic.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On Saturday, January 25, 2014 02:18:17 PM Henrique de Moraes Holschuh wrote:
> On Sat, 25 Jan 2014, Rafael J. Wysocki wrote:
> > On Saturday, January 25, 2014 02:53:24 PM Rafael J. Wysocki wrote:
> > > On Saturday, January 25, 2014 11:03:09 AM Jörg Otte wrote:
> > > > Kernel 3.13.0-06058-g2d08cd0 displays following errors on the console:
> > > >
> > > > ACPI: \_PR_.CPU4: failed to get CPU APIC ID.
> > > > ACPI: \_PR_.CPU5: failed to get CPU APIC ID.
> > > > ACPI: \_PR_.CPU6: failed to get CPU APIC ID.
> > > > ACPI: \_PR_.CPU7: failed to get CPU APIC ID.
> > > >
> > > > I don't have CPUs 4..7! Error messages regarding not existing
> > > > CPUs should not be displayed.
> > > > kernel 3.13.0-05617-g3aacd62 and before did'nt show this messages.
> > > >
> > > > This is a regression. I never saw this messages before.
> > >
> > > Does your system show any other suspicious symptoms or are you worried about
> > > those messages only?
> >
> > Gerry, this is your commit b981513f806d (ACPI / scan: bail out early if failed
> > to parse APIC ID for CPU). Apparently, the BIOS has room for 4 CPUs more than
> > there actually are in the system. Maybe we can reduce the log level of those
> > messages to avoid ringing bells unnecessarily?
>
> It is standard practice (at least in SuperMicro boxes, but I've also seen it
> elsewhere) for the BIOS to have ACPI tables mentioning all cores supported
> by the biggest core-count CPU topology possible by the motherboard. The
> cores you don't have are reported as if they were hotpluggable but absent,
> even if they will *never* show up at runtime. Meh.
>
> So yes, such warnings will get annoying *very* quickly.
Well, what about using acpi_handle_debug() in there, then?
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
Hi all,
I will take care of this issue and send out a patch soon.
Thanks!
Gerry
On 2014/1/26 6:31, Rafael J. Wysocki wrote:
> On Saturday, January 25, 2014 02:18:17 PM Henrique de Moraes Holschuh wrote:
>> On Sat, 25 Jan 2014, Rafael J. Wysocki wrote:
>>> On Saturday, January 25, 2014 02:53:24 PM Rafael J. Wysocki wrote:
>>>> On Saturday, January 25, 2014 11:03:09 AM Jörg Otte wrote:
>>>>> Kernel 3.13.0-06058-g2d08cd0 displays following errors on the console:
>>>>>
>>>>> ACPI: \_PR_.CPU4: failed to get CPU APIC ID.
>>>>> ACPI: \_PR_.CPU5: failed to get CPU APIC ID.
>>>>> ACPI: \_PR_.CPU6: failed to get CPU APIC ID.
>>>>> ACPI: \_PR_.CPU7: failed to get CPU APIC ID.
>>>>>
>>>>> I don't have CPUs 4..7! Error messages regarding not existing
>>>>> CPUs should not be displayed.
>>>>> kernel 3.13.0-05617-g3aacd62 and before did'nt show this messages.
>>>>>
>>>>> This is a regression. I never saw this messages before.
>>>>
>>>> Does your system show any other suspicious symptoms or are you worried about
>>>> those messages only?
>>>
>>> Gerry, this is your commit b981513f806d (ACPI / scan: bail out early if failed
>>> to parse APIC ID for CPU). Apparently, the BIOS has room for 4 CPUs more than
>>> there actually are in the system. Maybe we can reduce the log level of those
>>> messages to avoid ringing bells unnecessarily?
>>
>> It is standard practice (at least in SuperMicro boxes, but I've also seen it
>> elsewhere) for the BIOS to have ACPI tables mentioning all cores supported
>> by the biggest core-count CPU topology possible by the motherboard. The
>> cores you don't have are reported as if they were hotpluggable but absent,
>> even if they will *never* show up at runtime. Meh.
>>
>> So yes, such warnings will get annoying *very* quickly.
>
> Well, what about using acpi_handle_debug() in there, then?
>
Commit b981513f806d (ACPI / scan: bail out early if failed to parse
APIC ID for CPU) emits an error message if ACPI processor driver fails
to query APIC ID for the CPU.
Originally it's designed to catch BIOS bugs for CPU hot-addition. But
it accidently reveals another type of BIOS bug that:
1) BIOS implements ACPI objects for all possible instead of present
CPUs. (It's legal per ACPI specification.)
2) BIOS doesn't implement _STA method for CPU objects. OSPM assumes
that all CPU objects are present and functioning and binds ACPI
processor driver to those CPU objects, which then triggers the error
message. According to ACPI spec, BIOS should implement _STA method
for those absent CPUs at least.
Though it's a BIOS bug in essential, there are some BIOSes in the fields
which are implmented in this way. So reduce the log level from ERR to
DEBUG to accommodate these existing BIOSes.
Fixes: b981513f806d (ACPI / scan: bail out early if failed to parse APIC ID for CPU)
Signed-off-by: Jiang Liu <[email protected]>
---
drivers/acpi/acpi_processor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index c9311be..c29c2c3 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -261,7 +261,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
apic_id = acpi_get_apicid(pr->handle, device_declaration, pr->acpi_id);
if (apic_id < 0) {
- acpi_handle_err(pr->handle, "failed to get CPU APIC ID.\n");
+ acpi_handle_debug(pr->handle, "failed to get CPU APIC ID.\n");
return -ENODEV;
}
pr->apic_id = apic_id;
--
1.7.10.4
2014-01-27 Jiang Liu <[email protected]>:
> Commit b981513f806d (ACPI / scan: bail out early if failed to parse
> APIC ID for CPU) emits an error message if ACPI processor driver fails
> to query APIC ID for the CPU.
>
> Originally it's designed to catch BIOS bugs for CPU hot-addition. But
> it accidently reveals another type of BIOS bug that:
> 1) BIOS implements ACPI objects for all possible instead of present
> CPUs. (It's legal per ACPI specification.)
> 2) BIOS doesn't implement _STA method for CPU objects. OSPM assumes
> that all CPU objects are present and functioning and binds ACPI
> processor driver to those CPU objects, which then triggers the error
> message. According to ACPI spec, BIOS should implement _STA method
> for those absent CPUs at least.
>
> Though it's a BIOS bug in essential, there are some BIOSes in the fields
> which are implmented in this way. So reduce the log level from ERR to
> DEBUG to accommodate these existing BIOSes.
>
> Fixes: b981513f806d (ACPI / scan: bail out early if failed to parse APIC ID for CPU)
> Signed-off-by: Jiang Liu <[email protected]>
> ---
> drivers/acpi/acpi_processor.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index c9311be..c29c2c3 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -261,7 +261,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
>
> apic_id = acpi_get_apicid(pr->handle, device_declaration, pr->acpi_id);
> if (apic_id < 0) {
> - acpi_handle_err(pr->handle, "failed to get CPU APIC ID.\n");
> + acpi_handle_debug(pr->handle, "failed to get CPU APIC ID.\n");
> return -ENODEV;
> }
> pr->apic_id = apic_id;
> --
> 1.7.10.4
>
Thanks, the patch works for me.
Jörg
On Mon, 27 Jan 2014, Jiang Liu wrote:
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index c9311be..c29c2c3 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -261,7 +261,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
>
> apic_id = acpi_get_apicid(pr->handle, device_declaration, pr->acpi_id);
> if (apic_id < 0) {
> - acpi_handle_err(pr->handle, "failed to get CPU APIC ID.\n");
> + acpi_handle_debug(pr->handle, "failed to get CPU APIC ID.\n");
> return -ENODEV;
> }
Don't we already leave some artifact in the kernel log at boot about apic
ids that don't get registered? I'm wondering if we should have this
warning at all.
On 1/28/2014 1:18 AM, David Rientjes wrote:
> On Mon, 27 Jan 2014, Jiang Liu wrote:
>
>> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
>> index c9311be..c29c2c3 100644
>> --- a/drivers/acpi/acpi_processor.c
>> +++ b/drivers/acpi/acpi_processor.c
>> @@ -261,7 +261,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
>>
>> apic_id = acpi_get_apicid(pr->handle, device_declaration, pr->acpi_id);
>> if (apic_id < 0) {
>> - acpi_handle_err(pr->handle, "failed to get CPU APIC ID.\n");
>> + acpi_handle_debug(pr->handle, "failed to get CPU APIC ID.\n");
>> return -ENODEV;
>> }
> Don't we already leave some artifact in the kernel log at boot about apic
> ids that don't get registered? I'm wondering if we should have this
> warning at all.
It is useful for knowing that there are potentially broken objects in
the ACPI tables.
On 2014/1/28 8:28, Rafael J. Wysocki wrote:
> On 1/28/2014 1:18 AM, David Rientjes wrote:
>> On Mon, 27 Jan 2014, Jiang Liu wrote:
>>
>>> diff --git a/drivers/acpi/acpi_processor.c
>>> b/drivers/acpi/acpi_processor.c
>>> index c9311be..c29c2c3 100644
>>> --- a/drivers/acpi/acpi_processor.c
>>> +++ b/drivers/acpi/acpi_processor.c
>>> @@ -261,7 +261,7 @@ static int acpi_processor_get_info(struct
>>> acpi_device *device)
>>> apic_id = acpi_get_apicid(pr->handle, device_declaration,
>>> pr->acpi_id);
>>> if (apic_id < 0) {
>>> - acpi_handle_err(pr->handle, "failed to get CPU APIC ID.\n");
>>> + acpi_handle_debug(pr->handle, "failed to get CPU APIC ID.\n");
>>> return -ENODEV;
>>> }
>> Don't we already leave some artifact in the kernel log at boot about apic
>> ids that don't get registered? I'm wondering if we should have this
>> warning at all.
>
> It is useful for knowing that there are potentially broken objects in
> the ACPI tables.
And it's very useful to identify BIOS bug in case of CPU hot-addition.
It caused our test team about 1 week to identify BIOS bug in CPU
hot-addition, so I added this debug message.
Thanks!
Gerry
>
>