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=drivers/acpi/processor_driver.c;h=e83311bf1ebdaaaea1adbf2de1351cca907d3465;hb=5da1f88b8b727dc3a66c52d4513e871be6d43d19#l351
signature.asc
Description: This is a digitally signed message part
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
