kern/181590: amd related vm_page_unwire panics

Dominic Fandrey kamikaze at bsdforen.de
Tue Aug 27 21:10:01 UTC 2013


>Number:         181590
>Category:       kern
>Synopsis:       amd related vm_page_unwire panics
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 27 21:10:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     Dominic Fandrey
>Release:        stable/9
>Organization:
private
>Environment:
FreeBSD mobileKamikaze.norad 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254957: Tue Aug 27 19:07:40 CEST 2013     root at mobileKamikaze.norad:/usr/obj/HP6510b-9/amd64/usr/src/sys/HP6510b-9  amd64

>Description:
I have textdumps for two vm_page_unwire panics.

The first one occurred while copying data from one msdosfs to another, both mounted through amd:
http://pastebin.com/bVgmmcv1

The second one happened when SIGTERM was sent to amd, while there was heavy tmpfs load (building chromium). No file systems were mounted through amd at the time:
http://pastebin.com/uqgMiGPc

The second case is easy to reproduce, I have a 100% panic quota for this scenario.

The core trouble is that the issue even occurs /after/ there was heavy tmpfs load in the past, while amd was running. Again without any actual mounts happening. So there is a panic for every system shutdown/reboot.
>How-To-Repeat:
Set WRKDIRPREFIX to a tmpfs (I do not know whether the tmpfs is necessary, but it certainly helps avoiding excessive filesystem damage).

# cd /usr/ports/www/chromium
# make

Wait till the configure phase is over and the port is actually compiling.

# service amd stop
While chromium is still compiling.
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list