Panic on 6.1REL using linux compat

[John Baldwin]

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