Date: Mon, 19 Nov 2007 19:42:24 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-acpi@FreeBSD.org Subject: Re: kern/117591: [acpi][panic] Divide by zero bug in ACPI Message-ID: <200711191942.26740.jkim@FreeBSD.org> In-Reply-To: <47422550.8030208@varusonline.com> References: <200711192240.lAJMe3Sg075715@freefall.freebsd.org> <47421B56.2040809@root.org> <47422550.8030208@varusonline.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Boundary-00=_y1iQHzRg3hw8R10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --Boundary-00=_y1iQHzRg3hw8R10 Content-Type: text/plain; charset="iso-8859-1"; name="acpi_battery.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="acpi_battery.c.diff" 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; --Boundary-00=_y1iQHzRg3hw8R10--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200711191942.26740.jkim>