Date: Thu, 13 Oct 2011 20:42:25 +0200 From: Marius Strobl <marius@alchemy.franken.de> To: Peter Jeremy <peterjeremy@acm.org> Cc: freebsd-sparc64@freebsd.org Subject: Re: 'make -j16 universe' gives SIReset Message-ID: <20111013184224.GG39118@alchemy.franken.de> In-Reply-To: <20111013035648.GA54190@server.vk2pj.dyndns.org> References: <20110813143807.GY48988@alchemy.franken.de> <20110816214820.GA35017@server.vk2pj.dyndns.org> <20110817094541.GJ48988@alchemy.franken.de> <20110830152725.GA28552@alchemy.franken.de> <20110831212458.GA25926@server.vk2pj.dyndns.org> <20110902153206.GR40781@alchemy.franken.de> <20111006120411.GA903@alchemy.franken.de> <20111011030529.GA4093@server.vk2pj.dyndns.org> <20111011205543.GA81376@alchemy.franken.de> <20111013035648.GA54190@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 13, 2011 at 02:56:48PM +1100, Peter Jeremy wrote: > On 2011-Oct-11 22:55:43 +0200, Marius Strobl <marius@alchemy.franken.de> wrote: > >> I also ran 6 parallel -j16 buildworlds as a stress test and that was > >> less successful: > >> panic: mutex vm object not owned at /usr/src/sys/vm/vm_object.c:281 > > > >That line should be in vm_object_clear_flag(). The backtrace seems to be > >incomplete as it doesn't include that function. I'm not sure what to make > >out of the "VNASSERT failed" and "tag ufs, type VDIR" lines. I guess this > >could mean that there were two panics at the same time. Does the crashdump > >provide a better backtrace? > > Unfortunately, I can't get a crashdump because dumpon(8) doesn't like > my Solaris swap partitions: > GEOM_PART: Partition 'da0b' not suitable for kernel dumps (wrong type?) > GEOM_PART: Partition 'da6b' not suitable for kernel dumps (wrong type?) > No suitable dump device was found. > > I did write a patch for that but took it out during some earlier > testing to get back to stock code. It looks like I didn't PR it > either so I will do that when I get some time. > > I don't understand the panic backtrace either. Manually running > "where" gives saner output: > db> where > Tracing pid 1299 tid 100640 td 0xfffff8a346e8da40 > panic() at panic+0x20c > _mtx_assert() at _mtx_assert+0xb0 > vm_object_clear_flag() at vm_object_clear_flag+0x24 > vmtotal() at vmtotal+0xa4 > sysctl_root() at sysctl_root+0x234 > userland_sysctl() at userland_sysctl+0x1cc > sys___sysctl() at sys___sysctl+0x70 > syscall() at syscall+0x2d8 > -- syscall (202, FreeBSD ELF64, sys___sysctl) %o7=0x10daac -- > userland() at 0x4093c3a8 > user trace: trap %o7=0x10daac > pc 0x4093c3a8, sp 0x7fdffffcdd1 > pc 0x10dc58, sp 0x7fdffffcea1 > pc 0x1050c0, sp 0x7fdffffcf71 > pc 0x4089c6e0, sp 0x7fdffffd041 > pc 0, sp 0x7fdffffd401 > pc 0x403ab9a0, sp 0x7fdffffd561 > pc 0x104980, sp 0x7fdffffd631 > pc 0x105514, sp 0x7fdffffd751 > pc 0x102790, sp 0x7fdffffe031 > pc 0x4021b014, sp 0x7fdffffe0f1 > done Hrm, this backtrace seems impossible as vmtotal() explicitly locks the object before calling vm_object_clear_flag(). A crash dump of this panic really would be interesting. > > I'm not sure how to access registers in another stack frame so I > can't find the offending vmobject. I will need to shutdown that > box and will do some more digging next week. > I don't think ddb(4) supports accessing registers of another frame, it however has some VM object debugging support you could play with if the machine is still running. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111013184224.GG39118>