panic on fresh -CURRENT
kostikbel at gmail.com
Sat May 10 21:56:57 UTC 2014
On Sat, May 10, 2014 at 11:38:24PM +0200, Michael Moll wrote:
> I just got that panic with r265844 on a Fujitsu Primepower 250.
> panic: vm_page_free: freeing wired page 0xfffff800fc480870
> cpuid = 0
> KDB: stack backtrace:
> panic() at panic+0x1d4
> vm_page_free_toq() at vm_page_free_toq+0xa0
> vm_page_free_zero() at vm_page_free_zero+0x10
> pmap_release() at pmap_release+0xe4
> vmspace_exit() at vmspace_exit+0x104
> exit1() at exit1+0x6d4
> sys_sys_exit() at sys_sys_exit+0x10
> syscall() at syscall+0x320
> -- syscall (1, FreeBSD ELF64, sys_sys_exit) %o7=0x403d2d8c --
> userland() at 0x404ada28
> user trace: trap %o7=0x403d2d8c
> pc 0x404ada28, sp 0x7fdffffebc1
> panic: trap: fast data access mmu miss (kernel)
> cpuid = 0
> KDB: enter: panic
> [ thread pid 12340 tid 100513 ]
> Stopped at kdb_enter+0x80: ta %xcc, 1
> Is this a known problem or is my hardware going bad?
I cannot answer your question, at least not without some additional data.
Still, does it work if you revert the r265843 ?
Do you have INVARIANTS defined in your kernel config ?
Do you have vmcore from the panic ? If yes, please load it
in kgdb and do p *(struct vm_page *)0xfffff800fc480870.
The noted revision should not affected the sparc64 pmap and tsb,
but still please try to revert it and see.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 834 bytes
Desc: not available
More information about the freebsd-sparc64