panic on fresh -CURRENT

[Michael Moll]

Hi,

On Sun, May 11, 2014 at 08:26:23PM +0300, Konstantin Belousov wrote:
> Please try the following patch, it slightly modernizes the tsb page free
> sequence to the current VM KPI, and also adds assertions which reflect
> my understanding of the correct state of the tsb object and pages.
> The patch is not a fix, it only should somewhat improve debugging.
> And yes, enable INVARIANTS.

OK, I'm now at r265844 + your patch and enabled INVARIANTS. However,
the initial panic is not reproducible anymore, but I get different
ones and can't get hold of a dump, there are quite some messages
"cheetah_ipi_single: couldn't send IPI to module 0x1" after the panics.


panic: vm_page_alloc: page 0xfffff800f99164a0 is wired
cpuid = 1
KDB: stack backtrace:
vpanic() at vpanic+0x1b4
kassert_panic() at kassert_panic+0xb0
vm_page_alloc() at vm_page_alloc+0x480
vm_fault_hold() at vm_fault_hold+0x760
vm_fault() at vm_fault+0x88
trap_pfault() at trap_pfault+0x1ac
trap() at trap+0xdc
-- fast data access mmu miss tar=0x4222fbc6 %o7=0x19d974 --
userland() at 0x4d1044
user trace: trap %o7=0x19d974
pc 0x4d1044, sp 0x7fdffffd791
pc 0x3c3db4, sp 0x7fdffffd851
pc 0x410934, sp 0x7fdffffd911
pc 0x49f0e8, sp 0x7fdffffd9d1
pc 0x407fec, sp 0x7fdffffdad1
pc 0x40c8f4, sp 0x7fdffffdc01
pc 0x181480, sp 0x7fdffffdd71
pc 0x181624, sp 0x7fdffffde31
pc 0x181644, sp 0x7fdffffdef1
pc 0x4208b0, sp 0x7fdffffdfb1
pc 0x14a900, sp 0x7fdffffe071
pc 0x16c598, sp 0x7fdffffe131
pc 0x16d1ac, sp 0x7fdffffe1f1
pc 0x14ef90, sp 0x7fdffffe2b1
pc 0x1a8c28, sp 0x7fdffffe381
pc 0x100224, sp 0x7fdffffe441
pc 0, sp 0x7fdffffe501
done
KDB: enter: panic
[ thread pid 46014 tid 100541 ]
Stopped at      kdb_enter+0x80: ta              %xcc, 1
db> dump
Dumping 8192 MB (2 chunks)
  chunk at 0x200000000: 4294967296 bytes ... ok
  chunk at 0: 4294967296 bytes panic: Bad link elm -x100216578 prev->next != elm
cpuid = 0
Uptime: 14m46s
Rebooting...


panic: vm_page_alloc: page 0xfffff800fb6cb590 is wired
cpuid = 1
KDB: stack backtrace:
vpanic() at vpanic+0x1b4
kassert_panic() at kassert_panic+0xb0
vm_page_alloc() at vm_page_alloc+0x480
vm_page_grab() at vm_page_grab+0x2f4
uiomove_object() at uiomove_object+0x98
tmpfs_write() at tmpfs_write+0x238
VOP_WRITE_APV() at VOP_WRITE_APV+0x16c
vn_write() at vn_write+0x21c
vn_io_fault() at vn_io_fault+0xc8
dofilewrite() at dofilewrite+0x8c
kern_writev() at kern_writev+0x58
sys_write() at sys_write+0x74
syscall() at syscall+0x304
-- syscall (4, FreeBSD ELF64, sys_write) %o7=0x4055bf10 --
userland() at 0x405f9a28
user trace: trap %o7=0x4055bf10
pc 0x405f9a28, sp 0x7fdffffdf91
pc 0x4055be14, sp 0x7fdffffe051
pc 0x40564460, sp 0x7fdffffe111
pc 0x405610f4, sp 0x7fdffffe1d1
pc 0x405628a8, sp 0x7fdffffe291
pc 0x10d86c, sp 0x7fdffffe371
pc 0x10c920, sp 0x7fdffffe431
pc 0x10c920, sp 0x7fdffffe4f1
pc 0x11129c, sp 0x7fdffffe5b1
pc 0x10c920, sp 0x7fdffffe671
pc 0x1113cc, sp 0x7fdffffe731
pc 0x10b124, sp 0x7fdffffe7f1
pc 0x101b44, sp 0x7fdffffe8c1
pc 0x402239d4, sp 0x7fdffffe981
done
KDB: enter: panic
[...]
panic: Bad link elm 0x100210088 prev->next != elm


panic: vm_page_alloc: page 0xfffff800fd9c4a60 has unexpected queue 1
cpuid = 1
KDB: stack backtrace:
vpanic() at vpanic+0x1b4
kassert_panic() at kassert_panic+0xb0
vm_page_alloc() at vm_page_alloc+0x450
vm_fault_hold() at vm_fault_hold+0x760
vm_fault() at vm_fault+0x88
trap_pfault() at trap_pfault+0x1ac
trap() at trap+0xdc
-- fast data access mmu miss tar=0x40237a80 %o7=0x40218fc8 --
userland() at 0x40219054
user trace: trap %o7=0x40218fc8
pc 0x40219054, sp 0x7fdffffe371
pc 0x40213104, sp 0x7fdffffe431
pc 0x40207fa8, sp 0x7fdffffe4f1
pc 0x4020c08c, sp 0x7fdffffe5d1
pc 0x4020c250, sp 0x7fdffffe691
pc 0x40210250, sp 0x7fdffffe751
pc 0x402079d4, sp 0x7fdffffefe1
done
KDB: enter: panic
[...]
panic: Bad link elm|0x100216ef8 prev->next != elm


Regards
-- 
Michael Moll