From owner-freebsd-sparc64@FreeBSD.ORG Mon Oct 17 11:07:11 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 CC0211065674 for ; Mon, 17 Oct 2011 11:07:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BA79C8FC17 for ; Mon, 17 Oct 2011 11:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9HB7Bbw099345 for ; Mon, 17 Oct 2011 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9HB7Bw7099343 for freebsd-sparc64@FreeBSD.org; Mon, 17 Oct 2011 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Oct 2011 11:07:11 GMT Message-Id: <201110171107.p9HB7Bw7099343@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-sparc64@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-sparc64@FreeBSD.org 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: Mon, 17 Oct 2011 11:07:11 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- f sparc/145211 sparc64 [panic] Memory modified after free o sparc/142102 sparc64 [nfs] [panic] FreeBSD 8.0 kernel panics on sparc64 whe o sparc/141918 sparc64 [ehci] ehci_interrupt: unrecoverable error, controller s sparc/139134 sparc64 kernel output corruption f sparc/108732 sparc64 ping(8) reports 14 digit time on sparc64 s sparc/107087 sparc64 [hang] system is hung during boot from CD o sparc/105048 sparc64 [trm] trm(4) panics on sparc64 o sparc/104428 sparc64 [nullfs] nullfs panics on E4500 (but not E420) o sparc/80890 sparc64 [panic] kmem_malloc(73728): kmem_map too small running o sparc/71729 sparc64 printf in kernel thread causes panic on SPARC 10 problems total. From owner-freebsd-sparc64@FreeBSD.ORG Tue Oct 18 04:26:58 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 297E11065674 for ; Tue, 18 Oct 2011 04:26:58 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail26.syd.optusnet.com.au (mail26.syd.optusnet.com.au [211.29.133.167]) by mx1.freebsd.org (Postfix) with ESMTP id A6E278FC0A for ; Tue, 18 Oct 2011 04:26:57 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail26.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p9I4QmKm026288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Oct 2011 15:26:50 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id p9I4QmUF019880; Tue, 18 Oct 2011 15:26:48 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id p9I4QkL9019879; Tue, 18 Oct 2011 15:26:46 +1100 (EST) (envelope-from peter) Date: Tue, 18 Oct 2011 15:26:46 +1100 From: Peter Jeremy To: Marius Strobl Message-ID: <20111018042646.GA18863@server.vk2pj.dyndns.org> References: <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> <20111013184224.GG39118@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <20111013184224.GG39118@alchemy.franken.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) 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: Tue, 18 Oct 2011 04:26:58 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Oct-13 20:42:25 +0200, Marius Strobl wr= ote: >On Thu, Oct 13, 2011 at 02:56:48PM +1100, Peter Jeremy wrote: >> 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. >>=20 >> 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've resurrected that patch (and will send-pr it later). >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've reproduced the same panic and got a crashdump (2 hours for the dump and another hour for the savecore): VNASSERT failed panic: mutex vm object not owned at /usr/src/sys/vm/vm_object.c:281 cpuid =3D 7 #10 0x00000000c04ffbf4 in panic (fmt=3D0xc0a906d0 "mutex %s not owned at %s= :%d") at /usr/src/sys/kern/kern_shutdown.c:599 #11 0x00000000c04eb1b8 in _mtx_assert (m=3D0xfffff8b29d750ca8, what=3D0x4, = file=3D0xc0ac6c00 "/usr/src/sys/vm/vm_object.c", line=3D0x119) at /usr/src/= sys/kern/kern_mutex.c:706 #12 0x00000000c07f4b0c in vm_object_clear_flag (object=3D0xfffff8b29d750ca8= , bits=3D0x4) at /usr/src/sys/vm/vm_object.c:281 #13 0x00000000c07f1dac in vmtotal (oidp=3D0xc0ba9be8, arg1=3D0x0, arg2=3D0x= 30, req=3D0xef8a54e0) at /usr/src/sys/vm/vm_meter.c:121 #14 0x00000000c050c13c in sysctl_root (oidp=3DVariable "oidp" is not availa= ble. ) at /usr/src/sys/kern/kern_sysctl.c:1509 #15 0x00000000c050c434 in userland_sysctl (td=3D0x0, name=3D0xef8a5628, nam= elen=3D0x2, old=3D0x0, oldlenp=3DVariable "oldlenp" is not available.) at /= usr/src/sys/kern/kern_sysctl.c:1619 #16 0x00000000c050c858 in sys___sysctl (td=3D0xfffff8a2e3ef48c0, uap=3D0xef= 8a5768) at /usr/src/sys/kern/kern_sysctl.c:1545 #17 0x00000000c086ba00 in syscall (tf=3DVariable "tf" is not available.) at= subr_syscall.c:131 #18 0x00000000c0098e60 in tl0_intr () (kgdb) p *object $1 =3D { mtx =3D { lock_object =3D { lo_name =3D 0xc0a9a308 "vm object",=20 lo_flags =3D 0x1430000,=20 lo_data =3D 0x0,=20 lo_witness =3D 0xfff85180 },=20 mtx_lock =3D 0xfffff8a0112d75e0 },=20 =2E.. } (kgdb) p *object->mtx->lock_object->lo_witness $3 =3D { w_name =3D "standard object", '\0' ,=20 w_index =3D 0xa3,=20 w_class =3D 0xc0b82e88,=20 w_list =3D { stqe_next =3D 0xfff85100 },=20 w_typelist =3D { stqe_next =3D 0xfff85100 },=20 w_hash_next =3D 0x0,=20 w_file =3D 0xc0ac6388 "/usr/src/sys/vm/vm_meter.c",=20 w_line =3D 0x71,=20 w_refcount =3D 0x53718,=20 w_num_ancestors =3D 0xe,=20 w_num_descendants =3D 0xe,=20 w_ddb_level =3D 0x0,=20 w_displayed =3D 0x1,=20 w_reversed =3D 0x0 } (kgdb) p vm_object_list_mtx $4 =3D { lock_object =3D { lo_name =3D 0xc0ac6e30 "vm object_list",=20 lo_flags =3D 0x1030000,=20 lo_data =3D 0x0,=20 lo_witness =3D 0xfff81d80 },=20 mtx_lock =3D 0xfffff8a2e3ef48c2 } (kgdb) p *vm_object_list_mtx.lock_object.lo_witness=20 $6 =3D { w_name =3D "vm object_list", '\0' ,=20 w_index =3D 0x3b,=20 w_class =3D 0xc0b82e88,=20 w_list =3D { stqe_next =3D 0xfff81d00 },=20 w_typelist =3D { stqe_next =3D 0xfff81d00 },=20 w_hash_next =3D 0x0,=20 w_file =3D 0xc0ac6388 "/usr/src/sys/vm/vm_meter.c",=20 w_line =3D 0x6f,=20 w_refcount =3D 0x1,=20 w_num_ancestors =3D 0xf,=20 w_num_descendants =3D 0x0,=20 w_ddb_level =3D 0x0,=20 w_displayed =3D 0x1,=20 w_reversed =3D 0x0 } The witness information looks correct but I notice that vm_object_list_mtx is owned by a different thread to the vm_object that triggers the panic. The panic says it occurred on CPU 7: (kgdb) p cpuid_to_pcpu[7]->pc_curthread $21 =3D (struct thread *) 0xfffff8a2e3ef48c0 which matches the vm_object_list_mtx. My inital thought was a locking glitch but, looking through cpuid_to_pcpu[], the vm_object's lock doesn't match any running thread: (kgdb) p cpuid_to_pcpu[0]->pc_curthread $14 =3D (struct thread *) 0xfffff8a2e3008000 (kgdb) p cpuid_to_pcpu[1]->pc_curthread $15 =3D (struct thread *) 0xfffff8a2aae7c8c0 (kgdb) p cpuid_to_pcpu[2]->pc_curthread $16 =3D (struct thread *) 0xfffff8a0112acd20 (kgdb) p cpuid_to_pcpu[3]->pc_curthread $17 =3D (struct thread *) 0xfffff8a0112ac8c0 (kgdb) p cpuid_to_pcpu[4]->pc_curthread $18 =3D (struct thread *) 0xfffff8a2aae7da40 (kgdb) p cpuid_to_pcpu[5]->pc_curthread $19 =3D (struct thread *) 0xfffff8a2aa2a6460 (kgdb) p cpuid_to_pcpu[6]->pc_curthread $20 =3D (struct thread *) 0xfffff8a2e3148d20 (kgdb) p cpuid_to_pcpu[7]->pc_curthread $21 =3D (struct thread *) 0xfffff8a2e3ef48c0 (kgdb) p cpuid_to_pcpu[8]->pc_curthread $22 =3D (struct thread *) 0xfffff8d32cfa0460 (kgdb) p cpuid_to_pcpu[9]->pc_curthread $23 =3D (struct thread *) 0xfffff8a0112b3a40 (kgdb) p cpuid_to_pcpu[10]->pc_curthread $24 =3D (struct thread *) 0xfffff8a2a8f77180 (kgdb) p cpuid_to_pcpu[11]->pc_curthread $25 =3D (struct thread *) 0xfffff8a2e3ef1a40 (kgdb) p cpuid_to_pcpu[12]->pc_curthread $26 =3D (struct thread *) 0xfffff8a2e319e8c0 (kgdb) p cpuid_to_pcpu[13]->pc_curthread $27 =3D (struct thread *) 0xfffff8a2e3c30d20 (kgdb) p cpuid_to_pcpu[14]->pc_curthread $28 =3D (struct thread *) 0xfffff8a0112b2460 (kgdb) p cpuid_to_pcpu[15]->pc_curthread $29 =3D (struct thread *) 0xfffff8c1f78cb180 Some rummaging around says that the object is locked by yarrow: (kgdb) p ((struct thread *) 0xfffff8a0112d75e0)->td_proc.p_comm $35 =3D "yarrow", '\0' At this stage, I'm not sure where to go next. --=20 Peter Jeremy --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6dAAYACgkQ/opHv/APuIdILQCgvSvXFoWS5pZovoJT/RANMk8Y 95YAn3WeigJ2bT5zaE/7OYwl8zHPSeZP =SYZg -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From owner-freebsd-sparc64@FreeBSD.ORG Tue Oct 18 09:00:24 2011 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A759D1065674 for ; Tue, 18 Oct 2011 09:00:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 38E098FC12 for ; Tue, 18 Oct 2011 09:00:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9I90Nrt064309 for ; Tue, 18 Oct 2011 09:00:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9I90NZq064308; Tue, 18 Oct 2011 09:00:23 GMT (envelope-from gnats) Resent-Date: Tue, 18 Oct 2011 09:00:23 GMT Resent-Message-Id: <201110180900.p9I90NZq064308@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-sparc64@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Peter Jeremy Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34374106564A for ; Tue, 18 Oct 2011 08:53:32 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by mx1.freebsd.org (Postfix) with ESMTP id C3F018FC13 for ; Tue, 18 Oct 2011 08:53:31 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail28.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p9I8rShc011151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Oct 2011 19:53:29 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id p9I8pR0h020982; Tue, 18 Oct 2011 19:51:27 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id p9I8pRhR020981; Tue, 18 Oct 2011 19:51:27 +1100 (EST) (envelope-from peter) Message-Id: <201110180851.p9I8pRhR020981@server.vk2pj.dyndns.org> Date: Tue, 18 Oct 2011 19:51:27 +1100 (EST) From: Peter Jeremy To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: sparc64/161764: [patch] Support dumping to Solaris swap partitions X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Jeremy List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 09:00:24 -0000 >Number: 161764 >Category: sparc64 >Synopsis: [patch] Support dumping to Solaris swap partitions >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-sparc64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 18 09:00:22 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Peter Jeremy >Release: FreeBSD 10-CURRENT sparc64 >Organization: n/a >Environment: System: FreeBSD [10-current r226167 - full details not immediately available] >Description: FreeBSD currently only allows dumping onto either unused or FreeBSD swap partitions. Where systems are shared between FreeBSD and Solaris, it makes sense to allow both OSs to share common swap partitions. FreeBSD already allows swapping onto Solaris swap partitions - it just refuses to allow crashdumps. The attached patch fixes this. >How-To-Repeat: Attempt to dumpon(8) a Solaris swap partition. Kernel reports: GEOM_PART: Partition 'da0b' not suitable for kernel dumps (wrong type?) >Fix: Index: sys/geom/part/g_part_vtoc8.c =================================================================== RCS file: /usr/ncvs/src/sys/geom/part/g_part_vtoc8.c,v retrieving revision 1.12 diff -u -r1.12 g_part_vtoc8.c --- sys/geom/part/g_part_vtoc8.c 8 May 2011 12:28:13 -0000 1.12 +++ sys/geom/part/g_part_vtoc8.c 17 Oct 2011 01:27:27 -0000 @@ -274,7 +274,8 @@ */ table = (struct g_part_vtoc8_table *)basetable; tag = be16dec(&table->vtoc.part[entry->gpe_index - 1].tag); - return ((tag == 0 || tag == VTOC_TAG_FREEBSD_SWAP) ? 1 : 0); + return ((tag == 0 || tag == VTOC_TAG_SWAP || + tag == VTOC_TAG_FREEBSD_SWAP) ? 1 : 0); } static int >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-sparc64@FreeBSD.ORG Tue Oct 18 17:27:24 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 147F3106566B for ; Tue, 18 Oct 2011 17:27:24 +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 8E2E68FC1F for ; Tue, 18 Oct 2011 17:27:23 +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 p9IHRItu016382; Tue, 18 Oct 2011 19:27:18 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9IHRIX8016381; Tue, 18 Oct 2011 19:27:18 +0200 (CEST) (envelope-from marius) Date: Tue, 18 Oct 2011 19:27:18 +0200 From: Marius Strobl To: Peter Jeremy Message-ID: <20111018172718.GT39118@alchemy.franken.de> References: <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> <20111013184224.GG39118@alchemy.franken.de> <20111018042646.GA18863@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111018042646.GA18863@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: Tue, 18 Oct 2011 17:27:24 -0000 On Tue, Oct 18, 2011 at 03:26:46PM +1100, Peter Jeremy wrote: > On 2011-Oct-13 20:42:25 +0200, Marius Strobl wrote: > >On Thu, Oct 13, 2011 at 02:56:48PM +1100, Peter Jeremy wrote: > >> 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've resurrected that patch (and will send-pr it later). > > >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've reproduced the same panic and got a crashdump (2 hours for > the dump and another hour for the savecore): > VNASSERT failed > panic: mutex vm object not owned at /usr/src/sys/vm/vm_object.c:281 > cpuid = 7 > > #10 0x00000000c04ffbf4 in panic (fmt=0xc0a906d0 "mutex %s not owned at %s:%d") at /usr/src/sys/kern/kern_shutdown.c:599 > #11 0x00000000c04eb1b8 in _mtx_assert (m=0xfffff8b29d750ca8, what=0x4, file=0xc0ac6c00 "/usr/src/sys/vm/vm_object.c", line=0x119) at /usr/src/sys/kern/kern_mutex.c:706 > #12 0x00000000c07f4b0c in vm_object_clear_flag (object=0xfffff8b29d750ca8, bits=0x4) at /usr/src/sys/vm/vm_object.c:281 > #13 0x00000000c07f1dac in vmtotal (oidp=0xc0ba9be8, arg1=0x0, arg2=0x30, req=0xef8a54e0) at /usr/src/sys/vm/vm_meter.c:121 > #14 0x00000000c050c13c in sysctl_root (oidp=Variable "oidp" is not available. > ) at /usr/src/sys/kern/kern_sysctl.c:1509 > #15 0x00000000c050c434 in userland_sysctl (td=0x0, name=0xef8a5628, namelen=0x2, old=0x0, oldlenp=Variable "oldlenp" is not available.) at /usr/src/sys/kern/kern_sysctl.c:1619 > #16 0x00000000c050c858 in sys___sysctl (td=0xfffff8a2e3ef48c0, uap=0xef8a5768) at /usr/src/sys/kern/kern_sysctl.c:1545 > #17 0x00000000c086ba00 in syscall (tf=Variable "tf" is not available.) at subr_syscall.c:131 > #18 0x00000000c0098e60 in tl0_intr () > > (kgdb) p *object > $1 = { > mtx = { > lock_object = { > lo_name = 0xc0a9a308 "vm object", > lo_flags = 0x1430000, > lo_data = 0x0, > lo_witness = 0xfff85180 > }, > mtx_lock = 0xfffff8a0112d75e0 > }, > ... > } > (kgdb) p *object->mtx->lock_object->lo_witness > $3 = { > w_name = "standard object", '\0' , > w_index = 0xa3, > w_class = 0xc0b82e88, > w_list = { > stqe_next = 0xfff85100 > }, > w_typelist = { > stqe_next = 0xfff85100 > }, > w_hash_next = 0x0, > w_file = 0xc0ac6388 "/usr/src/sys/vm/vm_meter.c", > w_line = 0x71, > w_refcount = 0x53718, > w_num_ancestors = 0xe, > w_num_descendants = 0xe, > w_ddb_level = 0x0, > w_displayed = 0x1, > w_reversed = 0x0 > } > (kgdb) p vm_object_list_mtx > $4 = { > lock_object = { > lo_name = 0xc0ac6e30 "vm object_list", > lo_flags = 0x1030000, > lo_data = 0x0, > lo_witness = 0xfff81d80 > }, > mtx_lock = 0xfffff8a2e3ef48c2 > } > (kgdb) p *vm_object_list_mtx.lock_object.lo_witness > $6 = { > w_name = "vm object_list", '\0' , > w_index = 0x3b, > w_class = 0xc0b82e88, > w_list = { > stqe_next = 0xfff81d00 > }, > w_typelist = { > stqe_next = 0xfff81d00 > }, > w_hash_next = 0x0, > w_file = 0xc0ac6388 "/usr/src/sys/vm/vm_meter.c", > w_line = 0x6f, > w_refcount = 0x1, > w_num_ancestors = 0xf, > w_num_descendants = 0x0, > w_ddb_level = 0x0, > w_displayed = 0x1, > w_reversed = 0x0 > } > > The witness information looks correct but I notice that vm_object_list_mtx > is owned by a different thread to the vm_object that triggers the panic. > > The panic says it occurred on CPU 7: > (kgdb) p cpuid_to_pcpu[7]->pc_curthread > $21 = (struct thread *) 0xfffff8a2e3ef48c0 > which matches the vm_object_list_mtx. > > My inital thought was a locking glitch but, looking through > cpuid_to_pcpu[], the vm_object's lock doesn't match any running thread: > > (kgdb) p cpuid_to_pcpu[0]->pc_curthread > $14 = (struct thread *) 0xfffff8a2e3008000 > (kgdb) p cpuid_to_pcpu[1]->pc_curthread > $15 = (struct thread *) 0xfffff8a2aae7c8c0 > (kgdb) p cpuid_to_pcpu[2]->pc_curthread > $16 = (struct thread *) 0xfffff8a0112acd20 > (kgdb) p cpuid_to_pcpu[3]->pc_curthread > $17 = (struct thread *) 0xfffff8a0112ac8c0 > (kgdb) p cpuid_to_pcpu[4]->pc_curthread > $18 = (struct thread *) 0xfffff8a2aae7da40 > (kgdb) p cpuid_to_pcpu[5]->pc_curthread > $19 = (struct thread *) 0xfffff8a2aa2a6460 > (kgdb) p cpuid_to_pcpu[6]->pc_curthread > $20 = (struct thread *) 0xfffff8a2e3148d20 > (kgdb) p cpuid_to_pcpu[7]->pc_curthread > $21 = (struct thread *) 0xfffff8a2e3ef48c0 > (kgdb) p cpuid_to_pcpu[8]->pc_curthread > $22 = (struct thread *) 0xfffff8d32cfa0460 > (kgdb) p cpuid_to_pcpu[9]->pc_curthread > $23 = (struct thread *) 0xfffff8a0112b3a40 > (kgdb) p cpuid_to_pcpu[10]->pc_curthread > $24 = (struct thread *) 0xfffff8a2a8f77180 > (kgdb) p cpuid_to_pcpu[11]->pc_curthread > $25 = (struct thread *) 0xfffff8a2e3ef1a40 > (kgdb) p cpuid_to_pcpu[12]->pc_curthread > $26 = (struct thread *) 0xfffff8a2e319e8c0 > (kgdb) p cpuid_to_pcpu[13]->pc_curthread > $27 = (struct thread *) 0xfffff8a2e3c30d20 > (kgdb) p cpuid_to_pcpu[14]->pc_curthread > $28 = (struct thread *) 0xfffff8a0112b2460 > (kgdb) p cpuid_to_pcpu[15]->pc_curthread > $29 = (struct thread *) 0xfffff8c1f78cb180 > > Some rummaging around says that the object is locked by yarrow: > (kgdb) p ((struct thread *) 0xfffff8a0112d75e0)->td_proc.p_comm > $35 = "yarrow", '\0' > > At this stage, I'm not sure where to go next. > Hrm, AFAICT this would mean that the _mtx_obtain_lock(), which boils down to a atomic_cmpset_acq_ptr(), in _mtx_trylock() didn't work as expected, I currently can't think of a good reason why that could happen though. The assembly generated for that code also looks just fine. Have you run the workload which is triggering this before? It would be interesting to know whether it also happens with SCHED_4BSD with current sources, pre-r226054 and pre-r225889 if the machine previously survived that load. Have you enabled PREEMPTION by chance? The other thing that worries me is that it could be a silicon bug, especially since that machine also has that issue of issuing stale vector interrupts along with a state in which it traps even on locked TLB entries, which isn't mentioned in the public erratum ... Marius From owner-freebsd-sparc64@FreeBSD.ORG Tue Oct 18 19:41:38 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 458BC1065670 for ; Tue, 18 Oct 2011 19:41:38 +0000 (UTC) (envelope-from 4055849_6695794686@bounces.spamarrest.com) Received: from auth0x.spamarrest.com (auth0x.spamarrest.com [208.43.54.99]) by mx1.freebsd.org (Postfix) with ESMTP id 0FC3C8FC12 for ; Tue, 18 Oct 2011 19:41:38 +0000 (UTC) Received: from auth02.spamarrest.com (auth02.spamarrest.com [10.16.213.130]) by auth0x.spamarrest.com (Postfix) with ESMTP id BC15ECD6AE4 for ; Tue, 18 Oct 2011 14:15:31 -0500 (CDT) Received: from auth02 (localhost.localdomain [127.0.0.1]) by auth02.spamarrest.com (Postfix) with ESMTP id C0E93B85231 for ; Tue, 18 Oct 2011 14:15:30 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=spamarrest.com; h=from:to :message-id:in-reply-to:subject:mime-version:content-type; s= selector1; bh=8d4OmW21IfGizYkwWbIVGn6l5O4=; b=pIK2V66XPLrW6r+4Y8 6uOL2e9MMyHbjwfKJ850/dGEIsHF3pE7lypuMhqNlEUQ5Hi7yo5pTIjCNyhW1nI8 kRkKfI+qMsT0z5GSsQ1GVeqAfPzATlWB95gXmASeNmKuu10gKQ+FxtA7G/N1JV2k ZzOeEr7mVRASkHebFaqzWUJEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=spamarrest.com; h=from:to :message-id:in-reply-to:subject:mime-version:content-type; q= dns; s=selector1; b=ToJBC9tzy/PThMp4OxnfwYbECi8d19GDU6MrUtiXJB17 k1dv9FkrM3XOU481NmQudxYBoC8Po17t6RBImNJXvlfm+k07NcvX7U51VDN0Jvxo Hqn97a5I2F9n56FwO8n28aBBni/SqKf0GkZUcyDzujnVoY8C0LVnMyf0ZFfzMy0= From: Juli Land-Marx To: freebsd-sparc64@freebsd.org Message-ID: <18640572.1318965330789.JavaMail.root@auth02> In-reply-to: <201110181913.p9IJDlm8019637@imagenet.net> Errors-to: nobody@spamarrest.com MIME-Version: 1.0 X-Spamarrest-noauth: 1 X-Spamarrest-speedcode: Precedence: auto_reply Date: Tue, 18 Oct 2011 14:15:30 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: RE: (verification) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 19:41:38 -0000 Juli Land-Marx here, I'm protecting myself from receiving junk mail. Please click the link below to complete the verification process. You have to do this only once. http://www.spamarrest.com/a2?AQN1AGt0BGczpzIyLaAxYKAjLKWwAwENMaWyMJWmMP5ipzpj Spam Arrest - Take control of your inbox! ------------------------------------------------------------ You are receiving this message in response to your email to Juli Land-Marx, a Spam Arrest customer. Spam Arrest requests that senders verify themselves before their email is delivered. When you click the above link, you will be taken to a page with a graphic on it. Simply read the word in the graphic, type it into the form, and you're verified. You have to do this only once per Spam Arrest customer. ------------------------------------------------------------ Below are the complete headers of the message that this email was generated in response to. Received: from localhost by vm.imagenet.net with SpamAssassin (2.63 2004-01-11); Tue, 18 Oct 2011 15:13:49 -0400 From: freebsd-sparc64@freebsd.org To: design@imagenet.net Subject: Date: Tue, 18 Oct 2011 14:13:49 -0500 Message-Id: <201110181913.p9IJDlm8019637@imagenet.net> X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) X-Spam-Status: Yes, hits=7.4 required=5.0 tests=BAYES_10,FORGED_MUA_OUTLOOK, FROM_ENDS_IN_NUMS,MIME_BASE64_ILLEGAL,MSGID_FROM_MTA_SHORT, NO_REAL_NAME autolearn=no version=2.63 X-Spam-Level: ******* MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_4E9DCFED.5BCA7403" X-UIDL: 3K\!!aPH!!UN="!F8^"! ------------------------------------------------------------ Webmasters help stop spam and make 50%. http://www.spamarrest.com/affl?4055849/affiliates/index.jsp ------------------------------------------------------------ From owner-freebsd-sparc64@FreeBSD.ORG Tue Oct 18 20:20:14 2011 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7631106566B for ; Tue, 18 Oct 2011 20:20:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D70D58FC12 for ; Tue, 18 Oct 2011 20:20:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9IKKEWY007083 for ; Tue, 18 Oct 2011 20:20:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9IKKEs2007082; Tue, 18 Oct 2011 20:20:14 GMT (envelope-from gnats) Date: Tue, 18 Oct 2011 20:20:14 GMT Message-Id: <201110182020.p9IKKEs2007082@freefall.freebsd.org> To: freebsd-sparc64@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: sparc64/161764: commit references a PR X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 20:20:15 -0000 The following reply was made to PR sparc64/161764; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: sparc64/161764: commit references a PR Date: Tue, 18 Oct 2011 20:16:15 +0000 (UTC) Author: marius Date: Tue Oct 18 20:16:02 2011 New Revision: 226522 URL: http://svn.freebsd.org/changeset/base/226522 Log: Allow to dump on Solaris swap partitions. PR: 161764 Submitted by: Peter Jeremy Modified: head/sys/geom/part/g_part_vtoc8.c Modified: head/sys/geom/part/g_part_vtoc8.c ============================================================================== --- head/sys/geom/part/g_part_vtoc8.c Tue Oct 18 18:52:22 2011 (r226521) +++ head/sys/geom/part/g_part_vtoc8.c Tue Oct 18 20:16:02 2011 (r226522) @@ -274,7 +274,8 @@ g_part_vtoc8_dumpto(struct g_part_table */ table = (struct g_part_vtoc8_table *)basetable; tag = be16dec(&table->vtoc.part[entry->gpe_index - 1].tag); - return ((tag == 0 || tag == VTOC_TAG_FREEBSD_SWAP) ? 1 : 0); + return ((tag == 0 || tag == VTOC_TAG_FREEBSD_SWAP || + tag == VTOC_TAG_SWAP) ? 1 : 0); } static int _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-sparc64@FreeBSD.ORG Wed Oct 19 00:04:06 2011 Return-Path: Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC528106564A for ; Wed, 19 Oct 2011 00:04:06 +0000 (UTC) (envelope-from root@ns6.wowcardeals.com) Received: from ns6.wowcardeals.com (ns6.wowcardeals.com [217.23.9.146]) by mx1.freebsd.org (Postfix) with ESMTP id 29AF28FC17 for ; Wed, 19 Oct 2011 00:04:06 +0000 (UTC) Received: by ns6.wowcardeals.com (Postfix, from userid 0) id 015E090A17A; Wed, 19 Oct 2011 03:26:20 +0400 (MSD) To: freebsd-sparc@freebsd.org From: 'Drive a New BMW for R4999 P/M' Content-Disposition: inline Message-Id: <20111018232620.015E090A17A@ns6.wowcardeals.com> Date: Wed, 19 Oct 2011 03:26:20 +0400 (MSD) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Drive A New BMW for R4999 P/M 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: Wed, 19 Oct 2011 00:04:06 -0000 wowbmw.com Drive a new BMW from R4999 per month! Can't see the pictures? [1]Click here to view this email online. Save up to R1 411.54 per month [2]BMW E90 320i BMW E90 320i Petrol (Manual) * From R4 999.00 per month. * Manual * 2.0L Petrol * Radio/CD * Aircon Climate Control * Central Locking * ABS/ASC + T&CBC * Fog Lamps * Cruise Control * Alloy Wheels * Isofix * Multifunction Steering Wheel * Cruise Control * Run Flat Tyres * 5 Year / 100 000km Motorplan Are you Interested? [3]YES / [4]NO Save up to R1 463.76 per month [5]BMW E90 Auto BMW E90 320i Petrol (Automatic) * From R5 299.00 per month. * Automatic * 2.0L Petrol * Radio/CD * Aircon Climate Control * Central Locking * ABS/ASC + T&CBC * Fog Lamps * Cruise Control * Alloy Wheels * Isofix * Multifunction Steering Wheel * Cruise Control * Run Flat Tyres * 5 Year / 100 000km Motorplan Are you Interested? [6]YES / [7]NO Subject to availability of stock. Extra's not factory fitted will be charged Terms and conditions and cost of credit General terms and conditions and cost of credit Duration of contract 72 months. Once off initiation fee of R1140.00 VAT inclusive, already included in contract. Monthly service fee of R57.00 VAT inclusive. Rate at prime +2% variable. All delivery, lic, registration and number plates included in cost of credit. No residual value or deposit. Cost of credit and repayments may vary due to your credit risk profile. Application subject (at all times) to approval from our credit providers partners. Pre quote and pre contract available at all times. Terms and conditions and cost of credit available or request of contract in all official languages To qualify, the applicant must comply with the following basic conditions: * Earn a minimum salary of R5 500.00 nett (take home); * Not listed on the ITC; * Have a SA Driver's license and ID; * The rest of our terms and conditions are set out in the example [8]Advertising Contract. Advertising initiative cost of credit: * BMW E90 320i Petrol (Manual) = R359 928.00 * BMW E90 320i Petrol (Automatic) = R381 528.00 Please note that your repayment and cost of credit may vary as per terms and conditions of the advertising agreement. Advertised payment reduction is governed by a advertising program. Re-payments exclude monthly services charged and include initiation fee as allowed by the NCR. To view an example of an advertising contract please [9]click here. Example adverts on the back of the vehicles: Branding Branding Cost of credit and repayment if you opt not to enter into the advertising initiative: * BMW E90 320i Petrol (Manual) = R465 662.88 Repayment = R6 467.54 per month * BMW E90 320i Petrol (Automatic) = R491 022.72 Repayment = R6 819.76 per month Repayments and cost of credit includes initiation and monthly service fees as prescribed by the [10]NCR. To stop receiving emails, please [11]UNSUBSCRIBE here References 1. http://www.wowbmw.com/mailer/002/agent.php?page=online&agent=002&campaign=bmw&vehicle=1 2. http://www.wowbmw.com/mailer/002/agent.php?page=apply&agent=002&campaign=bmw&vehicle=25 3. http://www.wowbmw.com/mailer/002/agent.php?page=apply&agent=002&campaign=bmw&vehicle=25 4. http://www.wowbmw.com/mailer/002/agent.php?page=decline&agent=002&campaign=bmw&vehicle=25 5. http://www.wowbmw.com/mailer/002/agent.php?page=apply&agent=002&campaign=bmw&vehicle=26 6. http://www.wowbmw.com/mailer/002/agent.php?page=apply&agent=002&campaign=bmw&vehicle=26 7. http://www.wowbmw.com/mailer/002/agent.php?page=decline&agent=002&campaign=bmw&vehicle=26 8. http://www.wowbmw.com/contract.pdf 9. http://www.wowbmw.com/contract.pdf 10. http://www.ncr.org.za/ 11. http://www.wowbmw.com/site/decline.php From owner-freebsd-sparc64@FreeBSD.ORG Wed Oct 19 01:27:23 2011 Return-Path: Delivered-To: freebsd-sparc64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3BD71065673; Wed, 19 Oct 2011 01:27:23 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9B32A8FC08; Wed, 19 Oct 2011 01:27:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9J1RNOA098924; Wed, 19 Oct 2011 01:27:23 GMT (envelope-from eadler@freefall.freebsd.org) Received: (from eadler@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9J1RNGK098920; Wed, 19 Oct 2011 01:27:23 GMT (envelope-from eadler) Date: Wed, 19 Oct 2011 01:27:23 GMT Message-Id: <201110190127.p9J1RNGK098920@freefall.freebsd.org> To: peterjeremy@acm.org, eadler@FreeBSD.org, freebsd-sparc64@FreeBSD.org, marius@FreeBSD.org From: eadler@FreeBSD.org Cc: Subject: Re: sparc64/161764: [patch] Support dumping to Solaris swap partitions 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: Wed, 19 Oct 2011 01:27:23 -0000 Synopsis: [patch] Support dumping to Solaris swap partitions State-Changed-From-To: open->patched State-Changed-By: eadler State-Changed-When: Wed Oct 19 01:26:32 UTC 2011 State-Changed-Why: fix committed in head Responsible-Changed-From-To: freebsd-sparc64->marius Responsible-Changed-By: eadler Responsible-Changed-When: Wed Oct 19 01:26:32 UTC 2011 Responsible-Changed-Why: fix committed in head http://www.freebsd.org/cgi/query-pr.cgi?pr=161764 From owner-freebsd-sparc64@FreeBSD.ORG Fri Oct 21 22:17:15 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 67F381065674 for ; Fri, 21 Oct 2011 22:17:15 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id E9B028FC0A for ; Fri, 21 Oct 2011 22:17:14 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p9LMH7lV016469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Oct 2011 09:17:09 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id p9LMH7Pf031796; Sat, 22 Oct 2011 09:17:07 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id p9LMH6HI031795; Sat, 22 Oct 2011 09:17:06 +1100 (EST) (envelope-from peter) Date: Sat, 22 Oct 2011 09:17:05 +1100 From: Peter Jeremy To: Marius Strobl Message-ID: <20111021221705.GD45938@server.vk2pj.dyndns.org> References: <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> <20111013184224.GG39118@alchemy.franken.de> <20111018042646.GA18863@server.vk2pj.dyndns.org> <20111018172718.GT39118@alchemy.franken.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <20111018172718.GT39118@alchemy.franken.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) 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: Fri, 21 Oct 2011 22:17:15 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Oct-18 19:27:18 +0200, Marius Strobl wr= ote: >On Tue, Oct 18, 2011 at 03:26:46PM +1100, Peter Jeremy wrote: >> On 2011-Oct-13 20:42:25 +0200, Marius Strobl = wrote: >> >On Thu, Oct 13, 2011 at 02:56:48PM +1100, Peter Jeremy wrote: >> >> 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. >> >>=20 >> >> 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. >>=20 >> I've resurrected that patch (and will send-pr it later). Thanks for committing it. >Hrm, AFAICT this would mean that the _mtx_obtain_lock(), which boils >down to a atomic_cmpset_acq_ptr(), in _mtx_trylock() didn't work as >expected, I currently can't think of a good reason why that could >happen though. The assembly generated for that code also looks just >fine. Have you run the workload which is triggering this before? It >would be interesting to know whether it also happens with SCHED_4BSD >with current sources, pre-r226054 and pre-r225889 if the machine >previously survived that load. It was running 6 parallel -j16 buildworlds. I switched to SCHED_4BSD and haven't been able to reproduce it - even with a pile of added "sysctl sysctl vm.vmtotal". I haven't tried rolling back to an earlier kernel. >Have you enabled PREEMPTION by chance? That was using GENERIC and only changing the scheduler. >The other thing that worries me is that it could be a silicon bug, >especially since that machine also has that issue of issuing stale >vector interrupts along with a state in which it traps even on >locked TLB entries, which isn't mentioned in the public erratum ... I've had a rummage around in the OpenSolaris sources and nothing jumps out at me. (Actually, I can't find any special case code that looks like it addresses silicon bugs in Jaguar). One other thing is that I'm getting lots of isp watchdog timeouts: (da4:isp0:0:4:0): first watchdog (handle 0x5cf020f3) timed out- deferring f= or grace period (da4:isp0:0:4:0): first watchdog (handle 0x5cf1206d) timed out- deferring f= or grace period (da4:isp0:0:4:0): first watchdog (handle 0x5cf2203a) timed out- deferring f= or grace period isp0: isp_watchdog: timeout for handle 0x5cad2046 (da4:isp0:0:4:0): FIN dl16384 resid 0 CDB=3D0x2a 0x00 0x0f 0xdd 0xe8 0xe0 0= x00 0x00 0x20 0x00 STS 0x0 XS_ERR=3D0xb isp0: bad request handle 0x5cad2046 (iocb type 0x3) isp0: isp_watchdog: timeout for handle 0x5cdb20cb (da4:isp0:0:4:0): FIN dl16384 resid 0 CDB=3D0x2a 0x00 0x0f 0xe3 0xa8 0x00 0= x00 0x00 0x20 0x00 STS 0x0 XS_ERR=3D0xb isp0: isp_watchdog: timeout for handle 0x5cdc2059 (da4:isp0:0:4:0): FIN dl16384 resid 0 CDB=3D0x2a 0x00 0x0f 0xe3 0xa8 0x20 0= x00 0x00 0x20 0x00 STS 0x0 XS_ERR=3D0xb isp0: isp_watchdog: timeout for handle 0x5cdd2020 (da4:isp0:0:4:0): FIN dl16384 resid 0 CDB=3D0x2a 0x00 0x0f 0xe3 0xa8 0x40 0= x00 0x00 0x20 0x00 STS 0x0 XS_ERR=3D0xb isp0: bad request handle 0x5cdb20cb (iocb type 0x3) isp0: bad request handle 0x5cdc2059 (iocb type 0x3) isp0: bad request handle 0x5cdd2020 (iocb type 0x3) (da4:isp0:0:4:0): first watchdog (handle 0x6b9520bb) timed out- deferring f= or grace period (da4:isp0:0:4:0): first watchdog (handle 0x6b96200e) timed out- deferring f= or grace period Any ideas on that? --=20 Peter Jeremy --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6h72EACgkQ/opHv/APuId+4QCeOZF5pKFYCK8YNDvtgW8cqvkx 7HMAniAXehip+/skW2wTqX7/18FkvXlc =91W+ -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE--