From mo@sol.nevali.net  Fri Aug 10 09:30:17 2007
Return-Path: <mo@sol.nevali.net>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 82CD616A417
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 10 Aug 2007 09:30:17 +0000 (UTC)
	(envelope-from mo@sol.nevali.net)
Received: from sol.nevali.net (sol.nevali.net [217.112.91.80])
	by mx1.freebsd.org (Postfix) with ESMTP id 52FFD13C4A8
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 10 Aug 2007 09:30:17 +0000 (UTC)
	(envelope-from mo@sol.nevali.net)
Received: by sol.nevali.net (Postfix, from userid 501)
	id C45856512; Fri, 10 Aug 2007 10:10:10 +0100 (BST)
Message-Id: <20070810091010.C45856512@sol.nevali.net>
Date: Fri, 10 Aug 2007 10:10:10 +0100 (BST)
From: Mo McRoberts <mo@nevali.net>
Reply-To: Mo McRoberts <mo@nevali.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: panic: vm_fault: fault on nofault entry, addr: e120d000
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         115374
>Category:       kern
>Synopsis:       [panic] vm_fault: fault on nofault entry, addr: e120d000
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Aug 10 09:40:02 GMT 2007
>Closed-Date:    Mon May 23 15:28:24 UTC 2011
>Last-Modified:  Mon May 23 15:28:24 UTC 2011
>Originator:     Mo McRoberts
>Release:        FreeBSD 6.2-RELEASE-p6 i386
>Organization:
>Environment:
System: FreeBSD sol.nevali.net 6.2-RELEASE-p6 FreeBSD 6.2-RELEASE-p6 #0: Sun Jul 15 18:39:11 BST 2007 root@sol.nevali.net:/usr/obj/usr/src/sys/SOL i386

>Description:
Kernel panics on a regular basis with:

panic: vm_fault: fault on nofault entry, addr: e120d000

I must confess I don't know how to get more detailed information
on the problem. I remember reading a page a while ago with instructions,
but I can't locate it again.

I'm happy to provide more information if somebody can tell me how and what.
The machine is, however, situated several hundred miles away from me, so
anything requiring physical access is out of the question.

The panics are occurring at least once every 24h, sometimes more frequently.
Load patterns are variable but generally low.

>How-To-Repeat:
Unknown.
>Fix:
Unknown.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: remko 
State-Changed-When: Fri Aug 10 09:53:14 UTC 2007 
State-Changed-Why:  
I asked for additional information reflect that in the ticket (see my followup for my exact question). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=115374 

From: Remko Lodder <remko@elvandar.org>
To: Mo McRoberts <mo@nevali.net>
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: kern/115374: panic: vm_fault: fault on nofault entry, addr:
	e120d000
Date: Fri, 10 Aug 2007 11:52:28 +0200

 On Fri, Aug 10, 2007 at 10:10:10AM +0100, Mo McRoberts wrote:
 > 
 > Kernel panics on a regular basis with:
 > 
 > panic: vm_fault: fault on nofault entry, addr: e120d000
 > 
 > I must confess I don't know how to get more detailed information
 > on the problem. I remember reading a page a while ago with instructions,
 > but I can't locate it again.
 > 
 > I'm happy to provide more information if somebody can tell me how and what.
 > The machine is, however, situated several hundred miles away from me, so
 > anything requiring physical access is out of the question.
 > 
 > The panics are occurring at least once every 24h, sometimes more frequently.
 > Load patterns are variable but generally low.
 > 
 
 Hello,
 
 You need to look in the developers-handbook (http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html)
 for more information about this topic. Hopefully you have serial access or something to get into the Debugger. If not
 you might want to try and dump any panics to the disk (as mentioned in the dev-handbook). If that all is not possible
 I hate to say this but: then you are on your own, we need -a lot more- information before we can actually do anything
 with this (in that case: sorry).
 
 Cheers
 remko
 
 
 -- 
 Kind regards,
 
      Remko Lodder               ** remko@elvandar.org
      FreeBSD                    ** remko@FreeBSD.org
 
      /* Quis custodiet ipsos custodes */

From: Mo McRoberts <mo@nevali.net>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/115374: [panic] vm_fault: fault on nofault entry, addr: e120d000
Date: Sat, 11 Aug 2007 14:14:40 +0100

 Hi,
 
 Thanks for the pointer to the developer's handbook. I've enabled a  
 dump device and directory, and so should get a kernel dump next time  
 it panics. It's a custom-compiled kernel (though the only  
 configuration tweaks were IPFIREWALL options), so I've still got the  
 object files lying around for inspection via kgdb.
 
 I'll follow up when I've got something more useful.
 
 Thanks,
 
 Mo.
 
 

From: Mo McRoberts <mo@nevali.net>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/115374: [panic] vm_fault: fault on nofault entry, addr: e120d000
Date: Mon, 13 Aug 2007 10:11:30 +0100

 I don't know how much this backtrace helps in finding the problem,  
 but here goes:
 
 [root@sol.nevali.net SOL]# kgdb kernel.debug /var/crash/vmcore.0
 kgdb: kvm_nlist(_stopped_cpus):
 kgdb: kvm_nlist(_stoppcbs):
 [GDB will not be able to debug user-mode threads: /usr/lib/ 
 libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 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-marcel-freebsd".
 
 Unread portion of the kernel message buffer:
 panic: vm_fault: fault on nofault entry, addr: e120d000
 Uptime: 4h15m43s
 Dumping 735 MB (2 chunks)
    chunk 0: 1MB (159 pages) ... ok
    chunk 1: 735MB (188144 pages) 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:165
 165             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
 (kgdb) bt
 #0  doadump () at pcpu.h:165
 #1  0xc0672dae in boot (howto=260) at /usr/src/sys/kern/ 
 kern_shutdown.c:409
 #2  0xc0673044 in panic (
      fmt=0xc0915c6e "vm_fault: fault on nofault entry, addr: %lx")
      at /usr/src/sys/kern/kern_shutdown.c:565
 #3  0xc07e7738 in vm_fault (map=0xc104b000, vaddr=3777024000,
      fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/ 
 vm_fault.c:279
 #4  0xc088e74a in trap_pfault (frame=0xdb89bbf8, usermode=0,  
 eva=3777024000)
      at /usr/src/sys/i386/i386/trap.c:734
 #5  0xc088e3d9 in trap (frame=
        {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -999804900,  
 tf_esi = -517943298, tf_ebp = -611730300, tf_isp = -611730396, tf_ebx  
 = -1002619648, tf_edx = 0, tf_ecx = 505, tf_eax = -481861602,  
 tf_trapno = 12, tf_err = 0, tf_eip = -1064777994, tf_cs = 32,  
 tf_eflags = 66070, tf_esp = 18412, tf_ss = 2048})
      at /usr/src/sys/i386/i386/trap.c:435
 #6  0xc087caaa in calltrap () at /usr/src/sys/i386/i386/exception.s:139
 #7  0xc088c6f6 in generic_bcopy () at /usr/src/sys/i386/i386/ 
 support.s:489
 Previous frame inner to this frame (corrupt stack?)
 (kgdb) up 7
 #7  0xc088c6f6 in generic_bcopy () at /usr/src/sys/i386/i386/ 
 support.s:489
 489             cld                                     /* nope, copy  
 forwards */
 Current language:  auto; currently asm
 (kgdb)
 
 I'm assuming generic_bcopy()'s being called from whatever is really  
 at fault, and with a corrupted stack it's going to be very difficult  
 to find out what?
 
 Mo.
 
 

From: Mo McRoberts <mo@nevali.net>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/115374: [panic] vm_fault: fault on nofault entry, addr: e120d000
Date: Tue, 14 Aug 2007 11:13:05 +0100

 Also, I don't know if this is related, dmesg is showing the following  
 before a panic; it's not always there, but it is more often than it  
 isn't:
 
 rl0: discard oversize frame (ether type 806 flags 3 len 65514 > max  
 1514)
 
 The length always appears to be the same (65514), and is quite  
 obviously wrong (unless the local Ethernet has suddenly started  
 supporting 65KB frames).
 
 It could just be a nearby machine spewing bad frames, of course, but  
 the consistent bad length seems suspicious.
 
 Thanks,
 
 Mo.
 
State-Changed-From-To: feedback->open 
State-Changed-By: linimon 
State-Changed-When: Mon Mar 3 06:51:48 UTC 2008 
State-Changed-Why:  
Note that feedback was received some time ago. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=115374 
State-Changed-From-To: open->feedback 
State-Changed-By: jh 
State-Changed-When: Mon May 23 15:16:26 UTC 2011 
State-Changed-Why:  
Can you still reproduce this on a supported release? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=115374 
State-Changed-From-To: feedback->closed 
State-Changed-By: jh 
State-Changed-When: Mon May 23 15:28:23 UTC 2011 
State-Changed-Why:  
Submitter can't reproduce anymore. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=115374 
>Unformatted:
