Date: Mon, 1 May 2000 20:47:18 +0300 From: Panagiotis Astithas <past@netmode.ntua.gr> To: mobile@freebsd.org Subject: APM panics Message-ID: <20000501204717.A18149@netmode.ece.ntua.gr>
next in thread | raw e-mail | index | archive | help
Hello,
I have a DTK Computer laptop, with FreeBSD 4.0-STABLE, as of 2 weeks ago.
It is a Pentium 233MMX machine with an Intel 430TX chipset.
The BIOS is Phoenix BIOS 4.0 Release 6.0, and initially the version was
2.03, but I recently upgraded to 2.30. I guess this is the manufacturer's
version. The following symptoms were observed regardless of the version.
My machine constantly panics whenever I try to perform any action with
respect to APM. That is, it panics on booting when apm -e enable is
executed from rc.i386, it panics if I do apm without options (having
apm_enable='NO' in rc.conf), etc. Under 3.4-STABLE I could boot and do
suspend/resume by closing the cover, but I used to get panics whenever I
tried to get some status information with apm, xbatt, etc.
My kernel config has:
device apm0 at nexus? flags 0x20
but I have also tried:
device apm0
dmesg shows:
apm0: <APM BIOS> on motherboard
apm: found APM BIOS v1.2, connected at v1.2
and when I ran apm, I got in the console:
Apr 30 20:17:54 laptop /kernel: kernel trap 12 with interrupts disabled
Apr 30 20:17:54 laptop /kernel:
Apr 30 20:17:54 laptop /kernel:
Apr 30 20:17:54 laptop /kernel: Fatal trap 12: page fault while in kernel mode
Apr 30 20:17:54 laptop /kernel: fault virtual address = 0x9ccc
Apr 30 20:17:54 laptop /kernel: fault code = supervisor write, page
not present
Apr 30 20:17:54 laptop /kernel: instruction pointer = 0x58:0x2f9d
Apr 30 20:17:54 laptop /kernel: stack pointer = 0x10:0xc61a9ccc
Apr 30 20:17:54 laptop /kernel: frame pointer = 0x10:0xc61a9cce
Apr 30 20:17:54 laptop /kernel: code segment = base 0xc00f0000, limit
0xffff, type 0x1b
Apr 30 20:17:54 laptop /kernel: = DPL 0, pres 1, def32 0, gran 0
Apr 30 20:17:54 laptop /kernel: processor eflags = resume, IOPL = 0
Apr 30 20:17:54 laptop /kernel: current process = 229 (apm)
Apr 30 20:17:54 laptop /kernel: interrupt mask = none
Apr 30 20:17:54 laptop /kernel: trap number = 12
Apr 30 20:17:54 laptop /kernel: panic: page fault
Apr 30 20:17:54 laptop /kernel:
Apr 30 20:17:54 laptop /kernel: syncing disks... 10 7
Apr 30 20:17:54 laptop /kernel: done
Apr 30 20:17:54 laptop /kernel: Uptime: 2m24s
Apr 30 20:17:54 laptop /kernel: Apr 30 20:17:54 laptop /kernel: dumping to dev #ad/0x20001, offset 196608
Apr 30 20:17:54 laptop /kernel: dump ata0: resetting devices .. done
Apr 30 20:17:54 laptop /kernel: 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49
48 47 46
Using kgdb I get:
laptop# gdb -k kernel.debug /var/crash/vmcore.2
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 3174400
initial pcb at 292500
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x8ccc
fault code = supervisor write, page not present
instruction pointer = 0x58:0x2f9d
stack pointer = 0x10:0xc6118ccc
frame pointer = 0x10:0xc6118cce
code segment = base 0xc00f0000, limit 0xffff, type 0x1b
= DPL 0, pres 1, def32 0, gran 0
processor eflags = resume, IOPL = 0
current process = 142 (apm)
interrupt mask = none
trap number = 12
panic: page fault
syncing disks... 47 46 29 16 5
done
Uptime: 11s
dumping to dev #ad/0x20001, offset 196608
dump ata0: resetting devices .. done
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=Cannot access memory at address 0xc61a9bec.
) at ../../kern/kern_shutdown.c:304
304 dumppcb.pcb_cr3 = rcr3();
which gives me no clues on how to pursue this. Using up in kgdb at this point
does not show any other stack frames.
I would appreciate any insight anyone might have in this case.
Cheers,
-past
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000501204717.A18149>