Date: Fri, 1 Jul 2011 08:17:52 +1000 From: Peter Jeremy <peter.jeremy@alcatel-lucent.com> To: Marius Strobl <marius@alchemy.franken.de> Cc: "alc@freebsd.org" <alc@freebsd.org>, freebsd-sparc64@freebsd.org Subject: Re: 'make -j16 universe' gives SIReset Message-ID: <20110630221752.GG65891@pjdesk.au.alcatel-lucent.com> In-Reply-To: <20110629223008.GL14797@alchemy.franken.de> References: <20110601231237.GA5267@server.vk2pj.dyndns.org> <20110608224801.GB35494@alchemy.franken.de> <20110613235144.GA12470@server.vk2pj.dyndns.org> <20110615233445.GZ7064@alchemy.franken.de> <20110619220033.GA61397@server.vk2pj.dyndns.org> <20110622100524.GO14797@alchemy.franken.de> <20110629025433.GA48145@server.vk2pj.dyndns.org> <20110629175444.GH14797@alchemy.franken.de> <20110629220010.GA53017@pjdesk.au.alcatel-lucent.com> <20110629223008.GL14797@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--gMR3gsNFwZpnI/Ts Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Moving back on-list] On 2011-Jun-30 06:30:08 +0800, Marius Strobl <marius@alchemy.franken.de> wr= ote: >On Thu, Jun 30, 2011 at 08:00:10AM +1000, Peter Jeremy wrote: >> On 2011-Jun-29 19:54:44 +0200, Marius Strobl <marius@alchemy.franken.de>= wrote: >> >On Wed, Jun 29, 2011 at 12:54:33PM +1000, Peter Jeremy wrote: >> >> My V890 has been running "make -j32 buildworld" in a loop for a >> >> week now without problems so I think that was the problem. >>=20 >> OTOH, a V440 that has been running similar load for a similar period >> died overnight with: >>=20 >> panic: uma_small_alloc: free page still has mappings! >> VNASSERT failed >> cpuid =3D 3 >> 0xfffff800079643c0: KDB: enter: panic =2E.. >> I'm fairly sure that is the same kernel but will double-check and >> investigate that panic further. FWIW, that kernel didn't have the latest patchset (adding Zeus support). >Ok, this appears to be an unrelated problem though. Alan, do you >have an idea what could be causing this? I managed to get the same panic (though different traceback) on the V890 after about an hour of pho@'s stress test with INCARNATIONS=3D150: panic: uma_small_alloc: free page still has mappings! cpuid =3D 1 KDB: enter: panic [ thread pid 142 tid 100196 ] Stopped at kdb_enter+0x80: ta %xcc, 1 db> where Tracing pid 142 tid 100196 td 0xfffff8a016ace880 panic() at panic+0x20c uma_small_alloc() at uma_small_alloc+0xe8 keg_alloc_slab() at keg_alloc_slab+0xc8 keg_fetch_slab() at keg_fetch_slab+0x218 zone_fetch_slab() at zone_fetch_slab+0x44 uma_zalloc_arg() at uma_zalloc_arg+0x60c m_getm2() at m_getm2+0x134 m_uiotombuf() at m_uiotombuf+0x4c sosend_generic() at sosend_generic+0x420 sosend() at sosend+0x2c soo_write() at soo_write+0x3c dofilewrite() at dofilewrite+0x7c kern_writev() at kern_writev+0x38 write() at write+0x4c syscallenter() at syscallenter+0x270 syscall() at syscall+0x74 -- syscall (4, FreeBSD ELF64, write) %o7=3D0x101db4 -- userland() at 0x405936c8 user trace: trap %o7=3D0x101db4 pc 0x405936c8, sp 0x7fdffffd8a1 pc 0x101f44, sp 0x7fdffffd9a1 pc 0x104604, sp 0x7fdffffda81 pc 0x1046f0, sp 0x7fdffffdb51 pc 0x104994, sp 0x7fdffffdc21 pc 0x104d90, sp 0x7fdffffdd01 pc 0x101610, sp 0x7fdffffde41 pc 0x4020cff4, sp 0x7fdffffdf01 done db> I've got a crashdump on the V440 but discovered that gdb reports "GDB can't read core files on this machine." so it isn't much use. Any suggestions on how to debug this? >> >Have you additionally altered the DCR configuration in cheetah_init()? > >Ok, but that change isn't actually in effect on you machine as it's >inside the CPU_IMPL_ULTRASPARCIVp block. Oops. I didn't study the surrounding code closely enough. --=20 Peter Jeremy --gMR3gsNFwZpnI/Ts Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk4M9hAACgkQ/opHv/APuIc0owCgtscMvRjfYhzla0vKIypjJyX0 jPcAoKtdpopdnxq0RMlaqSJ8DliF1B7m =IVHH -----END PGP SIGNATURE----- --gMR3gsNFwZpnI/Ts--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110630221752.GG65891>