On Sun, 15 Mar 2009, Jiri Slaby wrote: > > sometimes, when booting up/resuming from disk, I get an oops[1]. > > obj_desc->common_field.access_bit_width is zero, but even after the loop. > Division before the loop is apparently OK. > > This is the case: > /* Mask off any extra bits in the last datum */ > > buffer_tail_bits = obj_desc->common_field.bit_length % > obj_desc->common_field.access_bit_width; Hmm. "bit_length" is zero too, according to the oops (it's in %eax). Looks like the whole "obj_desc" is basically uninitialized. I have no idea why, and why it is apparently not reliable. ACPI is odd. Does everything work if you just do something like the appended? It's insane, but so is ACPI. Linus --- drivers/acpi/acpica/exfldio.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/acpi/acpica/exfldio.c b/drivers/acpi/acpica/exfldio.c index ef58ac4..9297adb 100644 --- a/drivers/acpi/acpica/exfldio.c +++ b/drivers/acpi/acpica/exfldio.c @@ -698,6 +698,9 @@ acpi_ex_extract_from_field(union acpi_operand_object *obj_desc, } ACPI_MEMSET(buffer, 0, buffer_length); + if (!obj_desc->common_field.bit_length) + return_ACPI_STATUS(AE_OK); + /* Compute the number of datums (access width data items) */ datum_count = ACPI_ROUND_UP_TO(obj_desc->common_field.bit_length, -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
