Date: Sun, 11 May 2014 22:53:59 +0200 From: Michael Moll <kvedulv@kvedulv.de> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-sparc64@freebsd.org Subject: Re: panic on fresh -CURRENT Message-ID: <20140511205359.GA63005@darkthrone.kvedulv.de> In-Reply-To: <20140511172622.GA74331@kib.kiev.ua> References: <20140510213824.GA23740@darkthrone.kvedulv.de> <20140510215647.GU74331@kib.kiev.ua> <20140511073743.GA38923@darkthrone.kvedulv.de> <20140511172622.GA74331@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140511205359.GA63005>