9.2-RC4 amd64 panic: vm_page_unwire

[Oliver Pinter]

On 9/28/13, John Marshall <john.marshall at riverwillow.com.au> wrote:
> On Fri, 27 Sep 2013, 11:12 +0300, Konstantin Belousov wrote:
>> On Fri, Sep 27, 2013 at 10:07:28AM +1000, John Marshall wrote:
>> > I'm running 9.2-RC4 on a handful of desktop and server machines (both
>> > i386 and amd64).  I have seen three panics (all vm_page_unwire) on one
>> > of those systems only (amd64 server) during the past week.
>
>> > The first two panics were triggered when shutting down the ntpd daemon
>> > (a recent development snapshot version of ntpd: 4.2.7p387).  Exiting a
>> > later release (p388) has not triggered the panic.  The system panicked
>> > again overnight, this time while acting as an sftp server receiving
>> > large (GB) files from another system.
>
>> > I have made the core.txt.[0-2] files available in the following
>> > directory.  The directory is not browsable.
>> >
>> >   http://www.riverwillow.net.au/~john/92rc4/
>>
>> This might be fixed by r254087-r254090 on stable/9.
>
> Thank you.  Those patches applied cleanly to releng/9.2 so I rebuilt a
> patched 9.2.  I double-checked and verified that the following patched
> files in my releng/9.2 at 255904 working copy were identical to the same
> files in stable/9 at 254090, then I removed /usr/obj/* and built a fresh
> system.
>
>   M       /usr/src/sys/vm/vm_fault.c
>   M       /usr/src/sys/vm/vm_map.c
>   M       /usr/src/sys/vm/vm_map.h
>   M       /usr/src/sys/vm/vm_object.c
>   M       /usr/src/sys/vm/vm_object.h
>   M       /usr/src/sys/vm/vm_page.c
>
> The system panicked as follows during shutdown after its first boot.
> The corresponding core.txt.3 file is available at the same location
> previously posted.
>
> Fri Sep 27 22:32:18 2013 +1000
>   ozsrv04# kgdb kernel.debug /var/crash/vmcore.3
>   ...
>   Unread portion of the kernel message buffer:
>   .
>   <118>Stopping watchdogd.
>   <118>Waiting for PIDS: 1297
>   panic: vm_page_unwire: page 0xfffffe023743eb50's wire count is zero
>   cpuid = 1
>   KDB: stack backtrace:
>   #0 0xffffffff80490278 at kdb_backtrace+0x68
>   #1 0xffffffff8045630a at panic+0x21a
>   #2 0xffffffff8068bac2 at vm_page_unwire+0x102
>   #3 0xffffffff80678732 at vm_fault_unwire+0xd2
>   #4 0xffffffff80680851 at vm_map_delete+0x171
>   #5 0xffffffff80680acf at vm_map_remove+0x5f
>   #6 0xffffffff80683ea9 at vmspace_exit+0xc9
>   #7 0xffffffff8041f3ad at exit1+0x72d
>   #8 0xffffffff804203ae at sys_sys_exit+0xe
>   #9 0xffffffff806afc6f at amd64_syscall+0x3bf
>   #10 0xffffffff8069a717 at Xfast_syscall+0xf7
>   Uptime: 7m24s
>
> I have now seen this panic on a second server as well (also amd64 but
> different hardware vendor).  This second (unpatched) system also
> panicked during shutdown as follows. Corresponding file named
> core.txt.0.system2 is available at the same location as above.
>
> Sat Sep 28 06:19:59 2013 +1000
>   panic: vm_page_unwire: page 0xfffffe0429aa5d18's wire count is zero
>   cpuid = 1
>   KDB: stack backtrace:
>   #0 0xffffffff804e7398 at kdb_backtrace+0x68
>   #1 0xffffffff804ad43a at panic+0x21a
>   #2 0xffffffff80717d42 at vm_page_unwire+0x102
>   #3 0xffffffff80704882 at vm_fault_unwire+0xd2
>   #4 0xffffffff8070c9c1 at vm_map_delete+0x171
>   #5 0xffffffff8070cc3f at vm_map_remove+0x5f
>   #6 0xffffffff80710069 at vmspace_exit+0xc9
>   #7 0xffffffff804764dd at exit1+0x72d
>   #8 0xffffffff804774de at sys_sys_exit+0xe
>   #9 0xffffffff8073d7cf at amd64_syscall+0x3bf
>   #10 0xffffffff80728277 at Xfast_syscall+0xf7
>   Uptime: 5m31s

try this from 9-STABLE:
https://github.com/freebsd/freebsd/commit/98362329be8e2cdefda1988e5e9d32efbc94855f

>
> --
> John Marshall
>