Bug #271

acpi panic

Added by rnyberg over 7 years ago. Updated over 7 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Apart from the pf panic I have another panic that occurs from time to time.
Below are the backtrace and dmesg. The core dump is available if needed.

-Richard

Panic
*****
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xff807d10
stack pointer = 0x10:0xff807cfc
frame pointer = 0x10:0xff807d1c
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = resume, IOPL = 0
current process = Idle
current thread = pri 12

trap number = 12
panic: page fault

Backtrace
*********
#0 dumpsys () at thread.h:83
#1 0xc02b97bc in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:335
#2 0xc02b9d21 in panic (fmt=0xc051441d "%s")
at /usr/src/sys/kern/kern_shutdown.c:684
#3 0xc04c8cd8 in trap_fatal (frame=0xff807cbc, eva=0)
at /usr/src/sys/i386/i386/trap.c:1183
#4 0xc04c8977 in trap_pfault (frame=0xff807cbc, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:1083
#5 0xc04c8594 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = 1, tf_ebp = -8356580, tf_isp = -8356632, tf_ebx = 0, tf_edx = 0, tf_ecx = -8356592, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -8356592, tf_cs = 8, tf_eflags = 65606, tf_esp = 16, tf_ss = -8356592}) at /usr/src/sys/i386/i386/trap.c:654
#6 0xc04b532f in calltrap () at /usr/src/sys/i386/i386/exception.s:774
#7 0xff807d10 in ?? ()
#8 0x00000010 in ?? ()
#9 0xff807d10 in ?? ()
#10 0xc18fa694 in ?? ()
#11 0x00000010 in ?? ()
#12 0x00000000 in ?? ()
#13 0x00000001 in ?? ()
#14 0x00000000 in ?? ()
#15 0xc0724b24 in AcpiGbl_BitRegisterInfo ()
---Type <return> to continue, or q <return> to quit---
#16 0xff807d40 in ?? ()
#17 0xc07026b3 in AcpiGetRegister (RegisterId=0, ReturnValue=0x0, Flags=0)
at /usr/src/sys/dev/acpica5/../../contrib/dev/acpica-unix-20050309/hardware/hwregs.c:381
#18 0xc07026b3 in AcpiGetRegister (RegisterId=0, ReturnValue=0x0,
Flags=3228715812)
at /usr/src/sys/dev/acpica5/../../contrib/dev/acpica-unix-20050309/hardware/hwregs.c:381
#19 0xc07168c9 in acpi_cpu_idle () at /usr/src/sys/dev/acpica5/acpi_cpu.c:925
#20 0xc04baa87 in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:862
#21 0x00000000 in ?? ()

dmesg
*****
Copyright (c) 2003, 2004, 2005, 2006 The DragonFly Project.
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
DragonFly 1.6.0-RELEASE #0: Tue Jul 25 17:23:41 CEST 2006
:/usr/obj/usr/src/sys/GENERIC
TSC clock: 1470085453 Hz, i8254 clock: 1193251 Hz
CPU: AMD Athlon(tm) XP 1700+ (1470.01-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x662 Stepping = 2
Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
AMD Features=0xc0480000<MP,AMIE,DSP,3DNow!>
real memory = 536805376 (524224K bytes)
avail memory = 509386752 (497448K bytes)
Preloaded elf kernel "/kernel" at 0xc06dd000.
Pentium Pro MTRR support enabled
md0: Malloc disk
pcibios: BIOS version 2.10
Using $PIR table, 8 entries at 0xc00fdee0
npx0: <math processor> on motherboard
npx0: INT 16 interface
Using MMX optimized bcopy/copyin/copyout
legacypci0 on motherboard
pcib0: <Host to PCI bridge> on legacypci0
pci0: <PCI bus> on pcib0
agp0: <VIA Generic host to PCI bridge> mem 0xd0000000-0xd7ffffff at device 0.0 on pci0
pcib1: <PCI to PCI bridge (vendor=1106 device=b099)> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
pci1: <NVidia GeForce DDR graphics accelerator> at 0.0 irq 11
fxp0: <Intel 82550 Pro/100 Ethernet> port 0xd000-0xd03f mem 0xe3000000-0xe301ffff,0xe3020000-0xe3020fff irq 10 at device 10.0 on pci0
miibus0: <MII bus> on fxp0
inphy0: <i82555 10/100 media interface> on miibus0
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: MAC address: 00:02:b3:a7:68:1f
vr0: <VIA VT6102 Rhine II 10/100BaseTX> port 0xd400-0xd4ff mem 0xe3021000-0xe30210ff irq 10 at device 12.0 on pci0
miibus1: <MII bus> on vr0
ukphy0: <Generic IEEE 802.3u media interface> on miibus1
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr0: MAC address: 00:05:5d:f5:43:f9
pci0: <unknown card> (vendor=0x1274, dev=0x1371) at 13.0 irq 11
isab0: <PCI to ISA bridge (vendor=1106 device=3074)> at device 17.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <VIA 8233 ATA100 controller> port 0xdc00-0xdc0f at device 17.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: <VIA 83C572 USB controller> port 0xe000-0xe01f irq 11 at device 17.2 on pci0
usb0: <VIA 83C572 USB controller> on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub0: port error, restarting port 1
uhub0: port error, giving up port 1
uhci1: <VIA 83C572 USB controller> port 0xe400-0xe41f irq 11 at device 17.3 on pci0
usb1: <VIA 83C572 USB controller> on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub1: port error, restarting port 1
uhub1: port error, giving up port 1
uhci2: <VIA 83C572 USB controller> port 0xe800-0xe81f irq 11 at device 17.4 on pci0
usb2: <VIA 83C572 USB controller> on uhci2
usb2: USB revision 1.0
uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhub2: port error, restarting port 1
uhub2: port error, giving up port 1
orm0: <Option ROMs> at iomem 0xc0000-0xcffff,0xd0000-0xd7fff,0xd8000-0xd97ff,0xea800-0xf8fff on isa0
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0: <Parallel port bus> on ppc0
plip0: <PLIP network interface> on ppbus0
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
ad0: DMA limited to UDMA33, non-ATA66 cable or device
ad0: 19574MB <IBM-DPTA-372050> [39770/16/63] at ata0-master UDMA33
ad2: 190782MB <ST3200822A> [387621/16/63] at ata1-master UDMA100
acd0: CDROM <SONY CDU4811> at ata0-slave PIO4
Mounting root from ufs:/dev/ad0s1a
cd0 at ata0 bus 0 target 1 lun 0
cd0: <SONY CDU4811 PY06> Removable CD-ROM SCSI-0 device
cd0: 16.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present
WARNING: was not properly dismounted

acpi_cpu.c.diff Magnifier (4.4 KB) qhwt+dfly, 08/01/2006 01:39 PM

History

#1 Updated by qhwt+dfly over 7 years ago

On Mon, Jul 31, 2006 at 12:11:12PM +0200, Richard Nyberg wrote:
> Apart from the pf panic I have another panic that occurs from time to time.

Do you remember when this panic started to occur?
Is your hw.acpi.cpu.cx_lowest set to other than C1? If so, setting it
back to C1 help?

> Below are the backtrace and dmesg. The core dump is available if needed.

Yes, if you have leaf account, plus the asf file, which can be generated
according to simon's instruction:
http://leaf.dragonflybsd.org/mailarchive/bugs/2006-07/msg00163.html

And the output from `acpidump -dt > rnyberg.asl'.

Thanks.

> Backtrace
> *********
> #0 dumpsys () at thread.h:83
> #1 0xc02b97bc in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:335
> #2 0xc02b9d21 in panic (fmt=0xc051441d "%s")
> at /usr/src/sys/kern/kern_shutdown.c:684
> #3 0xc04c8cd8 in trap_fatal (frame=0xff807cbc, eva=0)
> at /usr/src/sys/i386/i386/trap.c:1183
> #4 0xc04c8977 in trap_pfault (frame=0xff807cbc, usermode=0, eva=0)
> at /usr/src/sys/i386/i386/trap.c:1083
> #5 0xc04c8594 in trap (frame=
> {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = 1, tf_ebp = -8356580, tf_isp = -8356632, tf_ebx = 0, tf_edx = 0, tf_ecx = -8356592, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -8356592, tf_cs = 8, tf_eflags = 65606, tf_esp = 16, tf_ss = -8356592}) at /usr/src/sys/i386/i386/trap.c:654
> #6 0xc04b532f in calltrap () at /usr/src/sys/i386/i386/exception.s:774
> #7 0xff807d10 in ?? ()
> #8 0x00000010 in ?? ()
> #9 0xff807d10 in ?? ()
> #10 0xc18fa694 in ?? ()
> #11 0x00000010 in ?? ()
> #12 0x00000000 in ?? ()
> #13 0x00000001 in ?? ()
> #14 0x00000000 in ?? ()
> #15 0xc0724b24 in AcpiGbl_BitRegisterInfo ()
> ---Type <return> to continue, or q <return> to quit---
> #16 0xff807d40 in ?? ()
> #17 0xc07026b3 in AcpiGetRegister (RegisterId=0, ReturnValue=0x0, Flags=0)
> at /usr/src/sys/dev/acpica5/../../contrib/dev/acpica-unix-20050309/hardware/hwregs.c:381
> #18 0xc07026b3 in AcpiGetRegister (RegisterId=0, ReturnValue=0x0,
> Flags=3228715812)
> at /usr/src/sys/dev/acpica5/../../contrib/dev/acpica-unix-20050309/hardware/hwregs.c:381
> #19 0xc07168c9 in acpi_cpu_idle () at /usr/src/sys/dev/acpica5/acpi_cpu.c:925
> #20 0xc04baa87 in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:862
> #21 0x00000000 in ?? ()

#2 Updated by qhwt+dfly over 7 years ago

On Mon, Jul 31, 2006 at 08:21:30PM +0900, YONETANI Tomokazu wrote:
> > Below are the backtrace and dmesg. The core dump is available if needed.
>
> Yes, if you have leaf account, plus the asf file, which can be generated
> according to simon's instruction:
> http://leaf.dragonflybsd.org/mailarchive/bugs/2006-07/msg00163.html

Oh, this already contains symbols from acpi driver, which means
either the driver is compiled into the kernel, or you already used
the asf file to show this backtrace. Hmm, I'm starting to feel that
the dump may not be very helpful, since it's showing an array
(AcpiGbl_BitRegisterInfo) as a function, and the addresses above that
frame doesn't look like valid to me. If you can reproduce the panic
while you're on console, the list of function names and the offset
below calltrap() in DDB is probably more helpful.

> > #6 0xc04b532f in calltrap () at /usr/src/sys/i386/i386/exception.s:774
> > #7 0xff807d10 in ?? ()
> > #8 0x00000010 in ?? ()
> > #9 0xff807d10 in ?? ()
> > #10 0xc18fa694 in ?? ()
> > #11 0x00000010 in ?? ()
> > #12 0x00000000 in ?? ()
> > #13 0x00000001 in ?? ()
> > #14 0x00000000 in ?? ()
> > #15 0xc0724b24 in AcpiGbl_BitRegisterInfo ()
> > ---Type <return> to continue, or q <return> to quit---
> > #16 0xff807d40 in ?? ()
> > #17 0xc07026b3 in AcpiGetRegister (RegisterId=0, ReturnValue=0x0, Flags=0)
> > at /usr/src/sys/dev/acpica5/../../contrib/dev/acpica-unix-20050309/hardware/hwregs.c:381

#3 Updated by rnyberg over 7 years ago

At Tue, 1 Aug 2006 11:12:17 +0900,
YONETANI Tomokazu wrote:
>
> On Mon, Jul 31, 2006 at 08:21:30PM +0900, YONETANI Tomokazu wrote:
> > > Below are the backtrace and dmesg. The core dump is available if needed.
> >
> > Yes, if you have leaf account, plus the asf file, which can be generated
> > according to simon's instruction:
> > http://leaf.dragonflybsd.org/mailarchive/bugs/2006-07/msg00163.html
>
> Oh, this already contains symbols from acpi driver, which means
> either the driver is compiled into the kernel, or you already used
> the asf file to show this backtrace. Hmm, I'm starting to feel that
> the dump may not be very helpful, since it's showing an array
> (AcpiGbl_BitRegisterInfo) as a function, and the addresses above that
> frame doesn't look like valid to me. If you can reproduce the panic
> while you're on console, the list of function names and the offset
> below calltrap() in DDB is probably more helpful.

Yes, I already loaded the symbols. I uploaded the core to leaf anyway, but
I have enabled DDB again. So now I'm just waiting for it to panic :)

Thanks!
-Richard

#4 Updated by rnyberg over 7 years ago

At Mon, 31 Jul 2006 20:21:30 +0900,
YONETANI Tomokazu wrote:
>
> On Mon, Jul 31, 2006 at 12:11:12PM +0200, Richard Nyberg wrote:
> > Apart from the pf panic I have another panic that occurs from time to time.
>
> Do you remember when this panic started to occur?
No, sorry.

It's set to C1.

All uploaded and available at ~rnyberg/crash/acpi.

Thanks!
-Richard

#5 Updated by rnyberg over 7 years ago

At Tue, 01 Aug 2006 10:59:30 +0200,
Richard Nyberg wrote:
>
> At Tue, 1 Aug 2006 11:12:17 +0900,
> YONETANI Tomokazu wrote:
> > Oh, this already contains symbols from acpi driver, which means
> > either the driver is compiled into the kernel, or you already used
> > the asf file to show this backtrace. Hmm, I'm starting to feel that
> > the dump may not be very helpful, since it's showing an array
> > (AcpiGbl_BitRegisterInfo) as a function, and the addresses above that
> > frame doesn't look like valid to me. If you can reproduce the panic
> > while you're on console, the list of function names and the offset
> > below calltrap() in DDB is probably more helpful.
>
> Yes, I already loaded the symbols. I uploaded the core to leaf anyway, but
> I have enabled DDB again. So now I'm just waiting for it to panic :)
>
Didn't have to wait very long :)
The strange frames seem to be some artifact of kgdb.

Should I upload this core too?

Trace from DDB:
CPU_prvspace + 0x7d10
AcpiGetRegister + 0x63
acpi_cpu_idle + 0x82
cpu_idle + 0x96

Trace from kgdb (with module symbols):
#0 dumpsys () at thread.h:83
#1 0xc0164009 in db_fncall (dummy1=-1067582128, dummy2=0, dummy3=-1070999800,
dummy4=0xff807b38 "`{\200ÿ\226WKÀ\001") at /usr/src/sys/ddb/db_command.c:541
#2 0xc0163dc3 in db_command (last_cmdp=0xc05cb110, cmd_table=0x0, aux_cmd_tablep=0xc056ec54,
aux_cmd_tablep_end=0xc056ec6c) at /usr/src/sys/ddb/db_command.c:343
#3 0xc0163ea3 in db_command_loop () at /usr/src/sys/ddb/db_command.c:469
#4 0xc0166a20 in db_trap (type=12, code=2) at /usr/src/sys/ddb/db_trap.c:71
#5 0xc04b4064 in kdb_trap (type=12, code=2, regs=0xff807cbc)
at /usr/src/sys/i386/i386/db_interface.c:150
#6 0xc04c8ca8 in trap_fatal (frame=0xff807cbc, eva=0) at /usr/src/sys/i386/i386/trap.c:1178
#7 0xc04c8977 in trap_pfault (frame=0xff807cbc, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:1083
#8 0xc04c8594 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = 1, tf_ebp = -8356580, tf_isp = -8356632, tf_ebx = 0, tf_edx = 0, tf_ecx = -8356592, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -8356592, tf_cs = 8, tf_eflags = 65606, tf_esp = 16, tf_ss = -8356592})
at /usr/src/sys/i386/i386/trap.c:654
#9 0xc04b532f in calltrap () at /usr/src/sys/i386/i386/exception.s:774
#10 0xff807d10 in ?? ()
#11 0x00000010 in ?? ()
#12 0xff807d10 in ?? ()
#13 0xc18fa694 in ?? ()
#14 0x00000010 in ?? ()
#15 0x00000000 in ?? ()
#16 0x00000001 in ?? ()
#17 0x00000000 in ?? ()
#18 0xc0724b24 in AcpiGbl_BitRegisterInfo ()
#19 0xff807d40 in ?? ()
#20 0xc07026b3 in AcpiGetRegister (RegisterId=0, ReturnValue=0x0, Flags=0)
at /usr/src/sys/dev/acpica5/../../contrib/dev/acpica-unix-20050309/hardware/hwregs.c:381
#21 0xc07026b3 in AcpiGetRegister (RegisterId=0, ReturnValue=0x0, Flags=3228715812)
at /usr/src/sys/dev/acpica5/../../contrib/dev/acpica-unix-20050309/hardware/hwregs.c:381
#22 0xc07168c9 in acpi_cpu_idle () at /usr/src/sys/dev/acpica5/acpi_cpu.c:925
#23 0xc04baa87 in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:862
#24 0x00000000 in ?? ()

-Richard

#6 Updated by qhwt+dfly over 7 years ago

On Tue, Aug 01, 2006 at 11:21:55AM +0200, Richard Nyberg wrote:
> At Tue, 01 Aug 2006 10:59:30 +0200,
> Richard Nyberg wrote:
> >
> > At Tue, 1 Aug 2006 11:12:17 +0900,
> > YONETANI Tomokazu wrote:
> > > Oh, this already contains symbols from acpi driver, which means
> > > either the driver is compiled into the kernel, or you already used
> > > the asf file to show this backtrace. Hmm, I'm starting to feel that
> > > the dump may not be very helpful, since it's showing an array
> > > (AcpiGbl_BitRegisterInfo) as a function, and the addresses above that
> > > frame doesn't look like valid to me. If you can reproduce the panic
> > > while you're on console, the list of function names and the offset
> > > below calltrap() in DDB is probably more helpful.
> >
> > Yes, I already loaded the symbols. I uploaded the core to leaf anyway, but
> > I have enabled DDB again. So now I'm just waiting for it to panic :)
> >
> Didn't have to wait very long :)
> The strange frames seem to be some artifact of kgdb.
>
> Should I upload this core too?
>
> Trace from DDB:
> CPU_prvspace + 0x7d10
> AcpiGetRegister + 0x63
> acpi_cpu_idle + 0x82
> cpu_idle + 0x96

Ok, please try the patch attached to this message (this brings
revisions 1.44-1.45 of acpi_cpu.c from FreeBSD), and see if it
helps.

Regards.

#7 Updated by rnyberg over 7 years ago

At Tue, 1 Aug 2006 22:32:40 +0900,
YONETANI Tomokazu wrote:
> Ok, please try the patch attached to this message (this brings
> revisions 1.44-1.45 of acpi_cpu.c from FreeBSD), and see if it
> helps.
>
Too early to be certain of course, but it seems to have done the trick.
I've had no crashes related to this for two days now.

Thanks!
-Richard

#8 Updated by corecode over 7 years ago

fixed in rev 1.13

Also available in: Atom PDF