Dear coreboot folks,
in Debian Sid/unstable with Linux 3.2.35 looking at the Linux messages in the output of `dmesg` I see
ACPI: Invalid PBLK length [0]
which results from
$ more src/mainboard/asrock/e350m1/dsdt.asl […] /* * Processor Object * */ Scope (_PR) { /* define processor scope */ Processor( C000, /* name space name, align with BLDCFG_PROCESSOR_SCOPE_NAME[01] */ 0, /* Unique number for this processor */ 0x810, /* PBLK system I/O address !hardcoded! */ 0x06 /* PBLKLEN for boot processor */ ) { }
Processor( C001, /* name space name */ 1, /* Unique number for this processor */ 0x810, /* PBLK system I/O address !hardcoded! */ 0x00 /* PBLKLEN for boot processor */ ) { } Processor( C002, /* name space name */ 2, /* Unique number for this processor */ 0x810, /* PBLK system I/O address !hardcoded! */ 0x00 /* PBLKLEN for boot processor */ ) { } Processor( C003, /* name space name */ 3, /* Unique number for this processor */ 0x810, /* PBLK system I/O address !hardcoded! */ 0x00 /* PBLKLEN for boot processor */ ) { } } /* End _PR scope */ […]
Is that an error in the Linux ACPI code? According to Colin King’s comment (25) to the Launchpad report [1], the ACPI specification allows it to be set to 0.
»Section 18.5.93 of the ACPI specification states that the PBlockLength is the length of the processor register block, in bytes and is either 0 (for no P_BLK) or 6.« [2]
So the DSDT seems to be valid. Before I report that to the Linux ACPI folks, could you please tell me if I am missing something?
Thanks,
Paul
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/197267 [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/197267/comments/25
Dear coreboot folks,
Am Sonntag, den 20.01.2013, 11:50 +0100 schrieb Paul Menzel:
in Debian Sid/unstable with Linux 3.2.35 looking at the Linux messages in the output of `dmesg` I see
ACPI: Invalid PBLK length [0]
which results from
$ more src/mainboard/asrock/e350m1/dsdt.asl […] /* * Processor Object * */ Scope (\_PR) { /* define processor scope */ Processor( C000, /* name space name, align with BLDCFG_PROCESSOR_SCOPE_NAME[01] */ 0, /* Unique number for this processor */ 0x810, /* PBLK system I/O address !hardcoded! */ 0x06 /* PBLKLEN for boot processor */ ) { } Processor( C001, /* name space name */ 1, /* Unique number for this processor */ 0x810, /* PBLK system I/O address !hardcoded! */ 0x00 /* PBLKLEN for boot processor */ ) { } Processor( C002, /* name space name */ 2, /* Unique number for this processor */ 0x810, /* PBLK system I/O address !hardcoded! */ 0x00 /* PBLKLEN for boot processor */ ) { } Processor( C003, /* name space name */ 3, /* Unique number for this processor */ 0x810, /* PBLK system I/O address !hardcoded! */ 0x00 /* PBLKLEN for boot processor */ ) { } } /* End _PR scope */ […]
Is that an error in the Linux ACPI code? According to Colin King’s comment (25) to the Launchpad report [1], the ACPI specification allows it to be set to 0.
»Section 18.5.93 of the ACPI specification states that the PBlockLength is the length of the processor register block, in bytes and is either 0 (for no P_BLK) or 6.« [2]
So the DSDT seems to be valid. Before I report that to the Linux ACPI folks, could you please tell me if I am missing something?
Looking at the Linux code in `drivers/acpi/processor_driver.c` only 6 seems to be allowed [2].
static int acpi_processor_get_info(struct acpi_device *device) { […] /* * On some boxes several processors use the same processor bus id. * But they are located in different scope. For example: * _SB.SCK0.CPU0 * _SB.SCK1.CPU0 * Rename the processor device bus id. And the new bus id will be * generated as the following format: * CPU+CPU ID. */ sprintf(acpi_device_bid(device), "CPU%X", pr->id); ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id, pr->acpi_id));
if (!object.processor.pblk_address) ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n")); else if (object.processor.pblk_length != 6) printk(KERN_ERR PREFIX "Invalid PBLK length [%d]\n", object.processor.pblk_length); else { pr->throttling.address = object.processor.pblk_address; pr->throttling.duty_offset = acpi_gbl_FADT.duty_offset; pr->throttling.duty_width = acpi_gbl_FADT.duty_width;
pr->pblk = object.processor.pblk_address;
/* * We don't care about error returns - we just try to mark * these reserved so that nobody else is confused into thinking * that this region might be unused.. * * (In particular, allocating the IO range for Cardbus) */ request_region(pr->throttling.address, 6, "ACPI CPU throttle"); } […] }
So I am going to submit a bug report to the Linux ACPI folks tomorrow.
Thanks,
Paul
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/197267 [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/197267/comments/25
[3] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=driver...
Dear coreboot folks,
Am Sonntag, den 20.01.2013, 23:46 +0100 schrieb Paul Menzel:
Am Sonntag, den 20.01.2013, 11:50 +0100 schrieb Paul Menzel:
in Debian Sid/unstable with Linux 3.2.35 looking at the Linux messages in the output of `dmesg` I see
ACPI: Invalid PBLK length [0]
which results from
$ more src/mainboard/asrock/e350m1/dsdt.asl […] /* * Processor Object * */ Scope (\_PR) { /* define processor scope */ Processor( C000, /* name space name, align with BLDCFG_PROCESSOR_SCOPE_NAME[01] */ 0, /* Unique number for this processor */ 0x810, /* PBLK system I/O address !hardcoded! */ 0x06 /* PBLKLEN for boot processor */ ) { } Processor( C001, /* name space name */ 1, /* Unique number for this processor */ 0x810, /* PBLK system I/O address !hardcoded! */ 0x00 /* PBLKLEN for boot processor */ ) { } Processor( C002, /* name space name */ 2, /* Unique number for this processor */ 0x810, /* PBLK system I/O address !hardcoded! */ 0x00 /* PBLKLEN for boot processor */ ) { } Processor( C003, /* name space name */ 3, /* Unique number for this processor */ 0x810, /* PBLK system I/O address !hardcoded! */ 0x00 /* PBLKLEN for boot processor */ ) { } } /* End _PR scope */ […]
Is that an error in the Linux ACPI code? According to Colin King’s comment (25) to the Launchpad report [1], the ACPI specification allows it to be set to 0.
»Section 18.5.93 of the ACPI specification states that the PBlockLength is the length of the processor register block, in bytes and is either 0 (for no P_BLK) or 6.« [2]
So the DSDT seems to be valid. Before I report that to the Linux ACPI folks, could you please tell me if I am missing something?
Looking at the Linux code in `drivers/acpi/processor_driver.c` only 6 seems to be allowed [2].
static int acpi_processor_get_info(struct acpi_device *device) { […] /* * On some boxes several processors use the same processor bus id. * But they are located in different scope. For example: * \_SB.SCK0.CPU0 * \_SB.SCK1.CPU0 * Rename the processor device bus id. And the new bus id will be * generated as the following format: * CPU+CPU ID. */ sprintf(acpi_device_bid(device), "CPU%X", pr->id); ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Processor [%d:%d]\n", pr->id, pr->acpi_id)); if (!object.processor.pblk_address) ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No PBLK (NULL address)\n")); else if (object.processor.pblk_length != 6) printk(KERN_ERR PREFIX "Invalid PBLK length [%d]\n", object.processor.pblk_length); else { pr->throttling.address = object.processor.pblk_address; pr->throttling.duty_offset = acpi_gbl_FADT.duty_offset; pr->throttling.duty_width = acpi_gbl_FADT.duty_width; pr->pblk = object.processor.pblk_address; /* * We don't care about error returns - we just try to mark * these reserved so that nobody else is confused into thinking * that this region might be unused.. * * (In particular, allocating the IO range for Cardbus) */ request_region(pr->throttling.address, 6, "ACPI CPU throttle"); } […] }
So I am going to submit a bug report to the Linux ACPI folks tomorrow.
Well, reading the ACPI specification [4], 0 is only allowed, if there is no PBlockAddress.
18.5.93 Processor (Declare Processor)
[…]
PBlockAddress provides the system I/O address for the processors register block. Each processor can supply a different such address. PBlockLength is the length of the processor register block, in bytes and is either 0 (for no P_BLK) or 6. With one exception, all processors are required to have the same PBlockLength. The exception is that the boot processor can have a non-zero PBlockLength when all other processors have a zero PBlockLength. It is valid for every processor to have a PBlockLength of 0.
Thanks,
Paul
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/197267 [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/197267/comments/25
[3] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=driver...