From owner-freebsd-arm@FreeBSD.ORG Fri Dec 20 20:40:00 2013 Return-Path: Delivered-To: freebsd-arm@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9994FD46 for ; Fri, 20 Dec 2013 20:40:00 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 73DCD184A for ; Fri, 20 Dec 2013 20:40:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rBKKe0GS043152 for ; Fri, 20 Dec 2013 20:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rBKKe0hA043151; Fri, 20 Dec 2013 20:40:00 GMT (envelope-from gnats) Resent-Date: Fri, 20 Dec 2013 20:40:00 GMT Resent-Message-Id: <201312202040.rBKKe0hA043151@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Adrian Chadd Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 918C5CD6 for ; Fri, 20 Dec 2013 20:35:32 +0000 (UTC) Received: from oldred.freebsd.org (oldred.freebsd.org [IPv6:2001:1900:2254:206a::50:4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7DE72182D for ; Fri, 20 Dec 2013 20:35:32 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id rBKKZWm1008505 for ; Fri, 20 Dec 2013 20:35:32 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id rBKKZWfa008504; Fri, 20 Dec 2013 20:35:32 GMT (envelope-from nobody) Message-Id: <201312202035.rBKKZWfa008504@oldred.freebsd.org> Date: Fri, 20 Dec 2013 20:35:32 GMT From: Adrian Chadd To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: arm/185046: [armv6] issues with dhclient/sshd and jemalloc on raspberry pi and others X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 20:40:00 -0000 >Number: 185046 >Category: arm >Synopsis: [armv6] issues with dhclient/sshd and jemalloc on raspberry pi and others >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Dec 20 20:40:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release: >Organization: >Environment: >Description: There's been issues with sshd/dhclient being very upset. It was traced down to some jemalloc behaviour with processes that fork and do.. stuff. I'm not going to pretend to know exactly what the errnat behaviour was; it's likely lurking in the freebsd-arm mailing lists. It was bisected down to this commit: http://svnweb.freebsd.org/base/head/sys/arm/arm/pmap-v6.c?r1=251370&r2=252694&pathrev=252694 Reverting this apparently fixes the issue. >From the committer of the change: > I guess it should be some performance impact since we will need to > write all pages marked as RW to backing > storage on page-out. This is regardless of its actual dirty state (no > modified emulation). > But this was how it behaved earlier and nothing bad happened so it > might be worth to temporary revert it and > debug the problem without the negative influence on the users. After > proper fix we should apply it again. > > It's up to you. I have no objections to that (I have few other patches > that need to wait for pmap problems > resolution anyway like pmap_copy() + SP). >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: