From: Lin Ming <ming.m.lin@intel.com>
To: Jiri Slaby <jirislaby@gmail.com>
Cc: "Moore, Robert" <robert.moore@intel.com>,
"lenb@kernel.org" <lenb@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
linux-kernel <linux-kernel@vger.kernel.org>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>
Subject: Re: 2.6.29 acpi regression: acpi_ex_extract_from_field -- div by zero
Date: Fri, 20 Mar 2009 12:53:30 +0800 [thread overview]
Message-ID: <1237524810.879.19.camel@minggr> (raw)
In-Reply-To: <49C26D91.3010904@gmail.com>
On Fri, 2009-03-20 at 00:06 +0800, Jiri Slaby wrote:
> On 18.3.2009 09:08, Jiri Slaby wrote:
> > On 16.3.2009 17:31, Jiri Slaby wrote:
> >> On 16.3.2009 04:42, Lin Ming 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.
> >>>
> >>> Would please try below debug patch to see which region filed is
> >>> accessed?
> >
> > I'm confused, but keep trying.
>
> Got it again. obj_desc->common_field.node is martian too (0x4000000), so
> the added acpi_get_name dies:
> http://www.fi.muni.cz/~xslaby/sklad/panics/acpi_oops1.png
>
> Whole common_field seems to be mangled. Ideas?
I should save the field object and node path name at the entry of
acpi_ex_extract_from_field.
Would you please try below debug patch?
I also add a return statement before the fault to disallow the oops to
flood screen.
Thanks.
diff --git a/drivers/acpi/acpica/exfldio.c b/drivers/acpi/acpica/exfldio.c
index ef58ac4..5109f5b 100644
--- a/drivers/acpi/acpica/exfldio.c
+++ b/drivers/acpi/acpica/exfldio.c
@@ -670,6 +670,34 @@ acpi_ex_write_with_update_rule(union acpi_operand_object *obj_desc,
*
******************************************************************************/
+void debug_dump_field(union acpi_operand_object *obj_desc)
+{
+ struct acpi_object_field_common *obj_field;
+
+ if (!obj_desc) {
+ printk(KERN_DEBUG "ACPI Debug: NULL field object\n");
+ return;
+ }
+
+ printk(KERN_DEBUG "next_object: %p\n", obj_desc->common.next_object);
+ printk(KERN_DEBUG "descriptor_type: %x\n", obj_desc->common.descriptor_type);
+ printk(KERN_DEBUG "type: %x\n", obj_desc->common.type);
+ printk(KERN_DEBUG "reference_count: %x\n", obj_desc->common.reference_count);
+ printk(KERN_DEBUG "flags: %x\n", obj_desc->common.flags);
+
+ obj_field = &obj_desc->common_field;
+
+ printk(KERN_DEBUG "field_flags: %x\n", obj_field->field_flags);
+ printk(KERN_DEBUG "attribute: %x\n", obj_field->attribute);
+ printk(KERN_DEBUG "access_byte_width: %x\n", obj_field->access_byte_width);
+ printk(KERN_DEBUG "node: %p\n", obj_field->node);
+ printk(KERN_DEBUG "bit_length: %x\n", obj_field->bit_length);
+ printk(KERN_DEBUG "base_byte_offset: %x\n", obj_field->base_byte_offset);
+ printk(KERN_DEBUG "value: %x\n", obj_field->value);
+ printk(KERN_DEBUG "start_field_bit_offset: %x\n", obj_field->start_field_bit_offset);
+ printk(KERN_DEBUG "access_bit_width: %x\n", obj_field->access_bit_width);
+}
+
acpi_status
acpi_ex_extract_from_field(union acpi_operand_object *obj_desc,
void *buffer, u32 buffer_length)
@@ -683,9 +711,24 @@ acpi_ex_extract_from_field(union acpi_operand_object *obj_desc,
u32 datum_count;
u32 field_datum_count;
u32 i;
+ struct acpi_buffer name_buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+ union acpi_operand_object backup_obj;
ACPI_FUNCTION_TRACE(ex_extract_from_field);
+ /* backup the object */
+ memcpy(&backup_obj, obj_desc, sizeof(*obj_desc));
+
+ name_buffer.pointer = NULL;
+ if (obj_desc->common_field.node) {
+ status = acpi_get_name(obj_desc->common_field.node,
+ ACPI_FULL_PATHNAME, &name_buffer);
+ if (ACPI_FAILURE(status)) {
+ printk(KERN_DEBUG "ACPI Debug: %s\n",
+ acpi_format_exception(status));
+ }
+ }
+
/* Validate target buffer and clear it */
if (buffer_length <
@@ -765,6 +808,29 @@ acpi_ex_extract_from_field(union acpi_operand_object *obj_desc,
raw_datum >> obj_desc->common_field.start_field_bit_offset;
}
+ if (obj_desc->common_field.bit_length == 0 ||
+ obj_desc->common_field.access_bit_width == 0) {
+
+ /* oops, dump the object */
+ if (name_buffer.pointer) {
+ printk(KERN_DEBUG "ACPI Debug: field node path: %s\n",
+ (char *) name_buffer.pointer);
+ }
+
+ printk(KERN_DEBUG "ACPI Debug: The original object:\n");
+ debug_dump_field(&backup_obj);
+
+ printk(KERN_DEBUG "ACPI Debug: The bad object:\n");
+ debug_dump_field(obj_desc);
+
+ kfree(name_buffer.pointer);
+
+ /* we return here to disallow the oops to flood screen */
+ return_ACPI_STATUS(AE_ERROR);
+ }
+
+ kfree(name_buffer.pointer);
+
/* Mask off any extra bits in the last datum */
buffer_tail_bits = obj_desc->common_field.bit_length %
prev parent reply other threads:[~2009-03-20 4:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-15 10:47 2.6.29 acpi regression: acpi_ex_extract_from_field -- div by zero Jiri Slaby
2009-03-15 17:49 ` Linus Torvalds
2009-03-15 19:08 ` Moore, Robert
2009-03-15 19:32 ` Jiri Slaby
[not found] ` <d3f22a0903152046m891dc0aq6ca01eed32a9eb32@mail.gmail.com>
2009-03-16 3:42 ` Lin Ming
2009-03-16 16:31 ` Jiri Slaby
2009-03-18 8:08 ` Jiri Slaby
2009-03-19 16:06 ` Jiri Slaby
2009-03-20 0:48 ` Lin Ming
2009-03-20 4:53 ` Lin Ming [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1237524810.879.19.camel@minggr \
--to=ming.m.lin@intel.com \
--cc=jirislaby@gmail.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=robert.moore@intel.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.