DragonFlyBSD

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 ?? ()

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

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

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

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

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.

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

fixed in rev 1.13