Date: Sat, 28 Aug 2004 14:50:56 -0500 (CDT) From: Sean Farley <sean-freebsd@farley.org> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/71086: Panic in vm_page_remove() Message-ID: <200408281950.i7SJoudh009780@thor.farley.org> Resent-Message-ID: <200408282000.i7SK0dKe020568@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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@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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408281950.i7SJoudh009780>