From owner-freebsd-arm@FreeBSD.ORG Wed Jul 30 01:30:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6D0915D for ; Wed, 30 Jul 2014 01:30:21 +0000 (UTC) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4E72212E for ; Wed, 30 Jul 2014 01:30:21 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id m1so515330oag.7 for ; Tue, 29 Jul 2014 18:30:20 -0700 (PDT) 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=YLZpQdcuUHiiOKm08c4EHIola6q1ciOQvQTIYxpRnnY=; b=onvr4SWDouHiAzMnMY4Z3fAumEl3vXgzdDiD+WW99zw8XMsQXd4jixnXzjxcMt3UUT 9K+fEIpjIByYWLdeteV63yH8u6bEUSayTINgiAFiRJ7oZhLwtKqUCTJcesmV0wAAWkWD eg/NvdEFUSwZyG9Dqr/ZyEglffx3/2bQYyTaH8QJZx/BfdidardkoMEMp61aaphlBdLs Tf2mDtFahZ6rouc+NFbxURuWmLU26Yrug4JMnngrXaJvZes5Vu/9DHM2l42k9WXfmGeN Cfzu9twTMapILVLwlRRRxMuWsHgcw/dDMy8K3CEU1SIhirgKpaqUl8+QCgP0086XB4Sp 6YGw== MIME-Version: 1.0 X-Received: by 10.60.33.35 with SMTP id o3mr928734oei.7.1406683820868; Tue, 29 Jul 2014 18:30:20 -0700 (PDT) Received: by 10.182.53.170 with HTTP; Tue, 29 Jul 2014 18:30:20 -0700 (PDT) Date: Tue, 29 Jul 2014 21:30:20 -0400 Message-ID: Subject: Porting to a Galaxy Centura From: Joe Nosay To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 01:30:21 -0000 Is this phone one of the ones with hypervisor in the CPU - a bit similar to IBM's history - or not? Has it been tested? Is there an available image for it? Thanks muchly From owner-freebsd-arm@FreeBSD.ORG Wed Jul 30 12:19:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FFB5288 for ; Wed, 30 Jul 2014 12:19:26 +0000 (UTC) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0EF3F259B for ; Wed, 30 Jul 2014 12:19:25 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id i50so1267073qgf.20 for ; Wed, 30 Jul 2014 05:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=pVDVXYbD46/6zSzSOXvGrpeutVoI7AzseN+AN1L0Wgo=; b=uDSda427sWCZcIcTct16YrTDV8REf6GN/K+QbrdCNj829AhFvE7sjZa+EwVhzaXine pIC1k5q/W7z9Pp+px9fRKGzTU5CLX6++o//egX/ow6+THjcdBLlb0ktnCEUmL7RmcZ29 zMAG7boEX51RbQoJt22yA3OMYAj9l8SDbiKzt09J+Hj+JbZGyzPhRPbkNkazzujLwyQv BcRm/mWEcP/0fiJKz7FXUxHVd6JYWH0sio5jt9CK7gTypdqBDHLAUD2WQDru5LozVGby GAdgTnxFo+hXwAS7Jtrc1UNEReOHhuj2xS9EdZVqdGxJl+ayc+3RDu1kjvXF6MHlVj4K MNxw== X-Received: by 10.229.184.9 with SMTP id ci9mr6227834qcb.11.1406722764995; Wed, 30 Jul 2014 05:19:24 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id s96sm2357509qgs.26.2014.07.30.05.19.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jul 2014 05:19:24 -0700 (PDT) Date: Wed, 30 Jul 2014 08:19:22 -0400 From: Shawn Webb To: freebsd-arm@freebsd.org Subject: Kernel Panic on BeagleBone Black Message-ID: <20140730121922.GI1869@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Encpt1P6Mxii2VuT" Content-Disposition: inline X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 12:19:26 -0000 --Encpt1P6Mxii2VuT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey All, I've just updated to a recent HEAD (r269240). I get a kernel panic almost immediately on boot. Below is the log. ==== Start of dump ==== cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq 40,41,42,43 on simplebus0 cpsw0: CPSW SS Version 1.12 (0) cpsw0: Initial queue size TX=128 RX=384 cpsw0: Ethernet address: 1c:ba:8c:e4:6d:6a cpsw0: Failed to read from PHY. cpsw0: attaching PHYs failed vm_fault(0xc070b9e0, 0, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc080eb28 FSR=00000005, FAR=00000018, spsr=80000193 r0 =c266f280, r1 =00000000, r2 =00000019, r3 =60000193 r4 =00000000, r5 =c266f280, r6 =00000006, r7 =c05c99b4 r8 =c266f280, r9 =c26ca28c, r10=c26c80c8, r11=c080eb88 r12=00000000, ssp=c080eb78, slr=c05ee1cc, pc =c03d2614 [ thread pid 0 tid 100000 ] Stopped at device_delete_child+0x14: ldr r1, [r4, #0x018] db> bt Tracing pid 0 tid 100000 td 0xc070b6d0 db_trace_self() at db_trace_self pc = 0xc05cdf5c lr = 0xc0237434 (db_stack_trace+0xf4) sp = 0xc080e820 fp = 0xc080e838 r10 = 0xc070a788 db_stack_trace() at db_stack_trace+0xf4 pc = 0xc0237434 lr = 0xc0236de8 (db_command+0x270) sp = 0xc080e840 fp = 0xc080e8e0 r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 db_command() at db_command+0x270 pc = 0xc0236de8 lr = 0xc0236b4c (db_command_loop+0x60) sp = 0xc080e8e8 fp = 0xc080e8f8 r4 = 0xc061b335 r5 = 0xc0630020 r6 = 0xc070a774 r7 = 0xc06bc188 r8 = 0xc0700894 r9 = 0xc0700890 r10 = 0x00000001 db_command_loop() at db_command_loop+0x60 pc = 0xc0236b4c lr = 0xc02395cc (db_trap+0xd8) sp = 0xc080e900 fp = 0xc080ea20 r4 = 0x00000000 r5 = 0xc070a780 r6 = 0xc07008b8 db_trap() at db_trap+0xd8 pc = 0xc02395cc lr = 0xc03dd270 (kdb_trap+0xbc) sp = 0xc080ea28 fp = 0xc080ea48 r4 = 0x00000000 r5 = 0x00000005 r6 = 0xc07008b8 r7 = 0xc06bc188 kdb_trap() at kdb_trap+0xbc pc = 0xc03dd270 lr = 0xc05e4bec (dab_fatal+0x174) sp = 0xc080ea50 fp = 0xc080ea68 r4 = 0xc080eb28 r5 = 0x00000005 r6 = 0x600001d3 r7 = 0x00000018 r8 = 0xc080eb28 r9 = 0x00000005 r10 = 0x00000001 dab_fatal() at dab_fatal+0x174 pc = 0xc05e4bec lr = 0xc05e49a0 (data_abort_handler+0x550) sp = 0xc080ea70 fp = 0xc080eb20 r4 = 0x00000013 r5 = 0xc070b6d0 r6 = 0xc080eeb0 r7 = 0xc070b6d0 data_abort_handler() at data_abort_handler+0x550 pc = 0xc05e49a0 lr = 0xc05cfaec (exception_exit) sp = 0xc080eb28 fp = 0xc080eb88 r4 = 0x00000000 r5 = 0xc266f280 r6 = 0x00000006 r7 = 0xc05c99b4 r8 = 0xc266f280 r9 = 0xc26ca28c r10 = 0xc26c80c8 exception_exit() at exception_exit pc = 0xc05cfaec lr = 0xc05ee1cc (cpsw_detach+0x2e4) sp = 0xc080eb78 fp = 0xc080eb88 r0 = 0xc266f280 r1 = 0x00000000 r2 = 0x00000019 r3 = 0x60000193 r4 = 0x00000000 r5 = 0xc266f280 r6 = 0x00000006 r7 = 0xc05c99b4 r8 = 0xc266f280 r9 = 0xc26ca28c r10 = 0xc26c80c8 r12 = 0x00000000 device_delete_child() at device_delete_child+0x14 pc = 0xc03d2614 lr = 0xc05ee1cc (cpsw_detach+0x2e4) sp = 0xc080eb90 fp = 0xc080ebc0 r4 = 0xc26c8000 r5 = 0xc26c8000 r6 = 0x00000006 cpsw_detach() at cpsw_detach+0x2e4 pc = 0xc05ee1cc lr = 0xc05edc48 (cpsw_attach+0x8c0) sp = 0xc080ebc8 fp = 0xc080ec38 r4 = 0x00000000 r5 = 0xc26c8000 r6 = 0x00000006 r7 = 0xc05c99b4 r8 = 0xc266f280 r9 = 0xc26ca28c cpsw_attach() at cpsw_attach+0x8c0 pc = 0xc05edc48 lr = 0xc03d3c88 (device_attach+0x310) sp = 0xc080ec40 fp = 0xc080ec78 r4 = 0xc266f280 r5 = 0xc266fb00 r6 = 0xc266f2b8 r7 = 0x00000000 r8 = 0xc064a54f r9 = 0x00000001 r10 = 0x00000000 device_attach() at device_attach+0x310 pc = 0xc03d3c88 lr = 0xc03d4e1c (bus_generic_attach+0x28) sp = 0xc080ec80 fp = 0xc080ec88 r4 = 0xc266f280 r5 = 0xc06d1120 r6 = 0xc26b0740 r7 = 0x00000008 r8 = 0xc266fb00 bus_generic_attach() at bus_generic_attach+0x28 pc = 0xc03d4e1c lr = 0xc023fca8 (simplebus_attach+0x634) sp = 0xc080ec90 fp = 0xc080ece8 r4 = 0xc266fb00 simplebus_attach() at simplebus_attach+0x634 pc = 0xc023fca8 lr = 0xc03d3c88 (device_attach+0x310) sp = 0xc080ecf0 fp = 0xc080ed28 r4 = 0xc266fb00 r5 = 0xc266fc00 r6 = 0xc266fb38 r7 = 0x00000000 r8 = 0xc064a54f r9 = 0xc0605e7c r10 = 0xc266fc00 device_attach() at device_attach+0x310 pc = 0xc03d3c88 lr = 0xc03d4e1c (bus_generic_attach+0x28) sp = 0xc080ed30 fp = 0xc080ed38 r4 = 0xc266fb00 r5 = 0x00000000 r6 = 0xc250f930 r7 = 0xc0605e38 r8 = 0xc06d1120 bus_generic_attach() at bus_generic_attach+0x28 pc = 0xc03d4e1c lr = 0xc0263ea0 (ofwbus_attach+0x4c4) sp = 0xc080ed40 fp = 0xc080ed88 r4 = 0x00000000 ofwbus_attach() at ofwbus_attach+0x4c4 pc = 0xc0263ea0 lr = 0xc03d3c88 (device_attach+0x310) sp = 0xc080ed90 fp = 0xc080edc8 r4 = 0xc266fc00 r5 = 0xc2670a00 r6 = 0xc266fc38 r7 = 0x00000000 r8 = 0xc064a54f r9 = 0xc070c300 r10 = 0x00000025 device_attach() at device_attach+0x310 pc = 0xc03d3c88 lr = 0xc03d4e1c (bus_generic_attach+0x28) sp = 0xc080edd0 fp = 0xc080edd8 r4 = 0xc266fc00 r5 = 0xc07092b4 r6 = 0xc2670a38 r7 = 0x00000000 r8 = 0xc064a54f bus_generic_attach() at bus_generic_attach+0x28 pc = 0xc03d4e1c lr = 0xc05d4008 (nexus_attach+0x6c) sp = 0xc080ede0 fp = 0xc080ede8 r4 = 0xc2670a00 nexus_attach() at nexus_attach+0x6c pc = 0xc05d4008 lr = 0xc03d3c88 (device_attach+0x310) sp = 0xc080edf0 fp = 0xc080ee28 r4 = 0xc2670a00 r5 = 0xc2670a50 device_attach() at device_attach+0x310 pc = 0xc03d3c88 lr = 0xc03d529c (bus_generic_new_pass+0xf0) sp = 0xc080ee30 fp = 0xc080ee48 r4 = 0xc2670a00 r5 = 0xc06c9510 r6 = 0xc06e78d0 r7 = 0x00000000 r8 = 0xc07006b0 bus_generic_new_pass() at bus_generic_new_pass+0xf0 pc = 0xc03d529c lr = 0xc03d1ab8 (bus_set_pass+0x84) sp = 0xc080ee50 fp = 0xc080ee68 r4 = 0xc2512720 r5 = 0xc06c9510 r6 = 0xc2670e00 r7 = 0xc07006b0 r8 = 0x7fffffff bus_set_pass() at bus_set_pass+0x84 pc = 0xc03d1ab8 lr = 0xc03d67d0 (root_bus_configure+0x10) sp = 0xc080ee70 fp = 0xc080ee70 r4 = 0x00000001 r5 = 0xc070b6c0 r6 = 0x00000000 r7 = 0xc252c8f0 r8 = 0xc070bedc r9 = 0xc070bed8 root_bus_configure() at root_bus_configure+0x10 pc = 0xc03d67d0 lr = 0xc05c87e0 (configure+0xc) sp = 0xc080ee78 fp = 0xc080ee78 configure() at configure+0xc pc = 0xc05c87e0 lr = 0xc0337bf4 (mi_startup+0x120) sp = 0xc080ee80 fp = 0xc080eea8 mi_startup() at mi_startup+0x120 pc = 0xc0337bf4 lr = 0xc0200238 (virt_done+0x44) sp = 0xc080eeb0 fp = 0x00000000 r4 = 0xc0200268 r5 = 0xc0714000 r6 = 0x8804da40 r7 = 0x8020014c r8 = 0x0000000a r9 = 0xc07fe000 virt_done() at virt_done+0x44 pc = 0xc0200238 lr = 0xc0200238 (virt_done+0x44) sp = 0xc080eeb0 fp = 0x00000000 Unable to unwind further ==== End of dump ==== If there's anything I can do, let me know. Thanks, Shawn --Encpt1P6Mxii2VuT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT2OLKAAoJEGqEZY9SRW7u8hAQAMPzedHwEj5kPo2wh7+zrdva QmwBpOtq2HD605sNRK61FvBEPMq0tZq8lNafEKPD4fsn3pmF5iW945b/xT7gTq1J XYsh9YtsKJXBTZDo0VY1T/yng2upbTFYvf/SPAlObevHMzy0RXAc7cSFrFbzTLl9 MfpipPb4Lc4qIpPJtWJNRw48cIjIIK3MgZXjQD8UYk5V+GA1FbL7G0hlSQAHM7iY A+ocaLHIE4+ADReJ59HvkZmf8crL/Dr96Y1JEsAm2Y9ZgvGaVme4N5UNMv/Q4Af9 OBGzvuuplJLUvLoipfLX/7hL4acoyvoN/QGL+q6fBoa0+Xcpkbyffcbf8vf1Sf4P IcONhCUO77oadVXZAxM5yDeqE4yfhIfzNYBoAUSvf9uESup68v3MNba6Nb63gnxl qHlyl5aBUaOzm7ayOe4gOH1T1OhPi/WQGeSRR+44otHyCDX1Jz63HEvy2UPV3Skt u+cL/rIljtOZo7rTHE6oOTNM3bs0o2QjD2TAuLb0z2W+yO8xUJGSml5hRvA7lPjW nQldO3ZmWLxHkFAOc7BQyByVYmL2zaV5mCUGV0N0IMN7nZrONkdSKnbrU4Wf79aV 1am5PjUlWD0p+08a4dx5C2025nKZ6moiNzy8nk4PQAPCsK4KZvTmXthihDid9epg ZicNugYcYwVhL1Eb3gH6 =7hkH -----END PGP SIGNATURE----- --Encpt1P6Mxii2VuT-- From owner-freebsd-arm@FreeBSD.ORG Wed Jul 30 17:30:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7861EFD5 for ; Wed, 30 Jul 2014 17:30:39 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D34A2BAC for ; Wed, 30 Jul 2014 17:30:38 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XCXhw-000M6u-58; Wed, 30 Jul 2014 17:30:32 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6UHUV2I001466; Wed, 30 Jul 2014 11:30:31 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+fLdYHDRc206wrxxifplU7 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Kernel Panic on BeagleBone Black From: Ian Lepore To: Shawn Webb In-Reply-To: <20140730121922.GI1869@pwnie.vrt.sourcefire.com> References: <20140730121922.GI1869@pwnie.vrt.sourcefire.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Jul 2014 11:30:30 -0600 Message-ID: <1406741430.56408.218.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 17:30:39 -0000 On Wed, 2014-07-30 at 08:19 -0400, Shawn Webb wrote: > Hey All, > > I've just updated to a recent HEAD (r269240). I get a kernel panic > almost immediately on boot. Below is the log. > > ==== Start of dump ==== > cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq 40,41,42,43 on simplebus0 > cpsw0: CPSW SS Version 1.12 (0) > cpsw0: Initial queue size TX=128 RX=384 > cpsw0: Ethernet address: 1c:ba:8c:e4:6d:6a > cpsw0: Failed to read from PHY. > cpsw0: attaching PHYs failed > > vm_fault(0xc070b9e0, 0, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc080eb28 > FSR=00000005, FAR=00000018, spsr=80000193 > r0 =c266f280, r1 =00000000, r2 =00000019, r3 =60000193 > r4 =00000000, r5 =c266f280, r6 =00000006, r7 =c05c99b4 > r8 =c266f280, r9 =c26ca28c, r10=c26c80c8, r11=c080eb88 > r12=00000000, ssp=c080eb78, slr=c05ee1cc, pc =c03d2614 > > [ thread pid 0 tid 100000 ] > Stopped at device_delete_child+0x14: ldr r1, [r4, #0x018] > db> bt > Tracing pid 0 tid 100000 td 0xc070b6d0 [...] > Unable to unwind further > ==== End of dump ==== > > If there's anything I can do, let me know. > > Thanks, > > Shawn Hmm, I can't reproduce this on my BB White at r269302. The real error is "Failed to read from PHY". The kernel abort was just accidental fallout from trying to clean up and detach the ethernet driver since it failed to init properly (error paths never get tested enough). What was the prior release you were on that worked okay? Since I just made a series of changes to armv6 busdma I'm tempted to suspect them, even though there shouldn't be any DMA involved in talking to the PHY. Still, it would be interesting to know if backing off to r269134 makes the problem go away. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Jul 30 17:43:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3CFF6A4; Wed, 30 Jul 2014 17:43:37 +0000 (UTC) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 705DF2EBB; Wed, 30 Jul 2014 17:43:37 +0000 (UTC) Received: by mail-qg0-f50.google.com with SMTP id q108so2050186qgd.37 for ; Wed, 30 Jul 2014 10:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=MTDYLiCOSr7qTugZ5LAW66FnevIn3oLDPtJlfMh6N3Y=; b=fVQYXHJPHZeyQDVJiQaSOpgvdaxQQvW1zQJrkmLOgLvv235K8sszhPMek1n/dLyP02 gdvBB9OBlF1ZN8NGLL+qWu3IHW/O5CrIgHvS4VcN3JavMy+oBybvO3CIMJT4eeUyhFfS tMDHBIWIJFSK1msJAiPQBLd1zGbGMU8zZXpQ2/XXeYXaJgMMtyQa9i6etLuxgX+u40hj LyvnznOdVMB2gzXdK8ejwSlKFGIBXoeg6XtQ8AL1QHSfURWXVVdsgyG1SHfwM3dEBB6C DymgE3+n4HUIu2LgQS0glMJIlEf90y8i+0hWLp3W4+mvnep0YSElnbuzhpDJuJe+hwEC Zulg== X-Received: by 10.224.137.193 with SMTP id x1mr9722785qat.0.1406742215049; Wed, 30 Jul 2014 10:43:35 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id t3sm5063533qak.18.2014.07.30.10.43.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jul 2014 10:43:34 -0700 (PDT) Date: Wed, 30 Jul 2014 13:43:32 -0400 From: Shawn Webb To: Ian Lepore Subject: Re: Kernel Panic on BeagleBone Black Message-ID: <20140730174332.GJ1869@pwnie.vrt.sourcefire.com> References: <20140730121922.GI1869@pwnie.vrt.sourcefire.com> <1406741430.56408.218.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ed/6oDxOLijJh8b0" Content-Disposition: inline In-Reply-To: <1406741430.56408.218.camel@revolution.hippie.lan> X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 17:43:37 -0000 --ed/6oDxOLijJh8b0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Jul 30, 2014 11:30 AM -0600, Ian Lepore wrote: > On Wed, 2014-07-30 at 08:19 -0400, Shawn Webb wrote: > > Hey All, > >=20 > > I've just updated to a recent HEAD (r269240). I get a kernel panic > > almost immediately on boot. Below is the log. > >=20 > > =3D=3D=3D=3D Start of dump =3D=3D=3D=3D > > cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq= 40,41,42,43 on simplebus0 > > cpsw0: CPSW SS Version 1.12 (0) > > cpsw0: Initial queue size TX=3D128 RX=3D384 > > cpsw0: Ethernet address: 1c:ba:8c:e4:6d:6a > > cpsw0: Failed to read from PHY. > > cpsw0: attaching PHYs failed > >=20 > > vm_fault(0xc070b9e0, 0, 1, 0) -> 1 > > Fatal kernel mode data abort: 'Translation Fault (S)' > > trapframe: 0xc080eb28 > > FSR=3D00000005, FAR=3D00000018, spsr=3D80000193 > > r0 =3Dc266f280, r1 =3D00000000, r2 =3D00000019, r3 =3D60000193 > > r4 =3D00000000, r5 =3Dc266f280, r6 =3D00000006, r7 =3Dc05c99b4 > > r8 =3Dc266f280, r9 =3Dc26ca28c, r10=3Dc26c80c8, r11=3Dc080eb88 > > r12=3D00000000, ssp=3Dc080eb78, slr=3Dc05ee1cc, pc =3Dc03d2614 > >=20 > > [ thread pid 0 tid 100000 ] > > Stopped at device_delete_child+0x14: ldr r1, [r4, #0x018] > > db> bt > > Tracing pid 0 tid 100000 td 0xc070b6d0 > [...] > > Unable to unwind further > > =3D=3D=3D=3D End of dump =3D=3D=3D=3D > >=20 > > If there's anything I can do, let me know. > >=20 > > Thanks, > >=20 > > Shawn >=20 > Hmm, I can't reproduce this on my BB White at r269302. The real error > is "Failed to read from PHY". The kernel abort was just accidental > fallout from trying to clean up and detach the ethernet driver since it > failed to init properly (error paths never get tested enough). >=20 > What was the prior release you were on that worked okay? >=20 > Since I just made a series of changes to armv6 busdma I'm tempted to > suspect them, even though there shouldn't be any DMA involved in talking > to the PHY. Still, it would be interesting to know if backing off to > r269134 makes the problem go away. >=20 > -- Ian >=20 >=20 The release prior worked okay. I did get occasional kernel panics (though, I didn't have time to do a backtrace and post here about it). I'm unsure what svn rev the prior build was at. I can try reverting that revision you mentioned tonight and report back if you'd like. Thanks, Shawn --ed/6oDxOLijJh8b0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT2S7EAAoJEGqEZY9SRW7u8gIQAMB1UlBgHB7rhBrkJEKRHfgr 1JIa5SEaAt9Ls58qJsVmCCCFz7JpnC30el0Gxi2GGhs/Z6/zCqZkY4H2K4asiUx6 Ud8EsQUTvfdO9eMCu34kzCnUtunQO++5hUGFrifjTvnwqUCtkI+031b5ELgo1vHc dbe6vyiPDzh+x0L/1ydzZ9CjwMfyy7pcnjvxzLkZLhgAxEEzdQhzahz7JATi8I+L ivs6jUwYO+1aMFI2pz8jcb0qfiY9qyAN8myB7p7rtVRf0Hrkkit4ohVYJYnmyBfD xqL78BsGQUN4qafdIykgDQuKVn21VO4aSi5SqTwXchoTprUWklxCqteJ96lb4bMz iFZGpasJJz0KFfaux7uCu4f5qKvyuPGa6G3Lb14pJ9yL6QRRbRgveD246uP7OSxg iScXNF9hdBz0zSpVowaZfeTtEOWlQgVs0s/lpES232W4G7Eq5MLQJp4wjIBwtN4d ZJcn/vEbNo+K3bymYnKpFJLBqOGPu/W/wAphO0fnhcs6lXEZuNiDq0WHJDLGQ3/O yyo8rvmRDp0IVurYx+EFmLrl0TMjmIf/oA2Y9sdFJrhjdhCy7lZC/imLzPYjeR4m Tt5juOfxwIJqy8+M3WSv65SF2Qeu4HvPfO36Zya4vq19l9Xcl/KQ6+Xoae4d5s7T ltM55qA1jhcL7Ep6kNwo =YpaN -----END PGP SIGNATURE----- --ed/6oDxOLijJh8b0-- From owner-freebsd-arm@FreeBSD.ORG Wed Jul 30 17:56:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 737E09B1 for ; Wed, 30 Jul 2014 17:56:02 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46E952034 for ; Wed, 30 Jul 2014 17:56:01 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XCY6a-000Bkg-T5; Wed, 30 Jul 2014 17:56:01 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6UHtxSo001516; Wed, 30 Jul 2014 11:55:59 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+BYAA8ocvHpX92zjzJoRe7 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Kernel Panic on BeagleBone Black From: Ian Lepore To: Shawn Webb In-Reply-To: <20140730174332.GJ1869@pwnie.vrt.sourcefire.com> References: <20140730121922.GI1869@pwnie.vrt.sourcefire.com> <1406741430.56408.218.camel@revolution.hippie.lan> <20140730174332.GJ1869@pwnie.vrt.sourcefire.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Jul 2014 11:55:59 -0600 Message-ID: <1406742959.56408.220.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 17:56:02 -0000 On Wed, 2014-07-30 at 13:43 -0400, Shawn Webb wrote: > On Jul 30, 2014 11:30 AM -0600, Ian Lepore wrote: > > On Wed, 2014-07-30 at 08:19 -0400, Shawn Webb wrote: > > > Hey All, > > > > > > I've just updated to a recent HEAD (r269240). I get a kernel panic > > > almost immediately on boot. Below is the log. > > > > > > ==== Start of dump ==== > > > cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff irq 40,41,42,43 on simplebus0 > > > cpsw0: CPSW SS Version 1.12 (0) > > > cpsw0: Initial queue size TX=128 RX=384 > > > cpsw0: Ethernet address: 1c:ba:8c:e4:6d:6a > > > cpsw0: Failed to read from PHY. > > > cpsw0: attaching PHYs failed > > > > > > vm_fault(0xc070b9e0, 0, 1, 0) -> 1 > > > Fatal kernel mode data abort: 'Translation Fault (S)' > > > trapframe: 0xc080eb28 > > > FSR=00000005, FAR=00000018, spsr=80000193 > > > r0 =c266f280, r1 =00000000, r2 =00000019, r3 =60000193 > > > r4 =00000000, r5 =c266f280, r6 =00000006, r7 =c05c99b4 > > > r8 =c266f280, r9 =c26ca28c, r10=c26c80c8, r11=c080eb88 > > > r12=00000000, ssp=c080eb78, slr=c05ee1cc, pc =c03d2614 > > > > > > [ thread pid 0 tid 100000 ] > > > Stopped at device_delete_child+0x14: ldr r1, [r4, #0x018] > > > db> bt > > > Tracing pid 0 tid 100000 td 0xc070b6d0 > > [...] > > > Unable to unwind further > > > ==== End of dump ==== > > > > > > If there's anything I can do, let me know. > > > > > > Thanks, > > > > > > Shawn > > > > Hmm, I can't reproduce this on my BB White at r269302. The real error > > is "Failed to read from PHY". The kernel abort was just accidental > > fallout from trying to clean up and detach the ethernet driver since it > > failed to init properly (error paths never get tested enough). > > > > What was the prior release you were on that worked okay? > > > > Since I just made a series of changes to armv6 busdma I'm tempted to > > suspect them, even though there shouldn't be any DMA involved in talking > > to the PHY. Still, it would be interesting to know if backing off to > > r269134 makes the problem go away. > > > > -- Ian > > > > > > The release prior worked okay. I did get occasional kernel panics > (though, I didn't have time to do a backtrace and post here about it). > I'm unsure what svn rev the prior build was at. I can try reverting that > revision you mentioned tonight and report back if you'd like. > > Thanks, > > Shawn Don't revert that single revision I mentioned, revert the whole source tree to that rev (or to speed things up, really just the sys tree, and rebuild just the kernel). -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Jul 30 23:02:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3F74C3EF; Wed, 30 Jul 2014 23:02:38 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DBEFF21E3; Wed, 30 Jul 2014 23:02:37 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id j7so1697945qaq.28 for ; Wed, 30 Jul 2014 16:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=qgDdDl3F9+vLWD4oXBuhEkF/ljOqhISGfAAgh9l+eLE=; b=pNp/t2xiKV0hCcifiyS28GkgRJ9ACc0RwF7UWkz1yXCSjlFsh1nvUhgH6tOhaR420n B/fYC0QLfP/FIjWxpCy9kgllnb8s/+DftfbueARzn/gSdMowbpS4AVDOQT5o6sFzQbn9 koncXpo0XB0fE/lB3p+YaWLhiS7ix0MwkjqAfgNhKHJO4J5IsWBLcx7o1JzlaI8N6WJZ m7S4XlEPX7nny2jxAk5A/1KCIoA5kwRMoDBCBzfOnztzfpo0f7fABIxy8pdUTgJrHXxF y1vylkXCRIIzpEv3qj+GSwSDLxT/yulc7rTnGEZFlQmmJvURsdYr47euBuioVpUkI+9p dx8A== X-Received: by 10.224.55.131 with SMTP id u3mr11829483qag.98.1406761357004; Wed, 30 Jul 2014 16:02:37 -0700 (PDT) Received: from pwnie.vrt.sourcefire.com (moist.vrt.sourcefire.com. [198.148.79.134]) by mx.google.com with ESMTPSA id g3sm6316433qar.31.2014.07.30.16.02.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jul 2014 16:02:36 -0700 (PDT) Date: Wed, 30 Jul 2014 19:02:34 -0400 From: Shawn Webb To: Ian Lepore Subject: Re: Kernel Panic on BeagleBone Black Message-ID: <20140730230234.GM1869@pwnie.vrt.sourcefire.com> References: <20140730121922.GI1869@pwnie.vrt.sourcefire.com> <1406741430.56408.218.camel@revolution.hippie.lan> <20140730174332.GJ1869@pwnie.vrt.sourcefire.com> <1406742959.56408.220.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pFpMklMRdxwSC3Yi" Content-Disposition: inline In-Reply-To: <1406742959.56408.220.camel@revolution.hippie.lan> X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 23:02:38 -0000 --pFpMklMRdxwSC3Yi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Jul 30, 2014 11:55 AM -0600, Ian Lepore wrote: > On Wed, 2014-07-30 at 13:43 -0400, Shawn Webb wrote: > > On Jul 30, 2014 11:30 AM -0600, Ian Lepore wrote: > > > On Wed, 2014-07-30 at 08:19 -0400, Shawn Webb wrote: > > > > Hey All, > > > >=20 > > > > I've just updated to a recent HEAD (r269240). I get a kernel panic > > > > almost immediately on boot. Below is the log. > > > >=20 > > > > =3D=3D=3D=3D Start of dump =3D=3D=3D=3D > > > > cpsw0: <3-port Switch Ethernet Subsystem> mem 0x4a100000-0x4a103fff= irq 40,41,42,43 on simplebus0 > > > > cpsw0: CPSW SS Version 1.12 (0) > > > > cpsw0: Initial queue size TX=3D128 RX=3D384 > > > > cpsw0: Ethernet address: 1c:ba:8c:e4:6d:6a > > > > cpsw0: Failed to read from PHY. > > > > cpsw0: attaching PHYs failed > > > >=20 > > > > vm_fault(0xc070b9e0, 0, 1, 0) -> 1 > > > > Fatal kernel mode data abort: 'Translation Fault (S)' > > > > trapframe: 0xc080eb28 > > > > FSR=3D00000005, FAR=3D00000018, spsr=3D80000193 > > > > r0 =3Dc266f280, r1 =3D00000000, r2 =3D00000019, r3 =3D60000193 > > > > r4 =3D00000000, r5 =3Dc266f280, r6 =3D00000006, r7 =3Dc05c99b4 > > > > r8 =3Dc266f280, r9 =3Dc26ca28c, r10=3Dc26c80c8, r11=3Dc080eb88 > > > > r12=3D00000000, ssp=3Dc080eb78, slr=3Dc05ee1cc, pc =3Dc03d2614 > > > >=20 > > > > [ thread pid 0 tid 100000 ] > > > > Stopped at device_delete_child+0x14: ldr r1, [r4, #0= x018] > > > > db> bt > > > > Tracing pid 0 tid 100000 td 0xc070b6d0 > > > [...] > > > > Unable to unwind further > > > > =3D=3D=3D=3D End of dump =3D=3D=3D=3D > > > >=20 > > > > If there's anything I can do, let me know. > > > >=20 > > > > Thanks, > > > >=20 > > > > Shawn > > >=20 > > > Hmm, I can't reproduce this on my BB White at r269302. The real error > > > is "Failed to read from PHY". The kernel abort was just accidental > > > fallout from trying to clean up and detach the ethernet driver since = it > > > failed to init properly (error paths never get tested enough). > > >=20 > > > What was the prior release you were on that worked okay? > > >=20 > > > Since I just made a series of changes to armv6 busdma I'm tempted to > > > suspect them, even though there shouldn't be any DMA involved in talk= ing > > > to the PHY. Still, it would be interesting to know if backing off to > > > r269134 makes the problem go away. > > >=20 > > > -- Ian > > >=20 > > >=20 > >=20 > > The release prior worked okay. I did get occasional kernel panics > > (though, I didn't have time to do a backtrace and post here about it). > > I'm unsure what svn rev the prior build was at. I can try reverting that > > revision you mentioned tonight and report back if you'd like. > >=20 > > Thanks, > >=20 > > Shawn >=20 > Don't revert that single revision I mentioned, revert the whole source > tree to that rev (or to speed things up, really just the sys tree, and > rebuild just the kernel). >=20 > -- Ian >=20 >=20 I just updated to HEAD from just a few moments ago. No kernel panic. Good to go. Thanks, Shawn --pFpMklMRdxwSC3Yi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT2XmKAAoJEGqEZY9SRW7ue8MP/0uNGKCPoCsR8WVkDqQ0LYH9 hgrmTyRnsDuMuiZii9OGNiCMwYFT9ruTOGXmzynzA5CTFTJejrNVk5wuJqvu2I2C XyvZ8z7QK5qzp8/pa89nuv4dUjlBlujIbTKGSu9WwG4BR9TRA/2vLfGO6EWclgvC tuToRKBTlWAydBiEEHp1NcgiuMRVHF97KbSxTvYLD3ba6bOMRxkTB9cPYzT0aMpu iBh0JUeYSDb6Txt2bZv8dKHBEY+v0zO5dCNFtmN1KgGnWSqi6hWyTnl9fiJEbJVb lap72gZPJgnRFIm0TBeF0j0mcBtwFagbfDOUtJ70IFUWo+fdzUBYnbyXTWj5WSnO XnoOo6i/6BxrAtqLCsr1RAVnP4399refg3q0L6YlaiHOGZoyzqxEvnyBq7UlACdH 2MKAheM3Ob1Z7nDeZDrcFgtovQ+EfuuTGmrgtYgYOefL/9/rwZtSI8DMd7AkWxph +1EHGj6ogmSM0AxUxxjCZQ1CuG0+nCLxIYOgEFgEYymgeQHEfx8lNIvfBS5wcYDy GgLuODVPJmDGKI7/GUk94L5VWgcskGyaWhPOC7IunsdPHIA71Q8HiBIPSJXuKqYG 7vdEQIGhxp3gHwmcq2JuNMMjV2hmHcQ5bDkxXK5VNi3YEdN+Sfnxh6h8MVuYeqQg 1JPcxrSGS0X+D+b1Qq6F =aJ6C -----END PGP SIGNATURE----- --pFpMklMRdxwSC3Yi-- From owner-freebsd-arm@FreeBSD.ORG Fri Aug 1 15:21:36 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50005531 for ; Fri, 1 Aug 2014 15:21:36 +0000 (UTC) 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 "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15F1D2EB0 for ; Fri, 1 Aug 2014 15:21:36 +0000 (UTC) Received: from [192.168.1.104] (p508F342F.dip0.t-ipconnect.de [80.143.52.47]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 830CD1C104F9B for ; Fri, 1 Aug 2014 17:21:32 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Can't compile libatomic_ops on RPi Message-Id: Date: Fri, 1 Aug 2014 17:21:31 +0200 To: "freebsd-arm@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 15:21:36 -0000 Dear all, I'm trying to build libatomic_ops on r269265 on a RPi B as part of = building git from the ports collection (this worked in the past). However, I got: ... /bin/sh ../libtool --tag=3DCC --mode=3Dcompile cc -DHAVE_CONFIG_H = -I../src -I../src -fPIC -Wall -Wextra -O -pipe -MT atomic_ops_stack.lo = -MD -MP -MF .deps/atomic_ops_stack.Tpo -c -o atomic_ops_stack.lo = atomic_ops_stack.c libtool: compile: cc -DHAVE_CONFIG_H -I../src -I../src -fPIC -Wall = -Wextra -O -pipe -MT atomic_ops_stack.lo -MD -MP -MF = .deps/atomic_ops_stack.Tpo -c atomic_ops_stack.c -o atomic_ops_stack.o /tmp/atomic_ops_stack-390892.s: Assembler messages: /tmp/atomic_ops_stack-390892.s:73: Error: selected processor does not = support `ldrexd r6,r7,[r0]' /tmp/atomic_ops_stack-390892.s:81: Error: selected processor does not = support `strexd r3,r4,r5,[r0]' cc: error: assembler command failed with exit code 1 (use -v to see = invocation) *** [atomic_ops_stack.lo] Error code 1 make[4]: stopped in = /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src 1 error make[4]: stopped in = /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src *** [all] Error code 2 make[3]: stopped in = /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src 1 error make[3]: stopped in = /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src *** [all-recursive] Error code 1 make[2]: stopped in = /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0 1 error make[2]: stopped in = /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0 =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to the maintainer. *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/libatomic_ops *** Error code 1 Stop. make: stopped in /usr/ports/devel/libatomic_ops > uname -a FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #85 r269265M: Tue = Jul 29 23:55:33 CEST 2014 = root@bsd5.fh-muenster.de:/usr/home/tuexen/obj/arm.armv6/usr/home/tuexen/he= ad/sys/RPI-B arm Any idea what is going wrong? Best regards Michael= From owner-freebsd-arm@FreeBSD.ORG Fri Aug 1 15:33:50 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDCE9867; Fri, 1 Aug 2014 15:33:50 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A286A2FF9; Fri, 1 Aug 2014 15:33:50 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XDEpy-000GQX-Ih; Fri, 01 Aug 2014 15:33:42 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s71FXfhN006305; Fri, 1 Aug 2014 09:33:41 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18JM6SnF1uZlCVwYLLpCdPJ X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Can't compile libatomic_ops on RPi From: Ian Lepore To: Michael Tuexen In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 01 Aug 2014 09:33:40 -0600 Message-ID: <1406907220.56408.248.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 15:33:50 -0000 On Fri, 2014-08-01 at 17:21 +0200, Michael Tuexen wrote: > Dear all, > > I'm trying to build libatomic_ops on r269265 on a RPi B as part of building git from > the ports collection (this worked in the past). However, I got: > > ... > /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I../src -I../src -fPIC -Wall -Wextra -O -pipe -MT atomic_ops_stack.lo -MD -MP -MF .deps/atomic_ops_stack.Tpo -c -o atomic_ops_stack.lo atomic_ops_stack.c > libtool: compile: cc -DHAVE_CONFIG_H -I../src -I../src -fPIC -Wall -Wextra -O -pipe -MT atomic_ops_stack.lo -MD -MP -MF .deps/atomic_ops_stack.Tpo -c atomic_ops_stack.c -o atomic_ops_stack.o > /tmp/atomic_ops_stack-390892.s: Assembler messages: > /tmp/atomic_ops_stack-390892.s:73: Error: selected processor does not support `ldrexd r6,r7,[r0]' > /tmp/atomic_ops_stack-390892.s:81: Error: selected processor does not support `strexd r3,r4,r5,[r0]' > cc: error: assembler command failed with exit code 1 (use -v to see invocation) > *** [atomic_ops_stack.lo] Error code 1 > > make[4]: stopped in /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src > 1 error > > make[4]: stopped in /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src > *** [all] Error code 2 > > make[3]: stopped in /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src > 1 error > > make[3]: stopped in /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src > *** [all-recursive] Error code 1 > > make[2]: stopped in /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0 > 1 error > > make[2]: stopped in /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0 > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > the maintainer. > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/devel/libatomic_ops > *** Error code 1 > > Stop. > make: stopped in /usr/ports/devel/libatomic_ops > > uname -a > FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #85 r269265M: Tue Jul 29 23:55:33 CEST 2014 root@bsd5.fh-muenster.de:/usr/home/tuexen/obj/arm.armv6/usr/home/tuexen/head/sys/RPI-B arm > > Any idea what is going wrong? > > Best regards > Michael Try adding CPUTYPE=arm1176jzf-s to /etc/make.conf -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Aug 1 17:49:55 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1970511; Fri, 1 Aug 2014 17:49:55 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 856352F69; Fri, 1 Aug 2014 17:49:54 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XDGxl-000Fej-Cw; Fri, 01 Aug 2014 17:49:53 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s71Hnqgl006486; Fri, 1 Aug 2014 11:49:52 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/EsGFlAiGD4mFiXhf/HVGb X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Can't compile libatomic_ops on RPi From: Ian Lepore To: Michael Tuexen In-Reply-To: <1406907220.56408.248.camel@revolution.hippie.lan> References: <1406907220.56408.248.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Fri, 01 Aug 2014 11:49:51 -0600 Message-ID: <1406915391.56408.257.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 17:49:55 -0000 On Fri, 2014-08-01 at 09:33 -0600, Ian Lepore wrote: > On Fri, 2014-08-01 at 17:21 +0200, Michael Tuexen wrote: > > Dear all, > > > > I'm trying to build libatomic_ops on r269265 on a RPi B as part of building git from > > the ports collection (this worked in the past). However, I got: > > > > ... > > /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I../src -I../src -fPIC -Wall -Wextra -O -pipe -MT atomic_ops_stack.lo -MD -MP -MF .deps/atomic_ops_stack.Tpo -c -o atomic_ops_stack.lo atomic_ops_stack.c > > libtool: compile: cc -DHAVE_CONFIG_H -I../src -I../src -fPIC -Wall -Wextra -O -pipe -MT atomic_ops_stack.lo -MD -MP -MF .deps/atomic_ops_stack.Tpo -c atomic_ops_stack.c -o atomic_ops_stack.o > > /tmp/atomic_ops_stack-390892.s: Assembler messages: > > /tmp/atomic_ops_stack-390892.s:73: Error: selected processor does not support `ldrexd r6,r7,[r0]' > > /tmp/atomic_ops_stack-390892.s:81: Error: selected processor does not support `strexd r3,r4,r5,[r0]' > > cc: error: assembler command failed with exit code 1 (use -v to see invocation) > > *** [atomic_ops_stack.lo] Error code 1 > > > > make[4]: stopped in /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src > > 1 error > > > > make[4]: stopped in /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src > > *** [all] Error code 2 > > > > make[3]: stopped in /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src > > 1 error > > > > make[3]: stopped in /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src > > *** [all-recursive] Error code 1 > > > > make[2]: stopped in /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0 > > 1 error > > > > make[2]: stopped in /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0 > > ===> Compilation failed unexpectedly. > > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > > the maintainer. > > *** Error code 1 > > > > Stop. > > make[1]: stopped in /usr/ports/devel/libatomic_ops > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/ports/devel/libatomic_ops > > > uname -a > > FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #85 r269265M: Tue Jul 29 23:55:33 CEST 2014 root@bsd5.fh-muenster.de:/usr/home/tuexen/obj/arm.armv6/usr/home/tuexen/head/sys/RPI-B arm > > > > Any idea what is going wrong? > > > > Best regards > > Michael > > Try adding CPUTYPE=arm1176jzf-s to /etc/make.confCPUTYPE=arm1176jzf-s > > -- Ian Update on this... as of r269387, arm1176jzf-s is the default cpu type in clang (as it has always been in gcc) and there's no need to add CPUTYPE. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Aug 1 18:41:54 2014 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD188AE3; Fri, 1 Aug 2014 18:41:54 +0000 (UTC) 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 "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E1A4262B; Fri, 1 Aug 2014 18:41:54 +0000 (UTC) Received: from [192.168.1.104] (p508F342F.dip0.t-ipconnect.de [80.143.52.47]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id AD8161C0B4054; Fri, 1 Aug 2014 20:41:50 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Can't compile libatomic_ops on RPi From: Michael Tuexen In-Reply-To: <1406915391.56408.257.camel@revolution.hippie.lan> Date: Fri, 1 Aug 2014 20:41:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <640B6C6A-B270-4F8D-B80D-B2778D18B703@freebsd.org> References: <1406907220.56408.248.camel@revolution.hippie.lan> <1406915391.56408.257.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 18:41:54 -0000 On 01 Aug 2014, at 19:49, Ian Lepore wrote: > On Fri, 2014-08-01 at 09:33 -0600, Ian Lepore wrote: >> On Fri, 2014-08-01 at 17:21 +0200, Michael Tuexen wrote: >>> Dear all, >>>=20 >>> I'm trying to build libatomic_ops on r269265 on a RPi B as part of = building git from >>> the ports collection (this worked in the past). However, I got: >>>=20 >>> ... >>> /bin/sh ../libtool --tag=3DCC --mode=3Dcompile cc = -DHAVE_CONFIG_H -I../src -I../src -fPIC -Wall -Wextra -O -pipe -MT = atomic_ops_stack.lo -MD -MP -MF .deps/atomic_ops_stack.Tpo -c -o = atomic_ops_stack.lo atomic_ops_stack.c >>> libtool: compile: cc -DHAVE_CONFIG_H -I../src -I../src -fPIC -Wall = -Wextra -O -pipe -MT atomic_ops_stack.lo -MD -MP -MF = .deps/atomic_ops_stack.Tpo -c atomic_ops_stack.c -o atomic_ops_stack.o >>> /tmp/atomic_ops_stack-390892.s: Assembler messages: >>> /tmp/atomic_ops_stack-390892.s:73: Error: selected processor does = not support `ldrexd r6,r7,[r0]' >>> /tmp/atomic_ops_stack-390892.s:81: Error: selected processor does = not support `strexd r3,r4,r5,[r0]' >>> cc: error: assembler command failed with exit code 1 (use -v to see = invocation) >>> *** [atomic_ops_stack.lo] Error code 1 >>>=20 >>> make[4]: stopped in = /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src >>> 1 error >>>=20 >>> make[4]: stopped in = /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src >>> *** [all] Error code 2 >>>=20 >>> make[3]: stopped in = /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src >>> 1 error >>>=20 >>> make[3]: stopped in = /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0/src >>> *** [all-recursive] Error code 1 >>>=20 >>> make[2]: stopped in = /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0 >>> 1 error >>>=20 >>> make[2]: stopped in = /usr/ports/devel/libatomic_ops/work/libatomic_ops-7.4.0 >>> =3D=3D=3D> Compilation failed unexpectedly. >>> Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to >>> the maintainer. >>> *** Error code 1 >>>=20 >>> Stop. >>> make[1]: stopped in /usr/ports/devel/libatomic_ops >>> *** Error code 1 >>>=20 >>> Stop. >>> make: stopped in /usr/ports/devel/libatomic_ops >>>> uname -a >>> FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #85 r269265M: = Tue Jul 29 23:55:33 CEST 2014 = root@bsd5.fh-muenster.de:/usr/home/tuexen/obj/arm.armv6/usr/home/tuexen/he= ad/sys/RPI-B arm >>>=20 >>> Any idea what is going wrong? >>>=20 >>> Best regards >>> Michael >>=20 >> Try adding CPUTYPE=3Darm1176jzf-s to = /etc/make.confCPUTYPE=3Darm1176jzf-s >>=20 >> -- Ian >=20 > Update on this... as of r269387, arm1176jzf-s is the default cpu type = in > clang (as it has always been in gcc) and there's no need to add = CPUTYPE. Ahh, great. I can also confirm that using the above setting in = /etc/make.conf resolves the issue. I guess it makes sense to try a newer build... Thanks for the help. Best regards Michael >=20 > -- Ian >=20 >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Fri Aug 1 20:38:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 569951E8 for ; Fri, 1 Aug 2014 20:38:55 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0049024A4 for ; Fri, 1 Aug 2014 20:38:54 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XDJbE-000Iv2-6O; Fri, 01 Aug 2014 20:38:48 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s71KckXX006742; Fri, 1 Aug 2014 14:38:46 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+PVmfpLZUTzyz2T7dDA2/I X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Compilation for ARM, patches From: Ian Lepore To: Stepan Dyatkovskiy In-Reply-To: <539F9830.9030004@narod.ru> References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> <539A2261.4070705@narod.ru> <539A62E2.20003@narod.ru> <1402676121.20883.231.camel@revolution.hippie.lan> <539B24DB.4090005@narod.ru> <1402677258.20883.235.camel@revolution.hippie.lan> <539B5F68.5020008@narod.ru> <1402692723.20883.237.camel@revolution.hippie.lan> <539F9830.9030004@narod.ru> Content-Type: text/plain; charset="us-ascii" Date: Fri, 01 Aug 2014 14:38:45 -0600 Message-ID: <1406925525.56408.264.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 20:38:55 -0000 On Tue, 2014-06-17 at 07:21 +0600, Stepan Dyatkovskiy wrote: > Hi all, > Ian, > May be you right about bug, but it's not allowed neither in gas, nor in > clang. > The issue actually was in double purpose of ENTRY: > 1. It just defines function entry. > 2. It defines .fnstart for exception unwinding. > > For example memset and bzero functions are overlapped in kernel, and > this is a reason of producing overlapping of .fnstart/.fnend definitions. > "bzero" starts earlier, and then enters into "memset" contents. So, it > looks like, actually we need .fnstart for "dzero" only (am I right?). > > I have attached patches that allows to compile kernel with binutils-2.23 > (compiled from ports/devel/cross-binutils, TGTARCH=arm, > TGTABI=unknown-freebsd). > > I have introduced EENTRY, that just defines label without .fnstart. > Please look what I did (I suppose I could be wrong with such approach, > since after this patch I have a lot of Warning: null messages). > > Anyways these patches allows to run kernel with cortex-a9 options. > Sorry it took so long, but I've finally gotten these patches committed, as of r269395, thanks for submitting them. You were right about the nested .fnstart being an error. I learned more about the unwind info while working on the c++ exception bugs -- multiple .fnstart without a .fnend in between can't be expressed correctly at all, the tools are right to complain about that. I made some changes to the EENTRY() stuff, if I didn't get it right and it needs more changes to compile with your newer binutils, just let me know and I'll adjust as needed. I also committed the .arch_extension for ti_smc.S, which actually required changing our base binutils to recognize .arch_extension (but it was worth it, because if we start correcting our code now it will be ready when we update our tools in base). -- Ian > P.S.: I also confused about u-boot version for pandaboard. uboot-2011.12 > manages to load kernel.bin, but failed to deal with ubldr (perhaps > because of absence of uboot-api). > Latest u-boot version loads ubldr, but then it failes to boot kernel: > loader> load boot/kernel/kernel > boot/kernel/kernel data=0x492b48+0x2d4b8 <-- hangs here > > Thanks, > Stepan. > > Ian Lepore wrote: > > That sounds like a compiler bug to me, there's nothing invalid about > > nesting a function within another function in assembler code. But, it's > > the only toolchain we've got, so I guess we'll have to figure out some > > other way to do things. > > > > That "nearby" comment I think is very old and outdated. > > > > -- Ian > > > > On Sat, 2014-06-14 at 02:30 +0600, Stepan Dyatkovskiy wrote: > >> Modern compilers forbid to use nested .fnstart constructions (actually > >> nested ENTRY uses). But FreeBSD code has them in few places. For > >> example, in arm/exception.S file (see swi_entry). I saw the comment > >> nearby swi_exit definition, but now quite understand how it relates with > >> nested ENTRY uses... > >> It looks like several entries were intruduced just because of > >> alternative names for the same function. But I'm not sure... > >> > >> Thanks! > >> > >> -Stepan > >> > >> Why we need them > >> Ian Lepore wrote: > >>> On Fri, 2014-06-13 at 22:20 +0600, Stepan Dyatkovskiy wrote: > >>>> Hi Ian, > >>>> Yup. I have done it with default options. That works fine. Thanks! > >>>> > >>>> But, currently we need to compare launch times for kernel that was > >>>> compiled with cortex-a9 options and for kernel that was compiled with > >>>> cortex-a15 options. > >>>> > >>>> The reason of doing that is some improvements in clang backend that > >>>> promises faster execution for (-mcpu=cortex-a15). So we would like to > >>>> check it on FreeBSD kernel, since we going to use this OS as base for > >>>> our applications. > >>>> > >>>> -Stepan > >>> > >>> I wonder if it is upset that the nesting is backwards, like > >>> > >>> NP_ENTRY(btext) > >>> ASENTRY_NP(_start) > >>> ... > >>> END(btext) > >>> END(_start) > >>> > >>> Maybe try switching the order of the END macros? If that doesn't help, > >>> try removing the btext macros completely, I don't think they're needed > >>> by anything these days. > >>> > >>> -- Ian > >>> > >>> > >> > >> _______________________________________________ > >> freebsd-arm@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sat Aug 2 16:30:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96B6CD3; Sat, 2 Aug 2014 16:30:25 +0000 (UTC) Received: from forward2l.mail.yandex.net (forward2l.mail.yandex.net [IPv6:2a02:6b8:0:1819::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47C492170; Sat, 2 Aug 2014 16:30:24 +0000 (UTC) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward2l.mail.yandex.net (Yandex) with ESMTP id E6E361AC1728; Sat, 2 Aug 2014 20:30:21 +0400 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 55B852C4954; Sat, 2 Aug 2014 20:30:21 +0400 (MSK) Received: from 188-122-240-86.clients.tlt.100megabit.ru (188-122-240-86.clients.tlt.100megabit.ru [188.122.240.86]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id sjZTM3pWro-UKFmbWdA; Sat, 2 Aug 2014 20:30:20 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 07f2e71f-327f-4fbe-a3fd-2fffd2cac2e5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1406997020; bh=eUW0CUr8KRdICVGbwNqlh5tmb7yXgaPVbxne1jFfFGA=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=UwZRoCO3qt92J/IP6udJO/zmYPR53P4o1eszMaYcwifEZ3UaGAN36jykPHnv3/fFq +qMBouo7mNszqXx8Tz4UWLomqQ4U+ikP5F416/TdJnmPQ0dIQoQ9K+uBuYCaSnV8GO HjDTlrkttxEAnpikk8XGmyo9nLIh7MixIUWXDc7Y= Authentication-Results: smtp4h.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <53DD121B.5040207@narod.ru> Date: Sat, 02 Aug 2014 22:30:19 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Compilation for ARM, patches References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> <539A2261.4070705@narod.ru> <539A62E2.20003@narod.ru> <1402676121.20883.231.camel@revolution.hippie.lan> <539B24DB.4090005@narod.ru> <1402677258.20883.235.camel@revolution.hippie.lan> <539B5F68.5020008@narod.ru> <1402692723.20883.237.camel@revolution.hippie.lan> <539F9830.9030004@narod.ru> <1406925525.56408.264.camel@revolution.hippie.lan> In-Reply-To: <1406925525.56408.264.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, sdyatkovskiy@accesssoftek.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 16:30:25 -0000 Hi Ian, Thanks! Of course I'll let you know if we get some issues in future (I think we will try to provide freebsd community with new patches in this case ;-)) -Stepan Ian Lepore wrote: > On Tue, 2014-06-17 at 07:21 +0600, Stepan Dyatkovskiy wrote: >> Hi all, >> Ian, >> May be you right about bug, but it's not allowed neither in gas, nor in >> clang. >> The issue actually was in double purpose of ENTRY: >> 1. It just defines function entry. >> 2. It defines .fnstart for exception unwinding. >> >> For example memset and bzero functions are overlapped in kernel, and >> this is a reason of producing overlapping of .fnstart/.fnend definitions. >> "bzero" starts earlier, and then enters into "memset" contents. So, it >> looks like, actually we need .fnstart for "dzero" only (am I right?). >> >> I have attached patches that allows to compile kernel with binutils-2.23 >> (compiled from ports/devel/cross-binutils, TGTARCH=arm, >> TGTABI=unknown-freebsd). >> >> I have introduced EENTRY, that just defines label without .fnstart. >> Please look what I did (I suppose I could be wrong with such approach, >> since after this patch I have a lot of Warning: null messages). >> >> Anyways these patches allows to run kernel with cortex-a9 options. >> > > Sorry it took so long, but I've finally gotten these patches committed, > as of r269395, thanks for submitting them. You were right about the > nested .fnstart being an error. I learned more about the unwind info > while working on the c++ exception bugs -- multiple .fnstart without > a .fnend in between can't be expressed correctly at all, the tools are > right to complain about that. > > I made some changes to the EENTRY() stuff, if I didn't get it right and > it needs more changes to compile with your newer binutils, just let me > know and I'll adjust as needed. > > I also committed the .arch_extension for ti_smc.S, which actually > required changing our base binutils to recognize .arch_extension (but it > was worth it, because if we start correcting our code now it will be > ready when we update our tools in base). > > -- Ian > > >> P.S.: I also confused about u-boot version for pandaboard. uboot-2011.12 >> manages to load kernel.bin, but failed to deal with ubldr (perhaps >> because of absence of uboot-api). >> Latest u-boot version loads ubldr, but then it failes to boot kernel: >> loader> load boot/kernel/kernel >> boot/kernel/kernel data=0x492b48+0x2d4b8 <-- hangs here >> >> Thanks, >> Stepan. >> >> Ian Lepore wrote: >>> That sounds like a compiler bug to me, there's nothing invalid about >>> nesting a function within another function in assembler code. But, it's >>> the only toolchain we've got, so I guess we'll have to figure out some >>> other way to do things. >>> >>> That "nearby" comment I think is very old and outdated. >>> >>> -- Ian >>> >>> On Sat, 2014-06-14 at 02:30 +0600, Stepan Dyatkovskiy wrote: >>>> Modern compilers forbid to use nested .fnstart constructions (actually >>>> nested ENTRY uses). But FreeBSD code has them in few places. For >>>> example, in arm/exception.S file (see swi_entry). I saw the comment >>>> nearby swi_exit definition, but now quite understand how it relates with >>>> nested ENTRY uses... >>>> It looks like several entries were intruduced just because of >>>> alternative names for the same function. But I'm not sure... >>>> >>>> Thanks! >>>> >>>> -Stepan >>>> >>>> Why we need them >>>> Ian Lepore wrote: >>>>> On Fri, 2014-06-13 at 22:20 +0600, Stepan Dyatkovskiy wrote: >>>>>> Hi Ian, >>>>>> Yup. I have done it with default options. That works fine. Thanks! >>>>>> >>>>>> But, currently we need to compare launch times for kernel that was >>>>>> compiled with cortex-a9 options and for kernel that was compiled with >>>>>> cortex-a15 options. >>>>>> >>>>>> The reason of doing that is some improvements in clang backend that >>>>>> promises faster execution for (-mcpu=cortex-a15). So we would like to >>>>>> check it on FreeBSD kernel, since we going to use this OS as base for >>>>>> our applications. >>>>>> >>>>>> -Stepan >>>>> >>>>> I wonder if it is upset that the nesting is backwards, like >>>>> >>>>> NP_ENTRY(btext) >>>>> ASENTRY_NP(_start) >>>>> ... >>>>> END(btext) >>>>> END(_start) >>>>> >>>>> Maybe try switching the order of the END macros? If that doesn't help, >>>>> try removing the btext macros completely, I don't think they're needed >>>>> by anything these days. >>>>> >>>>> -- Ian >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> freebsd-arm@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >>> >>> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > >