kern/117591: [acpi][panic] Divide by zero bug in ACPI

[Jung-uk Kim]

On Monday 19 November 2007 07:07 pm, Jessica Mahoney wrote:
> Nate Lawson wrote:
> > John Baldwin wrote:
> >> On Monday 19 November 2007 05:40:03 pm Jessica Mahoney wrote:
> >>>  John Baldwin wrote:
> >>>  > Can you get a stack trace?
> >>>
> >>>  Tracing pid 878 tid 100080 td 0xc3f26440
> >>> 
> >>> acpi_battery_get_battinfo(c3a27980,c3ee4d00,e51e1c60,c3ee4d00,0
> >>>,...) at acpi_battery_get_battinfo+0x26f
> >>>  acpi_battery_ioctl(c0a44203,c3ee4d00,0,c40ec880,e51e1c08,...)
> >>> at acpi_battery_ioctl+0x14b
> >>>  acpiioctl(c3a9e900,c0a44203,c3ee4d00,3,c3f26440,...) at
> >>> acpiioctl_0xdd
> >>> devfs_ioctl_f(c3e35d80,c0a44203,c3ee4d00,c3ee5800,c3f26440,...)
> >>> at devfs_ioctl_f+0xcb
> >>>  kern_ioctl(c3f26440,3,c0a44203,c3ee4d00,1000a24,..._ at
> >>> kern_ioctl+0x355
> >>> ioctl(c3f26440,e51e1cfc,c,c3f26440,e51e1d2c,...) at ioctl+0x134
> >>> syscall(e51e1d38) at syscall+0x345
> >>>  Xint0x80_syscall() at Xint0x80_syscall+0x20
> >>>  --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2815289b, esp
> >>> = 0xbfbfec3c, ebp = 0xbfbfed28 ---
> >>>
> >>>  If there's anything else needed, please let me know and I
> >>> shall provide.
> >>
> >> You can try this:
> >>
> >> Index: acpi_battery.c
> >> ================================================================
> >>=== RCS file: /usr/cvs/src/sys/dev/acpica/acpi_battery.c,v
> >> retrieving revision 1.25
> >> diff -u -r1.25 acpi_battery.c
> >> --- acpi_battery.c      9 Oct 2007 07:51:46 -0000       1.25
> >> +++ acpi_battery.c      19 Nov 2007 23:17:48 -0000
> >> @@ -198,8 +198,10 @@
> >>          */
> >>         if (bif->units == ACPI_BIF_UNITS_MA && bif->dvol != 0) {
> >>             bst[i].rate = (bst[i].rate * bif->dvol) / 1000;
> >> +#if 0
> >>             bst[i].cap = (bst[i].cap * bif->dvol) / 1000;
> >>             bif->lfcap = (bif->lfcap * bif->dvol) / 1000;
> >> +#endif
> >>         }
> >>
> >>         /* Calculate percent capacity remaining. */
> >>
> >> I think the mA => mW scaling is resulting in lfcap becoming 0,
> >> but since all we want is a ratio for 'cap' so we can generate a
> >> percentage, we don't actually need to scale this.
> >
> > I think this was already fixed in RELENG_6, 7, and 8-current. 
> > Can the submitter cvsup and try again?
>
> I just did a cvsup last night, and the issue still persists (hence
> why I was able to provide a trace).

Can you try the attached patch?

Jung-uk Kim
-------------- next part --------------
Index: acpi_battery.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_battery.c,v
retrieving revision 1.25
diff -u -r1.25 acpi_battery.c
--- acpi_battery.c	9 Oct 2007 07:51:46 -0000	1.25
+++ acpi_battery.c	20 Nov 2007 00:40:57 -0000
@@ -167,11 +167,12 @@
 	    dev_idx = i;
 
 	/*
-	 * Be sure we can get various info from the battery.  Note that we
-	 * can't check acpi_BatteryIsPresent() because smart batteries only
+	 * Be sure we can get various info from the battery.  Note that
+	 * acpi_BatteryIsPresent() is not enough because smart batteries only
 	 * return that the device is present.
 	 */
-	if (ACPI_BATT_GET_STATUS(batt_dev, &bst[i]) != 0 ||
+	if (!acpi_BatteryIsPresent(batt_dev) ||
+	    ACPI_BATT_GET_STATUS(batt_dev, &bst[i]) != 0 ||
 	    ACPI_BATT_GET_INFO(batt_dev, bif) != 0)
 	    continue;