From owner-freebsd-sparc64@FreeBSD.ORG Thu Oct 13 18:42:29 2011 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C03A4106566C for ; Thu, 13 Oct 2011 18:42:29 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 566E08FC1C for ; Thu, 13 Oct 2011 18:42:28 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p9DIgPOW049099; Thu, 13 Oct 2011 20:42:25 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9DIgPxK049098; Thu, 13 Oct 2011 20:42:25 +0200 (CEST) (envelope-from marius) Date: Thu, 13 Oct 2011 20:42:25 +0200 From: Marius Strobl To: Peter Jeremy Message-ID: <20111013184224.GG39118@alchemy.franken.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111013035648.GA54190@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: 'make -j16 universe' gives SIReset X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 18:42:29 -0000 On Thu, Oct 13, 2011 at 02:56:48PM +1100, Peter Jeremy wrote: > On 2011-Oct-11 22:55:43 +0200, Marius Strobl 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