Using the ioctl interface provided for manipulating /dev/acpi pseudo-device , in particular the ACPIIO_BATT_GET_BATTINFO request give me a integer divide kernel fault exception. The computer sysctl oids acpi information : hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.acline: 1 hw.acpi.battery.life: 100 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 52.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 88.0C hw.acpi.thermal.tz0._HOT: 95.0C hw.acpi.thermal.tz0._CRT: -1 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 How-To-Repeat: To repeat the problem, follow the next steps : 1) Connect the AC power cable to the computer, 2) Remove the battery from the computer. 3) Reconnect the battery to the computer 4) Request a ioctl ACPIIO_BATT_GET_BATTINFO to the /dev/acpi device like this function : (where fd is a reference to a open filedescriptor with /dev/acpi (in RO mode)) int get_battery_status(int *fd, short number) { union acpi_battery_ioctl_arg battio; battio.unit = number; if(ioctl(*fd, ACPIIO_BATT_GET_BATTINFO, &battio) == -1) { return -1; } if(battio.battinfo.state == ACPI_BATT_STAT_NOT_PRESENT) { return -1; } return 0; }
State Changed From-To: open->feedback To submitter: could you please recompile your kernel with options DDB options GDB then crash the machine again, take a copy of the whole of the panic text printed, then issue the command "bt" from the debugger prompt and again copy it down? Uploading readable digital camera images of this output is usually sufficient to determine what is going on.
Responsible Changed From-To: freebsd-i386->gavin Track
I got the next panic string Panic string : Integer divide fault The kgdb backtrace show me the next: (kgdb) backtrace #0 doadump () at pcpu.h:195 #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a4905c in trap_fatal (frame=0xd4fbab60, eva=0) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a49e1d in trap (frame=0xd4fbab60) at /usr/src/sys/i386/i386/trap.c:686 #5 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc0d7a957 in ?? () Previous frame inner to this frame (corrupt stack?) I got the crash dump files , if you need it , i can send it. -- Jorge Niedbalski R.
On Wed, 2008-03-26 at 03:50 +0000, jorge niedbalski wrote: > I got the next panic string > > Panic string : Integer divide fault > > The kgdb backtrace show me the next: > > (kgdb) backtrace > #0 doadump () at pcpu.h:195 > #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc0754719 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc0a4905c in trap_fatal (frame=0xd4fbab60, eva=0) > at /usr/src/sys/i386/i386/trap.c:899 > #4 0xc0a49e1d in trap (frame=0xd4fbab60) at > /usr/src/sys/i386/i386/trap.c:686 > #5 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #6 0xc0d7a957 in ?? () > Previous frame inner to this frame (corrupt stack?) > > I got the crash dump files , if you need it , i can send it. What happens if you try to get the backtrace from within the kernel debugger itself? Sometimes that is better at unravelling corrupt stacks. Thanks, Gavin
State Changed From-To: feedback->closed Feedback timeout (~1 year). I suspect this was fixed by src/sys/dev/acpica/acpi_battery.c 1.26, which was MFC'd before 7.1 was released.