From patchwork Sun Mar 15 17:49:41 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Torvalds X-Patchwork-Id: 12194 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n2FHs8I7026398 for ; Sun, 15 Mar 2009 17:54:08 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754162AbZCORyF (ORCPT ); Sun, 15 Mar 2009 13:54:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754105AbZCORyF (ORCPT ); Sun, 15 Mar 2009 13:54:05 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:59245 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751189AbZCORyE (ORCPT ); Sun, 15 Mar 2009 13:54:04 -0400 Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [140.211.169.55]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id n2FHngZb011783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Mar 2009 10:50:18 -0700 Received: from localhost (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id n2FHnfaP018551; Sun, 15 Mar 2009 10:49:41 -0700 Date: Sun, 15 Mar 2009 10:49:41 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Jiri Slaby cc: Len Brown , linux-acpi@vger.kernel.org, rjw@sisk.pl, Linux kernel mailing list Subject: Re: 2.6.29 acpi regression: acpi_ex_extract_from_field -- div by zero In-Reply-To: <49BCDCAA.8040309@gmail.com> Message-ID: References: <49BCDCAA.8040309@gmail.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 X-Spam-Status: No, hits=-3.452 required=5 tests=AWL,BAYES_00 X-Spam-Checker-Version: SpamAssassin 3.2.4-osdl_revision__1.47__ X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org 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(-) -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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,