From owner-freebsd-arm@freebsd.org Sun Nov 8 01:08:05 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B22FDA22930 for ; Sun, 8 Nov 2015 01:08:05 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id A005817B2; Sun, 8 Nov 2015 01:08:05 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 107291366; Sun, 8 Nov 2015 01:08:06 +0000 (UTC) Date: Sun, 8 Nov 2015 01:08:03 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: jilles@FreeBSD.org, imp@FreeBSD.org, ume@FreeBSD.org, cem@FreeBSD.org, bapt@FreeBSD.org, kp@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <299386945.39.1446944886023.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1998967916.35.1446937027116.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1998967916.35.1446937027116.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #1631 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 01:08:05 -0000 FreeBSD_HEAD_arm64 - Build #1631 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1631/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1631/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/1631/console Change summaries: 290522 by ume: Fix alignment of the short month names for CJK locales, as far as I could edit them. 290521 by kp: pf: Fix broken rule skip calculation r289932 accidentally broke the rule skip calculation. The address family argument to PF_ANEQ() is now important, and because it was set to 0 the macro always evaluated to false. This resulted in incorrect skip values, which in turn broke the rule evaluations. 290520 by cem: savecore(8): Be quiet unless the user asks for verbose Make savecore(8) more suitable for init-time scripts; be quiet by default. Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D3229 290519 by cem: hptmv(4): Fix broken sysctl(9) API assumptions Sponsored by: EMC / Isilon Storage Division 290518 by imp: Correct !FDT case with proper name. 290517 by bapt: Fix build of localedef(1) on arm where wchar_t is an unsigned int 290516 by imp: Implement the phy-mode property for ate and macb. If it is set to "rmii", use rmii mode for the MAC, otherwise use MII mode. The code is somewhat duplicated between these drivers for this. Also, add AT91RM9200 compatibility strings to the ate driver. In the future, there's a good chance that ate will lose the MACB support and only attach to the AT91RM9200 EMAC device since the macb works now that RMII support has been added to it. 290515 by jilles: periodic: Fix backwards compatibility for daily_status_security_* vars. Most daily_status_security_* variables in periodic.conf were changed to security_status_* in SVN r254974. The compatibility code for the old names did not work. PR: 204331 Submitted by: martin at lispworks.com MFC after: 1 week From owner-freebsd-arm@freebsd.org Sun Nov 8 08:49:58 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2CB2A29E04 for ; Sun, 8 Nov 2015 08:49:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E8EA13AB for ; Sun, 8 Nov 2015 08:49:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tA88nwts027721 for ; Sun, 8 Nov 2015 08:49:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 201760] AARCH64 clang crash building ftpcopy Date: Sun, 08 Nov 2015 08:49:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: Andrew@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 08:49:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201760 Andrew Turner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed CC| |Andrew@FreeBSD.org Resolution|--- |FIXED --- Comment #6 from Andrew Turner --- Fixed in Clang 3.7 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@freebsd.org Mon Nov 9 05:46:59 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A65BDA22EA3 for ; Mon, 9 Nov 2015 05:46:59 +0000 (UTC) (envelope-from vbotka@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DF871DF9 for ; Mon, 9 Nov 2015 05:46:59 +0000 (UTC) (envelope-from vbotka@gmail.com) Received: by wmnn186 with SMTP id n186so89535106wmn.1 for ; Sun, 08 Nov 2015 21:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-type; bh=Q+uZxxHxchVFFW7MBrtT5UcIFrHiQ1ZgwvEKQrj9csc=; b=zHf9vXnPBMmUXlkKFmy4iIfr69Wx6qLZjVfzjL2yYTyW7hM4bDj/LPgKfjfU82Gnu8 XBkGc4HXbCZ4hlKCTFGe8edZfUkQ0sGP73+IiUiA4RTqN4nqIXOOGA3AHNdeO6aFIT4l zoROoWjDgLKX9fZDcy6egowRnVXnx7KTbKXu15aQlopVGdNuHA3EZUNrYNRBs1t5ASKV WQ6orMyN0Flilv/T1aL/zq06s0VDvFVH9r0Ei0Pkpx5y+Gdc44yZYvWDDYj+s4kgkzHU QDSh6v3Otw7mPnbUcHfKVlrCnrhQbQBf0HuLP1r4kl1I366KMY7bcwzazmJ4r6Djnzb8 l+JQ== X-Received: by 10.28.218.83 with SMTP id r80mr25393885wmg.55.1447048017677; Sun, 08 Nov 2015 21:46:57 -0800 (PST) Received: from planb (ip-78-45-23-52.net.upcbroadband.cz. [78.45.23.52]) by smtp.gmail.com with ESMTPSA id ka10sm13394275wjc.30.2015.11.08.21.46.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Nov 2015 21:46:56 -0800 (PST) Date: Mon, 9 Nov 2015 06:46:54 +0100 From: Vladimir Botka To: Russell Haley Cc: freebsd-arm Subject: Re: Hummingboard with MicroSOM Dual (not dual lite) Message-ID: <20151109064654.3d125c42@planb> In-Reply-To: References: Organization: na X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Gh/xJ0VFesYz+sKijftFKE5"; protocol="application/pgp-signature" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 05:46:59 -0000 --Sig_/Gh/xJ0VFesYz+sKijftFKE5 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Russ, all, On Thu, 29 Oct 2015 22:55:01 -0700 Russell Haley wrote: > [...] > 2) Wi-fi. I found out that the SolidRun MicroSOM has a Broadcom BCM4330 > chip option (which I have). > http://wiki.solid-run.com/doku.php?id=3Dproducts:imx6:microsom:btwifi > Only the 2.4Ghz works acording to the website. Anyway, the driver list on > the current hardware page says BCM43xx is supported by the bwn driver. > https://www.freebsd.org/relnotes/CURRENT/hardware/support.html > https://www.freebsd.org/cgi/man.cgi?query=3Dbwn&sektion=3D4 > Again, do I need to add something to the fdt file? the bwn driver [1] supports PCI and CardBus devices only. BCM4330 is an SDIO adapter [4]. It doesn't work for me in FreeBSD 11.0 either [2]. Just for the record, Linux brcmfmac (Dual BSD/GPL) works with this adapter [3] in 2.4GHz (Uncomplete list of 5Ghz channels is reported, but don't work for me). Cheers, Vladimir [1] bwn -- Broadcom BCM43xx IEEE 802.11b/g wireless network driver https://www.freebsd.org/cgi/man.cgi?query=3Dbwn&sektion=3D4 [2] HummingBoard-i2eX FreeBSD-11.0 20151102-r290273.img (dmesg) http://pastebin.com/L8SMKqxa [3] HummingBoard-i2eX Armbian_4.5_Cubox-i_Ubuntu_trusty_3.14.54 (dmesg) http://pastebin.com/05xz0nm6 [4] HummingBoard-i2eX integrated WiFi/BT Broadcom 802.11abgn Wireless SDIO Adapter VID:PID: 0x02d0 : 0x4330 http://linuxwireless.org/en/users/Drivers/brcm80211/ http://www.datasheetwiki.com/entry/BCM4330-Datasheet-PDF The Broadcom BCM4330 single chip device provides the highest level of integration for a mobile or handheld wireless system, with integrated IEEE 802.11 a/b/g and single-stream 802.11 n (MAC/baseband/radio), Bluetooth 4.0+HS, and FM radio receiver and transmitter. It includes on-chip 2.4GHz and 5 GHz WLAN power amplifiers that meet the output power requirements for most handheld systems while permitting and an optional external power amplifier for higher output power applications, if required. /sys/class/net/wlan0/device -> ../../../mmc0:0001:1/ # cat /sys/class/net/wlan0/device/vendor=20 0x02d0 # cat /sys/class/net/wlan0/device/device=20 0x4330 -- --Sig_/Gh/xJ0VFesYz+sKijftFKE5 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWQDNPAAoJEJDRmRKO1E8BTWIH/0YHWNAuDpoHMUYXRY7N4nvP lfVGFVTQBUx005EiYfUETnrU+benYyHml+/YVm+WpGgL3x2LtdNlVbtm2RBuxzKQ t0gDqvJp4JwJHsj432b4cE2ldMyCBQ3HemWDAETyw26krezmQHRINNGdhIBaPfqm OoApY94Kcyzbsb3f9QRHs1GFBZE889ELyUTF5t1kWwgJMBz8+o/21R5Ke9QPtuaw nLJ+QrIZ0keCdMoFgWDJKFWk/Oyxa/qG4NEFw6fL9Gu18VrzTN0sNCi5JpelNrGE 92fJFI/Itvat1VhC4e/hm2vU/GMn4OK6Dy/JFuMwciHX2YASEBpbCK6uqIxfV7g= =WY9g -----END PGP SIGNATURE----- --Sig_/Gh/xJ0VFesYz+sKijftFKE5-- From owner-freebsd-arm@freebsd.org Mon Nov 9 08:05:06 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4B44A29B35 for ; Mon, 9 Nov 2015 08:05:06 +0000 (UTC) (envelope-from gabdelmalik@uniridge.com.au) Received: from mail.uniridge.com.au (ec2-54-206-17-100.ap-southeast-2.compute.amazonaws.com [54.206.17.100]) by mx1.freebsd.org (Postfix) with ESMTP id 637DD1038 for ; Mon, 9 Nov 2015 08:05:05 +0000 (UTC) (envelope-from gabdelmalik@uniridge.com.au) Received: from [192.168.11.50] (ip-192-168-11-50.ap-southeast-2.compute.internal [192.168.11.50]) by mail.uniridge.com.au (Postfix) with ESMTP id 6D84F4A6C; Mon, 9 Nov 2015 19:04:58 +1100 (EST) Subject: Re: atomic_testandset_int seems unimplemented To: Konstantin Belousov References: <563DA3E8.2060802@uniridge.com.au> <20151107113011.GW2257@kib.kiev.ua> <563DE43D.7030107@uniridge.com.au> Cc: freebsd-arm@freebsd.org From: George Abdelmalik Organization: Uniridge Pty Ltd Message-ID: <564053A9.3000604@uniridge.com.au> Date: Mon, 9 Nov 2015 19:04:57 +1100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563DE43D.7030107@uniridge.com.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 08:05:07 -0000 On 07/11/15 22:45, George Abdelmalik wrote: > On 07/11/15 22:30, Konstantin Belousov wrote: >> On Sat, Nov 07, 2015 at 06:10:32PM +1100, George Abdelmalik wrote: >>> Hi, >>> >>> My reading of atomic(9) implies that the atomic_testandset_* family of >>> functions should be present >>> on the arm architecture, however I don't see any evidence of it in any >>> of the expected locations, >>> ./sys/arm/include/atomic-v4.h >>> ./sys/arm/include/atomic-v6.h >>> ./sys/arm/include/atomic.h >>> >>> Is there some impediment within the architecture which doesn't make >>> that >>> semantic possible or is >>> it just that there is no in-tree consumer yet? >> No consumers, apparently. testandset has somewhat rarely needed >> semantic, >> and readandclear semantic is not complimentary, to confuse the users >> even >> more. >> >>> Any thoughts on this matter would be appreciated, or better yet a >>> possible implementation - sadly for >>> me assembly is not my strength. >> Below is the patch for ARMv6. I did not tested the _64 implementation, >> and I also doubt that we run in big endian mode for ARMv6 at all. >> Do you also need an implementation for ARMv5 ? > No I don't need ARMv5, my target is a Xilinx Zynq SOC which is > ARMv7 that we will only run in little endian mode. > > Thanks for the below patch. I will try it out tomorrow and report > back my experience. > > George. >> >> diff --git a/sys/arm/include/atomic-v6.h b/sys/arm/include/atomic-v6.h >> index d22f7e1..9ee8043 100644 >> --- a/sys/arm/include/atomic-v6.h >> +++ b/sys/arm/include/atomic-v6.h >> @@ -593,6 +593,60 @@ atomic_store_rel_long(volatile u_long *p, u_long v) >> *p = v; >> } >> +static __inline int >> +atomic_testandset_32(volatile uint32_t *p, u_int v) >> +{ >> + uint32_t tmp, tmp2, res, mask; >> + >> + mask = 1u << (v & 0x1f); >> + tmp = tmp2 = 0; >> + __asm __volatile( >> + "1: ldrex %0, [%3] \n" >> + " orr %1, %0, %4 \n" >> + " strex %2, %1, [%3] \n" >> + " cmp %2, #0 \n" >> + " it ne \n" >> + " bne 1b \n" >> + : "=&r" (res), "=&r" (tmp), "=&r" (tmp2), "+&r" (p) >> + : "r" (mask) >> + : "cc", "memory"); >> + return ((res & mask) != 0); >> +} >> + >> +static __inline int >> +atomic_testandset_int(volatile u_int *p, u_int v) >> +{ >> + >> + return (atomic_testandset_32((volatile uint32_t *)p, v)); >> +} >> + >> +static __inline int >> +atomic_testandset_long(volatile u_long *p, u_int v) >> +{ >> + >> + return (atomic_testandset_32((volatile uint32_t *)p, v)); >> +} >> + >> +static __inline int >> +atomic_testandset_64(volatile uint64_t *p, u_int v) >> +{ >> + volatile uint32_t *p32; >> + >> + p32 = (volatile uint32_t *)p; >> +#if BYTE_ORDER == LITTLE_ENDIAN >> + if (v >= 32) { >> + v &= 0x1f; >> + p32++; >> + } >> +#else >> + if (v >= 32) >> + v &= 0x1f; >> + else >> + p32++; >> +#endif >> + return (atomic_testandset_32(p32, v)); >> +} >> + >> #undef ATOMIC_ACQ_REL >> #undef ATOMIC_ACQ_REL_LONG > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Hi Konstantin, Thanks again for this. I've not yet run it on my Zedboard, due to unrelated issues of my own making, although it compiles fine into my project. It would be great to see it in the tree whenever you get the chance. Kindest regards, George. -- George Abdelmalik Director Principal Software Engineer Uniridge Pty Ltd http://www.uniridge.com.au/ From owner-freebsd-arm@freebsd.org Mon Nov 9 12:54:44 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 416C2A2A226 for ; Mon, 9 Nov 2015 12:54:44 +0000 (UTC) (envelope-from vbotka@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCAB01A92 for ; Mon, 9 Nov 2015 12:54:43 +0000 (UTC) (envelope-from vbotka@gmail.com) Received: by wmww144 with SMTP id w144so74862287wmw.1 for ; Mon, 09 Nov 2015 04:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:organization:mime-version :content-type; bh=0GXY3abjUw4fvtWqIJjI2iIcMi+8eEi2qZkKmxsyT50=; b=y0s3UDWXy67cffe6OXef+ggVRcrb+qRAqy4h9/mYt3A/2iTXLdPEIjTLt2XIWa5gX8 S+ITQ74GRO368RhCZnYbC3I42IZDGI+B5AtYvkIr8r9NVMaHTd0RDRbkTupIRzBCvvkS y921CUBOLEiHHCs/7ElZePquqvaDEWGQwE3CxrZ8WpoNS7DqAtHEjyE6reP8lid2kOpo iBfutC3sTPXzGWYh5M+DCEbVE0vw9NZLeWRq/wqk+mVn64W8LgbmHrZQ41RNp/dgV6uu 07Hal/YWOhcpDaI56BGTLpt9ad/wJOAXwrYjoR+9m9J3lvvT97NVGXyV0d3zR3g1O+8m p74A== X-Received: by 10.194.23.33 with SMTP id j1mr34053790wjf.4.1447073681543; Mon, 09 Nov 2015 04:54:41 -0800 (PST) Received: from planb (ip-78-45-23-52.net.upcbroadband.cz. [78.45.23.52]) by smtp.gmail.com with ESMTPSA id bf8sm15310875wjc.22.2015.11.09.04.54.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2015 04:54:40 -0800 (PST) Date: Mon, 9 Nov 2015 13:54:38 +0100 From: Vladimir Botka To: freebsd-arm Subject: wifi interface missing in 11.0 r290273 Hummingboard Message-ID: <20151109135438.7f429f41@planb> Organization: na X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/wfuQrpBN=WZj+NhzLRmXq6N"; protocol="application/pgp-signature" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:54:44 -0000 --Sig_/wfuQrpBN=WZj+NhzLRmXq6N Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, would it be possible to help me figure out why I'm missing the "run" interface in 11.0-CURRENT arm r290273 [1] with RT5592 adapter? I can see the interface run0 in 10.2 i386 [4-6], but run0 in missing in 11.0 arm [1-3]. The same behavior can be observed with RT5390. Cheers, Vladimir [1] # uname -a FreeBSD imx6 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r290273: Tue Nov 3 02:54:03 UTC 2015 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/IMX6 arm [2] Nov 9 12:41:12 imx6 kernel: ugen1.3: at usbus1 (disconnected) Nov 9 12:41:13 imx6 kernel: run0: at uhub2, port 1, addr 3 (disconnected)=20 Nov 9 12:41:20 imx6 kernel: ugen1.3: at usbus1 Nov 9 12:41:21 imx6 kernel: run0: <1.0> on usbus1 Nov 9 12:41:21 imx6 kernel: run0: MAC/BBP RT5592 (rev 0x0222), RF RT5592 (MIMO 2T2R), address 64:70:02:27:d6:42 [3] # ifconfig -a ffec0: flags=3D8843 metric 0 mtu 1500 options=3D80008 ether d0:63:00:00:00:00 inet 192.168.1.40 netmask 0xffffff00 broadcast 192.168.1.255=20 media: Ethernet autoselect (100baseTX ) status: active nd6 options=3D29 lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 inet 127.0.0.1 netmask 0xff000000=20 groups: lo=20 nd6 options=3D21 [4] # uname -a FreeBSD vlado-srv 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 19:31:38 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 [5] Nov 9 13:39:48 vlado-srv kernel: ugen1.3: at usbus1 Nov 9 13:39:48 vlado-srv kernel: run0: <1.0> on usbus1 Nov 9 13:39:48 vlado-srv kernel: run0: MAC/BBP RT5592 (rev 0x0222), RF RT5592 (MIMO 2T2R), address 64:70:02:27:d6:42=20 Nov 9 13:39:48 vlado-srv devd: Executing '/etc/pccard_ether run0 start'=20 Nov 9 13:39:48 vlado-srv devd: Executing '/etc/pccard_ether run0 start'=20 Nov 9 13:39:56 vlado-srv kernel: run0: firmware RT3071 ver. 0.33 loaded [6] # ifconfig run0 run0: flags=3D8802 metric 0 mtu 2290 ether 64:70:02:27:d6:42 nd6 options=3D29 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier -- --Sig_/wfuQrpBN=WZj+NhzLRmXq6N Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWQJePAAoJEJDRmRKO1E8BL54H/iiatUxJAHRxKSjlqJC8Rwli K1YDKykUwALquQQ7ChtiWPph682jlNUEcAcKDnKhBYZDuPREfLYYpWkJIq7LJSWS pNA2QJK47FAwYXtAHRJA0X27OfTwXv4A5qx95hf2dBMtL0mf9dlTMaB/1bBfdWIY sBZaHZODH2ECDTsnEQEL61gGBRXO4K7Yz35a1LOsIqgcHOR9UZ+Io6LKUz/PZajq zQnLdxn0hqHOzzmlezmZKg3SV8uSl9fY2LAR8Ivamhe6Gsko/Ioab9NnktrSce7h i7Z7hQWrSXHBu8fs6RmX0w2o431yp9HUrCTc3wcbLXB1fnzUKtVPtGCFMpiOsvo= =sC9K -----END PGP SIGNATURE----- --Sig_/wfuQrpBN=WZj+NhzLRmXq6N-- From owner-freebsd-arm@freebsd.org Mon Nov 9 15:55:04 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A634BA29789 for ; Mon, 9 Nov 2015 15:55:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E5EA1443 for ; Mon, 9 Nov 2015 15:55:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igcph11 with SMTP id ph11so29894711igc.1 for ; Mon, 09 Nov 2015 07:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4fKnT1ETow1jAwkWBC3tQyeNz5S/+p+pPxUet0Z+cus=; b=HU4j65ZZBE09S8S0NnNXp3nfOLIrYbjppTf1flPbhsH3m1dy7vSrBkRUa/V/j0CRNX XJsoj1wy8pi1/GIoeypx+I2xcJjWaa8VAzfLNTXum2bBaUGDfsScT9YQQXhuj6CiZU7t 32si0GrnX3ZAMmD2/DOhGxJmOS9RwN+R72FrW+Tq/aoTH9x3duZg8G7QFiqEFUtkdof4 ijDhWDewohakFX74+0jtw6l6JUUjiJX4JYkND/RVn9H6TWC2PfnIQh2tMHtXAVFNxBeE 4QDGgrTLLWPIzSsNpp+GRyAIIvLzraT7cH2s3bMjhjVbkq4c5Y0NGTAfyQDxvz7ZJqva FOjA== MIME-Version: 1.0 X-Received: by 10.50.73.228 with SMTP id o4mr21745161igv.37.1447084503977; Mon, 09 Nov 2015 07:55:03 -0800 (PST) Received: by 10.36.217.196 with HTTP; Mon, 9 Nov 2015 07:55:03 -0800 (PST) In-Reply-To: <20151109135438.7f429f41@planb> References: <20151109135438.7f429f41@planb> Date: Mon, 9 Nov 2015 07:55:03 -0800 Message-ID: Subject: Re: wifi interface missing in 11.0 r290273 Hummingboard From: Adrian Chadd To: Vladimir Botka Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 15:55:04 -0000 it's there: sysctl net.wlan.devices .. the top-level device was removed in freebsd-11.0. you can still clone it -eg "ifconfig wlan0 create wlandev run0" -a On 9 November 2015 at 04:54, Vladimir Botka wrote: > Hello, > > would it be possible to help me figure out why I'm missing the "run" > interface in 11.0-CURRENT arm r290273 [1] with RT5592 adapter? > > I can see the interface run0 in 10.2 i386 [4-6], but run0 in missing in > 11.0 arm [1-3]. The same behavior can be observed with RT5390. > > Cheers, > Vladimir > > [1] > # uname -a > FreeBSD imx6 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r290273: Tue Nov 3 > 02:54:03 UTC 2015 > root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/IMX6 arm > > [2] > Nov 9 12:41:12 imx6 kernel: ugen1.3: at usbus1 (disconnected) > Nov 9 12:41:13 imx6 kernel: run0: at uhub2, port 1, addr 3 > (disconnected) > Nov 9 12:41:20 imx6 kernel: ugen1.3: at usbus1 > Nov 9 12:41:21 imx6 kernel: run0: <1.0> on usbus1 > Nov 9 12:41:21 imx6 kernel: run0: MAC/BBP RT5592 (rev 0x0222), RF > RT5592 (MIMO 2T2R), address 64:70:02:27:d6:42 > > [3] > # ifconfig -a > ffec0: flags=8843 metric 0 mtu > 1500 options=80008 > ether d0:63:00:00:00:00 > inet 192.168.1.40 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=21 > > [4] > # uname -a > FreeBSD vlado-srv 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug > 12 19:31:38 UTC 2015 > root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 > > [5] > Nov 9 13:39:48 vlado-srv kernel: ugen1.3: at usbus1 > Nov 9 13:39:48 vlado-srv kernel: run0: <1.0> on usbus1 > Nov 9 13:39:48 vlado-srv kernel: run0: MAC/BBP RT5592 (rev 0x0222), RF > RT5592 (MIMO 2T2R), address 64:70:02:27:d6:42 > Nov 9 13:39:48 vlado-srv devd: Executing '/etc/pccard_ether run0 > start' > Nov 9 13:39:48 vlado-srv devd: Executing '/etc/pccard_ether run0 > start' > Nov 9 13:39:56 vlado-srv kernel: run0: firmware RT3071 ver. 0.33 loaded > > [6] > # ifconfig run0 > run0: flags=8802 metric 0 mtu 2290 > ether 64:70:02:27:d6:42 > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) > status: no carrier > -- From owner-freebsd-arm@freebsd.org Mon Nov 9 17:01:07 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44923A2A9A6 for ; Mon, 9 Nov 2015 17:01:07 +0000 (UTC) (envelope-from vbotka@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD3101E17 for ; Mon, 9 Nov 2015 17:01:06 +0000 (UTC) (envelope-from vbotka@gmail.com) Received: by wmnn186 with SMTP id n186so115247592wmn.1 for ; Mon, 09 Nov 2015 09:01:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-type; bh=qKVr7yxV7BbPLIdZdPovc2XLNdZ7vW/Pg0RAVrYvayc=; b=o6gIuJJCstTZ5F41R3+tI86oHFARLr/djURMLraJJ1jFN7nTDWbvRPNN7jmctoYbKX Y4I63BwIEYvqer9FNa1kZmZtvAwofi1wG0zRPbA6vTFRzLsPsv4deq+sdhHyjLHrBHhj /S2if5Qwyy+htqnT2HtwW/q29uAL1CgENgTenx2MlxrXGNEg3TDGZmZlM2P+gaFDk+Gv 0/qs6y6WB2lrHkgVVFWXedU80H4fhLheTxw2+qwW94Hfk7T8gM23Lhvri3zM0LFn/LIG 0t7JUErRFWILz5emt30WYs02JCGQyZBjElThmudCqdWqF6y2Od7LiRsAnmQSWt7oQXHu 2taQ== X-Received: by 10.28.215.205 with SMTP id o196mr28123342wmg.95.1447088465372; Mon, 09 Nov 2015 09:01:05 -0800 (PST) Received: from planb (ip-78-45-23-52.net.upcbroadband.cz. [78.45.23.52]) by smtp.gmail.com with ESMTPSA id j4sm15234004wmg.18.2015.11.09.09.01.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Nov 2015 09:01:04 -0800 (PST) Date: Mon, 9 Nov 2015 18:01:02 +0100 From: Vladimir Botka To: Adrian Chadd Cc: freebsd-arm Subject: Re: wifi interface missing in 11.0 r290273 Hummingboard Message-ID: <20151109180102.72fff10b@planb> In-Reply-To: References: <20151109135438.7f429f41@planb> Organization: na X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Fqg1vyi4NAFusdh2R97GIRy"; protocol="application/pgp-signature" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 17:01:07 -0000 --Sig_/Fqg1vyi4NAFusdh2R97GIRy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Thank you very much. Yes, the interface run0 is there. I was able to configure a working wlan0 as you described. Cheers, Vladimir On Mon, 9 Nov 2015 07:55:03 -0800 Adrian Chadd wrote: > it's there: > sysctl net.wlan.devices > .. the top-level device was removed in freebsd-11.0. you can still > clone it -eg "ifconfig wlan0 create wlandev run0" > -a >=20 > On 9 November 2015 at 04:54, Vladimir Botka wrote: > > Hello, > > would it be possible to help me figure out why I'm missing the "run" > > interface in 11.0-CURRENT arm r290273 [1] with RT5592 adapter? --Sig_/Fqg1vyi4NAFusdh2R97GIRy Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWQNFOAAoJEJDRmRKO1E8BqMIH/3CUCYium/waXsaXJj3WZvdN yI5LBaz5Jhk6d/VqNvUCBGJRASvOd1sU9eQ6owSmKhUY1VO5zGT+qx47pWVUMqND 2hyzrd/s3iPHQqoT7s0WM1MGCOFShn5LfocHccODUj3pLUqkDhD90LDpyoDGO85c eGjW+2/AdjUTgpTvrNefLcilRfJ4dYLuAOvXsH65TOLCB8RdiOawsvHS1RqcooeS ZmqwOiFrK72/jsITfNV4ZmOl+c5PlKtlUhTX1H+x23EQAN+yA8/KazokamdSLJ2P 83s2F3+7WLS4Qo7iwaP0rtV/zRkRHtfnhAPtkC2uTOTGyqbZ/0WXGq2kf9BMGEs= =jxuA -----END PGP SIGNATURE----- --Sig_/Fqg1vyi4NAFusdh2R97GIRy-- From owner-freebsd-arm@freebsd.org Mon Nov 9 17:21:06 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 112C9A2A0CE for ; Mon, 9 Nov 2015 17:21:06 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 883C91AF5 for ; Mon, 9 Nov 2015 17:21:04 +0000 (UTC) (envelope-from wsk@gddsn.org.cn) Received: by gddsn.org.cn (Postfix, from userid 65534) id 905B02E074; Tue, 10 Nov 2015 01:13:37 +0800 (CST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on gddsn.org.cn X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=failed autolearn_force=no version=3.4.0 Received: from lp.gddsn.org.cn (unknown [10.44.8.173]) (Authenticated sender: wsk) by gddsn.org.cn (Postfix) with ESMTPA id C7DC62E028 for ; Tue, 10 Nov 2015 01:13:34 +0800 (CST) To: freebsd-arm@freebsd.org From: Wu ShuKun Subject: pkg version is outdated with 11.0 r290273 on official's repo X-Enigmail-Draft-Status: N1110 Message-ID: <5640D43E.8090004@gddsn.org.cn> Date: Tue, 10 Nov 2015 01:13:34 +0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 17:21:06 -0000 greeting OpenSSL on head has been updated with r290273, but pkg on repo did not updated yet. root@beaglebone:/usr/lib # pkg -v Shared object "libssl.so.7" not found, required by "pkg" root@beaglebone:/usr/lib # ls -l /usr/lib/libssl.so* lrwxr-xr-x 1 root wheel 11 Nov 3 08:23 /usr/lib/libssl.so -> libssl.so.8 -r--r--r-- 1 root wheel 371776 Nov 3 08:23 /usr/lib/libssl.so.8 root@beaglebone:/usr/lib # ls -l /usr/lib/libcrypto.so* lrwxr-xr-x 1 root wheel 24 Nov 3 08:23 /usr/lib/libcrypto.so -> ../../lib/libcrypto.so.8 root@beaglebone:/usr/lib # ldd /usr/local/lib/libpkg.so /usr/local/lib/libpkg.so: libutil.so.9 => /lib/libutil.so.9 (0x20050000) libssl.so.7 => not found (0) libcrypto.so.7 => not found (0) libm.so.5 => /lib/libm.so.5 (0x2006a000) libelf.so.2 => /usr/lib/libelf.so.2 (0x20090000) libjail.so.1 => /lib/libjail.so.1 (0x200b0000) libarchive.so.6 => /usr/lib/libarchive.so.6 (0x2028d000) libz.so.6 => /lib/libz.so.6 (0x200bd000) libbz2.so.4 => /usr/lib/libbz2.so.4 (0x200da000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x20337000) libc.so.7 => /lib/libc.so.7 (0x20100000) libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x20365000) libcrypto.so.8 => /lib/libcrypto.so.8 (0x20b00000) libthr.so.3 => /lib/libthr.so.3 (0x20390000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x203bc000) From owner-freebsd-arm@freebsd.org Tue Nov 10 02:19:08 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6AB5A2A937 for ; Tue, 10 Nov 2015 02:19:08 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D28A1920 for ; Tue, 10 Nov 2015 02:19:08 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by igl9 with SMTP id 9so44542324igl.0 for ; Mon, 09 Nov 2015 18:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=9BVJuoOl3q0hX0M8y6SkqzHY01zspctLTRcbkxuLl14=; b=c6ASzrICIHlOm3a44+gHOX1hqLqEyXPi0sOFUdWsCJ4SAXePFFVJPIJE4as0AwOpbc KbGqIqjhBp3DconPld3knalxQH3ROQ2Ht/41KBECuvuYsYsq7doXhZmjZSm/DoDJlMC4 WEbpcjscCgtrUwSUBDXD/OqeEZZDZgkJqB7BFlY30h97biGFOWeUTgx3QqpD7z1c1BtV buJlv39Mr4pe2tzNRRbfYnt25mKhDbjX6IuxQrKmf8hXOTT1ITVIAmWzcGywKDGHB5Sl CfA90jaGkuFFnWJh4AWMwp3ueoRjTNC2tC82ez6xasyy81f6k6rvpC6rrey59hUKH0IS 6G8w== X-Received: by 10.50.129.98 with SMTP id nv2mr1363477igb.97.1447121947889; Mon, 09 Nov 2015 18:19:07 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.169.85 with HTTP; Mon, 9 Nov 2015 18:18:48 -0800 (PST) In-Reply-To: References: <20151106094714.5e8632c6@bender.Home> From: Ed Maste Date: Tue, 10 Nov 2015 02:18:48 +0000 X-Google-Sender-Auth: HIUH1hntXe8U_mJ6v3H1OpvfpD4 Message-ID: Subject: Re: HEADS UP: Cavium ThunderX support in the tree To: Zbigniew Bodek Cc: Andrew Turner , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 02:19:08 -0000 On 6 November 2015 at 11:23, Zbigniew Bodek wrote: > If you watched the youtube demo you should have seen that at first > there are no interfaces in ifconfig and then I do iovctl and they > appear. The command in the video is: # iovctl -C -f /etc/iovctl.conf but as far as I can tell the contents of /etc/iovctl.conf aren't shown. Can you post them here? From owner-freebsd-arm@freebsd.org Tue Nov 10 08:45:05 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EE37A2BCCE for ; Tue, 10 Nov 2015 08:45:05 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA2E11140 for ; Tue, 10 Nov 2015 08:45:04 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: by lfs39 with SMTP id 39so81332460lfs.3 for ; Tue, 10 Nov 2015 00:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YYefJoUPd1aPQKpcBWecEq0Ngs7oZHNaqtL8Ik0pUUw=; b=OTP515n9fW6P4A9NSDOuF8Q4XnNbYxKYZm/iOk6X+86hVjO+vu0V+vlxp2lIWsJibU jOh4Su1L5aESN6OqNG+DyqctoaxvS77keN+5nx7ywtu0pRogAPE8hy9o/yEpegd8DqXp GQTGaICMazXuUMfwFHcHWmPwvvHBzx+4TE47KgXWE78zLmEHsSJPcENGU3gV8NiPjvtN WtmPC3ANazXdNkY0uGByR2eJ+CwdzshF3+uTLFc8UzYK3hh76ZDyF97g0B931+NIWqV5 zTlUxSMfGk6F4ULSd0bJppIUY2pBC7DnVumaRwTu3jX1ObohbbCvwCBG/tAZHTKfB/MG iAwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YYefJoUPd1aPQKpcBWecEq0Ngs7oZHNaqtL8Ik0pUUw=; b=A1xtgKSDRuDubzlLXwHcuwOejhfQSOdR2hbkKnXqZL23ffapJqck5/mX6IeTsYZ3+Y XSlivGcswkYOLKgevlnX/CgkENuq8B96zzvtaWz2EmmGONuzsnGibk6G1Q11l4baSzrw ZunB/AqxOGfuB6Cv6El28HqD6gP+RwNwFAXqN5KM1CMi2RG6exzhunllL0zV+vBcER8M SUj2EzP9xIFeEfZyhv3kfTqif+kQdpbpzxZDaDIxqLk6dqWR8+C/QzuMbHoGoMqvV42S awq83tD8g/lJXI1ELa6RE5OsD7lmJxbRmCFIz4AkoI2N8yvyUVuAGSCr5RR5EWAbvtaS cIZQ== X-Gm-Message-State: ALoCoQkjA/bA/2S4q419m/57PhroKi0LMCsogfniLys8xzhzWSyy0BGZJXHIwA/VV4fe/mQ0TtVS X-Received: by 10.25.24.193 with SMTP id 62mr990125lfy.84.1447145102788; Tue, 10 Nov 2015 00:45:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.91.20 with HTTP; Tue, 10 Nov 2015 00:44:42 -0800 (PST) In-Reply-To: References: <20151106094714.5e8632c6@bender.Home> From: Zbigniew Bodek Date: Tue, 10 Nov 2015 09:44:42 +0100 Message-ID: Subject: Re: HEADS UP: Cavium ThunderX support in the tree To: Ed Maste Cc: Andrew Turner , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 08:45:05 -0000 2015-11-10 3:18 GMT+01:00 Ed Maste : > On 6 November 2015 at 11:23, Zbigniew Bodek wrote: >> If you watched the youtube demo you should have seen that at first >> there are no interfaces in ifconfig and then I do iovctl and they >> appear. > > The command in the video is: > # iovctl -C -f /etc/iovctl.conf > but as far as I can tell the contents of /etc/iovctl.conf aren't > shown. Can you post them here? Hello Ed, The most basic file example for 3 VNICs: PF { device : "vnicpf0"; num_vfs : 3; } You can of course set up MAC address too: VF-0 { mac-addr : "62:73:64:2b:88:c9"; } Best regards zbb From owner-freebsd-arm@freebsd.org Tue Nov 10 12:10:25 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81C9AA2A3ED for ; Tue, 10 Nov 2015 12:10:25 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 616AB1092 for ; Tue, 10 Nov 2015 12:10:25 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: by mailman.ysv.freebsd.org (Postfix) id 60E2EA2A3EC; Tue, 10 Nov 2015 12:10:25 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60754A2A3EB for ; Tue, 10 Nov 2015 12:10:25 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.0x20.net", Issuer "mail.0x20.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F400108E for ; Tue, 10 Nov 2015 12:10:24 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 57D656DF91B; Tue, 10 Nov 2015 13:10:22 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id tAACALjm028421; Tue, 10 Nov 2015 13:10:21 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id tAACAKub028123; Tue, 10 Nov 2015 13:10:20 +0100 (CET) (envelope-from lars) Date: Tue, 10 Nov 2015 13:10:20 +0100 From: Lars Engels To: Hans Petter Selasky Cc: arm@freebsd.org Subject: Re: [Banana Pi] Fatal kernel mode data abort: 'Alignment Fault' on read Message-ID: <20151110121020.GD27296@e-new.0x20.net> References: <20151105104859.GQ66179@e-new.0x20.net> <563B372E.20607@selasky.org> <20151105120950.GR66179@e-new.0x20.net> <563B4813.1060403@selasky.org> <20151105153423.GS66179@e-new.0x20.net> <563BAA36.60208@selasky.org> <20151105204209.GT66179@e-new.0x20.net> <563CA59F.40504@selasky.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mJm6k4Vb/yFcL9ZU" Content-Disposition: inline In-Reply-To: <563CA59F.40504@selasky.org> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 12:10:25 -0000 --mJm6k4Vb/yFcL9ZU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 06, 2015 at 02:05:35PM +0100, Hans Petter Selasky wrote: > Hi Lars, >=20 > > > > I think I could build an image with crochet, so if you have a patch, I > > can try. > > >=20 > I believe I've found the issue: >=20 > https://svnweb.freebsd.org/changeset/base/290441 >=20 > I've built you a default A20 kernel with kernel modules at: >=20 > http://home.selasky.org:8192/privat/A20.tar.gz >=20 > cd / > cat -zxvf A20.tar.gz >=20 > Can you test it? >=20 Thanks! With your kernel, I don't get a panic! --mJm6k4Vb/yFcL9ZU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJWQd6sXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1ts/kIAJZHzXdot1jJe/jjswp6aEEj VtvqyPIkNd7uQvSDzwSJ3Ss4fNgrz88toNgUd0K0Jf0q84AhAcSdEO41eueyMLlj w+ONeewRnXPiXJzbEOn+LXKg7aq9qLvb3Q/+BBHKUWJvHpKmUsSjnPtxiCbJn9+F c0YaQDo1xFo/uKLCFMqNsPs1dkezTch9SnEw3kQeQbMhgBPJoA1BOXvhN6rVyGHI BcqJ6E3w3wx+FvXqPLdRrV13JxPbStpucwuSIZIvbNMW/5rYMJn5XKYBtAtznohr 7EC0q6xSxd20CfNuvVNCsaYJnBiOylLkIa1OTIOyq1NriauO9xu7DPAeuTmN5W0= =GqZr -----END PGP SIGNATURE----- --mJm6k4Vb/yFcL9ZU-- From owner-freebsd-arm@freebsd.org Thu Nov 12 05:22:15 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F15A8A29BF7 for ; Thu, 12 Nov 2015 05:22:15 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF7FF1D2C for ; Thu, 12 Nov 2015 05:22:15 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by vkbk63 with SMTP id k63so4298270vkb.0 for ; Wed, 11 Nov 2015 21:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=q5JafuwO005VgKqeN913fFL7s5SMqXuDmjdiFqNXyN8=; b=wLAAtDqOVVrI+7ZVk6/JtAmtZ/FSBimDnj3OIy43g845SZLakEwbz6Oj5HVW6K0hqg nYyV9xg2t8z/E8CGCG6CqoYbEkIjkYSvtKUmTyp1C+B+dVdnOuhsArVwqJb9K2lK9gIo X6XTmGXebmBZ3zyUUlExXlt/VtROBnNdHFsy0wjL1xZEiHvYBzcqKsN/xRMCmQbO3VuI 6smIwFd/CJZvjmVkPloPvZkK9kFymj+9y0bRpxp8Tf3Sy736OwfC7b17VeeIh0SK8OEW iRgWxzIZNeuH+MaDqj+AxlnFrj0BanypNqrUWHFwQ7UNzdMVS8J6dePybEt9TJfR71El lSzg== MIME-Version: 1.0 X-Received: by 10.31.15.149 with SMTP id 143mr1406866vkp.107.1447305734506; Wed, 11 Nov 2015 21:22:14 -0800 (PST) Received: by 10.31.66.9 with HTTP; Wed, 11 Nov 2015 21:22:14 -0800 (PST) Date: Wed, 11 Nov 2015 21:22:14 -0800 Message-ID: Subject: Hummingboard SATA From: Russell Haley To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 05:22:16 -0000 Hello again, I have started looking at SATA support in FreeBSD by first reading the man pages and then examining the code. The Joseph Kong book is helping considerably to understand the structures. I see that there are three drivers in play: ahci, ada and ata. Man indicates that ahci takes precedence in driver selection. *Is that the driver for Arm and the Hummingboard?* What I can't seem to find is any direction on getting a debugger hooked up to driver code. Do I use gdb somehow, or do I use the kernel debugger? I'm going back over the Developers handbook again. I also don't understand how to boot with the -d option. When is this entered? I have used the sysctl to enter the debugger and poked around but it doesn't mean much yet. sysctl debug.kdb.enter=1 Thanks, Russ From owner-freebsd-arm@freebsd.org Thu Nov 12 05:39:41 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C47F9A29E01 for ; Thu, 12 Nov 2015 05:39:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AF4E11AC for ; Thu, 12 Nov 2015 05:39:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkcl124 with SMTP id l124so20058698qkc.3 for ; Wed, 11 Nov 2015 21:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp_com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uaSqfqbY84/Pc9pJrA5X2yfFodX66LZ0CmSfh+2yC34=; b=vUIWwEl9UA+X9i+cGUaZVTHOuO3QAB9yoJw/skC1vVWOm/9CEE4t6X/+RMR23wd9ly P4NVR8nLumGrNP0HSVgb0237HSLM4FzssStnoah3PJnBvC7qqoqAgWWnbZeEirR9J+po tFONOUgO1i4quysL932CUXyNoSiYlEwIy22I7tDjSBbY8g4ifp0G71YYjFcKoSB+myMR nHoJwX5gPQ280XljMcbFYFk3+FV6L2piqKZf4AV9tXRQ5kd2VNkZ3ztOQd111kveewY5 KP8Bhji8TAsJFc8b2ByGaXL7cKZz23PNtsUULQxhJarwd4IkKt3FeXKrlaiYReibJSJW DJJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uaSqfqbY84/Pc9pJrA5X2yfFodX66LZ0CmSfh+2yC34=; b=c2xH2YldKGrBoepaLbQZUNdTa3tUYkmlx/SUwjf/liUi8Yqe3Pasmcp8eN8rj+3AYr HHINHTdMsDSWrx5ovgi9NK4RZVO99PbrBOACIfNrcjxCLVzQw0IuiqCRAZfk1Gz8pk12 3GaeCz05lg0Mv06iT/Spp6DYWbUVtA/AU51AQ3yFZfuJLgHDNequmOmQLcpQojFKXrAB z7F50my3MQTh0d1TXJKfqNhNbyMTEnNr3AJNB/83flBf+OZd+WY/kypZTaO9E2Tt+Feg JKv+R8fDTwMMms+32jncm6WJKAt9tqoptvQ3hu6WV+PMlkBYbstcC/la+WmZ1oN9uU6J J69g== X-Gm-Message-State: ALoCoQlHJd00B8fq7gGJd6ZE6TyOBmQlwYnPk1YCkis4oD3kPrAs6oWsDSa45NQW982AnDQatNHa MIME-Version: 1.0 X-Received: by 10.55.21.65 with SMTP id f62mr14714174qkh.46.1447306780420; Wed, 11 Nov 2015 21:39:40 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Wed, 11 Nov 2015 21:39:40 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: Date: Wed, 11 Nov 2015 22:39:40 -0700 X-Google-Sender-Auth: YEVaXRG-tCYh7-DcvsxiRLwB75o Message-ID: Subject: Re: Hummingboard SATA From: Warner Losh To: Russell Haley Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 05:39:42 -0000 On Wed, Nov 11, 2015 at 10:22 PM, Russell Haley wrote: > Hello again, > > I have started looking at SATA support in FreeBSD by first reading the man > pages and then examining the code. The Joseph Kong book is helping > considerably to understand the structures. > > I see that there are three drivers in play: ahci, ada and ata. Man > indicates that ahci takes precedence in driver selection. *Is that the > driver for Arm and the Hummingboard?* > ata is out of the picture now. It never really was used on arm. ahci is likely the driver you want, though I'm not sure what a Hummingboard is. A quick google search suggests it is a imx6 board. That's good news because FreeBSD has an attachment. ahci is what's call a CAM SIM. This means that it will create the ata xpt (handled in sys/cam/ata/ata_xpt.c). The XPT then enumerates the transport and finds the sata drives, which wind up getting assigned the ada PERIPH driver (handled by sys/cam/ata/ata_da.c). Chances are very good you have a problem with the ahci driver and/or how that driver is connected / sets up the iMX6 SoC sata hardware. > What I can't seem to find is any direction on getting a debugger hooked up > to driver code. Do I use gdb somehow, or do I use the kernel debugger? I'm > going back over the Developers handbook again. > I'd start with ddb. > I also don't understand how to boot with the -d option. When is this > entered? I have used the sysctl to enter the debugger and poked around > but it doesn't mean much yet. > > sysctl debug.kdb.enter=1 > I don't think that the -d option is implemented on arm. Most of the ARM kernel config files have ALT_BREAK_TO_DEBUGGER defined, which means you'll need to send ~ ^B (that's hit return, hit the tilde key, hit control B). That will get you to the ddb prompt (db>). man 8 ddb for instructions on how to use it. Warner From owner-freebsd-arm@freebsd.org Thu Nov 12 10:28:13 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0AEABA2D511 for ; Thu, 12 Nov 2015 10:28:13 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBCB511CD for ; Thu, 12 Nov 2015 10:28:12 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [10.70.13.115] (unknown [193.174.91.161]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9E0321C1BC16D for ; Thu, 12 Nov 2015 11:28:08 +0100 (CET) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Memory management issue on RPi? Message-Id: Date: Thu, 12 Nov 2015 11:28:07 +0100 To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 10:28:13 -0000 Dear all, I'm experiencing a behaviour I don't expect. When running FreeBSD head on a RPI B+ without swap space it shows the following behaviour on the console: [bsd10:~] tuexen% dd if=3D/dev/zero of=3Dlarge_file bs=3D1m count=3D1024 Nov 12 11:22:16 bsd10 kernel: pid 666 (sshd), uid 1002, was killed: out = of swap space Nov 12 11:22:19 bsd10 kernel: pid 606 (thttpd), uid 65534, was killed: = out of swap space Nov 12 11:22:24 bsd10 kernel: pid 316 (devd), uid 0, was killed: out of = swap space Killed [bsd10:~] tuexen% Nov 12 11:22:27 bsd10 kernel: pid 676 (dd), uid 1002, = was killed: out of swap space [bsd10:~] tuexen% uname -a FreeBSD bsd10.fh-muenster.de 11.0-CURRENT FreeBSD 11.0-CURRENT #10 = r290676: Wed Nov 11 20:23:53 CET 2015 = tuexen@bsd10.fh-muenster.de:/home/tuexen/head/sys/arm/compile/RPI-B arm [bsd10:~] tuexen% ls -l large_file=20 -rw-r--r-- 1 tuexen tuexen 584056832 Nov 12 11:22 large_file Shouldn't I be able to use dd to generate an almost arbitrary large file = (limited by the filesystem, not by the memory)? Best regards Michael= From owner-freebsd-arm@freebsd.org Thu Nov 12 12:18:33 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75AE9A29983 for ; Thu, 12 Nov 2015 12:18:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E36ED15FD; Thu, 12 Nov 2015 12:18:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tACCIQNk057103 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 12 Nov 2015 14:18:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tACCIQNk057103 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tACCIP0i057102; Thu, 12 Nov 2015 14:18:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Nov 2015 14:18:25 +0200 From: Konstantin Belousov To: Michael Tuexen Cc: freebsd-arm Subject: Re: Memory management issue on RPi? Message-ID: <20151112121825.GJ2257@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 12:18:33 -0000 On Thu, Nov 12, 2015 at 11:28:07AM +0100, Michael Tuexen wrote: > Dear all, > > I'm experiencing a behaviour I don't expect. > When running FreeBSD head on a RPI B+ without swap space > it shows the following behaviour on the console: > > [bsd10:~] tuexen% dd if=/dev/zero of=large_file bs=1m count=1024 > Nov 12 11:22:16 bsd10 kernel: pid 666 (sshd), uid 1002, was killed: out of swap space > Nov 12 11:22:19 bsd10 kernel: pid 606 (thttpd), uid 65534, was killed: out of swap space > Nov 12 11:22:24 bsd10 kernel: pid 316 (devd), uid 0, was killed: out of swap space > Killed > [bsd10:~] tuexen% Nov 12 11:22:27 bsd10 kernel: pid 676 (dd), uid 1002, was killed: out of swap space > [bsd10:~] tuexen% uname -a > FreeBSD bsd10.fh-muenster.de 11.0-CURRENT FreeBSD 11.0-CURRENT #10 r290676: Wed Nov 11 20:23:53 CET 2015 tuexen@bsd10.fh-muenster.de:/home/tuexen/head/sys/arm/compile/RPI-B arm > [bsd10:~] tuexen% ls -l large_file > -rw-r--r-- 1 tuexen tuexen 584056832 Nov 12 11:22 large_file > > Shouldn't I be able to use dd to generate an almost arbitrary large file (limited > by the filesystem, not by the memory)? This is a known problem with the swap-less OOM. The following patch should give you an immediate relief. You might want to tweak sysctl vm.pageout_oom_seq if default value is not right, it was selected by 'try and see' approach on very small (32 or 64MB) i386 VM. diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h index a87f682..1fa61eb 100644 --- a/sys/vm/vm_page.h +++ b/sys/vm/vm_page.h @@ -227,6 +227,7 @@ struct vm_domain { long vmd_segs; /* bitmask of the segments */ boolean_t vmd_oom; int vmd_pass; /* local pagedaemon pass */ + int vmd_oom_seq; int vmd_last_active_scan; struct vm_page vmd_marker; /* marker for pagedaemon private use */ struct vm_page vmd_inacthead; /* marker for LRU-defeating insertions */ diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index f564fb5..b956e25 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -122,7 +122,8 @@ static void vm_pageout_init(void); static int vm_pageout_clean(vm_page_t m); static int vm_pageout_cluster(vm_page_t m); static void vm_pageout_scan(struct vm_domain *vmd, int pass); -static void vm_pageout_mightbe_oom(struct vm_domain *vmd, int pass); +static void vm_pageout_mightbe_oom(struct vm_domain *vmd, int page_shortage, + int starting_page_shortage); SYSINIT(pagedaemon_init, SI_SUB_KTHREAD_PAGE, SI_ORDER_FIRST, vm_pageout_init, NULL); @@ -158,6 +159,7 @@ SYSINIT(vmdaemon, SI_SUB_KTHREAD_VM, SI_ORDER_FIRST, kproc_start, &vm_kp); int vm_pages_needed; /* Event on which pageout daemon sleeps */ int vm_pageout_deficit; /* Estimated number of pages deficit */ int vm_pageout_wakeup_thresh; +static int vm_pageout_oom_seq = 24; #if !defined(NO_SWAPPING) static int vm_pageout_req_swapout; /* XXX */ @@ -223,6 +225,10 @@ static int pageout_lock_miss; SYSCTL_INT(_vm, OID_AUTO, pageout_lock_miss, CTLFLAG_RD, &pageout_lock_miss, 0, "vget() lock misses during pageout"); +SYSCTL_INT(_vm, OID_AUTO, pageout_oom_seq, + CTLFLAG_RW, &vm_pageout_oom_seq, 0, + "back-to-back calls to oom detector to start OOM"); + #define VM_PAGEOUT_PAGE_COUNT 16 int vm_pageout_page_count = VM_PAGEOUT_PAGE_COUNT; @@ -1041,7 +1047,8 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) vm_object_t object; long min_scan; int act_delta, addl_page_shortage, deficit, error, maxlaunder, maxscan; - int page_shortage, scan_tick, scanned, vnodes_skipped; + int page_shortage, scan_tick, scanned, starting_page_shortage; + int vnodes_skipped; boolean_t pageout_ok, queues_locked; /* @@ -1080,6 +1087,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) page_shortage = vm_paging_target() + deficit; } else page_shortage = deficit = 0; + starting_page_shortage = page_shortage; /* * maxlaunder limits the number of dirty pages we flush per scan. @@ -1343,6 +1351,12 @@ relock_queues: (void)speedup_syncer(); /* + * If the inactive queue scan fails repeatedly to meet its + * target, kill the largest process. + */ + vm_pageout_mightbe_oom(vmd, page_shortage, starting_page_shortage); + + /* * Compute the number of pages we want to try to move from the * active queue to the inactive queue. */ @@ -1453,15 +1467,6 @@ relock_queues: } } #endif - - /* - * If we are critically low on one of RAM or swap and low on - * the other, kill the largest process. However, we avoid - * doing this on the first pass in order to give ourselves a - * chance to flush out dirty vnode-backed pages and to allow - * active pages to be moved to the inactive queue and reclaimed. - */ - vm_pageout_mightbe_oom(vmd, pass); } static int vm_pageout_oom_vote; @@ -1472,12 +1477,17 @@ static int vm_pageout_oom_vote; * failed to reach free target is premature. */ static void -vm_pageout_mightbe_oom(struct vm_domain *vmd, int pass) +vm_pageout_mightbe_oom(struct vm_domain *vmd, int page_shortage, + int starting_page_shortage) { int old_vote; - if (pass <= 1 || !((swap_pager_avail < 64 && vm_page_count_min()) || - (swap_pager_full && vm_paging_target() > 0))) { + if (starting_page_shortage <= 0 || starting_page_shortage != + page_shortage) + vmd->vmd_oom_seq = 0; + else + vmd->vmd_oom_seq++; + if (vmd->vmd_oom_seq < vm_pageout_oom_seq) { if (vmd->vmd_oom) { vmd->vmd_oom = FALSE; atomic_subtract_int(&vm_pageout_oom_vote, 1); @@ -1485,6 +1495,12 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, int pass) return; } + /* + * Do not follow the call sequence until OOM condition is + * cleared. + */ + vmd->vmd_oom_seq = 0; + if (vmd->vmd_oom) return; @@ -1510,6 +1526,37 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, int pass) atomic_subtract_int(&vm_pageout_oom_vote, 1); } +static long +vm_pageout_resident_count(struct vmspace *vmspace) +{ + vm_map_t map; + vm_map_entry_t entry; + vm_object_t obj; + long res; + + map = &vmspace->vm_map; + KASSERT(!map->system_map, ("system map")); + sx_assert(&map->lock, SA_LOCKED); + res = 0; + for (entry = map->header.next; entry != &map->header; + entry = entry->next) { + if ((entry->eflags & MAP_ENTRY_IS_SUB_MAP) != 0) + continue; + obj = entry->object.vm_object; + if (obj == NULL) + continue; + switch (obj->type) { + case OBJT_DEFAULT: + case OBJT_SWAP: + case OBJT_VNODE: + case OBJT_PHYS: + res += obj->resident_page_count; + break; + } + } + return (res); +} + void vm_pageout_oom(int shortage) { @@ -1554,7 +1601,8 @@ vm_pageout_oom(int shortage) if (!TD_ON_RUNQ(td) && !TD_IS_RUNNING(td) && !TD_IS_SLEEPING(td) && - !TD_IS_SUSPENDED(td)) { + !TD_IS_SUSPENDED(td) && + !TD_IS_SWAPPED(td)) { thread_unlock(td); breakout = 1; break; @@ -1582,12 +1630,13 @@ vm_pageout_oom(int shortage) } PROC_UNLOCK(p); size = vmspace_swap_count(vm); - vm_map_unlock_read(&vm->vm_map); if (shortage == VM_OOM_MEM) - size += vmspace_resident_count(vm); + size += vm_pageout_resident_count(vm); + vm_map_unlock_read(&vm->vm_map); vmspace_free(vm); + /* - * if the this process is bigger than the biggest one + * If this process is bigger than the biggest one, * remember it. */ if (size > bigsize) { From owner-freebsd-arm@freebsd.org Thu Nov 12 16:12:11 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 701E1A2D83B for ; Thu, 12 Nov 2015 16:12:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DE861D56; Thu, 12 Nov 2015 16:12:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by ioir85 with SMTP id r85so28781731ioi.1; Thu, 12 Nov 2015 08:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wnVhWMvmyzBsXOVp1rSwCfOKw3Uo5dbFFTW6234ZJpA=; b=Z+PnyVXECFoV+DoFYLRdM7IrxfyKwEyyR3qDZWtOBAWP3l3D0Gbh7XdkzYv5Aukv6S SyCzhMqVWXobWCFNupB4P8IgXfQ6oORcLhWKyVqKYYl0qksrSBB9jVzO0Ev3AxAm1Iey rB9lxPjD56kKSXHCy2GdsmqG4Q4Ie3Fuv1ayrp8J2KaXi/WUQIHoTCzxa2UfNcDT+LwW cnpjBqXyNQLsFNT2Hz0/Nn5zysQ2CuadbczyCVxgZvTgqhycmta5aYty+NuBubuEw+gp of5VP8qsUxfC3rQh7JdjC6lL3BFLsQ9D7UMrQJfkkt32RWleoEN4JPtQs1xK/qi6WsfQ Ul5w== MIME-Version: 1.0 X-Received: by 10.107.10.199 with SMTP id 68mr14910871iok.75.1447344730440; Thu, 12 Nov 2015 08:12:10 -0800 (PST) Received: by 10.36.217.196 with HTTP; Thu, 12 Nov 2015 08:12:10 -0800 (PST) In-Reply-To: <20151112121825.GJ2257@kib.kiev.ua> References: <20151112121825.GJ2257@kib.kiev.ua> Date: Thu, 12 Nov 2015 08:12:10 -0800 Message-ID: Subject: Re: Memory management issue on RPi? From: Adrian Chadd To: Konstantin Belousov Cc: Michael Tuexen , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 16:12:11 -0000 [snip] So what's it doing behind the scenes? is it creating lots of dirty pages that aren't under enough pressure to write back to storage? -a From owner-freebsd-arm@freebsd.org Thu Nov 12 16:25:41 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63135A2DB7D for ; Thu, 12 Nov 2015 16:25:41 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1344317FD for ; Thu, 12 Nov 2015 16:25:41 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [10.70.13.115] (unknown [193.174.91.161]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 194B61C0C0BCF; Thu, 12 Nov 2015 17:25:38 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Memory management issue on RPi? From: Michael Tuexen In-Reply-To: <20151112121825.GJ2257@kib.kiev.ua> Date: Thu, 12 Nov 2015 17:25:37 +0100 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151112121825.GJ2257@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 16:25:41 -0000 > On 12 Nov 2015, at 13:18, Konstantin Belousov = wrote: >=20 > On Thu, Nov 12, 2015 at 11:28:07AM +0100, Michael Tuexen wrote: >> Dear all, >>=20 >> I'm experiencing a behaviour I don't expect. >> When running FreeBSD head on a RPI B+ without swap space >> it shows the following behaviour on the console: >>=20 >> [bsd10:~] tuexen% dd if=3D/dev/zero of=3Dlarge_file bs=3D1m = count=3D1024 >> Nov 12 11:22:16 bsd10 kernel: pid 666 (sshd), uid 1002, was killed: = out of swap space >> Nov 12 11:22:19 bsd10 kernel: pid 606 (thttpd), uid 65534, was = killed: out of swap space >> Nov 12 11:22:24 bsd10 kernel: pid 316 (devd), uid 0, was killed: out = of swap space >> Killed >> [bsd10:~] tuexen% Nov 12 11:22:27 bsd10 kernel: pid 676 (dd), uid = 1002, was killed: out of swap space >> [bsd10:~] tuexen% uname -a >> FreeBSD bsd10.fh-muenster.de 11.0-CURRENT FreeBSD 11.0-CURRENT #10 = r290676: Wed Nov 11 20:23:53 CET 2015 = tuexen@bsd10.fh-muenster.de:/home/tuexen/head/sys/arm/compile/RPI-B arm >> [bsd10:~] tuexen% ls -l large_file=20 >> -rw-r--r-- 1 tuexen tuexen 584056832 Nov 12 11:22 large_file >>=20 >> Shouldn't I be able to use dd to generate an almost arbitrary large = file (limited >> by the filesystem, not by the memory)? >=20 > This is a known problem with the swap-less OOM. The following patch > should give you an immediate relief. You might want to tweak > sysctl vm.pageout_oom_seq if default value is not right, it was = selected > by 'try and see' approach on very small (32 or 64MB) i386 VM. It just works... Will do some more testing... Best regards Michael >=20 > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > index a87f682..1fa61eb 100644 > --- a/sys/vm/vm_page.h > +++ b/sys/vm/vm_page.h > @@ -227,6 +227,7 @@ struct vm_domain { > long vmd_segs; /* bitmask of the segments */ > boolean_t vmd_oom; > int vmd_pass; /* local pagedaemon pass */ > + int vmd_oom_seq; > int vmd_last_active_scan; > struct vm_page vmd_marker; /* marker for pagedaemon private use = */ > struct vm_page vmd_inacthead; /* marker for LRU-defeating = insertions */ > diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c > index f564fb5..b956e25 100644 > --- a/sys/vm/vm_pageout.c > +++ b/sys/vm/vm_pageout.c > @@ -122,7 +122,8 @@ static void vm_pageout_init(void); > static int vm_pageout_clean(vm_page_t m); > static int vm_pageout_cluster(vm_page_t m); > static void vm_pageout_scan(struct vm_domain *vmd, int pass); > -static void vm_pageout_mightbe_oom(struct vm_domain *vmd, int pass); > +static void vm_pageout_mightbe_oom(struct vm_domain *vmd, int = page_shortage, > + int starting_page_shortage); >=20 > SYSINIT(pagedaemon_init, SI_SUB_KTHREAD_PAGE, SI_ORDER_FIRST, = vm_pageout_init, > NULL); > @@ -158,6 +159,7 @@ SYSINIT(vmdaemon, SI_SUB_KTHREAD_VM, = SI_ORDER_FIRST, kproc_start, &vm_kp); > int vm_pages_needed; /* Event on which pageout daemon sleeps = */ > int vm_pageout_deficit; /* Estimated number of pages = deficit */ > int vm_pageout_wakeup_thresh; > +static int vm_pageout_oom_seq =3D 24; >=20 > #if !defined(NO_SWAPPING) > static int vm_pageout_req_swapout; /* XXX */ > @@ -223,6 +225,10 @@ static int pageout_lock_miss; > SYSCTL_INT(_vm, OID_AUTO, pageout_lock_miss, > CTLFLAG_RD, &pageout_lock_miss, 0, "vget() lock misses during = pageout"); >=20 > +SYSCTL_INT(_vm, OID_AUTO, pageout_oom_seq, > + CTLFLAG_RW, &vm_pageout_oom_seq, 0, > + "back-to-back calls to oom detector to start OOM"); > + > #define VM_PAGEOUT_PAGE_COUNT 16 > int vm_pageout_page_count =3D VM_PAGEOUT_PAGE_COUNT; >=20 > @@ -1041,7 +1047,8 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) > vm_object_t object; > long min_scan; > int act_delta, addl_page_shortage, deficit, error, maxlaunder, = maxscan; > - int page_shortage, scan_tick, scanned, vnodes_skipped; > + int page_shortage, scan_tick, scanned, starting_page_shortage; > + int vnodes_skipped; > boolean_t pageout_ok, queues_locked; >=20 > /* > @@ -1080,6 +1087,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) > page_shortage =3D vm_paging_target() + deficit; > } else > page_shortage =3D deficit =3D 0; > + starting_page_shortage =3D page_shortage; >=20 > /* > * maxlaunder limits the number of dirty pages we flush per = scan. > @@ -1343,6 +1351,12 @@ relock_queues: > (void)speedup_syncer(); >=20 > /* > + * If the inactive queue scan fails repeatedly to meet its > + * target, kill the largest process. > + */ > + vm_pageout_mightbe_oom(vmd, page_shortage, = starting_page_shortage); > + > + /* > * Compute the number of pages we want to try to move from the > * active queue to the inactive queue. > */ > @@ -1453,15 +1467,6 @@ relock_queues: > } > } > #endif > - > - /* > - * If we are critically low on one of RAM or swap and low on > - * the other, kill the largest process. However, we avoid > - * doing this on the first pass in order to give ourselves a > - * chance to flush out dirty vnode-backed pages and to allow > - * active pages to be moved to the inactive queue and reclaimed. > - */ > - vm_pageout_mightbe_oom(vmd, pass); > } >=20 > static int vm_pageout_oom_vote; > @@ -1472,12 +1477,17 @@ static int vm_pageout_oom_vote; > * failed to reach free target is premature. > */ > static void > -vm_pageout_mightbe_oom(struct vm_domain *vmd, int pass) > +vm_pageout_mightbe_oom(struct vm_domain *vmd, int page_shortage, > + int starting_page_shortage) > { > int old_vote; >=20 > - if (pass <=3D 1 || !((swap_pager_avail < 64 && = vm_page_count_min()) || > - (swap_pager_full && vm_paging_target() > 0))) { > + if (starting_page_shortage <=3D 0 || starting_page_shortage !=3D > + page_shortage) > + vmd->vmd_oom_seq =3D 0; > + else > + vmd->vmd_oom_seq++; > + if (vmd->vmd_oom_seq < vm_pageout_oom_seq) { > if (vmd->vmd_oom) { > vmd->vmd_oom =3D FALSE; > atomic_subtract_int(&vm_pageout_oom_vote, 1); > @@ -1485,6 +1495,12 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, = int pass) > return; > } >=20 > + /* > + * Do not follow the call sequence until OOM condition is > + * cleared. > + */ > + vmd->vmd_oom_seq =3D 0; > + > if (vmd->vmd_oom) > return; >=20 > @@ -1510,6 +1526,37 @@ vm_pageout_mightbe_oom(struct vm_domain *vmd, = int pass) > atomic_subtract_int(&vm_pageout_oom_vote, 1); > } >=20 > +static long > +vm_pageout_resident_count(struct vmspace *vmspace) > +{ > + vm_map_t map; > + vm_map_entry_t entry; > + vm_object_t obj; > + long res; > + > + map =3D &vmspace->vm_map; > + KASSERT(!map->system_map, ("system map")); > + sx_assert(&map->lock, SA_LOCKED); > + res =3D 0; > + for (entry =3D map->header.next; entry !=3D &map->header; > + entry =3D entry->next) { > + if ((entry->eflags & MAP_ENTRY_IS_SUB_MAP) !=3D 0) > + continue; > + obj =3D entry->object.vm_object; > + if (obj =3D=3D NULL) > + continue; > + switch (obj->type) { > + case OBJT_DEFAULT: > + case OBJT_SWAP: > + case OBJT_VNODE: > + case OBJT_PHYS: > + res +=3D obj->resident_page_count; > + break; > + } > + } > + return (res); > +} > + > void > vm_pageout_oom(int shortage) > { > @@ -1554,7 +1601,8 @@ vm_pageout_oom(int shortage) > if (!TD_ON_RUNQ(td) && > !TD_IS_RUNNING(td) && > !TD_IS_SLEEPING(td) && > - !TD_IS_SUSPENDED(td)) { > + !TD_IS_SUSPENDED(td) && > + !TD_IS_SWAPPED(td)) { > thread_unlock(td); > breakout =3D 1; > break; > @@ -1582,12 +1630,13 @@ vm_pageout_oom(int shortage) > } > PROC_UNLOCK(p); > size =3D vmspace_swap_count(vm); > - vm_map_unlock_read(&vm->vm_map); > if (shortage =3D=3D VM_OOM_MEM) > - size +=3D vmspace_resident_count(vm); > + size +=3D vm_pageout_resident_count(vm); > + vm_map_unlock_read(&vm->vm_map); > vmspace_free(vm); > + > /* > - * if the this process is bigger than the biggest one > + * If this process is bigger than the biggest one, > * remember it. > */ > if (size > bigsize) { >=20 >=20 >=20 From owner-freebsd-arm@freebsd.org Thu Nov 12 17:12:27 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CAEAAA2C6E9 for ; Thu, 12 Nov 2015 17:12:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5EAEC12ED; Thu, 12 Nov 2015 17:12:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tACHCMgC027104 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 12 Nov 2015 19:12:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tACHCMgC027104 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tACHCLlI027103; Thu, 12 Nov 2015 19:12:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Nov 2015 19:12:21 +0200 From: Konstantin Belousov To: Michael Tuexen Cc: freebsd-arm Subject: Re: Memory management issue on RPi? Message-ID: <20151112171221.GO2257@kib.kiev.ua> References: <20151112121825.GJ2257@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 17:12:27 -0000 On Thu, Nov 12, 2015 at 05:25:37PM +0100, Michael Tuexen wrote: > > On 12 Nov 2015, at 13:18, Konstantin Belousov wrote: > > This is a known problem with the swap-less OOM. The following patch > > should give you an immediate relief. You might want to tweak > > sysctl vm.pageout_oom_seq if default value is not right, it was selected > > by 'try and see' approach on very small (32 or 64MB) i386 VM. > It just works... Will do some more testing... I am more interested in report if OOM was triggered when it should. Try running several instances of 'sort /dev/zero'. From owner-freebsd-arm@freebsd.org Thu Nov 12 17:57:06 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABFBBA2D74D for ; Thu, 12 Nov 2015 17:57:06 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 755EF18A9 for ; Thu, 12 Nov 2015 17:57:06 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [192.168.1.200] (p508F1D2F.dip0.t-ipconnect.de [80.143.29.47]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 39FDA1C16270F; Thu, 12 Nov 2015 18:57:03 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Memory management issue on RPi? From: Michael Tuexen In-Reply-To: <20151112171221.GO2257@kib.kiev.ua> Date: Thu, 12 Nov 2015 18:57:03 +0100 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <984BA2E2-DD1A-4D05-858B-362192660E54@freebsd.org> References: <20151112121825.GJ2257@kib.kiev.ua> <20151112171221.GO2257@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 17:57:06 -0000 > On 12 Nov 2015, at 18:12, Konstantin Belousov = wrote: >=20 > On Thu, Nov 12, 2015 at 05:25:37PM +0100, Michael Tuexen wrote: >>> On 12 Nov 2015, at 13:18, Konstantin Belousov = wrote: >>> This is a known problem with the swap-less OOM. The following patch >>> should give you an immediate relief. You might want to tweak >>> sysctl vm.pageout_oom_seq if default value is not right, it was = selected >>> by 'try and see' approach on very small (32 or 64MB) i386 VM. >> It just works... Will do some more testing... >=20 > I am more interested in report if OOM was triggered when it should. How do I know? What output do you want to see? Best regards Michael >=20 > Try running several instances of 'sort /dev/zero'. >=20 From owner-freebsd-arm@freebsd.org Thu Nov 12 18:10:06 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEFF7A2D98A for ; Thu, 12 Nov 2015 18:10:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 492FB1E10; Thu, 12 Nov 2015 18:10:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tACI9uCf048223 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 12 Nov 2015 20:09:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tACI9uCf048223 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tACI9sGc048222; Thu, 12 Nov 2015 20:09:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Nov 2015 20:09:54 +0200 From: Konstantin Belousov To: Michael Tuexen Cc: freebsd-arm Subject: Re: Memory management issue on RPi? Message-ID: <20151112180954.GP2257@kib.kiev.ua> References: <20151112121825.GJ2257@kib.kiev.ua> <20151112171221.GO2257@kib.kiev.ua> <984BA2E2-DD1A-4D05-858B-362192660E54@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <984BA2E2-DD1A-4D05-858B-362192660E54@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 18:10:06 -0000 On Thu, Nov 12, 2015 at 06:57:03PM +0100, Michael Tuexen wrote: > > On 12 Nov 2015, at 18:12, Konstantin Belousov wrote: > > > > On Thu, Nov 12, 2015 at 05:25:37PM +0100, Michael Tuexen wrote: > >>> On 12 Nov 2015, at 13:18, Konstantin Belousov wrote: > >>> This is a known problem with the swap-less OOM. The following patch > >>> should give you an immediate relief. You might want to tweak > >>> sysctl vm.pageout_oom_seq if default value is not right, it was selected > >>> by 'try and see' approach on very small (32 or 64MB) i386 VM. > >> It just works... Will do some more testing... > > > > I am more interested in report if OOM was triggered when it should. > How do I know? What output do you want to see? > > Best regards > Michael > > > > Try running several instances of 'sort /dev/zero'. ^^^^^^^^^^^^^ I already answered this. Run sort /dev/zero, and see whether OOM fires. From owner-freebsd-arm@freebsd.org Thu Nov 12 18:36:56 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2361A2DF28 for ; Thu, 12 Nov 2015 18:36:56 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9B531F4B for ; Thu, 12 Nov 2015 18:36:56 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id tACIErCW006442; Thu, 12 Nov 2015 10:14:53 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id tACIErsh006441; Thu, 12 Nov 2015 10:14:53 -0800 (PST) (envelope-from fbsd) Date: Thu, 12 Nov 2015 10:14:53 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: fatal error: 'device_if.h' file not found Message-ID: <20151112181453.GA70166@www.zefox.net> References: <20151112121825.GJ2257@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 18:36:57 -0000 Hi, The last two OS builds have reported /usr/src/sys/sys/bus.h:655:10: fatal error: 'device_if.h' file not found in buildkernel. It seemed possible to work around the missing file by separately updating /usr/src/sys and re-running buildkernel, but the fix didn't stick in the second iteration. What am I doing wrong? Many thanks, bob prohaska From owner-freebsd-arm@freebsd.org Thu Nov 12 18:43:05 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 626C4A2D40F for ; Thu, 12 Nov 2015 18:43:05 +0000 (UTC) (envelope-from serge0x76@gmail.com) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2091115B5 for ; Thu, 12 Nov 2015 18:43:05 +0000 (UTC) (envelope-from serge0x76@gmail.com) Received: by qgeb1 with SMTP id b1so53390255qge.1 for ; Thu, 12 Nov 2015 10:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iJ2jRTFkpAZgjTkc8UqXX9ybMzn6loB2QGXUubczlVA=; b=VCuzwTkiD3egaLunu3CyUDHYNUBCxAKbK6HfAUszI/ajH84IUUlM4O/JF+5LG2oIc0 Op5EyhMr9R/ivmBb0Sl6c2DkOmHprrSXsHAHiEZeAuKWFJbhlPFdrKU3OJmVqdxZI7XA H2U6lxm/LOS+sQOlAIOTJrxR7fRPXLSjGjlfY4WDk6+63CALGBcAcbqpw8TWS3UoSpQF 9JO5QeXX5wGMHECb/1MKl09kqvO8sq27dBZHJTnq7vzXnaE3r4HsVyTrCUTFJ6j7y+D0 kXWeB87DwQHb29WksSlLHbUchI0G8/EYcbxGKjLrzkuSu9CRfc12EbJHYQ+3DJ4sPOa6 9jQw== MIME-Version: 1.0 X-Received: by 10.140.81.166 with SMTP id f35mr17417611qgd.63.1447353784141; Thu, 12 Nov 2015 10:43:04 -0800 (PST) Received: by 10.55.179.2 with HTTP; Thu, 12 Nov 2015 10:43:04 -0800 (PST) In-Reply-To: <20151112181453.GA70166@www.zefox.net> References: <20151112121825.GJ2257@kib.kiev.ua> <20151112181453.GA70166@www.zefox.net> Date: Thu, 12 Nov 2015 13:43:04 -0500 Message-ID: Subject: Re: fatal error: 'device_if.h' file not found From: Serge Voilokov To: bob prohaska Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 18:43:05 -0000 temporarily workaround is to remove these tests from the build: file: sys/modules/Makefile remove lines: tests/framework \ tests/callout_test \ On Thu, Nov 12, 2015 at 1:14 PM, bob prohaska wrote: > Hi, > > The last two OS builds have reported > /usr/src/sys/sys/bus.h:655:10: fatal error: 'device_if.h' file not found > in buildkernel. It seemed possible to work around the missing file by > separately updating /usr/src/sys and re-running buildkernel, but the fix > didn't stick in the second iteration. > > What am I doing wrong? > > Many thanks, > > bob prohaska > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Thu Nov 12 19:47:34 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C67C1A2D198 for ; Thu, 12 Nov 2015 19:47:34 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 84C06177F for ; Thu, 12 Nov 2015 19:47:34 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [192.168.1.200] (p508F1D2F.dip0.t-ipconnect.de [80.143.29.47]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 68B641C0C0BCF; Thu, 12 Nov 2015 20:47:30 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Memory management issue on RPi? From: Michael Tuexen In-Reply-To: <20151112180954.GP2257@kib.kiev.ua> Date: Thu, 12 Nov 2015 20:47:29 +0100 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <29DB8CF5-7569-4139-885A-8496993805A7@freebsd.org> References: <20151112121825.GJ2257@kib.kiev.ua> <20151112171221.GO2257@kib.kiev.ua> <984BA2E2-DD1A-4D05-858B-362192660E54@freebsd.org> <20151112180954.GP2257@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 19:47:34 -0000 > On 12 Nov 2015, at 19:09, Konstantin Belousov = wrote: >=20 > On Thu, Nov 12, 2015 at 06:57:03PM +0100, Michael Tuexen wrote: >>> On 12 Nov 2015, at 18:12, Konstantin Belousov = wrote: >>>=20 >>> On Thu, Nov 12, 2015 at 05:25:37PM +0100, Michael Tuexen wrote: >>>>> On 12 Nov 2015, at 13:18, Konstantin Belousov = wrote: >>>>> This is a known problem with the swap-less OOM. The following = patch >>>>> should give you an immediate relief. You might want to tweak >>>>> sysctl vm.pageout_oom_seq if default value is not right, it was = selected >>>>> by 'try and see' approach on very small (32 or 64MB) i386 VM. >>>> It just works... Will do some more testing... >>>=20 >>> I am more interested in report if OOM was triggered when it should. >> How do I know? What output do you want to see? >>=20 >> Best regards >> Michael >>>=20 >>> Try running several instances of 'sort /dev/zero'. > ^^^^^^^^^^^^^ I already answered this. > Run sort /dev/zero, and see whether OOM fires. OK, now I understand. You want to see if some processes are getting = killed. (I was thinking that you might want to see some sysctl counters or so). Results: * I'm able to compile/link/install a kernel from source. This was not possible before. * When running three instances of sort /dev/zero, two of them get killed after a while (less than a minute). One continued to run, but got also kill eventually. All via ssh login. Let me know if you want me to do some more testing. Best regards Michael >=20 From owner-freebsd-arm@freebsd.org Thu Nov 12 20:03:06 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 121B7A2D4F5 for ; Thu, 12 Nov 2015 20:03:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D1921F42; Thu, 12 Nov 2015 20:03:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tACK30hQ075444 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 12 Nov 2015 22:03:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tACK30hQ075444 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tACK30uJ075443; Thu, 12 Nov 2015 22:03:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Nov 2015 22:03:00 +0200 From: Konstantin Belousov To: Michael Tuexen Cc: freebsd-arm Subject: Re: Memory management issue on RPi? Message-ID: <20151112200300.GR2257@kib.kiev.ua> References: <20151112121825.GJ2257@kib.kiev.ua> <20151112171221.GO2257@kib.kiev.ua> <984BA2E2-DD1A-4D05-858B-362192660E54@freebsd.org> <20151112180954.GP2257@kib.kiev.ua> <29DB8CF5-7569-4139-885A-8496993805A7@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29DB8CF5-7569-4139-885A-8496993805A7@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 20:03:06 -0000 On Thu, Nov 12, 2015 at 08:47:29PM +0100, Michael Tuexen wrote: > > On 12 Nov 2015, at 19:09, Konstantin Belousov wrote: > > > > On Thu, Nov 12, 2015 at 06:57:03PM +0100, Michael Tuexen wrote: > >>> On 12 Nov 2015, at 18:12, Konstantin Belousov wrote: > >>> > >>> On Thu, Nov 12, 2015 at 05:25:37PM +0100, Michael Tuexen wrote: > >>>>> On 12 Nov 2015, at 13:18, Konstantin Belousov wrote: > >>>>> This is a known problem with the swap-less OOM. The following patch > >>>>> should give you an immediate relief. You might want to tweak > >>>>> sysctl vm.pageout_oom_seq if default value is not right, it was selected > >>>>> by 'try and see' approach on very small (32 or 64MB) i386 VM. > >>>> It just works... Will do some more testing... > >>> > >>> I am more interested in report if OOM was triggered when it should. > >> How do I know? What output do you want to see? > >> > >> Best regards > >> Michael > >>> > >>> Try running several instances of 'sort /dev/zero'. > > ^^^^^^^^^^^^^ I already answered this. > > Run sort /dev/zero, and see whether OOM fires. > OK, now I understand. You want to see if some processes are getting killed. > (I was thinking that you might want to see some sysctl counters or so). > > Results: > * I'm able to compile/link/install a kernel from source. This was not > possible before. > * When running three instances of sort /dev/zero, two of them get killed > after a while (less than a minute). One continued to run, but got also > kill eventually. All via ssh login. Exactly, this is the experiment I want to occur, and even more, the results are good. > > Let me know if you want me to do some more testing. No, this is enough. Thank you. From owner-freebsd-arm@freebsd.org Thu Nov 12 22:10:20 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CD00A2D8D9 for ; Thu, 12 Nov 2015 22:10:20 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm47-vm8.bullet.mail.bf1.yahoo.com (nm47-vm8.bullet.mail.bf1.yahoo.com [216.109.115.143]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 525E0123A for ; Thu, 12 Nov 2015 22:10:19 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1447366053; bh=DZv+Zl33tqjKF9t31H3xnf6fw2mT4XBIKG7JoYub/3E=; h=From:Subject:Date:To:From:Subject; b=lm76cFvvdnqeaePc+CRMP2ar74j9duSt7bFYzz+iB5lxP0fh/pM3bMJN9/J4cEhpojM/rGngx/gfN9H+PwMB2NGAUxW+pn8ondnashwiHVSdlzQr9jLy2uBRHDW5oAiJqMAnfkFwAOQ+5yE7MOpdm8pslQH+BDCbuI78/Fmpt/xl3xZ75VW7k94dtxDYzDNcfFGv3gMgf6mUe526XqRAt7uVAM1+9p6y553DSQg+LzwKbkUBMPL47v5n+Vo3+htJPQ+qOFC5AUeeXcVlwr5k5uVco40f7mvHhLxWN0YFdThzw8lPdOcHoU4l+ugxuPfG3i5wzQYzeqBhWdW+JN2dFA== Received: from [66.196.81.170] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 12 Nov 2015 22:07:33 -0000 Received: from [98.139.211.161] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 12 Nov 2015 22:07:33 -0000 Received: from [127.0.0.1] by smtp218.mail.bf1.yahoo.com with NNFMP; 12 Nov 2015 22:07:33 -0000 X-Yahoo-Newman-Id: 341134.9967.bm@smtp218.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: tXpkSQ4VM1lUSQ47fXoC5o97LidZEKRYvqCNBkvd_LQDuE7 cbmUxoOnjMm.zOQfjWzGafqul3F9uny.4K7b7jkBMna5kjK9V0_k8AO5ITlE yFT4ByUsoCLbiMf6oak4QUz7SWwdB.ynKQwIW4qPunJuV9vgkMQCOj7u2jBG VEaqF5XlIDbTs.UkAr4qw6krG7kE7hn5323l58.0tvH8NTe6xKNL5KuiBQVd nvEMAoyg7NLND8sUa5isnRs5g9yusdWx0h63FaLAvyAcH37l.DycN5OR.DCw cBv4j5XDWCb1oEw1C3ohe.zh2CfsqBI1OFli1uxPeNVvKImoH8yyjBpS8CZb tMKhJ_3S6mhk41mA5QuSCDFtX0wHjhHFfna5uZ.ASPg8rq9hAxFahyOsU7V7 TNn5KhdN6OHsrweK4yTINkUSkxRrbidwa8504oHEiL1pjXWisUmvzu7RaMcr zvvyxIq8cZFunDi_Vo8NIDWiejyT7.z66XWHnxs_0604TKisKAd5l0.a6jWA Q68gBGEDC7dW4iOENKL4aEifQ2I5a0.xnLA90TCdF50k- X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV From: Thomas Skibo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Zybo support Message-Id: Date: Thu, 12 Nov 2015 14:07:32 -0800 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 22:10:20 -0000 Hello, all. FreeBSD now runs on the Zybo board. Zybo is a Xilinx Zynq-7000 board = from Digilent similar to Zedboard but smaller and significantly less = expensive. (See http://digilentinc.com/zybo). I put up an SD image for = Zybo on my zedbsd page: http://thomasskibo.com/zedbsd. I have two minor commits to add support for Zybo to the tree. I added = the rgephy driver to the ZEDBOARD conf file and I have a zybo.dts fdt = file. =E2=80=94 Thomas Skibo thomasskibo@yahoo.com From owner-freebsd-arm@freebsd.org Thu Nov 12 22:36:53 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4E8FA2DF23 for ; Thu, 12 Nov 2015 22:36:53 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm45-vm7.bullet.mail.bf1.yahoo.com (nm45-vm7.bullet.mail.bf1.yahoo.com [216.109.115.78]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 63D241156 for ; Thu, 12 Nov 2015 22:36:52 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1447367648; bh=OPqYPfts6snAUFgxl0zACr8UmWtl12X8Zuu4jORVtMU=; h=From:Subject:Date:To:From:Subject; b=Gr1Ig/VTO5DlEjiXouWkGpYnCG7l2z9PsZUkV2tTZxEi7f+FaS+l9mlQBOBvANb9kNqk84G4pvVmnQ/nhOJrCedvxDKoj1gkLeUvyrLLrXIt9x2eNP7LtdK7adFADP7iNE9zkTfztbpWxZ/sYz4eSDUYsUK7hMKnQ9URvCPDTreCmdUrvxPqU3XORoiClMDYCyPIe3Zrwxc5TjPvNdDHvHURvyqydwomKJKCDFRXBsLwlkT/H4+0aVT7pKBs16ERTL/thniZ+CCwjWk9bJBzT5mSzPS0Un4vEiafwQgg5U3cPFJYfp0cASzPwEXLCxrKqNQ6jeTk8EeA+Z1GKrnToQ== Received: from [98.139.215.143] by nm45.bullet.mail.bf1.yahoo.com with NNFMP; 12 Nov 2015 22:34:08 -0000 Received: from [98.139.211.193] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 12 Nov 2015 22:34:08 -0000 Received: from [127.0.0.1] by smtp202.mail.bf1.yahoo.com with NNFMP; 12 Nov 2015 22:34:08 -0000 X-Yahoo-Newman-Id: 172793.51139.bm@smtp202.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: nJeDatIVM1mzIFsf8HTGHUTthOCFGWNPwxDSuo8zRW0oLgW ADuVa4tnw0bACpKEBLGiLpHPjTitRiadxkpeZsplWApfM6eVlvbyi2dCI0cm _DE1RVksFyIf.PF9lBVcXGq0bpM8X4DPiHISchH6XIfYmTG5BiG_gZHKPGpV XCzUStAd9SHrPIebfW6IP2gZOxuP1xzkMhARPsmi00hYj9NQnfArs9tXhaDi VXfChyA03JqytqrdDsEJ0jGRLLN_6FemcH0Egeq._Gh.hWnbc_76i16xNsDP TZdPUXi7Kly3JJ2kEsGJYnPo.KnNBMJbvE5KSTrrqX_AlqrzSh488gxEwnK7 jBflnezbAu7WfgFhAQ7CIt.AWVtWx3WuxV4dlhY_oISI83XMcUOdHgQlZgN. MfvVp0xJlVs6DskP.K.qCIm5lq80yyfujWquER10kG3R5pwgk2BBTDc8vUOC o1HH7qxajxpN_104jGa9LnOnBqzpOijlNhIHW88nG9hpId6LGvA6s5ItMb8r AEOVTuvxTjb8djyNoN.s.1OLm5eSqzpYS36.BC9bJ X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV From: Thomas Skibo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Zybo support Message-Id: Date: Thu, 12 Nov 2015 14:34:06 -0800 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 22:36:53 -0000 argh. Remove the period from that link. = http://www.thomasskibo.com/zedbsd Sorry. =E2=80=94 Thomas Skibo thomasskibo@yahoo.com From owner-freebsd-arm@freebsd.org Fri Nov 13 05:43:02 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23551A2E2A7 for ; Fri, 13 Nov 2015 05:43:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4340132F for ; Fri, 13 Nov 2015 05:43:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iofh3 with SMTP id h3so88247904iof.3 for ; Thu, 12 Nov 2015 21:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=v9JmmcW/mCOaJEuQwZJN8NmLEI0m5mbDIcG8yQvmfFY=; b=yt9TVrhmQnmmQ8sVN/bFpL/OVrv9xHq11+SYa5G9Q0+i5a6m547WWQPcRKmtAFmwAd XM5IX4ugrfY1U79lmguRNQ0t4yntqb5QN+qCzZekXMnfX2YooBky7GNpbMZj5qy2Nsvu E9a4AWTtgrvrUbRAaG+BxbtzXYihG2kcNrz0yyQlM0Rv068h/6Q4Ujmvm8kQx+GOUo0V xDfP68s50wpd0hZ4BJsRA0e2fHcDnnD4o+o4HvEr1L80ugzc25o1NnfkFGvzXb6nra7w ouX52dqoK06ZDpgQjEjKVeWDsartONWO//qQWd42KVvNQDTTGe2try3mehX3UExHS2Da /CZQ== MIME-Version: 1.0 X-Received: by 10.107.10.199 with SMTP id 68mr18198378iok.75.1447393381366; Thu, 12 Nov 2015 21:43:01 -0800 (PST) Received: by 10.36.217.196 with HTTP; Thu, 12 Nov 2015 21:43:01 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Nov 2015 21:43:01 -0800 Message-ID: Subject: Re: Zybo support From: Adrian Chadd To: Thomas Skibo Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 05:43:02 -0000 hi cool! Can you put those two changes up somehere? That way we can drag them into -HEAD. Thanks! -a On 12 November 2015 at 14:07, Thomas Skibo via freebsd-arm wrote: > Hello, all. > > FreeBSD now runs on the Zybo board. Zybo is a Xilinx Zynq-7000 board fr= om Digilent similar to Zedboard but smaller and significantly less expensiv= e. (See http://digilentinc.com/zybo). I put up an SD image for Zybo on my= zedbsd page: http://thomasskibo.com/zedbsd. > > I have two minor commits to add support for Zybo to the tree. I added th= e rgephy driver to the ZEDBOARD conf file and I have a zybo.dts fdt file. > > =E2=80=94 > Thomas Skibo > thomasskibo@yahoo.com > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Nov 13 08:23:59 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34272A2B0C5 for ; Fri, 13 Nov 2015 08:23:59 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EEB1515D9 for ; Fri, 13 Nov 2015 08:23:58 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [192.168.1.200] (p508F1D2C.dip0.t-ipconnect.de [80.143.29.44]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6191B1C0C0BCF; Fri, 13 Nov 2015 09:23:55 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Memory management issue on RPi? From: Michael Tuexen In-Reply-To: <20151112200300.GR2257@kib.kiev.ua> Date: Fri, 13 Nov 2015 09:23:54 +0100 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <6452F207-A79B-42C6-A2CC-07BF454B7024@freebsd.org> References: <20151112121825.GJ2257@kib.kiev.ua> <20151112171221.GO2257@kib.kiev.ua> <984BA2E2-DD1A-4D05-858B-362192660E54@freebsd.org> <20151112180954.GP2257@kib.kiev.ua> <29DB8CF5-7569-4139-885A-8496993805A7@freebsd.org> <20151112200300.GR2257@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 08:23:59 -0000 > On 12 Nov 2015, at 21:03, Konstantin Belousov = wrote: >=20 > On Thu, Nov 12, 2015 at 08:47:29PM +0100, Michael Tuexen wrote: >>> On 12 Nov 2015, at 19:09, Konstantin Belousov = wrote: >>>=20 >>> On Thu, Nov 12, 2015 at 06:57:03PM +0100, Michael Tuexen wrote: >>>>> On 12 Nov 2015, at 18:12, Konstantin Belousov = wrote: >>>>>=20 >>>>> On Thu, Nov 12, 2015 at 05:25:37PM +0100, Michael Tuexen wrote: >>>>>>> On 12 Nov 2015, at 13:18, Konstantin Belousov = wrote: >>>>>>> This is a known problem with the swap-less OOM. The following = patch >>>>>>> should give you an immediate relief. You might want to tweak >>>>>>> sysctl vm.pageout_oom_seq if default value is not right, it was = selected >>>>>>> by 'try and see' approach on very small (32 or 64MB) i386 VM. >>>>>> It just works... Will do some more testing... >>>>>=20 >>>>> I am more interested in report if OOM was triggered when it = should. >>>> How do I know? What output do you want to see? >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> Try running several instances of 'sort /dev/zero'. >>> ^^^^^^^^^^^^^ I already answered this. >>> Run sort /dev/zero, and see whether OOM fires. >> OK, now I understand. You want to see if some processes are getting = killed. >> (I was thinking that you might want to see some sysctl counters or = so). >>=20 >> Results: >> * I'm able to compile/link/install a kernel from source. This was not >> possible before. >> * When running three instances of sort /dev/zero, two of them get = killed >> after a while (less than a minute). One continued to run, but got = also >> kill eventually. All via ssh login. > Exactly, this is the experiment I want to occur, and even more, the = results > are good. Any plans to commit it? Best regards Michael >=20 >>=20 >> Let me know if you want me to do some more testing. >=20 > No, this is enough. > Thank you. >=20 From owner-freebsd-arm@freebsd.org Fri Nov 13 09:49:31 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D378FA2D5F3 for ; Fri, 13 Nov 2015 09:49:31 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A5BD119A for ; Fri, 13 Nov 2015 09:49:31 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [192.168.1.200] (p508F1D2C.dip0.t-ipconnect.de [80.143.29.44]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4061E1C0AC839 for ; Fri, 13 Nov 2015 10:49:29 +0100 (CET) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Stray IRQ 35 when using /dev/led on RPi Message-Id: Date: Fri, 13 Nov 2015 10:49:27 +0100 To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 09:49:31 -0000 Dear all, when using morse -l "FreeBSD" > /dev/led/act on a RPi running FreeBSD head as of yesterday I get lots of Nov 13 10:43:56 rpi2 kernel: gpio0: Stray IRQ 35 Nov 13 10:44:00 rpi2 last message repeated 19 times Nov 13 10:46:37 rpi2 last message repeated 92 times messages on the console. When using vmstat -ia I get root@rpi2:/usr/home/tuexen # vmstat -ia interrupt total rate 0 0 irq1: mbox0 19579 0 irq2: vchiq0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 irq17: bcm283x_dwco 4248911995 7 0 0 0 0 0 0 0 0 0 0 0 0 irq24: bcm_dma0 0 0 irq25: bcm_dma0 0 0 irq26: bcm_dma0 2510498 14 irq27: bcm_dma0 0 0 irq28: bcm_dma0 0 0 irq29: bcm_dma0 0 0 irq30: bcm_dma0 0 0 irq31: bcm_dma0 0 0 irq32: bcm_dma0 0 0 irq33: bcm_dma0 0 0 irq34: bcm_dma0 0 0 irq35: bcm_dma0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 irq57: gpio0 0 0 irq58: gpio0 2457 0 irq59: gpio0 0 0 irq60: gpio0 0 0 irq61: iichb0 0 0 irq62: spi0 0 0 0 0 0 0 irq65: uart0 1839 0 0 0 0 0 0 0 0 0 irq70: sdhci_bcm0 858378 5 0 0 irq72: generic_time 0 0 irq73: generic_time 40798880 12 0 0 irq75: generic_time 0 0 irq76: ipi 18621941 8 0 0 ....... Total 4311725571 24383 root@rpi2:/usr/home/tuexen # Any idea whats wrong? Best regards Michael From owner-freebsd-arm@freebsd.org Fri Nov 13 13:00:52 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB125A2ECC3 for ; Fri, 13 Nov 2015 13:00:52 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) by mx1.freebsd.org (Postfix) with ESMTP id A271510C4; Fri, 13 Nov 2015 13:00:52 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from e-bsd.cs.huji.ac.il ([132.65.80.241] helo=outmail.cs.huji.ac.il) by kabab.cs.huji.ac.il with esmtp id 1ZxDy5-000AYm-GG; Fri, 13 Nov 2015 15:00:41 +0200 Received: from [132.65.179.20] (helo=mbpro2.bs.cs.huji.ac.il) by outmail.cs.huji.ac.il with esmtpsa id 1ZxDy5-000D5E-BN; Fri, 13 Nov 2015 15:00:41 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Stray IRQ 35 when using /dev/led on RPi From: Daniel Braniss In-Reply-To: Date: Fri, 13 Nov 2015 15:00:49 +0200 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: References: To: Michael Tuexen X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 13:00:53 -0000 i get them too, but they go away after fiddling with the gpio connectors or changing the power supply. danny > On 13 Nov 2015, at 11:49 AM, Michael Tuexen wrote: > > Dear all, > > when using > > morse -l "FreeBSD" > /dev/led/act > > on a RPi running FreeBSD head as of yesterday I get lots of > > Nov 13 10:43:56 rpi2 kernel: gpio0: Stray IRQ 35 > Nov 13 10:44:00 rpi2 last message repeated 19 times > Nov 13 10:46:37 rpi2 last message repeated 92 times > > messages on the console. > > When using vmstat -ia I get > > root@rpi2:/usr/home/tuexen # vmstat -ia > interrupt total rate > 0 0 > irq1: mbox0 19579 0 > irq2: vchiq0 4 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > irq17: bcm283x_dwco 4248911995 7 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > irq24: bcm_dma0 0 0 > irq25: bcm_dma0 0 0 > irq26: bcm_dma0 2510498 14 > irq27: bcm_dma0 0 0 > irq28: bcm_dma0 0 0 > irq29: bcm_dma0 0 0 > irq30: bcm_dma0 0 0 > irq31: bcm_dma0 0 0 > irq32: bcm_dma0 0 0 > irq33: bcm_dma0 0 0 > irq34: bcm_dma0 0 0 > irq35: bcm_dma0 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > 0 0 > irq57: gpio0 0 0 > irq58: gpio0 2457 0 > irq59: gpio0 0 0 > irq60: gpio0 0 0 > irq61: iichb0 0 0 > irq62: spi0 0 0 > 0 0 > 0 0 > irq65: uart0 1839 0 > 0 0 > 0 0 > 0 0 > 0 0 > irq70: sdhci_bcm0 858378 5 > 0 0 > irq72: generic_time 0 0 > irq73: generic_time 40798880 12 > 0 0 > irq75: generic_time 0 0 > irq76: ipi 18621941 8 > 0 0 > ....... > Total 4311725571 24383 > root@rpi2:/usr/home/tuexen # > > Any idea whats wrong? > > Best regards > Michael > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Nov 13 14:05:59 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 833ACA2E820 for ; Fri, 13 Nov 2015 14:05:59 +0000 (UTC) (envelope-from serge0x76@gmail.com) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CD301032 for ; Fri, 13 Nov 2015 14:05:59 +0000 (UTC) (envelope-from serge0x76@gmail.com) Received: by qkcl124 with SMTP id l124so48128322qkc.3 for ; Fri, 13 Nov 2015 06:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WqJScD+bZ/SGAuILdA4TY+6XHVkWiOZYAyC6RbIhGis=; b=dhoIfoOO6qA1P+TaK4qBIfHFEZ0i/SQfpSjlxqeKwYXKyZU+7VOrGOhG2jmQzNVUfi PIZwQzm1qKGVysLC/hka8UaHFzHEXbgb0IiF5ZoqrUGH+6VbhZEyr9ar6zX8ZTTcY23N xd4BB9fVSPhN2yqxPohtWo0zgRlgpecmFFs7I26qcyZu6tfBTqzsmS0Uwkv+gd9svWSt TJWzZdKKfelBh3fSYrrR6xOklxvvUxbbm7JGUypX0RBhEXcYKQnbTkTnf7xjrb9nvXuF Q7yC/Fp8x2hFbUcgC71rrz/jTogPYGWafkzAno4IuVBHMEXqC/ohdAlUFU2/yRM+0wl9 2m3Q== MIME-Version: 1.0 X-Received: by 10.140.43.139 with SMTP id e11mr21849347qga.6.1447423558268; Fri, 13 Nov 2015 06:05:58 -0800 (PST) Received: by 10.55.179.2 with HTTP; Fri, 13 Nov 2015 06:05:58 -0800 (PST) Date: Fri, 13 Nov 2015 09:05:58 -0500 Message-ID: Subject: Raspberry Pi Camera? From: Serge Voilokov To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 14:05:59 -0000 I was able to use raspistill to take pictures on RPI-A and r290273.img. However after installing the image I was needed to copy additional firmware (start_x.elf and fixup_x.dat) manually to /boot/msdos since it is absent on the image. So this set works: instructions: https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi%20Camera image: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-arm-armv6-RPI-B-20151102-r290273.img.xz firmware: https://github.com/raspberrypi/firmware/tree/193f600ff3df626a25887134daf8b5841cbfe0e5 userland (freebsd branch): https://github.com/gonzoua/userland/tree/fcbf8a3e028e830174ed1cbedf956464a8d26a68 From owner-freebsd-arm@freebsd.org Fri Nov 13 15:02:22 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A2E1A2E1CF for ; Fri, 13 Nov 2015 15:02:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 54D3118DB for ; Fri, 13 Nov 2015 15:02:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkao63 with SMTP id o63so49359842qka.2 for ; Fri, 13 Nov 2015 07:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp_com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+pqEoPCj4NhDCXhY7Q60dlJS36ElYCprhcXHecEtNlI=; b=bMCQ5cLsMFdyRm7ERQnf+EwTa5gH0b/YzER22/VGurBstEn4AhUkbFJEYUSLNiBLhQ zrpSliwpmTRPRQbOFV4kUfU0Ei60rEokq/1Bq0uQLJJtmJfIYqZP2bdP2AmarBQqkM0z mpz5YAPnNJzIS7MXN4puzYtdwYhk1KcfBRH4biYe0z5aiZp7C84RwHxJxvFPm3VnfL9d wsB+HL24hiTFtXYM45h70F3uU29ifNRTZmG433/ttRDSeJPtlCNFGwknrRD6BH+VU0zU 4WhAYR48OrrBQsUT8W+/fpFTizFUlrh1MsvSs/fCdBFLiZxBi7bkqKPLe11QfcxkqtU/ wMfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+pqEoPCj4NhDCXhY7Q60dlJS36ElYCprhcXHecEtNlI=; b=lTWcBCsiSaAV6DT8wUc4VreP2+R1Hj3vIwbMy7LlIMPCrHUF6J++4epxxKNzdoFSO7 9t1ZRhekpKi6Wm8UekffoT52qJCktkhLKE72wvLFq7fkm6CjwVRJPTS8yFYao14fMwkd okQ7ystCcSTaMkr3DmEQxImA5+iYgglLkPe/ae0pY8JWViAmA/37a1ra+YGGweNuWQ+U 2MdqEXBmkTDU87N3+irkviqHuLkjJj3v2WekUiqeVRUjuBQvIjO6GwsEzmbU/Gv8sFg/ iXMCZcOnoEkyRKs1F2LROhg1Jhu9UnG72PGavZDhwUSOMpSXD6ujHzWs05CZwTO6HTWS nJkg== X-Gm-Message-State: ALoCoQnjrm7/CojUJ3OokTyGKOa4Rgpyycdpw3+dbm+RqX1ZXg/zjQCYXchED0bBqHN4uwTzOjfr MIME-Version: 1.0 X-Received: by 10.140.221.198 with SMTP id r189mr23655262qhb.94.1447426940855; Fri, 13 Nov 2015 07:02:20 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Fri, 13 Nov 2015 07:02:20 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: Date: Fri, 13 Nov 2015 08:02:20 -0700 X-Google-Sender-Auth: 1EbV28yDDLPDM40JAlGh8TfJ32w Message-ID: Subject: Re: Zybo support From: Warner Losh To: Adrian Chadd Cc: Thomas Skibo , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 15:02:22 -0000 He already posted a link. Reading the link shows that all that's needed is a new DTB and maybe a new uboot (I haven't read in detail). The instructions look to be very good and match the broad outlines of all the different systems that build FreeBSD images that I've worked on or studied. Warner On Thu, Nov 12, 2015 at 10:43 PM, Adrian Chadd wrote: > hi cool! Can you put those two changes up somehere? > > That way we can drag them into -HEAD. > > Thanks! > > > -a > > > On 12 November 2015 at 14:07, Thomas Skibo via freebsd-arm > wrote: > > Hello, all. > > > > FreeBSD now runs on the Zybo board. Zybo is a Xilinx Zynq-7000 board > from Digilent similar to Zedboard but smaller and significantly less > expensive. (See http://digilentinc.com/zybo). I put up an SD image for > Zybo on my zedbsd page: http://thomasskibo.com/zedbsd. > > > > I have two minor commits to add support for Zybo to the tree. I added > the rgephy driver to the ZEDBOARD conf file and I have a zybo.dts fdt fil= e. > > > > =E2=80=94 > > Thomas Skibo > > thomasskibo@yahoo.com > > > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Fri Nov 13 15:05:22 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF2C1A2E215 for ; Fri, 13 Nov 2015 15:05:21 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm47-vm1.bullet.mail.bf1.yahoo.com (nm47-vm1.bullet.mail.bf1.yahoo.com [216.109.115.124]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9501819AA for ; Fri, 13 Nov 2015 15:05:21 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1447426957; bh=dIP+rCJcNONE7vUCXQQTvt1GnCGvBwe2VLh4k7BaO9M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=e0f2latd+n7I0hZCEFYKry50oPkGilUf7MFoJT7fPVC7Tv87SOX1mn7IJLXFb1LRqDRR7MDQIXE+CgWzwTaKJY/QS6kbp1uCmyVho4NIyzZ9H04+gn1g//JTt8MockcCFIxMneOVfuwdHgeiXuAxkntk8R1mRcquesxwuV01DFg57zMBJGzMuaDxQU7Yq6VWXT449ssK/oNYYm4A7mgfXM+/6/TIOo/7csw41pMP0Od8aLXkbKxq/owmvHOFAcUOYisiWJgmGzFxNIkE+3PUuiwI3m3UTxaXTr0VRqJ2d+38KvvmdK7tAOLlMMeG/2TSDrp/lU0nmWMMeFaJB5Gjtw== Received: from [98.139.215.141] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 13 Nov 2015 15:02:37 -0000 Received: from [98.139.213.15] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 13 Nov 2015 15:02:37 -0000 Received: from [127.0.0.1] by smtp115.mail.bf1.yahoo.com with NNFMP; 13 Nov 2015 15:02:37 -0000 X-Yahoo-Newman-Id: 711338.55051.bm@smtp115.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: j9ap8CAVM1khFIxyf0wNxxT5hn06mQWlkWrCtWtkRfZtUJv Fsubiyhk996txDg2IgGbBYDHzDHrCX126bUJJC2HwOJ8EQ86H6f3zPBJKp.4 hE9a_kG3_6qkS5vt2P4valHA.BTKVkmR.wiWfYMEvMYpXV900gRhuqsifr7m R.L67Elgwuoadrwjp5O.BwhVMCmLM.Z4J8XlGVZwGzmes7jofuo0j7n1dVHb YkW8Ku9Ro8l5Yb86sLWIcOc_ZZ8uBMgcXaQac8QheKldJBP57bPJT8jFpgLF W6JJWmFIWNAYGFSWWwINSyg_a3Px3.CY8VWgaCP6v7LNviT4ncFTMUzMsScY 1bcxoTD8io5tqSiiwZjA.g69yWOCUgFR05dHwx6ZywqeNfstfQZEaSHHyboH NTdQ_ihLgV9EmMj790asRFxoo6YjzQSh8k.VCJ75RMtP9JjH6PzeIE.KH5vK rDkouAZ7ldoDs5kdU27qQd0Z4beNvbEe_uqTgpCZ0mw7cx_f2m8LBN_DdCEf qmlDW5R0N1QBpgfT9zUAFQRGNDE.OvUqLwsuo X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV Content-Type: multipart/mixed; boundary="Apple-Mail=_B81D5F29-C3A2-4D0C-96A5-215D72465CFE" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Zybo support From: Thomas Skibo In-Reply-To: Date: Fri, 13 Nov 2015 07:02:36 -0800 Cc: "freebsd-arm@freebsd.org" Message-Id: References: To: Adrian Chadd X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 15:05:22 -0000 --Apple-Mail=_B81D5F29-C3A2-4D0C-96A5-215D72465CFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 12, 2015, at 9:43 PM, Adrian Chadd = wrote: >=20 > hi cool! Can you put those two changes up somehere? >=20 > That way we can drag them into -HEAD. >=20 > Thanks! >=20 >=20 > -a >=20 I=E2=80=99ve attached the fdt file zybo.dts for = /usr/src/sys/boot/fdt/dts/arm and the patch file for = /usr/src/sys/arm/conf/ZEDBOARD. Thanks! =E2=80=94 Thomas Skibo thomasskibo@yahoo.com --Apple-Mail=_B81D5F29-C3A2-4D0C-96A5-215D72465CFE Content-Disposition: attachment; filename=zybo.dts Content-Type: application/octet-stream; name="zybo.dts" Content-Transfer-Encoding: 7bit /*- * Copyright (c) 2015 The FreeBSD Foundation * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $FreeBSD$ */ /dts-v1/; / { model = "zybo"; compatible = "digilent,zybo"; #address-cells = <1>; #size-cells = <1>; interrupt-parent = <&GIC>; // cpus { // #address-cells = <1>; // #size-cells = <0>; // cpu@0 { // device-type = "cpu"; // model = "ARM Cortex-A9"; // }; // }; memory { // First megabyte isn't accessible by all interconnect masters. device_type = "memory"; reg = <0x100000 0x1ff00000>; /* 511MB RAM at 0x100000 */ }; // Zynq PS System registers. // ps7sys@f8000000 { device_type = "soc"; compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; ranges = <0x0 0xf8000000 0xf10000>; // SLCR block slcr: slcr@7000 { compatible = "xlnx,zy7_slcr"; reg = <0x0 0x1000>; clock-frequency = <50000000>; // 50Mhz PS_CLK }; // Interrupt controller GIC: gic { compatible = "arm,gic"; interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; reg = <0xf01000 0x1000>, // distributer registers <0xf00100 0x0100>; // CPU if registers }; // L2 cache controller pl310@f02000 { compatible = "arm,pl310"; reg = <0xf02000 0x1000>; interrupts = <34>; interrupt-parent = <&GIC>; }; // Device Config devcfg: devcfg@7000 { compatible = "xlnx,zy7_devcfg"; reg = <0x7000 0x1000>; interrupts = <40>; interrupt-parent = <&GIC>; }; // triple timer counters0,1 ttc0: ttc@1000 { compatible = "xlnx,ttc"; reg = <0x1000 0x1000>; }; ttc1: ttc@2000 { compatible = "xlnx,ttc"; reg = <0x2000 0x1000>; }; // ARM Cortex A9 TWD Timer timer@f00600 { compatible = "arm,mpcore-timers"; clock-frequency = <325000000>; // 325Mhz #address-cells = <1>; #size-cells = <0>; reg = <0xf00200 0x100>, // Global Timer Regs <0xf00600 0x20>; // Private Timer Regs interrupts = < 27 29 >; interrupt-parent = <&GIC>; }; // system watch-dog timer swdt@5000 { device_type = "watchdog"; compatible = "xlnx,zy7_wdt"; reg = <0x5000 0x1000>; interrupts = <41>; interrupt-parent = <&GIC>; }; scuwdt@f00620 { device_type = "watchdog"; compatible = "arm,mpcore_wdt"; reg = <0xf00620 0x20>; interrupts = <30>; interrupt-parent = <&GIC>; reset = <1>; }; }; // pssys@f8000000 // Zynq PS I/O Peripheral registers. // ps7io@e0000000 { device_type = "soc"; compatible = "simple-bus"; #address-cells = <1>; #size-cells = <1>; ranges = <0x0 0xe0000000 0x300000>; // uart0: uart@0000 { // device_type = "serial"; // compatible = "cadence,uart"; // reg = <0x0000 0x1000>; // interrupts = <59>; // interrupt-parent = <&GIC>; // clock-frequency = <50000000>; // }; uart1: uart@1000 { device_type = "serial"; compatible = "cadence,uart"; reg = <0x1000 0x1000>; interrupts = <82>; interrupt-parent = <&GIC>; clock-frequency = <50000000>; current-speed = <115200>; }; gpio: gpio@a000 { compatible = "xlnx,zy7_gpio"; reg = <0xa000 0x1000>; interrupts = <52>; interrupt-parent = <&GIC>; }; // GigE eth0: eth@b000 { // device_type = "network"; compatible = "cadence,gem"; reg = <0xb000 0x1000>; interrupts = <54 55>; interrupt-parent = <&GIC>; ref-clock-num = <0>; }; // SDIO sdhci0: sdhci@100000 { compatible = "xlnx,zy7_sdhci"; reg = <0x100000 0x1000>; interrupts = <56>; interrupt-parent = <&GIC>; max-frequency = <50000000>; }; // QSPI qspi0: qspi@d000 { compatible = "xlnx,zy7_qspi"; reg = <0xd000 0x1000>; interrupts = <51>; interrupt-parent = <&GIC>; spi-clock = <50000000>; ref-clock = <200000000>; }; // USB ehci0: ehci@2000 { compatible = "xlnx,zy7_ehci"; reg = <0x2000 0x1000>; interrupts = <53>; interrupt-parent = <&GIC>; }; }; // ps7io@e0000000 chosen { stdin = &uart1; stdout = &uart1; }; }; --Apple-Mail=_B81D5F29-C3A2-4D0C-96A5-215D72465CFE Content-Disposition: attachment; filename=patch.ZEDBOARD.txt Content-Type: text/plain; name="patch.ZEDBOARD.txt" Content-Transfer-Encoding: 7bit Index: sys/arm/conf/ZEDBOARD =================================================================== --- sys/arm/conf/ZEDBOARD (revision 290688) +++ sys/arm/conf/ZEDBOARD (working copy) @@ -1,6 +1,6 @@ # # ZEDBOARD -- Custom configuration for the Xilinx Zynq-7000 based -# ZedBoard (www.zedboard.org) +# ZedBoard (www.zedboard.org) and similar Zynq boards. # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: @@ -59,6 +59,7 @@ device cgem # Zynq-7000 gig ethernet device device mii device e1000phy +device rgephy # Zybo uses Realtek RTL8211E device pty device uart device gpio --Apple-Mail=_B81D5F29-C3A2-4D0C-96A5-215D72465CFE-- From owner-freebsd-arm@freebsd.org Fri Nov 13 15:12:05 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A14F5A2E35B for ; Fri, 13 Nov 2015 15:12:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49E0F1C99 for ; Fri, 13 Nov 2015 15:12:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkfo3 with SMTP id o3so49643301qkf.1 for ; Fri, 13 Nov 2015 07:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp_com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PDxJr3mwNuQrdrMocWfbbcuAubpjH8+flhQMZ5fgckk=; b=hM73cUiXyWH292jQzu8jIHwbwVOumCpuHXUJ5Im5Z/y15MEy7GEfAgssd2sVw/Qcka 2jIJn6rtUhiDDacllGWMGqs3NGSGu4uDD7+8SAmEvk3PgS64CnL1wY+P7LCJ+ji7ZBZL jd3iQju7lNSioIAzjWqSFL1RhMfLDYFvOpKI8nDFHwGETw5EDv+qRw9TOQHW8YEMYBv6 1jKpkrRv+eHLmtAvJe7KCAHwAXLE/eumW/DcQfj+GzDCH2hvULTq8CGF+C+jqEnCGOew uRArJVCPoS7fH/Wvw0nVJh8ebZE0DAPg2RLdV+UrwgE5u2bfsOENLqAd6JTay/VQu8nv slAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PDxJr3mwNuQrdrMocWfbbcuAubpjH8+flhQMZ5fgckk=; b=T52GjwXsGuJlx3LrVOjJEViZHH784Pxyp5GLtu/MScwqn/psyZnTbzwdjalKQFweF/ yKzRvvPdY2HIi4WVWbfy0B1f37w3W3Pm0H1BoJse/Z3yizu3myMNFn1L8MoRANvLmXVM HLYPGQMRSRxnfT/7TE1UM+sGP3qxoErDT/GnUN/SQjxWWR26dXUOIUVzysn/9k5pELOs t5tDGDkJy54elK0mPOsrUMQyeP5cskBWYX3/OZ1cje6fnR84/IkEa8kRyZDiFScWBv/A tSTqRRhgYKzC5RJenrwrXPuWSZytluBNCAafifBmU3fiYtqbol/yVXpRRsU590j+OVb7 1NPQ== X-Gm-Message-State: ALoCoQl3i+CELha+hT3pPOJ6n8lGCK3KLE8OaPXaaMdC8p0ifKjW39a5JumFMs1FqtHLJsDQ5yaH MIME-Version: 1.0 X-Received: by 10.140.196.69 with SMTP id r66mr8025575qha.40.1447427524472; Fri, 13 Nov 2015 07:12:04 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Fri, 13 Nov 2015 07:12:04 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <6452F207-A79B-42C6-A2CC-07BF454B7024@freebsd.org> References: <20151112121825.GJ2257@kib.kiev.ua> <20151112171221.GO2257@kib.kiev.ua> <984BA2E2-DD1A-4D05-858B-362192660E54@freebsd.org> <20151112180954.GP2257@kib.kiev.ua> <29DB8CF5-7569-4139-885A-8496993805A7@freebsd.org> <20151112200300.GR2257@kib.kiev.ua> <6452F207-A79B-42C6-A2CC-07BF454B7024@freebsd.org> Date: Fri, 13 Nov 2015 08:12:04 -0700 X-Google-Sender-Auth: Uh5o1JRlORqdutgAw6GahxI9kKI Message-ID: Subject: Re: Memory management issue on RPi? From: Warner Losh To: Michael Tuexen Cc: Konstantin Belousov , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 15:12:05 -0000 On Fri, Nov 13, 2015 at 1:23 AM, Michael Tuexen wrote: > > On 12 Nov 2015, at 21:03, Konstantin Belousov > wrote: > > > > On Thu, Nov 12, 2015 at 08:47:29PM +0100, Michael Tuexen wrote: > >>> On 12 Nov 2015, at 19:09, Konstantin Belousov > wrote: > >>> > >>> On Thu, Nov 12, 2015 at 06:57:03PM +0100, Michael Tuexen wrote: > >>>>> On 12 Nov 2015, at 18:12, Konstantin Belousov > wrote: > >>>>> > >>>>> On Thu, Nov 12, 2015 at 05:25:37PM +0100, Michael Tuexen wrote: > >>>>>>> On 12 Nov 2015, at 13:18, Konstantin Belousov > wrote: > >>>>>>> This is a known problem with the swap-less OOM. The following > patch > >>>>>>> should give you an immediate relief. You might want to tweak > >>>>>>> sysctl vm.pageout_oom_seq if default value is not right, it was > selected > >>>>>>> by 'try and see' approach on very small (32 or 64MB) i386 VM. > >>>>>> It just works... Will do some more testing... > >>>>> > >>>>> I am more interested in report if OOM was triggered when it should. > >>>> How do I know? What output do you want to see? > >>>> > >>>> Best regards > >>>> Michael > >>>>> > >>>>> Try running several instances of 'sort /dev/zero'. > >>> ^^^^^^^^^^^^^ I already answered this. > >>> Run sort /dev/zero, and see whether OOM fires. > >> OK, now I understand. You want to see if some processes are getting > killed. > >> (I was thinking that you might want to see some sysctl counters or so). > >> > >> Results: > >> * I'm able to compile/link/install a kernel from source. This was not > >> possible before. > >> * When running three instances of sort /dev/zero, two of them get killed > >> after a while (less than a minute). One continued to run, but got also > >> kill eventually. All via ssh login. > > Exactly, this is the experiment I want to occur, and even more, the > results > > are good. > Any plans to commit it? > These changes are good as an experiment. The RPi's relative speed of the CPU to the extremely slow SD card where pages are laundered to. Deferring the calls to the actual OOM a bit is useful. However, a simple count won't self-scale. What's good for the RPi likely is likely poor for a CPU connected to faster storage. The OOM won't kill things quickly enough in those circumstances. I imagine that there may be a more complicated relationship between the rate of page dirtying and laundering. I'd hope that there'd be some kind of scaling that would take this variation into account. At Netflix, we're developing some patches to do more pro-active laundering of pages rather than waiting for the page daemon to kick in. We do this primarily to avoid flushing the uma caches which have performance implications that we need to address to smooth out the performance. Perhaps something like this would be a more general way to cope with this situation? Warner From owner-freebsd-arm@freebsd.org Fri Nov 13 15:29:45 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D1A0A2E5D9 for ; Fri, 13 Nov 2015 15:29:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F12141218 for ; Fri, 13 Nov 2015 15:29:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkfo3 with SMTP id o3so50185421qkf.1 for ; Fri, 13 Nov 2015 07:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp_com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=a4fiewcwO0/olWWhoH3u0VlJiUtVaSrcVG+I6Oymoew=; b=S67Ug6dx2aTa/fs9lksDnZiRCJsaVeEucfIqkUSWlTYajekdlLRQAl0QB66LnVJq5p PM/BOaJopamwbw1xa7cFYbYXJafLvmIZaYkgN1wACPBMZB7JevTcz0Y7s3mB2GsM3/OB q32CFSlaoFuNEJOsSJmaO8k9BXa4+Vdau/iSezhj5rdO4w143Op4rL7p1HNcBljzkMaC y6zUk/mYwJvEuaUxSIkclj2kIJdst+f+aYsg1zkZjPZHjWmT3y8wBN7vBWgAi4h7EW1t 0ApbHwFhaJ5U6SWi4xxX+EqBxYENb6TJEgQEZlnfEDRxBO0qUY/+GTOd3nPNU+KmXZCg HgKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a4fiewcwO0/olWWhoH3u0VlJiUtVaSrcVG+I6Oymoew=; b=Zm3B3nUAeWJvaxn8JUQZu5qHXySuBoxAOA8gT8w7ThVnK3JnK/QjHEGAXYQWcVfnej gSPyrWYu8S0xAoBScDCFHMXFyGcIPD+ZqrktIReEst6Ebzfyw3GDwXadJWuN26RWjZCc rsCHyPxzEiD1Q1QVlHM2E5ZhkJd8q3xVenp9WuiMpxnqtj/YNEsa1DfCA9jTNfIa5HKw WTfg1UVsCdrKH5BIdnWhdAE+dFpCAutNu6rqscn/xA8X+Xj9ZG28t2WJ+u3A8kKc5ept WRA90oynXvN0T1fwRcaEPq3OoMtiSMHhG5ysZ8KQzK9TgxYNPjkuLgcc77ZST2U1vQqY NARw== X-Gm-Message-State: ALoCoQlRNdXPTho65sIskAX2uf9VaxG+s6lwNwSS9+HaFhHHeiZ69yn8Hvco484lNKVlQdw8uAtT MIME-Version: 1.0 X-Received: by 10.140.31.73 with SMTP id e67mr22998384qge.46.1447428583991; Fri, 13 Nov 2015 07:29:43 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Fri, 13 Nov 2015 07:29:43 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: Date: Fri, 13 Nov 2015 08:29:43 -0700 X-Google-Sender-Auth: MkcBAQXK809DZA5KiVEgbjXaHEI Message-ID: Subject: Re: Zybo support From: Warner Losh To: Thomas Skibo Cc: Adrian Chadd , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 15:29:45 -0000 Sorry for the top post, but I've committed these to the tree. Warner On Fri, Nov 13, 2015 at 8:02 AM, Thomas Skibo via freebsd-arm < freebsd-arm@freebsd.org> wrote: > > > On Nov 12, 2015, at 9:43 PM, Adrian Chadd > wrote: > > > > hi cool! Can you put those two changes up somehere? > > > > That way we can drag them into -HEAD. > > > > Thanks! > > > > > > -a > > > > I=E2=80=99ve attached the fdt file zybo.dts for /usr/src/sys/boot/fdt/dts= /arm and > the patch file for /usr/src/sys/arm/conf/ZEDBOARD. > > Thanks! > > =E2=80=94 > Thomas Skibo > thomasskibo@yahoo.com > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Fri Nov 13 17:10:05 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6156BA2E0B2 for ; Fri, 13 Nov 2015 17:10:05 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC7341501 for ; Fri, 13 Nov 2015 17:10:04 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [192.168.1.200] (p508F1D2C.dip0.t-ipconnect.de [80.143.29.44]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1DC9A1C1C0209; Fri, 13 Nov 2015 18:10:01 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Memory management issue on RPi? From: Michael Tuexen In-Reply-To: Date: Fri, 13 Nov 2015 18:09:59 +0100 Cc: Konstantin Belousov , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <270ED040-C0C0-4D0E-9A7C-4D13F0368729@freebsd.org> References: <20151112121825.GJ2257@kib.kiev.ua> <20151112171221.GO2257@kib.kiev.ua> <984BA2E2-DD1A-4D05-858B-362192660E54@freebsd.org> <20151112180954.GP2257@kib.kiev.ua> <29DB8CF5-7569-4139-885A-8496993805A7@freebsd.org> <20151112200300.GR2257@kib.kiev.ua> <6452F207-A79B-42C6-A2CC-07BF454B7024@freebsd.org> To: Warner Losh X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 17:10:05 -0000 > On 13 Nov 2015, at 16:12, Warner Losh wrote: >=20 >=20 >=20 > On Fri, Nov 13, 2015 at 1:23 AM, Michael Tuexen = wrote: > > On 12 Nov 2015, at 21:03, Konstantin Belousov = wrote: > > > > On Thu, Nov 12, 2015 at 08:47:29PM +0100, Michael Tuexen wrote: > >>> On 12 Nov 2015, at 19:09, Konstantin Belousov = wrote: > >>> > >>> On Thu, Nov 12, 2015 at 06:57:03PM +0100, Michael Tuexen wrote: > >>>>> On 12 Nov 2015, at 18:12, Konstantin Belousov = wrote: > >>>>> > >>>>> On Thu, Nov 12, 2015 at 05:25:37PM +0100, Michael Tuexen wrote: > >>>>>>> On 12 Nov 2015, at 13:18, Konstantin Belousov = wrote: > >>>>>>> This is a known problem with the swap-less OOM. The following = patch > >>>>>>> should give you an immediate relief. You might want to tweak > >>>>>>> sysctl vm.pageout_oom_seq if default value is not right, it = was selected > >>>>>>> by 'try and see' approach on very small (32 or 64MB) i386 VM. > >>>>>> It just works... Will do some more testing... > >>>>> > >>>>> I am more interested in report if OOM was triggered when it = should. > >>>> How do I know? What output do you want to see? > >>>> > >>>> Best regards > >>>> Michael > >>>>> > >>>>> Try running several instances of 'sort /dev/zero'. > >>> ^^^^^^^^^^^^^ I already answered this. > >>> Run sort /dev/zero, and see whether OOM fires. > >> OK, now I understand. You want to see if some processes are getting = killed. > >> (I was thinking that you might want to see some sysctl counters or = so). > >> > >> Results: > >> * I'm able to compile/link/install a kernel from source. This was = not > >> possible before. > >> * When running three instances of sort /dev/zero, two of them get = killed > >> after a while (less than a minute). One continued to run, but got = also > >> kill eventually. All via ssh login. > > Exactly, this is the experiment I want to occur, and even more, the = results > > are good. > Any plans to commit it? >=20 > These changes are good as an experiment. The RPi's relative speed of = the CPU > to the extremely slow SD card where pages are laundered to. Deferring = the calls > to the actual OOM a bit is useful. However, a simple count won't = self-scale. What's > good for the RPi likely is likely poor for a CPU connected to faster = storage. The OOM > won't kill things quickly enough in those circumstances. I imagine = that there may > be a more complicated relationship between the rate of page dirtying = and laundering. >=20 > I'd hope that there'd be some kind of scaling that would take this = variation into > account. >=20 > At Netflix, we're developing some patches to do more pro-active = laundering of pages > rather than waiting for the page daemon to kick in. We do this = primarily to avoid > flushing the uma caches which have performance implications that we = need to > address to smooth out the performance. Perhaps something like this = would be a > more general way to cope with this situation? I'm happy to test patches... Best regards Michael >=20 > Warner From owner-freebsd-arm@freebsd.org Fri Nov 13 18:32:49 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E5E7A2E1E6 for ; Fri, 13 Nov 2015 18:32:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 417FB1FE9; Fri, 13 Nov 2015 18:32:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tADIWgVb004218 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 13 Nov 2015 20:32:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tADIWgVb004218 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tADIWfxB004217; Fri, 13 Nov 2015 20:32:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 13 Nov 2015 20:32:41 +0200 From: Konstantin Belousov To: Warner Losh Cc: Michael Tuexen , freebsd-arm Subject: Re: Memory management issue on RPi? Message-ID: <20151113183241.GA2257@kib.kiev.ua> References: <20151112121825.GJ2257@kib.kiev.ua> <20151112171221.GO2257@kib.kiev.ua> <984BA2E2-DD1A-4D05-858B-362192660E54@freebsd.org> <20151112180954.GP2257@kib.kiev.ua> <29DB8CF5-7569-4139-885A-8496993805A7@freebsd.org> <20151112200300.GR2257@kib.kiev.ua> <6452F207-A79B-42C6-A2CC-07BF454B7024@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 18:32:49 -0000 On Fri, Nov 13, 2015 at 08:12:04AM -0700, Warner Losh wrote: > On Fri, Nov 13, 2015 at 1:23 AM, Michael Tuexen wrote: > > > > On 12 Nov 2015, at 21:03, Konstantin Belousov > > wrote: > > > > > > On Thu, Nov 12, 2015 at 08:47:29PM +0100, Michael Tuexen wrote: > > >>> On 12 Nov 2015, at 19:09, Konstantin Belousov > > wrote: > > >>> > > >>> On Thu, Nov 12, 2015 at 06:57:03PM +0100, Michael Tuexen wrote: > > >>>>> On 12 Nov 2015, at 18:12, Konstantin Belousov > > wrote: > > >>>>> > > >>>>> On Thu, Nov 12, 2015 at 05:25:37PM +0100, Michael Tuexen wrote: > > >>>>>>> On 12 Nov 2015, at 13:18, Konstantin Belousov > > wrote: > > >>>>>>> This is a known problem with the swap-less OOM. The following > > patch > > >>>>>>> should give you an immediate relief. You might want to tweak > > >>>>>>> sysctl vm.pageout_oom_seq if default value is not right, it was > > selected > > >>>>>>> by 'try and see' approach on very small (32 or 64MB) i386 VM. > > >>>>>> It just works... Will do some more testing... > > >>>>> > > >>>>> I am more interested in report if OOM was triggered when it should. > > >>>> How do I know? What output do you want to see? > > >>>> > > >>>> Best regards > > >>>> Michael > > >>>>> > > >>>>> Try running several instances of 'sort /dev/zero'. > > >>> ^^^^^^^^^^^^^ I already answered this. > > >>> Run sort /dev/zero, and see whether OOM fires. > > >> OK, now I understand. You want to see if some processes are getting > > killed. > > >> (I was thinking that you might want to see some sysctl counters or so). > > >> > > >> Results: > > >> * I'm able to compile/link/install a kernel from source. This was not > > >> possible before. > > >> * When running three instances of sort /dev/zero, two of them get killed > > >> after a while (less than a minute). One continued to run, but got also > > >> kill eventually. All via ssh login. > > > Exactly, this is the experiment I want to occur, and even more, the > > results > > > are good. > > Any plans to commit it? > > > > These changes are good as an experiment. The RPi's relative speed > of the CPU to the extremely slow SD card where pages are laundered > to. Deferring the calls to the actual OOM a bit is useful. However, > a simple count won't self-scale. What's good for the RPi likely is > likely poor for a CPU connected to faster storage. The OOM won't kill > things quickly enough in those circumstances. I imagine that there may > be a more complicated relationship between the rate of page dirtying > and laundering. The biggest problematic case fixed by this approach is *swap-less* setup, where the speed of the slow storage does not matter at all for the speed of pagedaemon, since there is no swap. > > I'd hope that there'd be some kind of scaling that would take this > variation into account. > > At Netflix, we're developing some patches to do more pro-active > laundering of pages rather than waiting for the page daemon to kick > in. We do this primarily to avoid flushing the uma caches which have > performance implications that we need to address to smooth out the > performance. Perhaps something like this would be a more general way > to cope with this situation? Page laundering speed cannot be a factor in deciding to trigger OOM. If you can clean up something, then OOM must not be fired. The patch does not trigger OOM when no progress is made, immediately, because it expects that some delay might indeed allow the async io to finish and provide some pages to cover the deficit. Only when the progress stalls completely, the ticking for OOM starts. Several iterations are performed before the deadlock is claimed. There is no good heuristic which I could formulate to provide suitable iterations count. But the current value was tested on both small (32-64M) and large (32GB) machines and found satisfactory. Even then, it is run-time tunable to allow to set it by operator for better-suited value. OOM means that the user data is lost. Netflix might not care, due to the specifics of the load, but I and most other users do care about their data. I always prefer the kernel flushing the caches (not only UMA caches, but also pv entries, UFS dirhashes, GPU unpinned buffers etc) over deadlocking or killing the browser where I filled a long form, or text editor, or any other unrecoverable state. If OOM is not fatal for your data, you can reduce the value of the tunable to prefer kernel caches over the user data. And, to make it clear, the current code which triggers OOM does not make much sense. It mostly takes the count of free pages as the indicator of OOM condition, which fails to account the simple fact that queued pages may be laundred or discarded. As result, false OOM is triggered, and it is easier to get false trigger on swap-less system due to swap being always 'full'. This is orthogonal to the issue of the pagedaemon performance. From owner-freebsd-arm@freebsd.org Fri Nov 13 19:58:11 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6581BA2EE30 for ; Fri, 13 Nov 2015 19:58:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D4101635 for ; Fri, 13 Nov 2015 19:58:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qkao63 with SMTP id o63so58354441qka.2 for ; Fri, 13 Nov 2015 11:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp_com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fNlRmlJczCUv17hxu8SwmtA7I6o/6UbJZu3aeBFVHKo=; b=t9jf8Mp39Q3mgYmhZ2Rc1dUX1qls3HUqaYzeasg0e8XqD4x9ACu/QQQS5j0fg/4com lxJGNzaNaDFe+oh3xwTXdHVttRNn1IBbO3EvM4KsjQ1s9WHGwSTZP8IEKsdqpVoBsfBg NDtNhwecZrUCWAze1dtxEF2uQrPWTY7YrQQQ/kLdynT279g+aUWzFrzk+RA7EpxPksJp VHIx+7daaJ4Of3arVJ9xTk3/Byjqp0Y60uGWxpNCmPF/6Lk50XlQzwFRotxrbsQiLLtY GgtZ4udnXb91YQan1Tmb86NUEPE52WW6e3qU/PIYWGikeIC1jXY6mfLHwXTURsH11zF9 NpCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fNlRmlJczCUv17hxu8SwmtA7I6o/6UbJZu3aeBFVHKo=; b=RpYFAWdYsbLSZg90f8DpTbb3S0mPXqIt7IzjFpkXJqfBW4a7/g7JOOLmx2Lj0Trfok j5T8OUmhOzSj37OVxWUs6P87PDEfXZg0bQYl8R0C234WzNsUFVS+9eDCbp64YyhRp4gi LG/MyJgjQhR/VjbHDxolSVHa8kky1AOYnCC6t1Ypa4mY5FTahxXozgPx4yP/n/gA0i2N r+Y7yK00gPe/tmFFkDHGs9CyJUPl5FhqpcfRWCQJZ99Ii26+AGKa4Odj3x5oxXEByMaK 01TIRdnLkaNnFalwtr3H9cK5xOdtuTZZFo97iySN6mmdWAFQ+ikaebbkP4ftQNv3k3il Sz8A== X-Gm-Message-State: ALoCoQmMtv5WF7MYMhr3nauOBv+ZGzO15gBTM6l74Eb0tB4TypohJwnvrcvPeB9SgqDLaSdDaGRH MIME-Version: 1.0 X-Received: by 10.140.253.135 with SMTP id y129mr25575949qhc.20.1447444690119; Fri, 13 Nov 2015 11:58:10 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Fri, 13 Nov 2015 11:58:10 -0800 (PST) X-Originating-IP: [2601:280:4900:3700:c5bf:3351:8857:774d] In-Reply-To: <20151113183241.GA2257@kib.kiev.ua> References: <20151112121825.GJ2257@kib.kiev.ua> <20151112171221.GO2257@kib.kiev.ua> <984BA2E2-DD1A-4D05-858B-362192660E54@freebsd.org> <20151112180954.GP2257@kib.kiev.ua> <29DB8CF5-7569-4139-885A-8496993805A7@freebsd.org> <20151112200300.GR2257@kib.kiev.ua> <6452F207-A79B-42C6-A2CC-07BF454B7024@freebsd.org> <20151113183241.GA2257@kib.kiev.ua> Date: Fri, 13 Nov 2015 12:58:10 -0700 X-Google-Sender-Auth: mjx0pRQPNYyRDnO5pSxwrMOOxyI Message-ID: Subject: Re: Memory management issue on RPi? From: Warner Losh To: Konstantin Belousov Cc: Michael Tuexen , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 19:58:11 -0000 On Fri, Nov 13, 2015 at 11:32 AM, Konstantin Belousov wrote: > On Fri, Nov 13, 2015 at 08:12:04AM -0700, Warner Losh wrote: > > On Fri, Nov 13, 2015 at 1:23 AM, Michael Tuexen > wrote: > > > > > > On 12 Nov 2015, at 21:03, Konstantin Belousov > > > wrote: > > > > > > > > On Thu, Nov 12, 2015 at 08:47:29PM +0100, Michael Tuexen wrote: > > > >>> On 12 Nov 2015, at 19:09, Konstantin Belousov > > > > wrote: > > > >>> > > > >>> On Thu, Nov 12, 2015 at 06:57:03PM +0100, Michael Tuexen wrote: > > > >>>>> On 12 Nov 2015, at 18:12, Konstantin Belousov < > kostikbel@gmail.com> > > > wrote: > > > >>>>> > > > >>>>> On Thu, Nov 12, 2015 at 05:25:37PM +0100, Michael Tuexen wrote: > > > >>>>>>> On 12 Nov 2015, at 13:18, Konstantin Belousov < > kostikbel@gmail.com> > > > wrote: > > > >>>>>>> This is a known problem with the swap-less OOM. The following > > > patch > > > >>>>>>> should give you an immediate relief. You might want to tweak > > > >>>>>>> sysctl vm.pageout_oom_seq if default value is not right, it was > > > selected > > > >>>>>>> by 'try and see' approach on very small (32 or 64MB) i386 VM. > > > >>>>>> It just works... Will do some more testing... > > > >>>>> > > > >>>>> I am more interested in report if OOM was triggered when it > should. > > > >>>> How do I know? What output do you want to see? > > > >>>> > > > >>>> Best regards > > > >>>> Michael > > > >>>>> > > > >>>>> Try running several instances of 'sort /dev/zero'. > > > >>> ^^^^^^^^^^^^^ I already answered this. > > > >>> Run sort /dev/zero, and see whether OOM fires. > > > >> OK, now I understand. You want to see if some processes are getting > > > killed. > > > >> (I was thinking that you might want to see some sysctl counters or > so). > > > >> > > > >> Results: > > > >> * I'm able to compile/link/install a kernel from source. This was > not > > > >> possible before. > > > >> * When running three instances of sort /dev/zero, two of them get > killed > > > >> after a while (less than a minute). One continued to run, but got > also > > > >> kill eventually. All via ssh login. > > > > Exactly, this is the experiment I want to occur, and even more, the > > > results > > > > are good. > > > Any plans to commit it? > > > > > > > These changes are good as an experiment. The RPi's relative speed > > of the CPU to the extremely slow SD card where pages are laundered > > to. Deferring the calls to the actual OOM a bit is useful. However, > > a simple count won't self-scale. What's good for the RPi likely is > > likely poor for a CPU connected to faster storage. The OOM won't kill > > things quickly enough in those circumstances. I imagine that there may > > be a more complicated relationship between the rate of page dirtying > > and laundering. > The biggest problematic case fixed by this approach is *swap-less* > setup, where the speed of the slow storage does not matter at all for > the speed of pagedaemon, since there is no swap. > > > > > I'd hope that there'd be some kind of scaling that would take this > > variation into account. > > > > At Netflix, we're developing some patches to do more pro-active > > laundering of pages rather than waiting for the page daemon to kick > > in. We do this primarily to avoid flushing the uma caches which have > > performance implications that we need to address to smooth out the > > performance. Perhaps something like this would be a more general way > > to cope with this situation? > Page laundering speed cannot be a factor in deciding to trigger OOM. > If you can clean up something, then OOM must not be fired. > > The patch does not trigger OOM when no progress is made, immediately, > because it expects that some delay might indeed allow the async io > to finish and provide some pages to cover the deficit. Only when the > progress stalls completely, the ticking for OOM starts. > I don't understand the argument you're making below that the speed we launder pages doesn't matter coupled with the argument here that you are waiting for async I/O to complete helping avoid declaring OOM. My main concern with a counting heuristic is that it doesn't seem to take into effect how long the I/O takes directly and relies on the count to do that instead. It's cool that the count is a sysctl, but it seems that a more automatic scaling to the I/O speed or rate would be better. > Several iterations are performed before the deadlock is claimed. There > is no good heuristic which I could formulate to provide suitable > iterations count. But the current value was tested on both small > (32-64M) and large (32GB) machines and found satisfactory. Even then, > it is run-time tunable to allow to set it by operator for better-suited > value. > > OOM means that the user data is lost. Netflix might not care, due to > the specifics of the load, but I and most other users do care about > their data. I always prefer the kernel flushing the caches (not only UMA > caches, but also pv entries, UFS dirhashes, GPU unpinned buffers etc) > over deadlocking or killing the browser where I filled a long form, or > text editor, or any other unrecoverable state. If OOM is not fatal > for your data, you can reduce the value of the tunable to prefer kernel > caches over the user data. > I agree that's desirable. The changes we made keep more pages available to the system so we don't hit the low memory situation in the page deamon as often. That's what keeps the uma cachces and other low memory handlers in the system from firing in our systems. Not that we force them not to fire, but rather more pages are available more quickly than on a system where the page daemon alone is triggering scans. Netflix's workload shuffles a lot of pages into and out of memory, so proactive laundering before there's a big shortage helps a lot. > And, to make it clear, the current code which triggers OOM does not make > much sense. It mostly takes the count of free pages as the indicator > of OOM condition, which fails to account the simple fact that queued > pages may be laundred or discarded. As result, false OOM is triggered, > and it is easier to get false trigger on swap-less system due to swap > being always 'full'. This is orthogonal to the issue of the pagedaemon > performance. > The thinking that I had was that the proactive laundering patches we have push things out to disk more quickly and return pages to the free pool more quickly than waiting for the page daemon to do it. This would keep more free pages in the system more quickly than the current setup which should help avoid triggering OOM in the first place. I agree that the current OOM code triggers aren't the best as well. To be clear, I'm also not trying to stand in the way of committing the code. I'm trying to ask questions to see if there's a better way to accomplish the same thing. Warner From owner-freebsd-arm@freebsd.org Sat Nov 14 14:11:20 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F05EDA2E750 for ; Sat, 14 Nov 2015 14:11:20 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 66CF51633 for ; Sat, 14 Nov 2015 14:11:20 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. (pc233031.norma.com [IPv6:fd00::7fa] (may be forged)) by elf.hq.norma.perm.ru (8.14.9/8.14.9) with ESMTP id tAEEBDN7079172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 14 Nov 2015 19:11:14 +0500 (YEKT) (envelope-from emz@norma.perm.ru) From: "Eugene M. Zheganin" Subject: poudriere and java/openjdk8 To: freebsd-arm@freebsd.org Message-ID: <56474100.2050505@norma.perm.ru> Date: Sat, 14 Nov 2015 19:11:12 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Sat, 14 Nov 2015 19:11:14 +0500 (YEKT) X-Spam-Status: No hits=-100.4 bayes=0.0000 testhits AWL=0.080,BAYES_00=-1.9, RDNS_NONE=0.793,SPF_SOFTFAIL=0.665,USER_IN_WHITELIST=-100 autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on elf.hq.norma.perm.ru X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2015 14:11:21 -0000 Hi, I'm trying to build multimedia/kodi for raspberry pi using multimedia. However, java/openjdk8 fails to build: [...] checking headful support... include support for both headful and headless configure: Found potential Boot JDK using configure arguments configure: Potential Boot JDK found at /usr/local/bootstrap-openjdk is incorrect JDK version (Error: could not find libj ava.so); ignoring configure: (Your Boot JDK must be version 7 or 8) configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK configure exiting with result code 1 ===> Script "../../configure" failed unexpectedly. Please report the problem to java@FreeBSD.org [maintainer] and attach the "/wrkdirs/usr/ports/java/openjdk8/work/openjdk/common/autoconf/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** Error code 1 Stop. make: stopped in /usr/ports/java/openjdk8 However, when building java/openjdk8 on an actual device (with all dependencies installed from private pkg repo, - i.e. even same java/bootstrap-openjdk port) it's able to pass that point (only this took way long). Who's bug is that, and is that a bug ? Ports, poudriere itself, or may be I am doing something wrong ? Right now I'm trying to build openjdk on raspberry pi using actual board, I hope I will be able to build the rest using a package created from it. Thanks. Eugene. From owner-freebsd-arm@freebsd.org Sat Nov 14 14:42:17 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28668A2F10A for ; Sat, 14 Nov 2015 14:42:17 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DDEEC1805 for ; Sat, 14 Nov 2015 14:42:16 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: by ykdr82 with SMTP id r82so186152492ykd.3 for ; Sat, 14 Nov 2015 06:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=IkKwHgvBV7wEeBHB5YP10J8rQ0siBde8Z48yYWSpO6s=; b=eimwvOMJ8wDIPf2F0zs+bKM+hfuU/BzvvgiOTpZLIC3sk2OkhfClfsoVGLQISHbcrP qwc99ykbalqJIr6nMbPtD3CUEAwwPfjvXZnfR8lKeX2GVPAatviuTuI1Rs9urUDL4RC/ LL6YFRH65j20wam9gIPGWjOs/B3jXAV1wf/K/+OPNYoYCptR7s1+fJTxMynONH5Z90ZG SXSQOB4zKGaXcLRlOtH3EtMqqUDpExO3qIeqhNG2XsTeOcvDXn3fTN+VdJs2pTIxKfJN rzImGJN5NMu55ju7rPifdOpzUw0h5ykPQ9M/lrVyCWxdvTmjmWcTpBdzGzBv+3Q05ZEl mKMQ== X-Received: by 10.129.55.197 with SMTP id e188mr7896376ywa.332.1447512135965; Sat, 14 Nov 2015 06:42:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.217.17 with HTTP; Sat, 14 Nov 2015 06:41:36 -0800 (PST) In-Reply-To: <56474100.2050505@norma.perm.ru> References: <56474100.2050505@norma.perm.ru> From: =?UTF-8?Q?Mika=C3=ABl_Urankar?= Date: Sat, 14 Nov 2015 15:41:36 +0100 Message-ID: Subject: Re: poudriere and java/openjdk8 To: "Eugene M. Zheganin" Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2015 14:42:17 -0000 2015-11-14 15:11 GMT+01:00 Eugene M. Zheganin : > Hi, > > I'm trying to build multimedia/kodi for raspberry pi using multimedia. > However, java/openjdk8 fails to build: > > [...] > checking headful support... include support for both headful and headless > configure: Found potential Boot JDK using configure arguments > configure: Potential Boot JDK found at /usr/local/bootstrap-openjdk is > incorrect JDK version (Error: could not find libj > ava.so); ignoring > configure: (Your Boot JDK must be version 7 or 8) > configure: error: The path given by --with-boot-jdk does not contain a > valid Boot JDK > configure exiting with result code 1 > =3D=3D=3D> Script "../../configure" failed unexpectedly. > Please report the problem to java@FreeBSD.org [maintainer] and attach the > "/wrkdirs/usr/ports/java/openjdk8/work/openjdk/common/autoconf/config.log= " > including the output of the failure of your make command. Also, it might = be > a good idea to provide an overview of all packages installed on your syst= em > (e.g. a /usr/local/sbin/pkg-static info -g -Ea). > *** Error code 1 > > Stop. > make: stopped in /usr/ports/java/openjdk8 > > However, when building java/openjdk8 on an actual device (with all > dependencies installed from private pkg repo, - i.e. even same > java/bootstrap-openjdk port) it's able to pass that point (only this > took way long). Who's bug is that, and is that a bug ? Ports, poudriere > itself, or may be I am doing something wrong ? > > Right now I'm trying to build openjdk on raspberry pi using actual > board, I hope I will be able to build the rest using a package created > from it. Hi, If you build java with poudriere/qemu you need to put USE_PROCFS=3Dno in /usr/local/etc/poudriere.conf. You also need to lower down the memory requirement to build java with qemu = [1] If you use poudriere with native-xtools you'll need this upstream patch [2] or the one that sbruno@ submitted [3] I've started to work on kodi, you can find my work in progress (and hackish) patch at [4] You'll need to recompile multimedia/libass without harfbuzz option (otherwise it will deinstall misc/raspberrypi-userland) If you need a prebuilt package for openjdk8 -> [5] [1] http://mikael.urankar.free.fr/FreeBSD/arm/patches/java_openjdk8_qemu.pa= tch [2] http://hg.openjdk.java.net/jdk9/jdk9/rev/56c1a2adf6c4 [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D203747 [4] http://mikael.urankar.free.fr/FreeBSD/arm/patches/kodi.patch [5] http://mikael.urankar.free.fr/FreeBSD/arm/openjdk8-8.60.24.txz HTH, Mika=C3=ABl From owner-freebsd-arm@freebsd.org Sat Nov 14 16:29:22 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F847A2F254 for ; Sat, 14 Nov 2015 16:29:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C5531829; Sat, 14 Nov 2015 16:29:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id tAEGTCJZ084490 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 14 Nov 2015 18:29:12 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tAEGTCJZ084490 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tAEGTC1K084488; Sat, 14 Nov 2015 18:29:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 Nov 2015 18:29:12 +0200 From: Konstantin Belousov To: Warner Losh Cc: Michael Tuexen , freebsd-arm Subject: Re: Memory management issue on RPi? Message-ID: <20151114162912.GA5854@kib.kiev.ua> References: <20151112171221.GO2257@kib.kiev.ua> <984BA2E2-DD1A-4D05-858B-362192660E54@freebsd.org> <20151112180954.GP2257@kib.kiev.ua> <29DB8CF5-7569-4139-885A-8496993805A7@freebsd.org> <20151112200300.GR2257@kib.kiev.ua> <6452F207-A79B-42C6-A2CC-07BF454B7024@freebsd.org> <20151113183241.GA2257@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2015 16:29:22 -0000 On Fri, Nov 13, 2015 at 12:58:10PM -0700, Warner Losh wrote: > On Fri, Nov 13, 2015 at 11:32 AM, Konstantin Belousov > wrote: > > > On Fri, Nov 13, 2015 at 08:12:04AM -0700, Warner Losh wrote: > > > On Fri, Nov 13, 2015 at 1:23 AM, Michael Tuexen > > wrote: > > > > > > > > On 12 Nov 2015, at 21:03, Konstantin Belousov > > > > wrote: > > > > > > > > > > On Thu, Nov 12, 2015 at 08:47:29PM +0100, Michael Tuexen wrote: > > > > >>> On 12 Nov 2015, at 19:09, Konstantin Belousov > > > > > > wrote: > > > > >>> > > > > >>> On Thu, Nov 12, 2015 at 06:57:03PM +0100, Michael Tuexen wrote: > > > > >>>>> On 12 Nov 2015, at 18:12, Konstantin Belousov < > > kostikbel@gmail.com> > > > > wrote: > > > > >>>>> > > > > >>>>> On Thu, Nov 12, 2015 at 05:25:37PM +0100, Michael Tuexen wrote: > > > > >>>>>>> On 12 Nov 2015, at 13:18, Konstantin Belousov < > > kostikbel@gmail.com> > > > > wrote: > > > > >>>>>>> This is a known problem with the swap-less OOM. The following > > > > patch > > > > >>>>>>> should give you an immediate relief. You might want to tweak > > > > >>>>>>> sysctl vm.pageout_oom_seq if default value is not right, it was > > > > selected > > > > >>>>>>> by 'try and see' approach on very small (32 or 64MB) i386 VM. > > > > >>>>>> It just works... Will do some more testing... > > > > >>>>> > > > > >>>>> I am more interested in report if OOM was triggered when it > > should. > > > > >>>> How do I know? What output do you want to see? > > > > >>>> > > > > >>>> Best regards > > > > >>>> Michael > > > > >>>>> > > > > >>>>> Try running several instances of 'sort /dev/zero'. > > > > >>> ^^^^^^^^^^^^^ I already answered this. > > > > >>> Run sort /dev/zero, and see whether OOM fires. > > > > >> OK, now I understand. You want to see if some processes are getting > > > > killed. > > > > >> (I was thinking that you might want to see some sysctl counters or > > so). > > > > >> > > > > >> Results: > > > > >> * I'm able to compile/link/install a kernel from source. This was > > not > > > > >> possible before. > > > > >> * When running three instances of sort /dev/zero, two of them get > > killed > > > > >> after a while (less than a minute). One continued to run, but got > > also > > > > >> kill eventually. All via ssh login. > > > > > Exactly, this is the experiment I want to occur, and even more, the > > > > results > > > > > are good. > > > > Any plans to commit it? > > > > > > > > > > These changes are good as an experiment. The RPi's relative speed > > > of the CPU to the extremely slow SD card where pages are laundered > > > to. Deferring the calls to the actual OOM a bit is useful. However, > > > a simple count won't self-scale. What's good for the RPi likely is > > > likely poor for a CPU connected to faster storage. The OOM won't kill > > > things quickly enough in those circumstances. I imagine that there may > > > be a more complicated relationship between the rate of page dirtying > > > and laundering. > > The biggest problematic case fixed by this approach is *swap-less* > > setup, where the speed of the slow storage does not matter at all for > > the speed of pagedaemon, since there is no swap. > > > > > > > > I'd hope that there'd be some kind of scaling that would take this > > > variation into account. > > > > > > At Netflix, we're developing some patches to do more pro-active > > > laundering of pages rather than waiting for the page daemon to kick > > > in. We do this primarily to avoid flushing the uma caches which have > > > performance implications that we need to address to smooth out the > > > performance. Perhaps something like this would be a more general way > > > to cope with this situation? > > Page laundering speed cannot be a factor in deciding to trigger OOM. > > If you can clean up something, then OOM must not be fired. > > > > The patch does not trigger OOM when no progress is made, immediately, > > because it expects that some delay might indeed allow the async io > > to finish and provide some pages to cover the deficit. Only when the > > progress stalls completely, the ticking for OOM starts. > > > > I don't understand the argument you're making below that the > speed we launder pages doesn't matter coupled with the argument > here that you are waiting for async I/O to complete helping avoid > declaring OOM. Consider this as a bug in the current patch, that should be eventually fixed. I consider the positive effect of the patch as greatly exceeding the issue. Let me explain. As I already stated, OOM should not be triggered while pagedaemon might produce any reclamaible pages. The fact that there are writes in flight initiated by pagedaemon, means that we get some progress soon. The bug is that the writes in flight do not delay OOM trigger, instead I do several more iterations of inactive scan. It is easy for pagedaemon to increment a counter, which would be released on successfull pageout completion by vnode and swap pagers, and formally fix the bug. The problem, which prevents me from coding this easy solution right now is that our current i/o subsystem is deadlock-prone by requiring memory allocations on write. This holds both for geom and ZFS. If/when i/o would be fixed to not deadlock on low memory, the counter can be easily added. Instead, the current implementation actively fights against the deadlocked i/o by ignoring writes in progress. Large back-to-back counter is dumb but effective way to prevent false positives there. Of course it would not help if you have swap on iscsi volume which stalled for minute, but current value of dozen half-second sleeps and scans is good enough, verified by test. > > My main concern with a counting heuristic is that it doesn't seem > to take into effect how long the I/O takes directly and relies on the > count to do that instead. It's cool that the count is a sysctl, but it > seems that a more automatic scaling to the I/O speed or rate would > be better. > > > > Several iterations are performed before the deadlock is claimed. There > > is no good heuristic which I could formulate to provide suitable > > iterations count. But the current value was tested on both small > > (32-64M) and large (32GB) machines and found satisfactory. Even then, > > it is run-time tunable to allow to set it by operator for better-suited > > value. > > > > OOM means that the user data is lost. Netflix might not care, due to > > the specifics of the load, but I and most other users do care about > > their data. I always prefer the kernel flushing the caches (not only UMA > > caches, but also pv entries, UFS dirhashes, GPU unpinned buffers etc) > > over deadlocking or killing the browser where I filled a long form, or > > text editor, or any other unrecoverable state. If OOM is not fatal > > for your data, you can reduce the value of the tunable to prefer kernel > > caches over the user data. > > > > I agree that's desirable. The changes we made keep more pages available > to the system so we don't hit the low memory situation in the page deamon > as often. That's what keeps the uma cachces and other low memory handlers > in the system from firing in our systems. Not that we force them not to > fire, > but rather more pages are available more quickly than on a system where > the page daemon alone is triggering scans. Netflix's workload shuffles a lot > of pages into and out of memory, so proactive laundering before there's > a big shortage helps a lot. No, preventing depletion of the free pools is not related to the OOM logic. OOM must not trigger only because you are low on free memory (as it is now). Only when you are low _and_ you cannot make a progress should OOM start ticking. Or, in other words, when there is no other way to make forward progress other than destroy non-restorable data (not cache). > > > > And, to make it clear, the current code which triggers OOM does not make > > much sense. It mostly takes the count of free pages as the indicator > > of OOM condition, which fails to account the simple fact that queued > > pages may be laundred or discarded. As result, false OOM is triggered, > > and it is easier to get false trigger on swap-less system due to swap > > being always 'full'. This is orthogonal to the issue of the pagedaemon > > performance. > > > > The thinking that I had was that the proactive laundering patches we have > push things out to disk more quickly and return pages to the free pool > more quickly than waiting for the page daemon to do it. This would keep > more free pages in the system more quickly than the current setup which > should help avoid triggering OOM in the first place. > > I agree that the current OOM code triggers aren't the best as well. > > To be clear, I'm also not trying to stand in the way of committing the > code. I'm trying to ask questions to see if there's a better way to > accomplish the same thing. > > Warner