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