kern/71086: Panic in vm_page_remove()

[Sean Farley]

>Number:         71086
>Category:       kern
>Synopsis:       Panic in vm_page_remove()
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Aug 28 20:00:39 GMT 2004
>Closed-Date:
>Last-Modified:
>Originator:     Sean Farley
>Release:        FreeBSD 4.10-STABLE i386
>Organization:
>Environment:
System: FreeBSD thor.farley.org 4.10-STABLE FreeBSD 4.10-STABLE #2: Tue Aug 3 17:37:38 CDT 2004 root at thor.farley.org:/usr/obj/usr/src/sys/THOR i386

Latest nVidia drivers.

>Description:
I recently received a panic in vm_page_remove() which got me looking for
similar panics in the past for other people.  From this search, I came
across a change that was made to fix a similar problem and was quickly
reverted afterwards.

My system experienced panics in the past, but I may or may not have
fixed it.  More recently my system has been freezing (with and without
nVidia drivers) providing no clue to the reason.  Fortunately, I was on
the console when it died as opposed to within X, although X was running
with some applications.  I believe this allowed the kernel to at least
fall into DDB.

Fix:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/pmap.c.diff?r1=1.250.2.19&r2=1.250.2.20&only_with_tag=RELENG_4&f=h

Regression?:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/i386/pmap.c.diff?r1=1.250.2.20&r2=1.250.2.21&only_with_tag=RELENG_4&f=h

Mention of patch to remove the change:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=bilo8r%241vbn%241%40FreeBSD.csie.NCTU.edu.tw&rnum=14

Panic (function trace) as scribbled from DDB:
vm_page_remove
vm_page_free_toq
vm_page_alloc
vm_hold_load_pages
allocbuf
geteblk
bwrite
vop_stdbwrite
vop_defaultop
spec_vnoperate
ufs_vnoperatespec
bawrite
softdep_fsync_mountdev
ffs_fsync
sched_sync
fork_trampoline

Kernel message some time (longer than several minutes but unknown)
earlier:
Aug 21 18:46:36 thor /kernel: handle_workitem_freeblocks: block count

While RELENG_4 and RELENG_5 are fairly close in that section of code,
RELENG_5 has the assignment of pte within the for-loop, uses
pmap_pte_quick() instead of pmap_pte() and performs a slightly different
check against pte.

memtest86 has been run on this system for longer than a day without any
problems.

Does anyone know if it was reverted back on purpose?  Should it be more
similar to RELENG_5.  I am fairly good at C; I just do not know the
kernel all that well.  :)
>How-To-Repeat:
Unknown.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: