Date: Mon, 21 Aug 2006 12:49:06 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-amd64@freebsd.org Subject: Re: Panic on 6.1REL using linux compat Message-ID: <200608211249.07018.jhb@freebsd.org> In-Reply-To: <200608192359.36462.pieter@degoeje.nl> References: <200608192359.36462.pieter@degoeje.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 19 August 2006 17:59, Pieter de Goeje wrote:
> The box in question is a dual core athlon64, running 6.1-RELEASE-p3 amd64
with
> SMP enabled. The box has been panicing every month or so, and i've obtained
a
> crashdump the last time. The primary use for the box is hosting Half-Life
> Dedicated Servers, using linux compatibility. One of them was the current
> process seen in the panic below.
>
> Backtrace:
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address = 0x48
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xffffffff8023d923
> stack pointer = 0x10:0xffffffffa79c9620
> frame pointer = 0x10:0x4
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 74823 (hlds_amd)
> trap number = 12
> panic: page fault
> cpuid = 1
> Uptime: 14d14h36m48s
> Dumping 1023 MB (2 chunks)
> chunk 0: 1MB (156 pages) ... ok
> chunk 1: 1023MB (261808 pages) 1007 991 975 959 943 927 911 895 879 863
847
> 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543
> 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239
> 223 207 191 175 159 143 127 111 95 79 63 47 31 15
>
> #0 doadump () at pcpu.h:172
> 172 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
> (kgdb) backtrace
> #0 doadump () at pcpu.h:172
> #1 0x8888888888888889 in ?? ()
> #2 0xffffffff801f97d7 in boot (howto=260)
> at /usr/src/sys/kern/kern_shutdown.c:402
> #3 0xffffffff801f9e71 in panic (fmt=0xffffff000a44abe0 "")
> at /usr/src/sys/kern/kern_shutdown.c:558
> #4 0xffffffff803350ff in trap_fatal (frame=0xffffff000a44abe0,
> eva=18446742974534823936) at /usr/src/sys/amd64/amd64/trap.c:660
> #5 0xffffffff8033541f in trap_pfault (frame=0xffffffffa79c9570, usermode=0)
> at /usr/src/sys/amd64/amd64/trap.c:573
> #6 0xffffffff803356d3 in trap (frame=
> {tf_rdi = 72, tf_rsi = 0, tf_rdx = 72, tf_rcx = 0, tf_r8
> = -1098734541056, tf_r9 = 50, tf_rax = 144, tf_rbx = -1098734541056, tf_rbp
=
> 4, tf_r10 = -1098734541056, tf_r11 = -2144558112, tf_r12 = -1098734541056,
> tf_r13 = -1099503775744, tf_r14 = 0, tf_r15 = 1, tf_trapno = 12, tf_addr =
> 72, tf_flags = -2144884788, tf_err = 0, tf_rip = -2145134301, tf_cs = 8,
> tf_rflags = 66054, tf_rsp = -1482910152, tf_ss = 0})
> at /usr/src/sys/amd64/amd64/trap.c:352
> #7 0xffffffff80321acb in calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:168
> #8 0xffffffff8023d923 in m_length (m0=0x48, last=0x0)
> at /usr/src/sys/kern/uipc_mbuf.c:1173
> #9 0xffffffff8023d94b in m_fixhdr (m0=0xffffff002e516700)
> at /usr/src/sys/kern/uipc_mbuf.c:1161
This doesn't make any sense.. m0 is passed directly to m_length, it's value
shouldn't change. You either have a random memory corruption bug or you have
faulty hardware.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200608211249.07018.jhb>