Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 9 Mar 1997 08:07:17 +0200 (EET)
From:      Heikki Suonsivu <hsu@clinet.fi>
To:        FreeBSD-gnats-submit@freebsd.org
Subject:   kern/2923: panic: vm_fault: fault on nofault entry, addr: f6e21000
Message-ID:  <199703090607.IAA01418@news.clinet.fi>
Resent-Message-ID: <199703090610.WAA29190@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         2923
>Category:       kern
>Synopsis:       panic: vm_fault: fault on nofault entry, addr: f6e21000
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar  8 22:10:02 PST 1997
>Last-Modified:
>Originator:     Heikki Suonsivu
>Organization:
Clinet, Espoo, Finland
>Release:        FreeBSD 2.2-GAMMA i386
>Environment:

news server, 7 disks now (3G quantum), P150, 2*2940.  This also happened
with 4*seagate + P120 + 1*3940.

>Description:

hsu#news.clinet.fi Sun 3: gdb -k kernel.18 vmcore.18
GDB is free software and you are welcome to 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.
GDB 4.16 (i386-unknown-freebsd), 
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 272000
current pcb at 211dd8
panic: vm_fault: fault on nofault entry, addr: %lx
#0  boot (howto=256) at ../../kern/kern_shutdown.c:243
243                                     dumppcb.pcb_cr3 = rcr3();
(kgdb) up
#1  0xf01124e2 in panic (
    fmt=0xf01bab87 "vm_fault: fault on nofault entry, addr: %lx")
    at ../../kern/kern_shutdown.c:367
367             boot(bootopt);
(kgdb) up
#2  0xf01bacae in vm_fault (map=0xf3ce8f00, vaddr=4142010368, 
    fault_type=1 '\001', change_wiring=0) at ../../vm/vm_fault.c:201
201                     panic("vm_fault: fault on nofault entry, addr: %lx",
(kgdb) up
#3  0xf01cf7e4 in trap_pfault (frame=0xefbffc74, usermode=0)
    at ../../i386/i386/trap.c:642
642                     rv = vm_fault(map, va, ftype, FALSE);
(kgdb) up
#4  0xf01cf50f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = 8191, 
      tf_esi = -190055168, tf_ebp = -272630456, tf_isp = -272630628, 
      tf_ebx = -152955599, tf_edx = -158953624, tf_ecx = 54577, tf_eax = 0, 
      tf_trapno = 12, tf_err = 0, tf_eip = -266652905, tf_cs = 8, 
      tf_eflags = 66178, tf_esp = -186717952, tf_ss = -272630396})
    at ../../i386/i386/trap.c:311
311                             (void) trap_pfault(&frame, FALSE);
(kgdb) up
#5  0xf01b3317 in ufs_lookup (ap=0xefbffd84) at ../../ufs/ufs/ufs_lookup.c:279
279                     ep = (struct direct *)((char *)bp->b_data + entryoffsetinblock);
(kgdb) list
274                      * Full validation checks are slow, so we only check
275                      * enough to insure forward progress through the
276                      * directory. Complete checks can be run by patching
277                      * "dirchk" to be true.
278                      */
279                     ep = (struct direct *)((char *)bp->b_data + entryoffsetinblock);
280                     if (ep->d_reclen == 0 ||
281                         (dirchk && ufs_dirbadentry(vdp, ep, entryoffsetinblock))) {
282                             int i;
283
(kgdb)

This problem is exactly the same as bad dir panic, it just freaks out
differently.  The panic always occurs at the above point, with wrong data
(usually seems contents of a some file) in a block the directory lookup
routine thinks is part of a directory.

Access to this and 4-5 other dumps on the subject is available on request I
do not have space for more than 4-5 dumps on-line.  They seem to always be
from the same problem, so there should be good material to find
similarities from to solve this.

>How-To-Repeat:

Run a news server with 2.2.  Full feed and bunch of readers (around 100
max, but panics usually occur with less load).  Expire articles one-by-one
to keep the free disk space at certain limit instead of running traditional
expire.  The latter may contribute to the problem, as I got metoos for
this.

This same problem happens with all machines, but the problem is very rare
with unloaded machines.

>Fix:
	
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703090607.IAA01418>