From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 27 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 A35AE106566C for ; Mon, 27 Jun 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 92ADC8FC12 for ; Mon, 27 Jun 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 p5RB7BD9071961 for ; Mon, 27 Jun 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 p5RB7A9b071959 for freebsd-sparc64@FreeBSD.org; Mon, 27 Jun 2011 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Jun 2011 11:07:10 GMT Message-Id: <201106271107.p5RB7A9b071959@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, 27 Jun 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 Mon Jun 27 12:30:10 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 6382D106566C for ; Mon, 27 Jun 2011 12:30:10 +0000 (UTC) (envelope-from bounceback@bounce.mylistmanager.co.za) Received: from bounce.mylistmanager.co.za (mylistmanager.co.za [41.222.33.137]) by mx1.freebsd.org (Postfix) with ESMTP id D09408FC19 for ; Mon, 27 Jun 2011 12:30:08 +0000 (UTC) Received: by bounce.mylistmanager.co.za (Postfix, from userid 0) id D431F2619F30; Mon, 27 Jun 2011 14:15:45 +0200 (SAST) From: infomags@colorpages.co.za (Life Enriching InfoMagazines) To: freebsd-sparc@freebsd.org (Reader ) MIME-Version: 1.0 X-Mailer: OFPHFOCMPIBNBIEJSCM8.2.2 X-Bounce: 9103:2224418:1711:1987:freebsd-sparc@freebsd.org: CAN-SPAM_Compliant: To unsubscribe from all Mailing Lists go to CAN-SPAM_Compliant: http://www.mylistmanager.co.za/cgi-bin/uls/uls.cgi?globalrem=1 Report-SPAM: To report this Member for SPAM go to Report-SPAM: http://www.mylistmanager.co.za/cgi-bin/uls/uls.cgi?KXDJk3HeME3NSVoG=fHB4elDl4GL=I==fbDNHeEGMEHG4EVfwDHKeEGfEeHPlwGbVEEC7k4Zk3HJVB9bVEEE7k41SVWMfwlkol4LG0=YyfENl4GpppzFz=gfHVBLjl4G=0gJI Message-Id: <20110627121545.D431F2619F30@bounce.mylistmanager.co.za> Date: Mon, 27 Jun 2011 14:15:45 +0200 (SAST) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: =?iso-8859-1?q?VIP_Exclusive_-_How_To_Excel_Yourself__Series_-_P?= =?iso-8859-1?q?art_2_-_SA=92s_Read_Green_Initiative?= 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, 27 Jun 2011 12:30:10 -0000 Your VIP Access... Improve Your Lifestyle & Business Series! South Africa's New Read Green Online Publishing Technology Save Paper Save Trees... Help South Africa Reduce Climate Change (Facts About Paper) "http://www.colorpages.co.za/smartread/default1210" - Support This Read Green Initiative! Excel Yourself - Life Enriching Exclusive Series Part 2 - Now Online in Modern Living InfoMags Click on any Magazine to Open - Experience and Enjoy Interactive Online Magazines with Digital Pageflip Technology! Self Improvement Made Easy Camping Holidays Anti-Ageing and Skincare Made Easy How To Decorate Like a Pro Gardening Made Easy Home Security Made Easy Tips About Buying Your Next Car Become an Effective Time Manager You May Need Flash Player Free Download "http://www.adobe.com/shockwave/download/alternates" If this message is not displaying properly Click here to launch your browser "http://www.colorpages.co.za/index.php" "http://www.colorpages.co.za/competition/default0611" InfoMags: Instant Viewing - No Huge Downloads FREE! Click on any Magazine to Open FREE! Enter Our Competition! "http://www.colorpages.co.za/flashbooks/citypages1/default1210"> Delivered-To: freebsd-sparc64@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 9924A106566C; Tue, 28 Jun 2011 17:27:10 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Marius Strobl Date: Tue, 28 Jun 2011 13:26:57 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_m7gCO49rbORZkTy" Message-Id: <201106281327.02537.jkim@FreeBSD.org> Cc: freebsd-sparc64@freebsd.org Subject: [RFC] Clean up sparc64 timecounters 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, 28 Jun 2011 17:27:11 -0000 --Boundary-00=_m7gCO49rbORZkTy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Can you please review the attached patch? sys/sparc64/pci/fire.c: - Remove redundant timecounter masking from tc_get_timecount method. - Remove an unnecessary macro for timecounter mask. - Remove a redundant NULL assignment. sys/sparc64/pci/schizo.c: - Remove redundant timecounter masking from tc_get_timecount method. - Correct timecounter mask. Note this is a no-op because the STX_CTRL_PERF_CNT_CNT0_SHIFT is actually zero. - Remove a redundant NULL assignment. sys/sparc64/sparc64/counter.c: - Remove redundant timecounter masking from tc_get_timecount method. - Add M_ZERO flag to malloc(9) for timecounter to be consistent with other timecounters. - Remove now a redundant NULL assignment. sys/sparc64/sparc64/tick.c: - Remove redundant NULL assignments for static timecounters. Basically, I wanted to get rid of unnecessary (and wrong) timecounter masking within tc_get_timecount methods. Other changes are for consistencies. Thanks! Jung-uk Kim --Boundary-00=_m7gCO49rbORZkTy Content-Type: text/plain; charset="iso-8859-1"; name="tc_sparc64.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tc_sparc64.diff" Index: sys/sparc64/pci/schizo.c =================================================================== --- sys/sparc64/pci/schizo.c (revision 223648) +++ sys/sparc64/pci/schizo.c (working copy) @@ -482,8 +482,8 @@ schizo_attach(device_t dev) if (tc == NULL) panic("%s: could not malloc timecounter", __func__); tc->tc_get_timecount = schizo_get_timecount; - tc->tc_poll_pps = NULL; - tc->tc_counter_mask = STX_CTRL_PERF_CNT_MASK; + tc->tc_counter_mask = STX_CTRL_PERF_CNT_MASK << + STX_CTRL_PERF_CNT_CNT0_SHIFT; if (OF_getprop(OF_peer(0), "clock-frequency", &prop, sizeof(prop)) == -1) panic("%s: could not determine clock frequency", @@ -1521,6 +1521,5 @@ schizo_get_timecount(struct timecounter *tc) struct schizo_softc *sc; sc = tc->tc_priv; - return (SCHIZO_CTRL_READ_8(sc, STX_CTRL_PERF_CNT) & - (STX_CTRL_PERF_CNT_MASK << STX_CTRL_PERF_CNT_CNT0_SHIFT)); + return (SCHIZO_CTRL_READ_8(sc, STX_CTRL_PERF_CNT)); } Index: sys/sparc64/pci/fire.c =================================================================== --- sys/sparc64/pci/fire.c (revision 223648) +++ sys/sparc64/pci/fire.c (working copy) @@ -660,8 +660,6 @@ fire_attach(device_t dev) FIRE_PCI_WRITE_8(sc, FO_PCI_EQ_CTRL_SET_BASE + (j << 3), FO_PCI_EQ_CTRL_SET_EN); -#define TC_COUNTER_MAX_MASK 0xffffffff - /* * Setup JBC/UBC performance counter 0 in bus cycle counting * mode as timecounter. Unfortunately, at least with Fire all @@ -686,8 +684,7 @@ fire_attach(device_t dev) if (tc == NULL) panic("%s: could not malloc timecounter", __func__); tc->tc_get_timecount = fire_get_timecount; - tc->tc_poll_pps = NULL; - tc->tc_counter_mask = TC_COUNTER_MAX_MASK; + tc->tc_counter_mask = ~0ul; if (OF_getprop(OF_peer(0), "clock-frequency", &prop, sizeof(prop)) == -1) panic("%s: could not determine clock frequency", @@ -2170,5 +2167,5 @@ fire_get_timecount(struct timecounter *tc) struct fire_softc *sc; sc = tc->tc_priv; - return (FIRE_CTRL_READ_8(sc, FO_XBC_PRF_CNT0) & TC_COUNTER_MAX_MASK); + return (FIRE_CTRL_READ_8(sc, FO_XBC_PRF_CNT0)); } Index: sys/sparc64/sparc64/counter.c =================================================================== --- sys/sparc64/sparc64/counter.c (revision 223648) +++ sys/sparc64/sparc64/counter.c (working copy) @@ -86,13 +86,12 @@ sparc64_counter_init(const char *name, bus_space_t bus_space_write_8(tag, handle, offset + CTR_CT1 + CTR_LIMIT, COUNTER_MASK); /* Register as a time counter. */ - tc = malloc(sizeof(*tc), M_DEVBUF, M_WAITOK); + tc = malloc(sizeof(*tc), M_DEVBUF, M_WAITOK | M_ZERO); sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK); sc->sc_tag = tag; sc->sc_handle = handle; sc->sc_offset = offset + CTR_CT0; tc->tc_get_timecount = counter_get_timecount; - tc->tc_poll_pps = NULL; tc->tc_counter_mask = COUNTER_MASK; tc->tc_frequency = COUNTER_FREQ; tc->tc_name = strdup(name, M_DEVBUF); @@ -107,6 +106,5 @@ counter_get_timecount(struct timecounter *tc) struct ct_softc *sc; sc = tc->tc_priv; - return (bus_space_read_8(sc->sc_tag, sc->sc_handle, sc->sc_offset) & - COUNTER_MASK); + return (bus_space_read_8(sc->sc_tag, sc->sc_handle, sc->sc_offset)); } Index: sys/sparc64/sparc64/tick.c =================================================================== --- sys/sparc64/sparc64/tick.c (revision 223648) +++ sys/sparc64/sparc64/tick.c (working copy) @@ -197,12 +197,10 @@ cpu_initclocks(void) * quality (S)TICK timers in the MP case. */ tick_tc.tc_get_timecount = tick_get_timecount_up; - tick_tc.tc_poll_pps = NULL; tick_tc.tc_counter_mask = ~0u; tick_tc.tc_frequency = clock; tick_tc.tc_name = "tick"; tick_tc.tc_quality = TICK_QUALITY_UP; - tick_tc.tc_priv = NULL; #ifdef SMP if (cpu_mp_probe()) { tick_tc.tc_get_timecount = tick_get_timecount_mp; @@ -212,12 +210,10 @@ cpu_initclocks(void) tc_init(&tick_tc); if (sclock != 0) { stick_tc.tc_get_timecount = stick_get_timecount_up; - stick_tc.tc_poll_pps = NULL; stick_tc.tc_counter_mask = ~0u; stick_tc.tc_frequency = sclock; stick_tc.tc_name = "stick"; stick_tc.tc_quality = TICK_QUALITY_UP; - stick_tc.tc_priv = NULL; #ifdef SMP if (cpu_mp_probe()) { stick_tc.tc_get_timecount = stick_get_timecount_mp; --Boundary-00=_m7gCO49rbORZkTy-- From owner-freebsd-sparc64@FreeBSD.ORG Tue Jun 28 17:38:04 2011 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 9D2FC1065673; Tue, 28 Jun 2011 17:38:04 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Marius Strobl Date: Tue, 28 Jun 2011 13:37:52 -0400 User-Agent: KMail/1.6.2 References: <201106281327.02537.jkim@FreeBSD.org> In-Reply-To: <201106281327.02537.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_yFhCOrf8sDIl+Nl" Message-Id: <201106281337.54901.jkim@FreeBSD.org> Cc: freebsd-sparc64@freebsd.org Subject: Re: [RFC] Clean up sparc64 timecounters 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, 28 Jun 2011 17:38:05 -0000 --Boundary-00=_yFhCOrf8sDIl+Nl Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday 28 June 2011 01:26 pm, Jung-uk Kim wrote: > Can you please review the attached patch? > > sys/sparc64/pci/fire.c: > - Remove redundant timecounter masking from tc_get_timecount > method. - Remove an unnecessary macro for timecounter mask. > - Remove a redundant NULL assignment. > > sys/sparc64/pci/schizo.c: > - Remove redundant timecounter masking from tc_get_timecount > method. - Correct timecounter mask. Note this is a no-op because > the STX_CTRL_PERF_CNT_CNT0_SHIFT is actually zero. > - Remove a redundant NULL assignment. > > sys/sparc64/sparc64/counter.c: > - Remove redundant timecounter masking from tc_get_timecount > method. - Add M_ZERO flag to malloc(9) for timecounter to be > consistent with other timecounters. > - Remove now a redundant NULL assignment. > > sys/sparc64/sparc64/tick.c: > - Remove redundant NULL assignments for static timecounters. > > Basically, I wanted to get rid of unnecessary (and wrong) > timecounter masking within tc_get_timecount methods. Other changes > are for consistencies. @@ -686,8 +684,7 @@ fire_attach(device_t dev) if (tc == NULL) panic("%s: could not malloc timecounter", __func__); tc->tc_get_timecount = fire_get_timecount; - tc->tc_poll_pps = NULL; - tc->tc_counter_mask = TC_COUNTER_MAX_MASK; + tc->tc_counter_mask = ~0ul; ^^^^ ~0u if (OF_getprop(OF_peer(0), "clock-frequency", &prop, sizeof(prop)) == -1) panic("%s: could not determine clock frequency", Sorry, attached a revised patch. Jung-uk Kim --Boundary-00=_yFhCOrf8sDIl+Nl Content-Type: text/plain; charset="iso-8859-1"; name="tc_sparc64.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tc_sparc64.diff" Index: sys/sparc64/pci/schizo.c =================================================================== --- sys/sparc64/pci/schizo.c (revision 223648) +++ sys/sparc64/pci/schizo.c (working copy) @@ -482,8 +482,8 @@ schizo_attach(device_t dev) if (tc == NULL) panic("%s: could not malloc timecounter", __func__); tc->tc_get_timecount = schizo_get_timecount; - tc->tc_poll_pps = NULL; - tc->tc_counter_mask = STX_CTRL_PERF_CNT_MASK; + tc->tc_counter_mask = STX_CTRL_PERF_CNT_MASK << + STX_CTRL_PERF_CNT_CNT0_SHIFT; if (OF_getprop(OF_peer(0), "clock-frequency", &prop, sizeof(prop)) == -1) panic("%s: could not determine clock frequency", @@ -1521,6 +1521,5 @@ schizo_get_timecount(struct timecounter *tc) struct schizo_softc *sc; sc = tc->tc_priv; - return (SCHIZO_CTRL_READ_8(sc, STX_CTRL_PERF_CNT) & - (STX_CTRL_PERF_CNT_MASK << STX_CTRL_PERF_CNT_CNT0_SHIFT)); + return (SCHIZO_CTRL_READ_8(sc, STX_CTRL_PERF_CNT)); } Index: sys/sparc64/pci/fire.c =================================================================== --- sys/sparc64/pci/fire.c (revision 223648) +++ sys/sparc64/pci/fire.c (working copy) @@ -660,8 +660,6 @@ fire_attach(device_t dev) FIRE_PCI_WRITE_8(sc, FO_PCI_EQ_CTRL_SET_BASE + (j << 3), FO_PCI_EQ_CTRL_SET_EN); -#define TC_COUNTER_MAX_MASK 0xffffffff - /* * Setup JBC/UBC performance counter 0 in bus cycle counting * mode as timecounter. Unfortunately, at least with Fire all @@ -686,8 +684,7 @@ fire_attach(device_t dev) if (tc == NULL) panic("%s: could not malloc timecounter", __func__); tc->tc_get_timecount = fire_get_timecount; - tc->tc_poll_pps = NULL; - tc->tc_counter_mask = TC_COUNTER_MAX_MASK; + tc->tc_counter_mask = ~0u; if (OF_getprop(OF_peer(0), "clock-frequency", &prop, sizeof(prop)) == -1) panic("%s: could not determine clock frequency", @@ -2170,5 +2167,5 @@ fire_get_timecount(struct timecounter *tc) struct fire_softc *sc; sc = tc->tc_priv; - return (FIRE_CTRL_READ_8(sc, FO_XBC_PRF_CNT0) & TC_COUNTER_MAX_MASK); + return (FIRE_CTRL_READ_8(sc, FO_XBC_PRF_CNT0)); } Index: sys/sparc64/sparc64/counter.c =================================================================== --- sys/sparc64/sparc64/counter.c (revision 223648) +++ sys/sparc64/sparc64/counter.c (working copy) @@ -86,13 +86,12 @@ sparc64_counter_init(const char *name, bus_space_t bus_space_write_8(tag, handle, offset + CTR_CT1 + CTR_LIMIT, COUNTER_MASK); /* Register as a time counter. */ - tc = malloc(sizeof(*tc), M_DEVBUF, M_WAITOK); + tc = malloc(sizeof(*tc), M_DEVBUF, M_WAITOK | M_ZERO); sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK); sc->sc_tag = tag; sc->sc_handle = handle; sc->sc_offset = offset + CTR_CT0; tc->tc_get_timecount = counter_get_timecount; - tc->tc_poll_pps = NULL; tc->tc_counter_mask = COUNTER_MASK; tc->tc_frequency = COUNTER_FREQ; tc->tc_name = strdup(name, M_DEVBUF); @@ -107,6 +106,5 @@ counter_get_timecount(struct timecounter *tc) struct ct_softc *sc; sc = tc->tc_priv; - return (bus_space_read_8(sc->sc_tag, sc->sc_handle, sc->sc_offset) & - COUNTER_MASK); + return (bus_space_read_8(sc->sc_tag, sc->sc_handle, sc->sc_offset)); } Index: sys/sparc64/sparc64/tick.c =================================================================== --- sys/sparc64/sparc64/tick.c (revision 223648) +++ sys/sparc64/sparc64/tick.c (working copy) @@ -197,12 +197,10 @@ cpu_initclocks(void) * quality (S)TICK timers in the MP case. */ tick_tc.tc_get_timecount = tick_get_timecount_up; - tick_tc.tc_poll_pps = NULL; tick_tc.tc_counter_mask = ~0u; tick_tc.tc_frequency = clock; tick_tc.tc_name = "tick"; tick_tc.tc_quality = TICK_QUALITY_UP; - tick_tc.tc_priv = NULL; #ifdef SMP if (cpu_mp_probe()) { tick_tc.tc_get_timecount = tick_get_timecount_mp; @@ -212,12 +210,10 @@ cpu_initclocks(void) tc_init(&tick_tc); if (sclock != 0) { stick_tc.tc_get_timecount = stick_get_timecount_up; - stick_tc.tc_poll_pps = NULL; stick_tc.tc_counter_mask = ~0u; stick_tc.tc_frequency = sclock; stick_tc.tc_name = "stick"; stick_tc.tc_quality = TICK_QUALITY_UP; - stick_tc.tc_priv = NULL; #ifdef SMP if (cpu_mp_probe()) { stick_tc.tc_get_timecount = stick_get_timecount_mp; --Boundary-00=_yFhCOrf8sDIl+Nl-- From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 29 02:54:43 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 B134E106564A for ; Wed, 29 Jun 2011 02:54:43 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id 402F68FC0C for ; Wed, 29 Jun 2011 02:54:42 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p5T2sZ6q018678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jun 2011 12:54:37 +1000 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.4/8.14.4) with ESMTP id p5T2sYsp048172; Wed, 29 Jun 2011 12:54:34 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p5T2sY8Y048171; Wed, 29 Jun 2011 12:54:34 +1000 (EST) (envelope-from peter) Date: Wed, 29 Jun 2011 12:54:33 +1000 From: Peter Jeremy To: Marius Strobl Message-ID: <20110629025433.GA48145@server.vk2pj.dyndns.org> References: <20110526234728.GA69750@server.vk2pj.dyndns.org> <20110527120659.GA78000@alchemy.franken.de> <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <20110622100524.GO14797@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: Wed, 29 Jun 2011 02:54:43 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Jun-22 12:05:24 +0200, Marius Strobl wr= ote: >Okay, given that it considerably improves the situation though I >suspect that the problem is that we instantly begin to fault on >kernel mappings once we flush all unlocked TLB entries in order >to get rid of the user mappings, which in case of cpu_switch() >still is covered by sched_lock. That would mean that we should use >a fine grained approach instead as the current one doesn't behave/ >scale well even if sched_lock wasn't be (ab)used here. Could you >please give the following patch a try on top of what you already >have? >http://people.freebsd.org/~marius/sparc64_flush_user_no_sledgehammer.diff 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 Peter Jeremy --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk4Kk+kACgkQ/opHv/APuIcC4wCfQcxFObwVz786CmmvZdJH7pGW fhwAnj+MJmPN7HEIa4lfj0cWbt6kRCGN =DPN7 -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 29 17:54:49 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 6D055106564A for ; Wed, 29 Jun 2011 17:54:49 +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 033BA8FC14 for ; Wed, 29 Jun 2011 17:54:48 +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 p5THsiF6040505; Wed, 29 Jun 2011 19:54:44 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p5THsiIx040504; Wed, 29 Jun 2011 19:54:44 +0200 (CEST) (envelope-from marius) Date: Wed, 29 Jun 2011 19:54:44 +0200 From: Marius Strobl To: Peter Jeremy Message-ID: <20110629175444.GH14797@alchemy.franken.de> References: <20110526234728.GA69750@server.vk2pj.dyndns.org> <20110527120659.GA78000@alchemy.franken.de> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110629025433.GA48145@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: Wed, 29 Jun 2011 17:54:49 -0000 On Wed, Jun 29, 2011 at 12:54:33PM +1000, Peter Jeremy wrote: > On 2011-Jun-22 12:05:24 +0200, Marius Strobl wrote: > >Okay, given that it considerably improves the situation though I > >suspect that the problem is that we instantly begin to fault on > >kernel mappings once we flush all unlocked TLB entries in order > >to get rid of the user mappings, which in case of cpu_switch() > >still is covered by sched_lock. That would mean that we should use > >a fine grained approach instead as the current one doesn't behave/ > >scale well even if sched_lock wasn't be (ab)used here. Could you > >please give the following patch a try on top of what you already > >have? > >http://people.freebsd.org/~marius/sparc64_flush_user_no_sledgehammer.diff > > My V890 has been running "make -j32 buildworld" in a loop for a > week now without problems so I think that was the problem. > Okay, fine, thanks for testing! Just to recap, apart from the above patch you're running with the one-line patch for exception.S which turns the sir in intr_vector into a retry and the patch for pmap.c reducing the lock coverage in pmap_activate() (committed as r223347). Have you additionally altered the DCR configuration in cheetah_init()? Marius From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 29 20:56:49 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 8FB4B106566B for ; Wed, 29 Jun 2011 20:56:49 +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 2B9EA8FC0C for ; Wed, 29 Jun 2011 20:56:48 +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 p5TKukWw041087; Wed, 29 Jun 2011 22:56:47 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p5TKukx8041086; Wed, 29 Jun 2011 22:56:46 +0200 (CEST) (envelope-from marius) Date: Wed, 29 Jun 2011 22:56:46 +0200 From: Marius Strobl To: Jung-uk Kim Message-ID: <20110629205646.GK14797@alchemy.franken.de> References: <201106281327.02537.jkim@FreeBSD.org> <201106281337.54901.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201106281337.54901.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@FreeBSD.org Subject: Re: [RFC] Clean up sparc64 timecounters 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, 29 Jun 2011 20:56:49 -0000 On Tue, Jun 28, 2011 at 01:37:52PM -0400, Jung-uk Kim wrote: > On Tuesday 28 June 2011 01:26 pm, Jung-uk Kim wrote: > > Can you please review the attached patch? > > > > sys/sparc64/pci/fire.c: > > - Remove redundant timecounter masking from tc_get_timecount > > method. - Remove an unnecessary macro for timecounter mask. > > - Remove a redundant NULL assignment. > > > > sys/sparc64/pci/schizo.c: > > - Remove redundant timecounter masking from tc_get_timecount > > method. - Correct timecounter mask. Note this is a no-op because > > the STX_CTRL_PERF_CNT_CNT0_SHIFT is actually zero. > > - Remove a redundant NULL assignment. I'm not sure whether you correctly understand how that timer works. The hardware actually provides a pair of 32-bit timers which are read via a single 64-bit register so the existing tc_counter_mask is correct and your change is wrong. For the same reason the masking and shifting in schizo_get_timecount() only happens to be unnecessary in so far as we currently use the lower 32-bit counter and the tc_get_timecount methods return u_int. If we'd either switch to the upper 32-bit counter or the timecounter code would be enhanced to support up to 64-bit counters it wouldn't be redundant. There's actually a right-shift missing in schizo_get_timecount() though, i.e. it should actually do: return ((SCHIZO_CTRL_READ_8(sc, STX_CTRL_PERF_CNT) & (STX_CTRL_PERF_CNT_MASK << STX_CTRL_PERF_CNT_CNT0_SHIFT) >> STX_CTRL_PERF_CNT_CNT0_SHIFT); The compiler should be smart enough to boil all that down to a single 64-bit to 32-bit conversion when returning though. For similar reasons I'd prefer to also keep the masking in fire_get_timecount(), besides using the macro IMO is cleaner than using ~0u(l). > > @@ -686,8 +684,7 @@ fire_attach(device_t dev) > if (tc == NULL) > panic("%s: could not malloc timecounter", __func__); > tc->tc_get_timecount = fire_get_timecount; > - tc->tc_poll_pps = NULL; > - tc->tc_counter_mask = TC_COUNTER_MAX_MASK; > + tc->tc_counter_mask = ~0ul; > ^^^^ > ~0u > if (OF_getprop(OF_peer(0), "clock-frequency", &prop, > sizeof(prop)) == -1) > panic("%s: could not determine clock frequency", > Well, if you really remove the masking from fire_get_timecount() then you should actually also use ~0ul here for consistency as it's an 64-bit counter. Marius From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 29 21:31:35 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 6FDFC1065677 for ; Wed, 29 Jun 2011 21:31:35 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 41A398FC0A for ; Wed, 29 Jun 2011 21:31:35 +0000 (UTC) Received: by pvg11 with SMTP id 11so1554329pvg.13 for ; Wed, 29 Jun 2011 14:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=52+TgRiDRSaenKQnZc8ZOc9iF/GXBc1lO22S4NTZU2Q=; b=Qpjg+aLDDWMqRedKhbnjdNAKd8ix/mqHayqYCuWIuDMus3A7+lhj+XSXuFMjFDJEHT D68ZcpGNXRcRpCZXRmUoZa445NhOCm6/MK+D0AStw7bmh0w4FFsCa43Anw8Dk/fJgAoi V6yhhJJ8DrHndcUZEekKplQ1qQKn5GUlhSYqU= MIME-Version: 1.0 Received: by 10.68.5.234 with SMTP id v10mr1660529pbv.132.1309383094650; Wed, 29 Jun 2011 14:31:34 -0700 (PDT) Received: by 10.68.48.133 with HTTP; Wed, 29 Jun 2011 14:31:34 -0700 (PDT) In-Reply-To: <20110629205646.GK14797@alchemy.franken.de> References: <201106281327.02537.jkim@FreeBSD.org> <201106281337.54901.jkim@FreeBSD.org> <20110629205646.GK14797@alchemy.franken.de> Date: Wed, 29 Jun 2011 17:31:34 -0400 Message-ID: From: Super Bisquit To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-sparc64@freebsd.org, Jung-uk Kim Subject: Re: [RFC] Clean up sparc64 timecounters 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, 29 Jun 2011 21:31:35 -0000 On Wed, Jun 29, 2011 at 4:56 PM, Marius Strobl wrote: > On Tue, Jun 28, 2011 at 01:37:52PM -0400, Jung-uk Kim wrote: > > On Tuesday 28 June 2011 01:26 pm, Jung-uk Kim wrote: > > > Can you please review the attached patch? > > > > > > sys/sparc64/pci/fire.c: > > > - Remove redundant timecounter masking from tc_get_timecount > > > method. - Remove an unnecessary macro for timecounter mask. > > > - Remove a redundant NULL assignment. > > > > > > sys/sparc64/pci/schizo.c: > > > - Remove redundant timecounter masking from tc_get_timecount > > > method. - Correct timecounter mask. Note this is a no-op because > > > the STX_CTRL_PERF_CNT_CNT0_SHIFT is actually zero. > > > - Remove a redundant NULL assignment. > > I'm not sure whether you correctly understand how that timer works. > The hardware actually provides a pair of 32-bit timers which are > read via a single 64-bit register so the existing tc_counter_mask > is correct and your change is wrong. For the same reason the masking > and shifting in schizo_get_timecount() only happens to be unnecessary > in so far as we currently use the lower 32-bit counter and the > tc_get_timecount methods return u_int. If we'd either switch to > the upper 32-bit counter or the timecounter code would be enhanced > to support up to 64-bit counters it wouldn't be redundant. There's > actually a right-shift missing in schizo_get_timecount() though, > i.e. it should actually do: > return ((SCHIZO_CTRL_READ_8(sc, STX_CTRL_PERF_CNT) & > (STX_CTRL_PERF_CNT_MASK << STX_CTRL_PERF_CNT_CNT0_SHIFT) >> > STX_CTRL_PERF_CNT_CNT0_SHIFT); > The compiler should be smart enough to boil all that down to a > single 64-bit to 32-bit conversion when returning though. > For similar reasons I'd prefer to also keep the masking in > fire_get_timecount(), besides using the macro IMO is cleaner > than using ~0u(l). > > > > > @@ -686,8 +684,7 @@ fire_attach(device_t dev) > > if (tc == NULL) > > panic("%s: could not malloc timecounter", > __func__); > > tc->tc_get_timecount = fire_get_timecount; > > - tc->tc_poll_pps = NULL; > > - tc->tc_counter_mask = TC_COUNTER_MAX_MASK; > > + tc->tc_counter_mask = ~0ul; > > ^^^^ > > ~0u > > if (OF_getprop(OF_peer(0), "clock-frequency", &prop, > > sizeof(prop)) == -1) > > panic("%s: could not determine clock frequency", > > > > Well, if you really remove the masking from fire_get_timecount() > then you should actually also use ~0ul here for consistency as it's > an 64-bit counter. > > Marius > > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" > I'm curious as to how this would improve performance on the overall SPARC64 port or is it only for one model? From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 29 22:32:22 2011 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 31C221065670; Wed, 29 Jun 2011 22:32:22 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Marius Strobl Date: Wed, 29 Jun 2011 18:32:11 -0400 User-Agent: KMail/1.6.2 References: <201106281327.02537.jkim@FreeBSD.org> <201106281337.54901.jkim@FreeBSD.org> <20110629205646.GK14797@alchemy.franken.de> In-Reply-To: <20110629205646.GK14797@alchemy.franken.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106291832.13735.jkim@FreeBSD.org> Cc: freebsd-sparc64@FreeBSD.org Subject: Re: [RFC] Clean up sparc64 timecounters 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, 29 Jun 2011 22:32:22 -0000 On Wednesday 29 June 2011 04:56 pm, Marius Strobl wrote: > On Tue, Jun 28, 2011 at 01:37:52PM -0400, Jung-uk Kim wrote: > > On Tuesday 28 June 2011 01:26 pm, Jung-uk Kim wrote: > > > Can you please review the attached patch? > > > > > > sys/sparc64/pci/fire.c: > > > - Remove redundant timecounter masking from tc_get_timecount > > > method. - Remove an unnecessary macro for timecounter mask. > > > - Remove a redundant NULL assignment. > > > > > > sys/sparc64/pci/schizo.c: > > > - Remove redundant timecounter masking from tc_get_timecount > > > method. - Correct timecounter mask. Note this is a no-op > > > because the STX_CTRL_PERF_CNT_CNT0_SHIFT is actually zero. > > > - Remove a redundant NULL assignment. > > I'm not sure whether you correctly understand how that timer works. > The hardware actually provides a pair of 32-bit timers which are > read via a single 64-bit register so the existing tc_counter_mask > is correct and your change is wrong. For the same reason the > masking and shifting in schizo_get_timecount() only happens to be > unnecessary in so far as we currently use the lower 32-bit counter > and the tc_get_timecount methods return u_int. Actually, tc_counter_mask is also u_int and the upper 32-bit is always ignored. > If we'd either switch to the upper 32-bit counter or the timecounter > code would be enhanced to support up to 64-bit counters it wouldn't > be redundant. There is no reason to support 64-bit timecounter as kern_tc.c was meant to be MI code. > There's actually a right-shift missing in schizo_get_timecount() > though, i.e. it should actually do: > return ((SCHIZO_CTRL_READ_8(sc, STX_CTRL_PERF_CNT) & > (STX_CTRL_PERF_CNT_MASK << STX_CTRL_PERF_CNT_CNT0_SHIFT) >> > STX_CTRL_PERF_CNT_CNT0_SHIFT); > The compiler should be smart enough to boil all that down to a > single 64-bit to 32-bit conversion when returning though. tc_get_timecount method should return a raw value. There is no reason to mask it here because kern_tc.c does it whenever necessary. > For similar reasons I'd prefer to also keep the masking in > fire_get_timecount(), besides using the macro IMO is cleaner > than using ~0u(l). Please see above. tc_counter_mask is u_int. Jung-uk Kim > > @@ -686,8 +684,7 @@ fire_attach(device_t dev) > > if (tc == NULL) > > panic("%s: could not malloc timecounter", > > __func__); tc->tc_get_timecount = fire_get_timecount; - > > tc->tc_poll_pps = NULL; > > - tc->tc_counter_mask = TC_COUNTER_MAX_MASK; > > + tc->tc_counter_mask = ~0ul; > > ^^^^ > > ~0u > > if (OF_getprop(OF_peer(0), "clock-frequency", > > &prop, sizeof(prop)) == -1) > > panic("%s: could not determine clock > > frequency", > > Well, if you really remove the masking from fire_get_timecount() > then you should actually also use ~0ul here for consistency as it's > an 64-bit counter. > > Marius From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 29 22:43:07 2011 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 741CD106566C; Wed, 29 Jun 2011 22:43:07 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Super Bisquit Date: Wed, 29 Jun 2011 18:42:58 -0400 User-Agent: KMail/1.6.2 References: <201106281327.02537.jkim@FreeBSD.org> <20110629205646.GK14797@alchemy.franken.de> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106291843.00030.jkim@FreeBSD.org> Cc: freebsd-sparc64@freebsd.org, Marius Strobl Subject: Re: [RFC] Clean up sparc64 timecounters 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, 29 Jun 2011 22:43:07 -0000 On Wednesday 29 June 2011 05:31 pm, Super Bisquit wrote: > On Wed, Jun 29, 2011 at 4:56 PM, Marius Strobl wrote: > > On Tue, Jun 28, 2011 at 01:37:52PM -0400, Jung-uk Kim wrote: > > > On Tuesday 28 June 2011 01:26 pm, Jung-uk Kim wrote: > > > > Can you please review the attached patch? > > > > > > > > sys/sparc64/pci/fire.c: > > > > - Remove redundant timecounter masking from tc_get_timecount > > > > method. - Remove an unnecessary macro for timecounter mask. > > > > - Remove a redundant NULL assignment. > > > > > > > > sys/sparc64/pci/schizo.c: > > > > - Remove redundant timecounter masking from tc_get_timecount > > > > method. - Correct timecounter mask. Note this is a no-op > > > > because the STX_CTRL_PERF_CNT_CNT0_SHIFT is actually zero. > > > > - Remove a redundant NULL assignment. > > > > I'm not sure whether you correctly understand how that timer > > works. The hardware actually provides a pair of 32-bit timers > > which are read via a single 64-bit register so the existing > > tc_counter_mask is correct and your change is wrong. For the same > > reason the masking and shifting in schizo_get_timecount() only > > happens to be unnecessary in so far as we currently use the lower > > 32-bit counter and the tc_get_timecount methods return u_int. If > > we'd either switch to the upper 32-bit counter or the timecounter > > code would be enhanced to support up to 64-bit counters it > > wouldn't be redundant. There's actually a right-shift missing in > > schizo_get_timecount() though, i.e. it should actually do: > > return ((SCHIZO_CTRL_READ_8(sc, STX_CTRL_PERF_CNT) & > > (STX_CTRL_PERF_CNT_MASK << > > STX_CTRL_PERF_CNT_CNT0_SHIFT) >> STX_CTRL_PERF_CNT_CNT0_SHIFT); > > The compiler should be smart enough to boil all that down to a > > single 64-bit to 32-bit conversion when returning though. > > For similar reasons I'd prefer to also keep the masking in > > fire_get_timecount(), besides using the macro IMO is cleaner > > than using ~0u(l). > > > > > @@ -686,8 +684,7 @@ fire_attach(device_t dev) > > > if (tc == NULL) > > > panic("%s: could not malloc > > > timecounter", > > > > __func__); > > > > > tc->tc_get_timecount = fire_get_timecount; > > > - tc->tc_poll_pps = NULL; > > > - tc->tc_counter_mask = TC_COUNTER_MAX_MASK; > > > + tc->tc_counter_mask = ~0ul; > > > ^^^^ > > > ~0u > > > if (OF_getprop(OF_peer(0), "clock-frequency", > > > &prop, sizeof(prop)) == -1) > > > panic("%s: could not determine clock > > > frequency", > > > > Well, if you really remove the masking from fire_get_timecount() > > then you should actually also use ~0ul here for consistency as > > it's an 64-bit counter. > > > > Marius > > > I'm curious as to how this would improve performance on the overall > SPARC64 port or is it only for one model? It is a trivial clean up and it won't really improve performance. Jung-uk Kim From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 29 23:02:08 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 4C8D1106566B; Wed, 29 Jun 2011 23:02:08 +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 DB32E8FC0A; Wed, 29 Jun 2011 23:02:07 +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 p5TN26gl041556; Thu, 30 Jun 2011 01:02:06 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p5TN26QN041555; Thu, 30 Jun 2011 01:02:06 +0200 (CEST) (envelope-from marius) Date: Thu, 30 Jun 2011 01:02:06 +0200 From: Marius Strobl To: Jung-uk Kim Message-ID: <20110629230206.GM14797@alchemy.franken.de> References: <201106281327.02537.jkim@FreeBSD.org> <201106281337.54901.jkim@FreeBSD.org> <20110629205646.GK14797@alchemy.franken.de> <201106291832.13735.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201106291832.13735.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@FreeBSD.org Subject: Re: [RFC] Clean up sparc64 timecounters 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, 29 Jun 2011 23:02:08 -0000 On Wed, Jun 29, 2011 at 06:32:11PM -0400, Jung-uk Kim wrote: > On Wednesday 29 June 2011 04:56 pm, Marius Strobl wrote: > > On Tue, Jun 28, 2011 at 01:37:52PM -0400, Jung-uk Kim wrote: > > > On Tuesday 28 June 2011 01:26 pm, Jung-uk Kim wrote: > > > > Can you please review the attached patch? > > > > > > > > sys/sparc64/pci/fire.c: > > > > - Remove redundant timecounter masking from tc_get_timecount > > > > method. - Remove an unnecessary macro for timecounter mask. > > > > - Remove a redundant NULL assignment. > > > > > > > > sys/sparc64/pci/schizo.c: > > > > - Remove redundant timecounter masking from tc_get_timecount > > > > method. - Correct timecounter mask. Note this is a no-op > > > > because the STX_CTRL_PERF_CNT_CNT0_SHIFT is actually zero. > > > > - Remove a redundant NULL assignment. > > > > I'm not sure whether you correctly understand how that timer works. > > The hardware actually provides a pair of 32-bit timers which are > > read via a single 64-bit register so the existing tc_counter_mask > > is correct and your change is wrong. For the same reason the > > masking and shifting in schizo_get_timecount() only happens to be > > unnecessary in so far as we currently use the lower 32-bit counter > > and the tc_get_timecount methods return u_int. > > Actually, tc_counter_mask is also u_int and the upper 32-bit is always > ignored. I'm aware of that. The point of the existing code is to not make assumptions about what 32-bit half of the register is used as shifting down has to be done in the tc_get_timecount method as long as the MI code only supports up to 32-bit counters. I've also just checked that return ((SCHIZO_CTRL_READ_8(sc, STX_CTRL_PERF_CNT) & (STX_CTRL_PERF_CNT_MASK << STX_CTRL_PERF_CNT_CNT0_SHIFT)) >> STX_CTRL_PERF_CNT_CNT0_SHIFT); and return (SCHIZO_CTRL_READ_8(sc, STX_CTRL_PERF_CNT)); both result in the same object code already with -O so there's no real reason to use the latter, which IMO would be a clean-down. In any case, the following approach is wrong as it breaks when replacing CNT0 with CNT1 as long as tc_counter_mask is u_int + tc->tc_counter_mask = STX_CTRL_PERF_CNT_MASK << + STX_CTRL_PERF_CNT_CNT0_SHIFT; > > > If we'd either switch to the upper 32-bit counter or the timecounter > > code would be enhanced to support up to 64-bit counters it wouldn't > > be redundant. > > There is no reason to support 64-bit timecounter as kern_tc.c was > meant to be MI code. > > > There's actually a right-shift missing in schizo_get_timecount() > > though, i.e. it should actually do: > > return ((SCHIZO_CTRL_READ_8(sc, STX_CTRL_PERF_CNT) & > > (STX_CTRL_PERF_CNT_MASK << STX_CTRL_PERF_CNT_CNT0_SHIFT) >> > > STX_CTRL_PERF_CNT_CNT0_SHIFT); > > The compiler should be smart enough to boil all that down to a > > single 64-bit to 32-bit conversion when returning though. > > tc_get_timecount method should return a raw value. There is no reason > to mask it here because kern_tc.c does it whenever necessary. > > > For similar reasons I'd prefer to also keep the masking in > > fire_get_timecount(), besides using the macro IMO is cleaner > > than using ~0u(l). > > Please see above. tc_counter_mask is u_int. My point is that if you use the raw value, i.e. the full 64-bit, of the counter register you should also use the corresponding raw and 64-bit mask for tc_counter_mask for consistency. In both cases these raw values will converted to 32-bit implicitly, which is why I prefer the existing TC_COUNTER_MAX_MASK approach. Marius From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 30 22:33: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 6417B106566C for ; Thu, 30 Jun 2011 22:33:24 +0000 (UTC) (envelope-from peter.jeremy@alcatel-lucent.com) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 229B48FC08 for ; Thu, 30 Jun 2011 22:33:23 +0000 (UTC) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p5UMXK6Q029043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Jun 2011 17:33:20 -0500 (CDT) Received: from unixmail.au.alcatel-lucent.com (unixmail.au.alcatel-lucent.com [139.188.42.130]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5UMXGo5023175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2011 17:33:19 -0500 Received: from insmb.au.alcatel-lucent.com (insmb.au.alcatel-lucent.com [139.188.42.184]) by unixmail.au.alcatel-lucent.com (8.13.8+Sun/8.13.3) with ESMTP id p5UMX0HI025953; Fri, 1 Jul 2011 08:33:01 +1000 (EST) Received: from pjdesk.au.alcatel-lucent.com (pjdesk.au.alcatel-lucent.com [139.188.2.2]) by insmb.au.alcatel-lucent.com (8.13.8+Sun/8.13.8) with ESMTP id p5UMHwII025483; Fri, 1 Jul 2011 08:17:59 +1000 (EST) X-Bogosity: Ham, spamicity=0.000000 Received: from pjdesk.au.alcatel-lucent.com (localhost [127.0.0.1]) by pjdesk.au.alcatel-lucent.com (8.14.4/8.14.4) with ESMTP id p5UMHrdE020553; Fri, 1 Jul 2011 08:17:53 +1000 (EST) (envelope-from peter.jeremy@alcatel-lucent.com) Received: (from pjeremy@localhost) by pjdesk.au.alcatel-lucent.com (8.14.4/8.14.4/Submit) id p5UMHqA1020552; Fri, 1 Jul 2011 08:17:52 +1000 (EST) (envelope-from peter.jeremy@alcatel-lucent.com) Date: Fri, 1 Jul 2011 08:17:52 +1000 From: Peter Jeremy To: Marius Strobl Message-ID: <20110630221752.GG65891@pjdesk.au.alcatel-lucent.com> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gMR3gsNFwZpnI/Ts" Content-Disposition: inline In-Reply-To: <20110629223008.GL14797@alchemy.franken.de> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "alc@freebsd.org" , 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, 30 Jun 2011 22:33:24 -0000 --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 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 = 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-- From owner-freebsd-sparc64@FreeBSD.ORG Thu Jun 30 22:34:43 2011 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6F74106566B; Thu, 30 Jun 2011 22:34:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A64A98FC12; Thu, 30 Jun 2011 22:34:43 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p5UMYgcP091024; Thu, 30 Jun 2011 18:34:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p5UMYgPF091023; Thu, 30 Jun 2011 22:34:42 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 30 Jun 2011 22:34:42 GMT Message-Id: <201106302234.p5UMYgPF091023@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 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: Thu, 30 Jun 2011 22:34:44 -0000 TB --- 2011-06-30 21:40:13 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-06-30 21:40:13 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-06-30 21:40:13 - cleaning the object tree TB --- 2011-06-30 21:40:31 - cvsupping the source tree TB --- 2011-06-30 21:40:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-06-30 21:40:45 - building world TB --- 2011-06-30 21:40:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-06-30 21:40:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-06-30 21:40:45 - TARGET=sparc64 TB --- 2011-06-30 21:40:45 - TARGET_ARCH=sparc64 TB --- 2011-06-30 21:40:45 - TZ=UTC TB --- 2011-06-30 21:40:45 - __MAKE_CONF=/dev/null TB --- 2011-06-30 21:40:45 - cd /src TB --- 2011-06-30 21:40:45 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 30 21:40:45 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/devopen.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/disk.c /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_openmbr': /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: 'LABELSECTOR' undeclared (first use in this function) /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: (Each undeclared identifier is reported only once /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: for each function it appears in.) /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_printbsdslice': /src/sys/boot/sparc64/loader/../../common/disk.c:376: error: 'LABELSECTOR' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/boot/sparc64/loader. *** Error code 1 Stop in /src/sys/boot/sparc64. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-06-30 22:34:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-06-30 22:34:42 - ERROR: failed to build world TB --- 2011-06-30 22:34:42 - 2453.42 user 603.88 system 3268.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Fri Jul 1 04:26:00 2011 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FFFA106564A; Fri, 1 Jul 2011 04:26:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 011128FC19; Fri, 1 Jul 2011 04:25:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p614PxdS064847; Fri, 1 Jul 2011 00:25:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p614Pw9H064838; Fri, 1 Jul 2011 04:25:58 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Jul 2011 04:25:58 GMT Message-Id: <201107010425.p614Pw9H064838@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 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: Fri, 01 Jul 2011 04:26:00 -0000 TB --- 2011-07-01 03:30:49 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-01 03:30:49 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-01 03:30:49 - cleaning the object tree TB --- 2011-07-01 03:30:58 - cvsupping the source tree TB --- 2011-07-01 03:30:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-01 03:31:11 - building world TB --- 2011-07-01 03:31:11 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-01 03:31:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-01 03:31:11 - TARGET=sparc64 TB --- 2011-07-01 03:31:11 - TARGET_ARCH=sparc64 TB --- 2011-07-01 03:31:11 - TZ=UTC TB --- 2011-07-01 03:31:11 - __MAKE_CONF=/dev/null TB --- 2011-07-01 03:31:11 - cd /src TB --- 2011-07-01 03:31:11 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 1 03:31:12 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/devopen.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/disk.c /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_openmbr': /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: 'LABELSECTOR' undeclared (first use in this function) /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: (Each undeclared identifier is reported only once /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: for each function it appears in.) /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_printbsdslice': /src/sys/boot/sparc64/loader/../../common/disk.c:376: error: 'LABELSECTOR' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/boot/sparc64/loader. *** Error code 1 Stop in /src/sys/boot/sparc64. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-01 04:25:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-01 04:25:58 - ERROR: failed to build world TB --- 2011-07-01 04:25:58 - 2500.08 user 607.30 system 3308.72 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Fri Jul 1 10:19:10 2011 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 704A8106564A; Fri, 1 Jul 2011 10:19:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 411A98FC0A; Fri, 1 Jul 2011 10:19:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p61AJ9RV026010; Fri, 1 Jul 2011 06:19:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p61AJ91N025987; Fri, 1 Jul 2011 10:19:09 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Jul 2011 10:19:09 GMT Message-Id: <201107011019.p61AJ91N025987@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 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: Fri, 01 Jul 2011 10:19:10 -0000 TB --- 2011-07-01 09:23:48 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-01 09:23:48 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-01 09:23:48 - cleaning the object tree TB --- 2011-07-01 09:23:56 - cvsupping the source tree TB --- 2011-07-01 09:23:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-01 09:24:10 - building world TB --- 2011-07-01 09:24:10 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-01 09:24:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-01 09:24:10 - TARGET=sparc64 TB --- 2011-07-01 09:24:10 - TARGET_ARCH=sparc64 TB --- 2011-07-01 09:24:10 - TZ=UTC TB --- 2011-07-01 09:24:10 - __MAKE_CONF=/dev/null TB --- 2011-07-01 09:24:10 - cd /src TB --- 2011-07-01 09:24:10 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 1 09:24:12 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/devopen.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/disk.c /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_openmbr': /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: 'LABELSECTOR' undeclared (first use in this function) /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: (Each undeclared identifier is reported only once /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: for each function it appears in.) /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_printbsdslice': /src/sys/boot/sparc64/loader/../../common/disk.c:376: error: 'LABELSECTOR' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/boot/sparc64/loader. *** Error code 1 Stop in /src/sys/boot/sparc64. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-01 10:19:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-01 10:19:09 - ERROR: failed to build world TB --- 2011-07-01 10:19:09 - 2503.76 user 605.66 system 3320.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Fri Jul 1 13:00:25 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 CFBDC1065670 for ; Fri, 1 Jul 2011 13:00:25 +0000 (UTC) (envelope-from mirflickr@yahoo.com) Received: from n5-vm3.bullet.mail.bf1.yahoo.com (n5-vm3.bullet.mail.bf1.yahoo.com [72.30.235.223]) by mx1.freebsd.org (Postfix) with SMTP id 85BB58FC0C for ; Fri, 1 Jul 2011 13:00:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=gcom1024; t=1309524337; bh=Lvb3ZVimY/B97LsSPnM/kZNz57doFnBV6xaRAGA/LL0=; h=Received:Received:Received:Date:Received:X-yahoo-newman-expires:To:From:Subject:X-Yahoo-Newman-Property:X-Yahoo-Newman-Id; b=AjPhV0Ww5qVXgPP2vd46FdBlYtK/cZyVvGwrW3YW6ojCfZ2xo4hJpyDn1xnYFrmzpSYnrL0SMa/aOadsI34mLiYwrPcZf5MAC+Mvctcm6Q+blOElhdQRqjtrPFQFz9yn1bUxobjfiLReyVZpQAw3UqUE5LtxWD+3O0WwyIZIEWg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=gcom1024; d=yahoo.com; b=ktSXG7F7euPM5f/c6tPHvW6smidKSxyfWVDP/YpdiG0MaY/XTfK2dTx0iCudvoRgLA1xOr1lpLpuwbqWwmyoTMDoeXrzpU/EJgSLLKZvgP3rvyZ8Ht1/UlLM/pC+EvQjvbOyKq3e9uhWy7EGKw24oMViWN4z1YjE7uEb2jb6RJg=; Received: from [72.30.235.64] by n5.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2011 12:45:37 -0000 Received: from [66.228.161.143] by t1.bullet.mail.bf1.yahoo.com with NNFMP; 01 Jul 2011 12:45:37 -0000 Received: from [10.78.36.210] by b1.corp.yahoo.com with NNFMP; 01 Jul 2011 12:45:36 -0000 Date: 01 Jul 2011 14:10:04 +0200 Received: from [127.0.0.1] by media1.barcelona.corp.yahoo.com with NNFMP; 01 Jul 2011 12:10:03 -0000 X-yahoo-newman-expires: 1309525803 To: From: CVIU Call for Papers X-Yahoo-Newman-Property: cfp X-Yahoo-Newman-Id: cfp_cviu2012_10343 Message-Id: <20110701130025.CFBDC1065670@hub.freebsd.org> Subject: CVIU Special Issue on Visual Concept Detection 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, 01 Jul 2011 13:00:26 -0000 CALL FOR PAPERS Computer Vision and Image Understanding: Special Issue on Visual Concept Detection http://press.liacs.nl/cviu Guest editors: Bart Thomee, Yahoo! Research, Spain Mark J. Huiskes, Leiden University, Netherlands Michael S. Lew, Leiden University, Netherlands Important dates: Submission of manuscript: 1 November 2011 First notification of acceptance: 1 March 2012 Revised manuscript submission: 1 May 2012 Final notification of acceptance: 15 June 2012 Publication of special issue: Fall 2012 Description: One of the grand challenges in multimedia information retrieval is automatic visual concept detection. This special issue calls on researchers that aim to raise the bar with novel approaches and techniques. All contributions are welcomed that address the topic of visual concept detection using the MIRFLICKR image collection, which is a popular large-scale open test benchmark. This special issue provides an excellent venue to publish high-quality work on novel ideas and insights that will significantly advance the state of the art. Dataset: The special issue centers around the MIRFLICKR image collection for the visual concept detection challenge. This set consists of one million images from thousands of real world users that were published to the Flickr social photography website under a creative commons license. To facilitate training and testing a subset of the collection has been carefully annotated by hand. The dataset can be obtained from http://mirflickr.liacs.nl. It is at the discretion of the authors to use the collection in its entirety or only partially. Besides the annotations already supplied with the dataset, the ImageCLEF organization has additionally defined 99 concepts and 40 topics that can be expressed as a logical combination of these concepts. Their custom MIRFLICKR collection is available to registered participants of the ImageCLEF Photo Annotation task. Please refer to http://www.imageclef.org/2011/Photo for more details on this dataset. Results based on the ImageCLEF annotations are within the scope of this special issue. Submissions: All submissions for this special issue are required to follow the same format as regular full-length Computer Vision and Image Understanding papers. Manuscripts must be submitted through the CVIU online submission system at http://ees.elsevier.com/cviu. Please ensure to select 'Special Issue: Visual Concept Detection' as the 'Article Type'. All manuscripts should contain at least 30% original material. When submitting a manuscript that is an expanded version of a conference or workshop paper, this prior paper must be included as 'Supplementary Material' during submission. All manuscripts will be peer-reviewed according to the CVIU reviewing procedures. Contact: If you have any questions, please contact Bart Thomee at mirflickr@yahoo.com. From owner-freebsd-sparc64@FreeBSD.ORG Fri Jul 1 16:08:02 2011 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5C98106566B; Fri, 1 Jul 2011 16:08:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 74FC68FC12; Fri, 1 Jul 2011 16:08:02 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p61G81VN085948; Fri, 1 Jul 2011 12:08:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p61G81mm085922; Fri, 1 Jul 2011 16:08:01 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 1 Jul 2011 16:08:01 GMT Message-Id: <201107011608.p61G81mm085922@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on sparc64/sparc64 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: Fri, 01 Jul 2011 16:08:02 -0000 TB --- 2011-07-01 15:12:58 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-07-01 15:12:58 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-07-01 15:12:58 - cleaning the object tree TB --- 2011-07-01 15:13:06 - cvsupping the source tree TB --- 2011-07-01 15:13:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-07-01 15:13:20 - building world TB --- 2011-07-01 15:13:20 - MAKEOBJDIRPREFIX=/obj TB --- 2011-07-01 15:13:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-07-01 15:13:20 - TARGET=sparc64 TB --- 2011-07-01 15:13:20 - TARGET_ARCH=sparc64 TB --- 2011-07-01 15:13:20 - TZ=UTC TB --- 2011-07-01 15:13:20 - __MAKE_CONF=/dev/null TB --- 2011-07-01 15:13:20 - cd /src TB --- 2011-07-01 15:13:20 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 1 15:13:20 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/devopen.c cc -O2 -pipe -DLOADER_DISK_SUPPORT -DLOADER_UFS_SUPPORT -DLOADER_CD9660_SUPPORT -DLOADER_GZIP_SUPPORT -DLOADER_NET_SUPPORT -DLOADER_NFS_SUPPORT -DLOADER_TFTP_SUPPORT -DBOOT_FORTH -I/src/sys/boot/sparc64/loader/../../ficl -I/src/sys/boot/sparc64/loader/../../ficl/sparc64 -I/src/sys/boot/sparc64/loader/../../common -I. -DNETIF_OPEN_CLOSE_ONCE -I/src/sys/boot/sparc64/loader/../../ofw/libofw/ -I/src/sys/boot/sparc64/loader/../../../../lib/libstand/ -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/loader/../../common/disk.c /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_openmbr': /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: 'LABELSECTOR' undeclared (first use in this function) /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: (Each undeclared identifier is reported only once /src/sys/boot/sparc64/loader/../../common/disk.c:328: error: for each function it appears in.) /src/sys/boot/sparc64/loader/../../common/disk.c: In function 'disk_printbsdslice': /src/sys/boot/sparc64/loader/../../common/disk.c:376: error: 'LABELSECTOR' undeclared (first use in this function) *** Error code 1 Stop in /src/sys/boot/sparc64/loader. *** Error code 1 Stop in /src/sys/boot/sparc64. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-07-01 16:08:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-07-01 16:08:01 - ERROR: failed to build world TB --- 2011-07-01 16:08:01 - 2499.77 user 607.25 system 3302.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-sparc64@FreeBSD.ORG Sat Jul 2 00:23:31 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 2B1DD1065670; Sat, 2 Jul 2011 00:23:31 +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 89B9B8FC19; Sat, 2 Jul 2011 00:23:30 +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 p620NPG8056187; Sat, 2 Jul 2011 02:23: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 p620NP9Z056186; Sat, 2 Jul 2011 02:23:25 +0200 (CEST) (envelope-from marius) Date: Sat, 2 Jul 2011 02:23:25 +0200 From: Marius Strobl To: Peter Jeremy Message-ID: <20110702002325.GS14797@alchemy.franken.de> References: <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> <20110630221752.GG65891@pjdesk.au.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110630221752.GG65891@pjdesk.au.alcatel-lucent.com> User-Agent: Mutt/1.4.2.3i Cc: "alc@freebsd.org" , 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: Sat, 02 Jul 2011 00:23:31 -0000 On Fri, Jul 01, 2011 at 08:17:52AM +1000, Peter Jeremy wrote: > [Moving back on-list] > > On 2011-Jun-30 06:30:08 +0800, Marius Strobl wrote: > >On Thu, Jun 30, 2011 at 08:00:10AM +1000, Peter Jeremy wrote: > >> On 2011-Jun-29 19:54:44 +0200, Marius Strobl 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. > >> > >> OTOH, a V440 that has been running similar load for a similar period > >> died overnight with: > >> > >> panic: uma_small_alloc: free page still has mappings! > >> VNASSERT failed > >> cpuid = 3 > >> 0xfffff800079643c0: KDB: enter: panic > ... > >> 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). That shouldn't make a difference; the later version only adds the SPARC64 bits as you already noticed and adjusts the boot loader to compile again. I made no changes to the existing parts apart from fixing a comment. Besides I see no connection between fixing the gross user TLB flushing and the below problem so far. > > >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=150: > > panic: uma_small_alloc: free page still has mappings! > cpuid = 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=0x101db4 -- > userland() at 0x405936c8 > user trace: trap %o7=0x101db4 > 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? The VM and its interaction with the MD code are beyond me, I hope Alan can chime in here. Reading through the code I see a possible path which could lead to this though; tsb_tte_enter(), which is the only place where TD_PV ever is set and also only in case of managed pages, always calls pmap_cache_enter(), which together with pmap_cache_remove() does the page color handling. In pmap_remove_all() however, pmap_cache_remove() is only called for managed pages, so for unmanaged pages we might miss the removal of the mapping from the the color used. I've no idea though if this actually is relevant, i.e. whether the VM ever calls pmap_remove_all() for unmanaged pages. Tentatively I'd say it doesn't, in which case the only solution I see is to exclude unmanaged pages from the page color handling and caching, which I don't know whether it's safe (besides impacting performance). Unfortunately, with my gear I can't reproduce this. Could you please try the below patch? I've no idea whether it's correct but might give another datapoint. Marius Index: pmap.c =================================================================== --- pmap.c (revision 223705) +++ pmap.c (working copy) @@ -1382,21 +1385,21 @@ pmap_remove_all(vm_page_t m) vm_page_lock_queues(); for (tp = TAILQ_FIRST(&m->md.tte_list); tp != NULL; tp = tpn) { tpn = TAILQ_NEXT(tp, tte_link); - if ((tp->tte_data & TD_PV) == 0) - continue; pm = TTE_GET_PMAP(tp); va = TTE_GET_VA(tp); PMAP_LOCK(pm); if ((tp->tte_data & TD_WIRED) != 0) pm->pm_stats.wired_count--; - if ((tp->tte_data & TD_REF) != 0) - vm_page_flag_set(m, PG_REFERENCED); - if ((tp->tte_data & TD_W) != 0) - vm_page_dirty(m); + if ((tp->tte_data & TD_PV) != 0) { + if ((tp->tte_data & TD_REF) != 0) + vm_page_flag_set(m, PG_REFERENCED); + if ((tp->tte_data & TD_W) != 0) + vm_page_dirty(m); + pm->pm_stats.resident_count--; + } tp->tte_data &= ~TD_V; tlb_page_demap(pm, va); TAILQ_REMOVE(&m->md.tte_list, tp, tte_link); - pm->pm_stats.resident_count--; pmap_cache_remove(m, va); TTE_ZERO(tp); PMAP_UNLOCK(pm); From owner-freebsd-sparc64@FreeBSD.ORG Sat Jul 2 19:22:39 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 B8C84106566C for ; Sat, 2 Jul 2011 19:22:39 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0FE8FC0C for ; Sat, 2 Jul 2011 19:22:39 +0000 (UTC) Received: from mh3.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh3.mail.rice.edu (Postfix) with ESMTP id 88C9328FA30; Sat, 2 Jul 2011 14:03:43 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh3.mail.rice.edu, auth channel Received: from mh3.mail.rice.edu ([127.0.0.1]) by mh3.mail.rice.edu (mh3.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id OxoCC52Wc-jK; Sat, 2 Jul 2011 14:03:43 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh3.mail.rice.edu (Postfix) with ESMTPSA id DC4E328F99A; Sat, 2 Jul 2011 14:03:42 -0500 (CDT) Message-ID: <4E0F6B8D.8000500@rice.edu> Date: Sat, 02 Jul 2011 14:03:41 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.15) Gecko/20110328 Thunderbird/3.1.9 MIME-Version: 1.0 To: Marius Strobl References: <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> <20110630221752.GG65891@pjdesk.au.alcatel-lucent.com> <20110702002325.GS14797@alchemy.franken.de> In-Reply-To: <20110702002325.GS14797@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , "alc@freebsd.org" , 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: Sat, 02 Jul 2011 19:22:39 -0000 On 07/01/2011 19:23, Marius Strobl wrote: > On Fri, Jul 01, 2011 at 08:17:52AM +1000, Peter Jeremy wrote: >> [Moving back on-list] >> >> On 2011-Jun-30 06:30:08 +0800, Marius Strobl wrote: >>> On Thu, Jun 30, 2011 at 08:00:10AM +1000, Peter Jeremy wrote: >>>> On 2011-Jun-29 19:54:44 +0200, Marius Strobl 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. >>>> OTOH, a V440 that has been running similar load for a similar period >>>> died overnight with: >>>> >>>> panic: uma_small_alloc: free page still has mappings! >>>> VNASSERT failed >>>> cpuid = 3 >>>> 0xfffff800079643c0: KDB: enter: panic >> ... >>>> 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). > That shouldn't make a difference; the later version only adds the > SPARC64 bits as you already noticed and adjusts the boot loader to > compile again. I made no changes to the existing parts apart from > fixing a comment. Besides I see no connection between fixing the > gross user TLB flushing and the below problem so far. > >>> 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=150: >> >> panic: uma_small_alloc: free page still has mappings! >> cpuid = 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=0x101db4 -- >> userland() at 0x405936c8 >> user trace: trap %o7=0x101db4 >> 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? > The VM and its interaction with the MD code are beyond me, I hope > Alan can chime in here. Reading through the code I see a possible > path which could lead to this though; tsb_tte_enter(), which is > the only place where TD_PV ever is set and also only in case of > managed pages, always calls pmap_cache_enter(), which together > with pmap_cache_remove() does the page color handling. In > pmap_remove_all() however, pmap_cache_remove() is only called for > managed pages, so for unmanaged pages we might miss the removal > of the mapping from the the color used. I've no idea though if > this actually is relevant, i.e. whether the VM ever calls > pmap_remove_all() for unmanaged pages. In HEAD, it does not. Other architectures have an assertion forbidding pmap_remove_all() calls on unmanaged pages. (Btw, I'm happy to add this assertion to sparc64's pmap if you like.) In older versions, calling pmap_remove_all() on unmanaged pages is expected to be a harmless NOP that's just a waste of cycles. With unmanaged pages, it is expected that pmap_remove() is used to destroy mappings before the page is freed. For years, vm_page_free{,_toq}() has asserted that the page has no managed mappings: if ((m->flags & PG_UNMANAGED) == 0) { vm_page_lock_assert(m, MA_OWNED); KASSERT(!pmap_page_is_mapped(m), ("vm_page_free_toq: freeing mapped page %p", m)); } As a debugging aid, you might want to add an additional check here on colors. > ... Tentatively I'd say it > doesn't, in which case the only solution I see is to exclude > unmanaged pages from the page color handling and caching, which > I don't know whether it's safe (besides impacting performance). > Unfortunately, with my gear I can't reproduce this. Could you > please try the below patch? I've no idea whether it's correct > but might give another datapoint. > > Marius > > Index: pmap.c > =================================================================== > --- pmap.c (revision 223705) > +++ pmap.c (working copy) > @@ -1382,21 +1385,21 @@ pmap_remove_all(vm_page_t m) > vm_page_lock_queues(); > for (tp = TAILQ_FIRST(&m->md.tte_list); tp != NULL; tp = tpn) { > tpn = TAILQ_NEXT(tp, tte_link); > - if ((tp->tte_data& TD_PV) == 0) > - continue; > pm = TTE_GET_PMAP(tp); > va = TTE_GET_VA(tp); > PMAP_LOCK(pm); > if ((tp->tte_data& TD_WIRED) != 0) > pm->pm_stats.wired_count--; > - if ((tp->tte_data& TD_REF) != 0) > - vm_page_flag_set(m, PG_REFERENCED); > - if ((tp->tte_data& TD_W) != 0) > - vm_page_dirty(m); > + if ((tp->tte_data& TD_PV) != 0) { > + if ((tp->tte_data& TD_REF) != 0) > + vm_page_flag_set(m, PG_REFERENCED); > + if ((tp->tte_data& TD_W) != 0) > + vm_page_dirty(m); > + pm->pm_stats.resident_count--; > + } > tp->tte_data&= ~TD_V; > tlb_page_demap(pm, va); > TAILQ_REMOVE(&m->md.tte_list, tp, tte_link); > - pm->pm_stats.resident_count--; > pmap_cache_remove(m, va); > TTE_ZERO(tp); > PMAP_UNLOCK(pm); >