From owner-freebsd-arm@FreeBSD.ORG Sun May 17 00:24:39 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6D966A6 for ; Sun, 17 May 2015 00:24:39 +0000 (UTC) Received: from pmta2.delivery4.ore.mailhop.org (pmta2.delivery4.ore.mailhop.org [54.200.247.200]) by mx1.freebsd.org (Postfix) with SMTP id A5BCD1770 for ; Sun, 17 May 2015 00:24:39 +0000 (UTC) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 17 May 2015 00:24:32 +0000 (UTC) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t4H0OVZ9011197; Sat, 16 May 2015 18:24:31 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1431822271.91685.43.camel@freebsd.org> Subject: Re: RPI2 performance comparison using LINPACK From: Ian Lepore To: Erik Moe Cc: freebsd-arm@freebsd.org Date: Sat, 16 May 2015 18:24:31 -0600 In-Reply-To: <1B7FC791-3DEE-4310-8BE0-BBB3C8E34C78@rcn.com> References: <1B7FC791-3DEE-4310-8BE0-BBB3C8E34C78@rcn.com> Content-Type: text/plain; charset="iso-8859-13" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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, 17 May 2015 00:24:39 -0000 On Sat, 2015-05-16 at 18:14 -0500, Erik Moe wrote: [...] > > The FreeBSD results were very similar to Linux as long as it was compiled with "-mfloat-abi=softfpˇ and the cpu is running at the full 900Mhz. I tried to compile the Linux version of LINPACK using "-mfloat-abi=softˇ, but got the error "linpack uses VFP register arguments, /tmp/cc24nslQ.o does notˇ, so I assume that it doesn˙t support a soft floating-point implementation. FreeBSD must default to "-mfloat-abi=softˇ. Raspbian must default to "-mfloat-abi=hardˇ because that˙s the only option that would work neither "-mfloat-abi=softˇ or -mfloat-abi=softfpˇ would link. Will hard float work for FreeBSD if I compile with "TARGET_ARCH=armv6hfˇ? > > Erik If you do "make " it gets built with system default options, which include softfp. If you do "cc ..." you get exactly the options you put on the command line. If your overall system is built as TARGET_ARCH=armv6hf instead of armv6 then hardfloat is the default whether you use make or cc directly. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun May 17 00:29:53 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45C497A3 for ; Sun, 17 May 2015 00:29:53 +0000 (UTC) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) by mx1.freebsd.org (Postfix) with SMTP id 258041792 for ; Sun, 17 May 2015 00:29:53 +0000 (UTC) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 17 May 2015 00:29:59 +0000 (UTC) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t4H0Tmkb011205; Sat, 16 May 2015 18:29:48 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1431822588.91685.48.camel@freebsd.org> Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] From: Ian Lepore To: Svatopluk Kraus Cc: Keith White , "freebsd-arm@freebsd.org" Date: Sat, 16 May 2015 18:29:48 -0600 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 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: Sun, 17 May 2015 00:29:53 -0000 On Fri, 2015-05-15 at 10:18 +0200, Svatopluk Kraus wrote: > On Fri, May 15, 2015 at 2:13 AM, Keith White wrote: > > On Thu, 14 May 2015, Svatopluk Kraus wrote: > > > >> On Thu, May 14, 2015 at 2:03 AM, Keith White > >> wrote: > >>> > >>> I get the following panic when trying to load an mfs_root on a > >>> reasonably current BBB image: > >>> > >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read > >>> trapframe: 0xdd43fd50 > >>> FSR=00000005, FAR=01211ef0, spsr=20000113 > >>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 > >>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 > >>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 > >>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 > >>> > >>> [ thread pid 4 tid 100054 ] > >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} > >>> db> > >>> > >>> Hints, suggestions? > >>> > >>> ...keith > >>> > >>> --------------------------------- > >>> More (trimmed) details from boot: > >>> > >>> ... > >>> U-Boot 2014.10 (Mar 19 2015 - 18:29:51) > >>> ... > >>> FreeBSD/armv6hf U-Boot loader, Revision 1.2 > >>> (kwhite@freebsd11, Tue Mar 17 22:23:25 EDT 2015) > >>> ... > >>> Found U-Boot device: disk > >>> Checking unit=1 slice= partition=... good. > >>> /boot/kernel/kernel data=0x505c2c+0x923d4 syms=[0x4+0x606a0+0x4+0x65ed4] > >>> /boot/kernel/snd_uaudio.ko text=0xed3c data=0x620+0x10 > >>> syms=[0x4+0x1ec0+0x4+0x1a2f] > >>> ... > >>> Type '?' for a list of commands, 'help' for more detailed help. > >>> loader> load -t mfs_root /rootfs > >>> /rootfs size=0x858000 > >>> loader> boot -asv > >>> Booting... > >>> /boot/dtb/beaglebone-black.dtb size=0x24b4 > >>> Loaded DTB from file 'beaglebone-black.dtb'. > >>> Kernel entry at 0x80200100... > >>> Kernel args: -asv > >>> KDB: debugger backends: ddb > >>> KDB: current backend: ddb > >>> Copyright (c) 1992-2015 The FreeBSD Project. > >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > >>> The Regents of the University of California. All rights reserved. > >>> FreeBSD is a registered trademark of The FreeBSD Foundation. > >>> FreeBSD 11.0-CURRENT #1 r282672M: Tue May 12 06:57:24 EDT 2015 > >>> > >>> kwhite@freebsd11:/usr/obj/arm.armv6hf/tank/RPI/head/sys/BEAGLEBONE-LOCAL > >>> arm > >>> FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 > >>> WARNING: WITNESS option enabled, expect reduced performance. > >>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc1219000. > >>> ... > >>> mmc0: Probing bus > >>> usbus0: 480Mbps High Speed USB v2.0 > >>> usbus1: 480Mbps High Speed USB v2.0 > >>> md0: Preloaded image 8749056 bytes at 0x9b9f00 > >>> ugen1.1: at usbus1 > >>> uhub0: > >>> on > >>> usbus1 > >>> ugen0.1: at usbus0 > >>> uhub1: > >>> on > >>> usbus0 > >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read > >>> trapframe: 0xdd43fd50 > >>> FSR=00000005, FAR=01211ef0, spsr=20000113 > >>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 > >>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 > >>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 > >>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 > >>> > >>> [ thread pid 4 tid 100054 ] > >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} > >> > >> > >> > >> Well, FAR (fault address) points to user address space. System is > >> still in boot process and no user address should be used. The first > >> thing is to find out if arguments pushed to bcopy() in > >> mdstart_preload() are correct. Can you print them out? > >> ... > > > > > > Thanks for the hint! After a little digging with ddb, it appears > > that the fault address is missing an offset of KERNBASE (0xc0000000). > > The mfs_root being found at 0x9b9f00 ("md0: preloaded image at") + > > KERNBASE (0xc0000000). The following patch fixes the symptom, and > > allows a boot to successfully complete. The resulting md is also > > usable as /. > > > > I'm sure there's a more correct patch? > > > > Index: sys/dev/md/md.c > > =================================================================== > > --- sys/dev/md/md.c (revision 282672) > > +++ sys/dev/md/md.c (working copy) > > @@ -1590,7 +1590,11 @@ > > len = preload_fetch_size(mod); > > if (ptr != NULL && len != 0) { > > sx_xlock(&md_sx); > > +#ifdef __arm__ > > + md_preloaded(KERNBASE + ptr, len, name); > > +#else > > md_preloaded(ptr, len, name); > > +#endif > > sx_xunlock(&md_sx); > > } > > } > > > Thanks for debugging it. The preload_fetch_addr() already uses > preload_addr_relocate to adjust returned address. IMO, a patch should > either deal with preload_addr_relocate and init it correctly or fix > MODINFO_ADDR info in kernel modules. Now, preload_addr_relocate is set > only when FREEBSD_BOOT_LOADER is defined. In this moment, I know > nothing about how MODINFO_ADDR info is generated. > > BTW, physical address space starts at 0x80000000 on BBB and KERNBASE > is 0xC0000000, so I would be expecting that preload_addr_relocate > should be set to 0x40000000. The FAR is 0x01211ef0, so it's not > physical address. And as your patch helps, it's an offset to either > physical or virtual address space. So it looks more like MODINFO_ADDR > info problem. > I think the problem here is likely to be in ubldr. Today I tried to recreate this and all I could get was complete system lockup right after the kernel copyright displayed. Eventually I noticed that your root image is less than 10MB, so I created a little image about the same size as yours and put init(8) in it, and with that I get the same panic you do (different physical address, I'm doing it on a wandboard). I think there are at least two separate problems here. ubldr isn't setting the right metadata for the load address, and then separately from that, trying to load really big files corrupts memory somehow in a way that locks up the kernel. I'll keep poking at it. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun May 17 01:12:16 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C87FB1D; Sun, 17 May 2015 01:12:16 +0000 (UTC) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) (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 F3E471BFC; Sun, 17 May 2015 01:12:14 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 80F7C50F0B; Sun, 17 May 2015 10:12:11 +0900 (JST) Received: from artemis (unknown [172.18.0.21]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 528B550F08; Sun, 17 May 2015 10:12:11 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: "Ian Lepore" , "Svatopluk Kraus" Cc: "Keith White" , References: <1431822588.91685.48.camel@freebsd.org> In-Reply-To: <1431822588.91685.48.camel@freebsd.org> Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] Date: Sun, 17 May 2015 10:12:09 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP 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, 17 May 2015 01:12:16 -0000 -------------------------------------------------- From: "Ian Lepore" Sent: Sunday, May 17, 2015 9:29 AM To: "Svatopluk Kraus" Cc: "Keith White" ; Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] > On Fri, 2015-05-15 at 10:18 +0200, Svatopluk Kraus wrote: >> On Fri, May 15, 2015 at 2:13 AM, Keith White wrote: >> > On Thu, 14 May 2015, Svatopluk Kraus wrote: >> > >> >> On Thu, May 14, 2015 at 2:03 AM, Keith White >> >> wrote: >> >>> >> >>> I get the following panic when trying to load an mfs_root on a >> >>> reasonably current BBB image: >> >>> >> >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> >>> trapframe: 0xdd43fd50 >> >>> FSR=00000005, FAR=01211ef0, spsr=20000113 >> >>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 >> >>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 >> >>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 >> >>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 >> >>> >> >>> [ thread pid 4 tid 100054 ] >> >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >> >>> db> >> >>> >> >>> Hints, suggestions? >> >>> >> >>> ...keith >> >>> >> >>> --------------------------------- >> >>> More (trimmed) details from boot: >> >>> >> >>> ... >> >>> U-Boot 2014.10 (Mar 19 2015 - 18:29:51) >> >>> ... >> >>> FreeBSD/armv6hf U-Boot loader, Revision 1.2 >> >>> (kwhite@freebsd11, Tue Mar 17 22:23:25 EDT 2015) >> >>> ... >> >>> Found U-Boot device: disk >> >>> Checking unit=1 slice= partition=... good. >> >>> /boot/kernel/kernel data=0x505c2c+0x923d4 syms=[0x4+0x606a0+0x4+0x65ed4] >> >>> /boot/kernel/snd_uaudio.ko text=0xed3c data=0x620+0x10 >> >>> syms=[0x4+0x1ec0+0x4+0x1a2f] >> >>> ... >> >>> Type '?' for a list of commands, 'help' for more detailed help. >> >>> loader> load -t mfs_root /rootfs >> >>> /rootfs size=0x858000 >> >>> loader> boot -asv >> >>> Booting... >> >>> /boot/dtb/beaglebone-black.dtb size=0x24b4 >> >>> Loaded DTB from file 'beaglebone-black.dtb'. >> >>> Kernel entry at 0x80200100... >> >>> Kernel args: -asv >> >>> KDB: debugger backends: ddb >> >>> KDB: current backend: ddb >> >>> Copyright (c) 1992-2015 The FreeBSD Project. >> >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> >>> The Regents of the University of California. All rights reserved. >> >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >> >>> FreeBSD 11.0-CURRENT #1 r282672M: Tue May 12 06:57:24 EDT 2015 >> >>> >> >>> kwhite@freebsd11:/usr/obj/arm.armv6hf/tank/RPI/head/sys/BEAGLEBONE-LOCAL >> >>> arm >> >>> FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 >> >>> WARNING: WITNESS option enabled, expect reduced performance. >> >>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc1219000. >> >>> ... >> >>> mmc0: Probing bus >> >>> usbus0: 480Mbps High Speed USB v2.0 >> >>> usbus1: 480Mbps High Speed USB v2.0 >> >>> md0: Preloaded image 8749056 bytes at 0x9b9f00 >> >>> ugen1.1: at usbus1 >> >>> uhub0: >> >>> on >> >>> usbus1 >> >>> ugen0.1: at usbus0 >> >>> uhub1: >> >>> on >> >>> usbus0 >> >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> >>> trapframe: 0xdd43fd50 >> >>> FSR=00000005, FAR=01211ef0, spsr=20000113 >> >>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 >> >>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 >> >>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 >> >>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 >> >>> >> >>> [ thread pid 4 tid 100054 ] >> >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >> >> >> >> >> >> >> >> Well, FAR (fault address) points to user address space. System is >> >> still in boot process and no user address should be used. The first >> >> thing is to find out if arguments pushed to bcopy() in >> >> mdstart_preload() are correct. Can you print them out? >> >> ... >> > >> > >> > Thanks for the hint! After a little digging with ddb, it appears >> > that the fault address is missing an offset of KERNBASE (0xc0000000). >> > The mfs_root being found at 0x9b9f00 ("md0: preloaded image at") + >> > KERNBASE (0xc0000000). The following patch fixes the symptom, and >> > allows a boot to successfully complete. The resulting md is also >> > usable as /. >> > >> > I'm sure there's a more correct patch? >> > >> > Index: sys/dev/md/md.c >> > =================================================================== >> > --- sys/dev/md/md.c (revision 282672) >> > +++ sys/dev/md/md.c (working copy) >> > @@ -1590,7 +1590,11 @@ >> > len = preload_fetch_size(mod); >> > if (ptr != NULL && len != 0) { >> > sx_xlock(&md_sx); >> > +#ifdef __arm__ >> > + md_preloaded(KERNBASE + ptr, len, name); >> > +#else >> > md_preloaded(ptr, len, name); >> > +#endif >> > sx_xunlock(&md_sx); >> > } >> > } >> >> >> Thanks for debugging it. The preload_fetch_addr() already uses >> preload_addr_relocate to adjust returned address. IMO, a patch should >> either deal with preload_addr_relocate and init it correctly or fix >> MODINFO_ADDR info in kernel modules. Now, preload_addr_relocate is set >> only when FREEBSD_BOOT_LOADER is defined. In this moment, I know >> nothing about how MODINFO_ADDR info is generated. >> >> BTW, physical address space starts at 0x80000000 on BBB and KERNBASE >> is 0xC0000000, so I would be expecting that preload_addr_relocate >> should be set to 0x40000000. The FAR is 0x01211ef0, so it's not >> physical address. And as your patch helps, it's an offset to either >> physical or virtual address space. So it looks more like MODINFO_ADDR >> info problem. >> > > I think the problem here is likely to be in ubldr. Today I tried to > recreate this and all I could get was complete system lockup right after > the kernel copyright displayed. Eventually I noticed that your root > image is less than 10MB, so I created a little image about the same size > as yours and put init(8) in it, and with that I get the same panic you > do (different physical address, I'm doing it on a wandboard). > > I think there are at least two separate problems here. ubldr isn't > setting the right metadata for the load address, and then separately > from that, trying to load really big files corrupts memory somehow in a > way that locks up the kernel. > > I'll keep poking at it. I posted about ubldr/mfsroot last year. no one interest it... http://lists.freebsd.org/pipermail/freebsd-arm/2014-December/009839.html I think ubldr should be fixed. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Sun May 17 02:41:09 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43A2A174; Sun, 17 May 2015 02:41:09 +0000 (UTC) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.site.uottawa.ca", Issuer "PositiveSSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE73813AA; Sun, 17 May 2015 02:41:08 +0000 (UTC) Received: from [10.0.2.15] (dsl-66-225-165-235.vianet.ca [66.225.165.235]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id t4H2ewuw068222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 May 2015 22:40:59 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Sat, 16 May 2015 22:40:56 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: Daisuke Aoyama cc: Ian Lepore , Svatopluk Kraus , freebsd-arm@freebsd.org Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] In-Reply-To: Message-ID: References: <1431822588.91685.48.camel@freebsd.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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, 17 May 2015 02:41:09 -0000 On Sun, 17 May 2015, Daisuke Aoyama wrote: > -------------------------------------------------- > From: "Ian Lepore" > Sent: Sunday, May 17, 2015 9:29 AM > To: "Svatopluk Kraus" > Cc: "Keith White" ; > Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB > [solved?] [patch] > >> On Fri, 2015-05-15 at 10:18 +0200, Svatopluk Kraus wrote: >>> On Fri, May 15, 2015 at 2:13 AM, Keith White >>> wrote: >>> > On Thu, 14 May 2015, Svatopluk Kraus wrote: >>> > >>> >> On Thu, May 14, 2015 at 2:03 AM, Keith White >>> >> wrote: >>> >>> >>> >>> I get the following panic when trying to load an mfs_root on a >>> >>> reasonably current BBB image: >>> >>> >>> >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>> >>> trapframe: 0xdd43fd50 >>> >>> FSR=00000005, FAR=01211ef0, spsr=20000113 >>> >>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 >>> >>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 >>> >>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 >>> >>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 >>> >>> >>> >>> [ thread pid 4 tid 100054 ] >>> >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >>> >>> db> >>> >>> >>> >>> Hints, suggestions? >>> >>> >>> >>> ...keith >>> >>> >>> >>> --------------------------------- >>> >>> More (trimmed) details from boot: >>> >>> >>> >>> ... >>> >>> U-Boot 2014.10 (Mar 19 2015 - 18:29:51) >>> >>> ... >>> >>> FreeBSD/armv6hf U-Boot loader, Revision 1.2 >>> >>> (kwhite@freebsd11, Tue Mar 17 22:23:25 EDT 2015) >>> >>> ... >>> >>> Found U-Boot device: disk >>> >>> Checking unit=1 slice= partition=... good. >>> >>> /boot/kernel/kernel data=0x505c2c+0x923d4 >>> syms=[0x4+0x606a0+0x4+0x65ed4] >>> >>> /boot/kernel/snd_uaudio.ko text=0xed3c data=0x620+0x10 >>> >>> syms=[0x4+0x1ec0+0x4+0x1a2f] >>> >>> ... >>> >>> Type '?' for a list of commands, 'help' for more detailed help. >>> >>> loader> load -t mfs_root /rootfs >>> >>> /rootfs size=0x858000 >>> >>> loader> boot -asv >>> >>> Booting... >>> >>> /boot/dtb/beaglebone-black.dtb size=0x24b4 >>> >>> Loaded DTB from file 'beaglebone-black.dtb'. >>> >>> Kernel entry at 0x80200100... >>> >>> Kernel args: -asv >>> >>> KDB: debugger backends: ddb >>> >>> KDB: current backend: ddb >>> >>> Copyright (c) 1992-2015 The FreeBSD Project. >>> >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, >>> 1994 >>> >>> The Regents of the University of California. All rights >>> reserved. >>> >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> >>> FreeBSD 11.0-CURRENT #1 r282672M: Tue May 12 06:57:24 EDT 2015 >>> >>> >>> >>> >>> kwhite@freebsd11:/usr/obj/arm.armv6hf/tank/RPI/head/sys/BEAGLEBONE-LOCAL >>> >>> arm >>> >>> FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 >>> >>> WARNING: WITNESS option enabled, expect reduced performance. >>> >>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc1219000. >>> >>> ... >>> >>> mmc0: Probing bus >>> >>> usbus0: 480Mbps High Speed USB v2.0 >>> >>> usbus1: 480Mbps High Speed USB v2.0 >>> >>> md0: Preloaded image 8749056 bytes at 0x9b9f00 >>> >>> ugen1.1: at usbus1 >>> >>> uhub0: >> 1> >>> >>> on >>> >>> usbus1 >>> >>> ugen0.1: at usbus0 >>> >>> uhub1: >> 1> >>> >>> on >>> >>> usbus0 >>> >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>> >>> trapframe: 0xdd43fd50 >>> >>> FSR=00000005, FAR=01211ef0, spsr=20000113 >>> >>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 >>> >>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 >>> >>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 >>> >>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 >>> >>> >>> >>> [ thread pid 4 tid 100054 ] >>> >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >>> >> >>> >> >>> >> >>> >> Well, FAR (fault address) points to user address space. System is >>> >> still in boot process and no user address should be used. The first >>> >> thing is to find out if arguments pushed to bcopy() in >>> >> mdstart_preload() are correct. Can you print them out? >>> >> ... >>> > >>> > >>> > Thanks for the hint! After a little digging with ddb, it appears >>> > that the fault address is missing an offset of KERNBASE (0xc0000000). >>> > The mfs_root being found at 0x9b9f00 ("md0: preloaded image at") + >>> > KERNBASE (0xc0000000). The following patch fixes the symptom, and >>> > allows a boot to successfully complete. The resulting md is also >>> > usable as /. >>> > >>> > I'm sure there's a more correct patch? >>> > >>> > Index: sys/dev/md/md.c >>> > =================================================================== >>> > --- sys/dev/md/md.c (revision 282672) >>> > +++ sys/dev/md/md.c (working copy) >>> > @@ -1590,7 +1590,11 @@ >>> > len = preload_fetch_size(mod); >>> > if (ptr != NULL && len != 0) { >>> > sx_xlock(&md_sx); >>> > +#ifdef __arm__ >>> > + md_preloaded(KERNBASE + ptr, len, name); >>> > +#else >>> > md_preloaded(ptr, len, name); >>> > +#endif >>> > sx_xunlock(&md_sx); >>> > } >>> > } >>> >>> >>> Thanks for debugging it. The preload_fetch_addr() already uses >>> preload_addr_relocate to adjust returned address. IMO, a patch should >>> either deal with preload_addr_relocate and init it correctly or fix >>> MODINFO_ADDR info in kernel modules. Now, preload_addr_relocate is set >>> only when FREEBSD_BOOT_LOADER is defined. In this moment, I know >>> nothing about how MODINFO_ADDR info is generated. >>> >>> BTW, physical address space starts at 0x80000000 on BBB and KERNBASE >>> is 0xC0000000, so I would be expecting that preload_addr_relocate >>> should be set to 0x40000000. The FAR is 0x01211ef0, so it's not >>> physical address. And as your patch helps, it's an offset to either >>> physical or virtual address space. So it looks more like MODINFO_ADDR >>> info problem. >>> >> >> I think the problem here is likely to be in ubldr. Today I tried to >> recreate this and all I could get was complete system lockup right after >> the kernel copyright displayed. Eventually I noticed that your root >> image is less than 10MB, so I created a little image about the same size >> as yours and put init(8) in it, and with that I get the same panic you >> do (different physical address, I'm doing it on a wandboard). >> >> I think there are at least two separate problems here. ubldr isn't >> setting the right metadata for the load address, and then separately >> from that, trying to load really big files corrupts memory somehow in a >> way that locks up the kernel. >> >> I'll keep poking at it. > > I posted about ubldr/mfsroot last year. no one interest it... > http://lists.freebsd.org/pipermail/freebsd-arm/2014-December/009839.html > I think ubldr should be fixed. > -- > Daisuke Aoyama > > Thanks Ian for looking at this! Based upon the comments by Daisuke Aoyama, the patch above using KERNBASE becomes this using preload_addr_relocate: ----------------- --- sys/dev/md/md.c (revision 282672) +++ sys/dev/md/md.c (working copy) @@ -1590,7 +1590,11 @@ len = preload_fetch_size(mod); if (ptr != NULL && len != 0) { sx_xlock(&md_sx); +#ifdef __arm__ + md_preloaded(ptr - preload_addr_relocate, len, name); +#else md_preloaded(ptr, len, name); +#endif sx_xunlock(&md_sx); } } ----------------- ...keith From owner-freebsd-arm@FreeBSD.ORG Sun May 17 04:01:07 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 250EF9ED for ; Sun, 17 May 2015 04:01:07 +0000 (UTC) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (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 DE6E51B8F for ; Sun, 17 May 2015 04:01:06 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so64210641igb.0 for ; Sat, 16 May 2015 21:01:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=7zJLhyCZO1ylQzUdIkyoRFKq17+mtGEyvKOCB29myNA=; b=T/NA/cFphvf50ZnG+zize4AW7L4bXXJgrpHPTrRUQFzc/UP0NknhVNFrKTEBPB0Cco o+wRJaHWFmeWYYvCeVO7oXVCsdFoRWuYEobG11Ku/XcDsxSMB3HIMUrXLhSZDCxKfvZS UH0SH38oUwYLYY+ySJonaCBjhvYfuS2ddw9d6Ep+0uOYgcX/pO6LKD7fxY0dbRsgKeVG Bd1CwT5FNvIPGMHVNAPhPQQnHaeWJsPJejZ8B0uG9AXkd18MUKyz9Qqe66f95VNzxbqF uKCgTtn9yhZuIfkUa10Bq2LRkFJZbaYmF1ymFZoYgjxnJxuV8Zhl17Rw4Ldd8MNPHg8z 2w+Q== X-Gm-Message-State: ALoCoQmIR7r67YPE1jgv17Vh7HXmRHDWDQy1QR/DdpaHC2/canrEnEsB5LcfP3nBgkSys1xWwnlL X-Received: by 10.107.5.210 with SMTP id 201mr22376414iof.57.1431834886763; Sat, 16 May 2015 20:54:46 -0700 (PDT) Received: from netflix-mac-wired.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id v102sm2753555iov.8.2015.05.16.20.54.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 May 2015 20:54:45 -0700 (PDT) Sender: Warner Losh Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D09AAF2F-C7F9-44FF-86A3-6F7CF1FB98C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: Date: Sat, 16 May 2015 21:54:43 -0600 Cc: Daisuke Aoyama , freebsd-arm@freebsd.org, Ian Lepore Message-Id: References: <1431822588.91685.48.camel@freebsd.org> To: Keith White X-Mailer: Apple Mail (2.2098) 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, 17 May 2015 04:01:07 -0000 --Apple-Mail=_D09AAF2F-C7F9-44FF-86A3-6F7CF1FB98C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 16, 2015, at 8:40 PM, Keith White = wrote: >=20 > On Sun, 17 May 2015, Daisuke Aoyama wrote: >=20 >> -------------------------------------------------- >> From: "Ian Lepore" >> Sent: Sunday, May 17, 2015 9:29 AM >> To: "Svatopluk Kraus" >> Cc: "Keith White" ; >> Subject: Re: Translation Fault panic when trying to use an mfs_root = on BBB [solved?] [patch] >>=20 >>> On Fri, 2015-05-15 at 10:18 +0200, Svatopluk Kraus wrote: >>>> On Fri, May 15, 2015 at 2:13 AM, Keith White = wrote: >>>> > On Thu, 14 May 2015, Svatopluk Kraus wrote: >>>> > >>>> >> On Thu, May 14, 2015 at 2:03 AM, Keith White = >>>> >> wrote: >>>> >>> >>>> >>> I get the following panic when trying to load an mfs_root on a >>>> >>> reasonably current BBB image: >>>> >>> >>>> >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>> >>> trapframe: 0xdd43fd50 >>>> >>> FSR=3D00000005, FAR=3D01211ef0, spsr=3D20000113 >>>> >>> r0 =3Dc35f4200, r1 =3D01211f00, r2 =3D000001e0, r3 =3D3dc1dd00 >>>> >>> r4 =3Dc3638930, r5 =3Dc362d838, r6 =3Dc362d810, r7 =3Dc06037b8 >>>> >>> r8 =3D0000002d, r9 =3D00000000, r10=3Dc3638930, r11=3Ddd43fdf0 >>>> >>> r12=3D00000000, ssp=3Ddd43fde0, slr=3Dc0249918, pc =3Dc05c6a68 >>>> >>> >>>> >>> [ thread pid 4 tid 100054 ] >>>> >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >>>> >>> db> >>>> >>> >>>> >>> Hints, suggestions? >>>> >>> >>>> >>> ...keith >>>> >>> >>>> >>> --------------------------------- >>>> >>> More (trimmed) details from boot: >>>> >>> >>>> >>> ... >>>> >>> U-Boot 2014.10 (Mar 19 2015 - 18:29:51) >>>> >>> ... >>>> >>> FreeBSD/armv6hf U-Boot loader, Revision 1.2 >>>> >>> (kwhite@freebsd11, Tue Mar 17 22:23:25 EDT 2015) >>>> >>> ... >>>> >>> Found U-Boot device: disk >>>> >>> Checking unit=3D1 slice=3D partition=3D... good. >>>> >>> /boot/kernel/kernel data=3D0x505c2c+0x923d4 = syms=3D[0x4+0x606a0+0x4+0x65ed4] >>>> >>> /boot/kernel/snd_uaudio.ko text=3D0xed3c data=3D0x620+0x10 >>>> >>> syms=3D[0x4+0x1ec0+0x4+0x1a2f] >>>> >>> ... >>>> >>> Type '?' for a list of commands, 'help' for more detailed help. >>>> >>> loader> load -t mfs_root /rootfs >>>> >>> /rootfs size=3D0x858000 >>>> >>> loader> boot -asv >>>> >>> Booting... >>>> >>> /boot/dtb/beaglebone-black.dtb size=3D0x24b4 >>>> >>> Loaded DTB from file 'beaglebone-black.dtb'. >>>> >>> Kernel entry at 0x80200100... >>>> >>> Kernel args: -asv >>>> >>> KDB: debugger backends: ddb >>>> >>> KDB: current backend: ddb >>>> >>> Copyright (c) 1992-2015 The FreeBSD Project. >>>> >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, = 1993, 1994 >>>> >>> The Regents of the University of California. All rights = reserved. >>>> >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>> >>> FreeBSD 11.0-CURRENT #1 r282672M: Tue May 12 06:57:24 EDT 2015 >>>> >>> >>>> >>> = kwhite@freebsd11:/usr/obj/arm.armv6hf/tank/RPI/head/sys/BEAGLEBONE-LOCAL >>>> >>> arm >>>> >>> FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) = 20150225 >>>> >>> WARNING: WITNESS option enabled, expect reduced performance. >>>> >>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc1219000. >>>> >>> ... >>>> >>> mmc0: Probing bus >>>> >>> usbus0: 480Mbps High Speed USB v2.0 >>>> >>> usbus1: 480Mbps High Speed USB v2.0 >>>> >>> md0: Preloaded image 8749056 bytes at 0x9b9f00 >>>> >>> ugen1.1: at usbus1 >>>> >>> uhub0: >>>> >>> on >>>> >>> usbus1 >>>> >>> ugen0.1: at usbus0 >>>> >>> uhub1: >>>> >>> on >>>> >>> usbus0 >>>> >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>> >>> trapframe: 0xdd43fd50 >>>> >>> FSR=3D00000005, FAR=3D01211ef0, spsr=3D20000113 >>>> >>> r0 =3Dc35f4200, r1 =3D01211f00, r2 =3D000001e0, r3 =3D3dc1dd00 >>>> >>> r4 =3Dc3638930, r5 =3Dc362d838, r6 =3Dc362d810, r7 =3Dc06037b8 >>>> >>> r8 =3D0000002d, r9 =3D00000000, r10=3Dc3638930, r11=3Ddd43fdf0 >>>> >>> r12=3D00000000, ssp=3Ddd43fde0, slr=3Dc0249918, pc =3Dc05c6a68 >>>> >>> >>>> >>> [ thread pid 4 tid 100054 ] >>>> >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >>>> >> >>>> >> >>>> >> >>>> >> Well, FAR (fault address) points to user address space. System = is >>>> >> still in boot process and no user address should be used. The = first >>>> >> thing is to find out if arguments pushed to bcopy() in >>>> >> mdstart_preload() are correct. Can you print them out? >>>> >> ... >>>> > >>>> > >>>> > Thanks for the hint! After a little digging with ddb, it appears >>>> > that the fault address is missing an offset of KERNBASE = (0xc0000000). >>>> > The mfs_root being found at 0x9b9f00 ("md0: preloaded image at") = + >>>> > KERNBASE (0xc0000000). The following patch fixes the symptom, = and >>>> > allows a boot to successfully complete. The resulting md is also >>>> > usable as /. >>>> > >>>> > I'm sure there's a more correct patch? >>>> > >>>> > Index: sys/dev/md/md.c >>>> > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> > --- sys/dev/md/md.c (revision 282672) >>>> > +++ sys/dev/md/md.c (working copy) >>>> > @@ -1590,7 +1590,11 @@ >>>> > len =3D preload_fetch_size(mod); >>>> > if (ptr !=3D NULL && len !=3D 0) { >>>> > sx_xlock(&md_sx); >>>> > +#ifdef __arm__ >>>> > + md_preloaded(KERNBASE + ptr, len, name); >>>> > +#else >>>> > md_preloaded(ptr, len, name); >>>> > +#endif >>>> > sx_xunlock(&md_sx); >>>> > } >>>> > } >>>> Thanks for debugging it. The preload_fetch_addr() already uses >>>> preload_addr_relocate to adjust returned address. IMO, a patch = should >>>> either deal with preload_addr_relocate and init it correctly or fix >>>> MODINFO_ADDR info in kernel modules. Now, preload_addr_relocate is = set >>>> only when FREEBSD_BOOT_LOADER is defined. In this moment, I know >>>> nothing about how MODINFO_ADDR info is generated. >>>> BTW, physical address space starts at 0x80000000 on BBB and = KERNBASE >>>> is 0xC0000000, so I would be expecting that preload_addr_relocate >>>> should be set to 0x40000000. The FAR is 0x01211ef0, so it's not >>>> physical address. And as your patch helps, it's an offset to either >>>> physical or virtual address space. So it looks more like = MODINFO_ADDR >>>> info problem. >>> I think the problem here is likely to be in ubldr. Today I tried to >>> recreate this and all I could get was complete system lockup right = after >>> the kernel copyright displayed. Eventually I noticed that your root >>> image is less than 10MB, so I created a little image about the same = size >>> as yours and put init(8) in it, and with that I get the same panic = you >>> do (different physical address, I'm doing it on a wandboard). >>> I think there are at least two separate problems here. ubldr isn't >>> setting the right metadata for the load address, and then separately >>> from that, trying to load really big files corrupts memory somehow = in a >>> way that locks up the kernel. >>> I'll keep poking at it. >>=20 >> I posted about ubldr/mfsroot last year. no one interest it... >> = http://lists.freebsd.org/pipermail/freebsd-arm/2014-December/009839.html >> I think ubldr should be fixed. >> -- >> Daisuke Aoyama >>=20 >>=20 >=20 > Thanks Ian for looking at this! >=20 > Based upon the comments by Daisuke Aoyama, the patch above using > KERNBASE becomes this using preload_addr_relocate: >=20 > ----------------- > --- sys/dev/md/md.c (revision 282672) > +++ sys/dev/md/md.c (working copy) > @@ -1590,7 +1590,11 @@ > len =3D preload_fetch_size(mod); > if (ptr !=3D NULL && len !=3D 0) { > sx_xlock(&md_sx); > +#ifdef __arm__ > + md_preloaded(ptr - preload_addr_relocate, len, = name); > +#else > md_preloaded(ptr, len, name); > +#endif > sx_xunlock(&md_sx); > } > } This is almost certainly the wrong place to fix this. The right place to = fix it is in ubldr. It says that all the ptrs are AFU only on arm, and = this one is likely the first of many. Warner --Apple-Mail=_D09AAF2F-C7F9-44FF-86A3-6F7CF1FB98C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVWBEDAAoJEGwc0Sh9sBEAMXoQAIwhN8B+QhgxHZU/DrFAHM9w PLD6gSs5uiKB+3Ib4wYT7SF9Psk6wXTwL6968VDfdh4AnsMvm9nnxCfNQSgftzRA L3wPEDUDgkd8Dv4Kw0yMFQT87hD4L0NCCX5TLEgGAB5z8brT08NneVyDhfM+PEbi VltxC08xcllOA7oa6oqTpi5YxZAz+DlRPG7M3HtZHOObLZQhOxpLlFYQ47zgfawm flXAG1r7iXU7zR0QQP7BOAUy0Gy+jVICAc89VSdgmNQFF5oNmRwW3OUQeycBwcIf V74GwLuGIU8jVMG+8fY2RArMIxaQwnVEtTUj/cSIhOqyUfqIE3Mw3nJzEnVpEckc oQoYx3tuPUNdiM41uj6okbIBdmG6P++QCZ/7TJ27LLwIHCyHAcUg/S7JhqEejbdf V9Umgn6byBPOu4dK89mMrvxq096OPL+/698ah684Jp6pP4TWr5rcUCU0XHOAQJqQ ra1mi1Kl1M4I6MNYKlnrQj/dQlk8xKMuuTuLUBLcUozIXExPU5q/dROtaWd16Zmr 4od6Q8MdSYITkoeqZkamDvhgrhXRpKEYItVJ4FpVidwa7zrPcpd6QKZIDvwuluGp 4eOoQKFQb8Y3hPDbmIBZT2fmDGmUYd/L0eQSZ+HSeQajTxKq/Vtj9OaiL/1MbLTr hy7HRUdMsRAUHAOJEt1I =PUKV -----END PGP SIGNATURE----- --Apple-Mail=_D09AAF2F-C7F9-44FF-86A3-6F7CF1FB98C7-- From owner-freebsd-arm@FreeBSD.ORG Sun May 17 07:54:54 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 071A017F; Sun, 17 May 2015 07:54:54 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 C4E3D10AF; Sun, 17 May 2015 07:54:53 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so65573286igb.0; Sun, 17 May 2015 00:54:53 -0700 (PDT) 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=JZ1YR/VROstb6sNoYtCW+Pzv4IA+TGVAgptIJP+XIeo=; b=qGEfVZQkQ4oI2ALn/K5W2Rks5MVZY/6SZuNIbrm2Tw2gXoIkaFPF5/7TsJw3CNj6fm d3W3bmHMscjnm1QP6Mjx9bhilu178XfGylRFsN6AP09Pnr4ay8or78UpHjNqV7jJK4rG 81kIVN55rYdQcT3ztGO8WgPNc1SCPkZQgRzLbGMJRuj/sVktwRY171ySZkG/Il87duSu XvikegHBrv9sVL38+6DzUvz/rBR6/mz4VJboUUdYdVz4wbeS9oIGPl03BPJ9Bq1ouZpf PrPmkpMwRNYh4f3u0ETCl0ZBNBImTb2HW1huVf8QId5XfQ0DDXoRcdpoMP7RauVxpxgf dsxA== MIME-Version: 1.0 X-Received: by 10.42.76.146 with SMTP id e18mr30146365ick.42.1431849293190; Sun, 17 May 2015 00:54:53 -0700 (PDT) Received: by 10.64.228.199 with HTTP; Sun, 17 May 2015 00:54:53 -0700 (PDT) In-Reply-To: <1431822588.91685.48.camel@freebsd.org> References: <1431822588.91685.48.camel@freebsd.org> Date: Sun, 17 May 2015 09:54:53 +0200 Message-ID: Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] From: Svatopluk Kraus To: Ian Lepore Cc: Keith White , "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: Sun, 17 May 2015 07:54:54 -0000 On Sun, May 17, 2015 at 2:29 AM, Ian Lepore wrote: > On Fri, 2015-05-15 at 10:18 +0200, Svatopluk Kraus wrote: >> On Fri, May 15, 2015 at 2:13 AM, Keith White wrote: >> > On Thu, 14 May 2015, Svatopluk Kraus wrote: >> > >> >> On Thu, May 14, 2015 at 2:03 AM, Keith White >> >> wrote: >> >>> >> >>> I get the following panic when trying to load an mfs_root on a >> >>> reasonably current BBB image: >> >>> >> >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> >>> trapframe: 0xdd43fd50 >> >>> FSR=00000005, FAR=01211ef0, spsr=20000113 >> >>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 >> >>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 >> >>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 >> >>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 >> >>> >> >>> [ thread pid 4 tid 100054 ] >> >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >> >>> db> >> >>> >> >>> Hints, suggestions? >> >>> >> >>> ...keith >> >>> >> >>> --------------------------------- >> >>> More (trimmed) details from boot: >> >>> >> >>> ... >> >>> U-Boot 2014.10 (Mar 19 2015 - 18:29:51) >> >>> ... >> >>> FreeBSD/armv6hf U-Boot loader, Revision 1.2 >> >>> (kwhite@freebsd11, Tue Mar 17 22:23:25 EDT 2015) >> >>> ... >> >>> Found U-Boot device: disk >> >>> Checking unit=1 slice= partition=... good. >> >>> /boot/kernel/kernel data=0x505c2c+0x923d4 syms=[0x4+0x606a0+0x4+0x65ed4] >> >>> /boot/kernel/snd_uaudio.ko text=0xed3c data=0x620+0x10 >> >>> syms=[0x4+0x1ec0+0x4+0x1a2f] >> >>> ... >> >>> Type '?' for a list of commands, 'help' for more detailed help. >> >>> loader> load -t mfs_root /rootfs >> >>> /rootfs size=0x858000 >> >>> loader> boot -asv >> >>> Booting... >> >>> /boot/dtb/beaglebone-black.dtb size=0x24b4 >> >>> Loaded DTB from file 'beaglebone-black.dtb'. >> >>> Kernel entry at 0x80200100... >> >>> Kernel args: -asv >> >>> KDB: debugger backends: ddb >> >>> KDB: current backend: ddb >> >>> Copyright (c) 1992-2015 The FreeBSD Project. >> >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> >>> The Regents of the University of California. All rights reserved. >> >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >> >>> FreeBSD 11.0-CURRENT #1 r282672M: Tue May 12 06:57:24 EDT 2015 >> >>> >> >>> kwhite@freebsd11:/usr/obj/arm.armv6hf/tank/RPI/head/sys/BEAGLEBONE-LOCAL >> >>> arm >> >>> FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 >> >>> WARNING: WITNESS option enabled, expect reduced performance. >> >>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc1219000. >> >>> ... >> >>> mmc0: Probing bus >> >>> usbus0: 480Mbps High Speed USB v2.0 >> >>> usbus1: 480Mbps High Speed USB v2.0 >> >>> md0: Preloaded image 8749056 bytes at 0x9b9f00 >> >>> ugen1.1: at usbus1 >> >>> uhub0: >> >>> on >> >>> usbus1 >> >>> ugen0.1: at usbus0 >> >>> uhub1: >> >>> on >> >>> usbus0 >> >>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >> >>> trapframe: 0xdd43fd50 >> >>> FSR=00000005, FAR=01211ef0, spsr=20000113 >> >>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 >> >>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 >> >>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 >> >>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 >> >>> >> >>> [ thread pid 4 tid 100054 ] >> >>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >> >> >> >> >> >> >> >> Well, FAR (fault address) points to user address space. System is >> >> still in boot process and no user address should be used. The first >> >> thing is to find out if arguments pushed to bcopy() in >> >> mdstart_preload() are correct. Can you print them out? >> >> ... >> > >> > >> > Thanks for the hint! After a little digging with ddb, it appears >> > that the fault address is missing an offset of KERNBASE (0xc0000000). >> > The mfs_root being found at 0x9b9f00 ("md0: preloaded image at") + >> > KERNBASE (0xc0000000). The following patch fixes the symptom, and >> > allows a boot to successfully complete. The resulting md is also >> > usable as /. >> > >> > I'm sure there's a more correct patch? >> > >> > Index: sys/dev/md/md.c >> > =================================================================== >> > --- sys/dev/md/md.c (revision 282672) >> > +++ sys/dev/md/md.c (working copy) >> > @@ -1590,7 +1590,11 @@ >> > len = preload_fetch_size(mod); >> > if (ptr != NULL && len != 0) { >> > sx_xlock(&md_sx); >> > +#ifdef __arm__ >> > + md_preloaded(KERNBASE + ptr, len, name); >> > +#else >> > md_preloaded(ptr, len, name); >> > +#endif >> > sx_xunlock(&md_sx); >> > } >> > } >> >> >> Thanks for debugging it. The preload_fetch_addr() already uses >> preload_addr_relocate to adjust returned address. IMO, a patch should >> either deal with preload_addr_relocate and init it correctly or fix >> MODINFO_ADDR info in kernel modules. Now, preload_addr_relocate is set >> only when FREEBSD_BOOT_LOADER is defined. In this moment, I know >> nothing about how MODINFO_ADDR info is generated. >> >> BTW, physical address space starts at 0x80000000 on BBB and KERNBASE >> is 0xC0000000, so I would be expecting that preload_addr_relocate >> should be set to 0x40000000. The FAR is 0x01211ef0, so it's not >> physical address. And as your patch helps, it's an offset to either >> physical or virtual address space. So it looks more like MODINFO_ADDR >> info problem. >> > > I think the problem here is likely to be in ubldr. Today I tried to > recreate this and all I could get was complete system lockup right after > the kernel copyright displayed. Eventually I noticed that your root > image is less than 10MB, so I created a little image about the same size > as yours and put init(8) in it, and with that I get the same panic you > do (different physical address, I'm doing it on a wandboard). > > I think there are at least two separate problems here. ubldr isn't > setting the right metadata for the load address, and then separately > from that, trying to load really big files corrupts memory somehow in a > way that locks up the kernel. > > I'll keep poking at it. > Well, there is a way how to get 0x01211ef0 which looks like an offset on BBB. If MODINFO_ADDR is already relocated to VA (above 0xC0000000) and preload_addr_relocate is not zero (0x40000000), then preload_fetch_addr() will return an "offset" in BBB case. From owner-freebsd-arm@FreeBSD.ORG Sun May 17 11:10:05 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E650B90 for ; Sun, 17 May 2015 11:10:05 +0000 (UTC) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (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 BD3D61246 for ; Sun, 17 May 2015 11:10:04 +0000 (UTC) Received: by wicmx19 with SMTP id mx19so45100328wic.0 for ; Sun, 17 May 2015 04:09:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=pUMoglpMV1pXvulKyeQKfUlryEyE/m4JRK42uuefE5s=; b=b0w2eWtfg4k0LaUkDfKDU4lOuIoHvrwjYsaDGI4lXJTEstpfbAIL9C7dGRSorPNECM ZM7tdWt31UP4M/1I4gY2TTmLvKM/FWQOF9q7Rk9y/yCtjaeZwpt3ndUaBY8M+3y8MS66 H2TWsgkGREpsPJ+wDY0ZzbsJV1cE17MKnZIRS+Iwq8dGyoH9LO6BIQqcZ65p4JxkYslC 9hMJ2XCTLsfdvWow0RprGdyz/wOQsz659eUmrwdZxf4sXj6IDju9rVj+R5RTmaggL5r8 /om4oXbGXkyqO5jkMUoVMR8wHDbGqmCrgWUZ6X7HS03yMLLBFRddnSb9NgtFuAGD3iAZ yH/g== X-Gm-Message-State: ALoCoQl5Xphncx6zVcGcCp7dNrYFiC7kUx1vnomXHiBet+Awn0kzP2v9o6xLd0/l44HFOi5Z+5xP X-Received: by 10.180.187.232 with SMTP id fv8mr13153044wic.28.1431860996812; Sun, 17 May 2015 04:09:56 -0700 (PDT) Received: from [192.168.1.117] ([192.166.203.79]) by mx.google.com with ESMTPSA id q10sm474881wjo.38.2015.05.17.04.09.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 May 2015 04:09:56 -0700 (PDT) Message-ID: <5558770A.70903@semihalf.com> Date: Sun, 17 May 2015 13:10:02 +0200 From: =?UTF-8?B?TWljaGHFgiBTdGFuZWs=?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stanislav Sedov CC: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: UMA initialization failure with 48 core ARM64 References: <2A6C7643-0C10-4451-B547-9D50EA6809B8@freebsd.org> In-Reply-To: <2A6C7643-0C10-4451-B547-9D50EA6809B8@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Sun, 17 May 2015 11:10:05 -0000 On 2015-05-16 00:42, Stanislav Sedov wrote: > >> On May 15, 2015, at 11:30 AM, MichaĹ‚ Stanek wrote: >> >> Hi, >> >> I am experiencing an early failure of UMA on an ARM64 platform with 48 >> cores enabled. I get a kernel panic during initialization of VM. Here is >> the boot log (lines with 'MST:' are my own debug printfs). >> >> Copyright (c) 1992-2015 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 11.0-CURRENT #333 52fd91e(smp_48)-dirty: Fri May 15 18:26:56 CEST >> 2015 >> mst@arm64-prime:/usr/home/mst/freebsd_v8/obj_kernel/arm64.aarch64/usr/home/mst/freebsd_v8/kernel/sys/THUNDER-88XX >> arm64 >> FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 >> MST: in vm_mem_init() >> MST: in vmem_init() with param *vm == kernel_arena >> MST: in vmem_xalloc() with param *vm == kernel_arena >> MST: in vmem_xalloc() with param *vm == kmem_arena >> panic: mtx_lock() of spin mutex (null) @ >> /usr/home/mst/freebsd_v8/kernel/sys/kern/subr_vmem.c:1165 >> cpuid = 0 >> KDB: enter: panic >> [ thread pid 0 tid 0 ] >> Stopped at 0xffffff80001f4f80: >> >> The kernel boots fine when MAXCPU is set to 30 or lower, but the error >> above always appears when it is set to a higher value. >> >> The panic is triggered by a KASSERT in __mtx_lock_flags() which is called >> with the macro VMEM_LOCK(vm) in vmem_xalloc(). This is line 1143 in >> subr_vmem.c (log shows different line number due to added printfs). >> It looks like the lock belongs to 'kmem_arena' which is uninitialized at >> this point (kmeminit() has not been called yet). >> >> While debugging, I tried modifying VM code as a quick workaround. I >> replaced the number of cores to 1 wherever mp_ncpus, mp_maxid or MAXCPU >> (and others) are read. This, I believe, limits UMA per-cpu caches to just >> one, while the rest of the OS (scheduler, etc) sees all 48 cores. >> In addition, I changed UMA_BOOT_PAGES in sys/vm/uma_int.h to 512 (default >> was 64). >> With these tweaks, I got a successful (but not really stable) boot with 48 >> cores. Of course these are dirty hacks and a proper solution is needed. >> >> I am a bit surprised that the kernel fails with MAXCPU==48 as the amd64 >> arch has this value set to '256' and I have read posts that other platforms >> with even more cores have worked fine. Perhaps I need to tweak some other >> VM parameters, apart from UMA_BOOT_PAGES (AKA vm.boot_pages), but I am not >> sure how. >> >> I included a full stacktrace and a more verbose log (with UMA_DEBUG macros >> enabled) in the attachment. There is also a diff of the hacks I used while >> debugging. >> >> > > Hi, Michal! > > It looks like the log attachment didn’t make it though the mailing list. > Can you please resend it again? > > The panic suggests that a mutex was left uninitialized... > > -- > ST4096-RIPE > > > Yes you're right, kmem_arena's mutex is used before it is initialized. I do not know why increasing MAXCPU causes such behavior. Here is the stacktrace at the point of the panic: db_stack_trace db_command db_command_loop db_trap kdb_trap handle_el1h_sync vpanic kassert_panic __mtx_lock_flags vmem_xalloc vmem_bt_alloc keg_alloc_slab keg_fetch_slab zone_fetch_slab zone_import zone_alloc_item bt_fill vmem_xalloc vmem_alloc kmem_init_zero_region vm_mem_init mi_startup virtdone Diff of the hacks in UMA: diff --git a/sys/kern/kern_malloc.c b/sys/kern/kern_malloc.c index aef1e4e..be225fb 100644 --- a/sys/kern/kern_malloc.c +++ b/sys/kern/kern_malloc.c @@ -874,7 +874,7 @@ malloc_uninit(void *data) * Look for memory leaks. */ temp_allocs = temp_bytes = 0; - for (i = 0; i < MAXCPU; i++) { + for (i = 0; i < 1; i++) { mtsp = &mtip->mti_stats[i]; temp_allocs += mtsp->mts_numallocs; temp_allocs -= mtsp->mts_numfrees; diff --git a/sys/kern/subr_vmem.c b/sys/kern/subr_vmem.c index 80940be..89d62ed 100644 --- a/sys/kern/subr_vmem.c +++ b/sys/kern/subr_vmem.c @@ -665,7 +665,8 @@ vmem_startup(void) * CPUs to attempt to allocate new tags concurrently to limit * false restarts in UMA. */ - uma_zone_reserve(vmem_bt_zone, BT_MAXALLOC * (mp_ncpus + 1) / 2); + //mst look here + uma_zone_reserve(vmem_bt_zone, BT_MAXALLOC * (1 + 1) / 2); uma_zone_set_allocf(vmem_bt_zone, vmem_bt_alloc); #endif } diff --git a/sys/vm/uma_core.c b/sys/vm/uma_core.c index b96c421..6382437 100644 --- a/sys/vm/uma_core.c +++ b/sys/vm/uma_core.c @@ -98,6 +98,14 @@ __FBSDID("$FreeBSD$"); #include #endif +//mst: override some defines +#undef curcpu +#define curcpu 0 +#undef CPU_FOREACH +#define CPU_FOREACH(i) \ + for ((i) = 0; (i) <= 0; (i)++) \ + if (!CPU_ABSENT((i))) + /* * This is the zone and keg from which all zones are spawned. The idea is that * even the zone & keg heads are allocated from the allocator, so we use the @@ -1228,6 +1236,7 @@ keg_small_init(uma_keg_t keg) if (keg->uk_flags & UMA_ZONE_PCPU) { u_int ncpus = mp_ncpus ? mp_ncpus : MAXCPU; + ncpus = 1; keg->uk_slabsize = sizeof(struct pcpu); keg->uk_ppera = howmany(ncpus * sizeof(struct pcpu), @@ -1822,7 +1831,7 @@ uma_startup(void *bootmem, int boot_pages) #endif args.name = "UMA Zones"; args.size = sizeof(struct uma_zone) + - (sizeof(struct uma_cache) * (mp_maxid + 1)); + (sizeof(struct uma_cache) * (0 + 1)); args.ctor = zone_ctor; args.dtor = zone_dtor; args.uminit = zero_init; @@ -3301,7 +3310,7 @@ uma_zero_item(void *item, uma_zone_t zone) { if (zone->uz_flags & UMA_ZONE_PCPU) { - for (int i = 0; i < mp_ncpus; i++) + for (int i = 0; i < 1; i++) bzero(zpcpu_get_cpu(item, i), zone->uz_size); } else bzero(item, zone->uz_size); @@ -3465,7 +3474,7 @@ sysctl_vm_zone_stats(SYSCTL_HANDLER_ARGS) */ bzero(&ush, sizeof(ush)); ush.ush_version = UMA_STREAM_VERSION; - ush.ush_maxcpus = (mp_maxid + 1); + ush.ush_maxcpus = (0 + 1); ush.ush_count = count; (void)sbuf_bcat(&sbuf, &ush, sizeof(ush)); @@ -3509,7 +3518,7 @@ sysctl_vm_zone_stats(SYSCTL_HANDLER_ARGS) * accept the possible race associated with bucket * exchange during monitoring. */ - for (i = 0; i < (mp_maxid + 1); i++) { + for (i = 0; i < (0 + 1); i++) { bzero(&ups, sizeof(ups)); if (kz->uk_flags & UMA_ZFLAG_INTERNAL) goto skip; diff --git a/sys/vm/uma_int.h b/sys/vm/uma_int.h index 11ab24f..b5b5a05 100644 --- a/sys/vm/uma_int.h +++ b/sys/vm/uma_int.h @@ -107,7 +107,7 @@ #define UMA_SLAB_MASK (PAGE_SIZE - 1) /* Mask to get back to the page */ #define UMA_SLAB_SHIFT PAGE_SHIFT /* Number of bits PAGE_MASK */ -#define UMA_BOOT_PAGES 64 /* Pages allocated for startup */ +#define UMA_BOOT_PAGES 512 /* Pages allocated for startup */ /* Max waste percentage before going to off page slab management */ #define UMA_MAX_WASTE 10 And lastly, the more verbose log: Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #336 52fd91e(smp_48)-dirty: Fri May 15 18:57:05 CEST 2015 mst@arm64-prime:/usr/home/mst/freebsd_v8/obj_kernel/arm64.aarch64/usr/home/mst/freebsd_v8/kernel/sys/THUNDER-88XX arm64 FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 MST: in vm_mem_init() Creating uma keg headers zone and keg. UMA: UMA Kegs(0xffffff8000d1b140) size 256(256) flags 0x20000000 ipers 15 ppera 1 out 0 free 0 Filling boot free list. Creating uma zone headers zone and keg. INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) alloc_slab: Allocating a new slab for UMA Kegs UMA: UMA Zones(0xffffff8000d1b000) size 1856(1856) flags 0x20000000 ipers 2 ppera 1 out 0 free 0 Creating slab and hash zones. INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) alloc_slab: Allocating a new slab for UMA Zones INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: UMA Slabs(0xffffffc0789fe000) size 112(112) flags 0x20000000 ipers 35 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: UMA RCntSlabs(0xffffffc0789fe740) size 120(120) flags 0x20000000 ipers 33 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) alloc_slab: Allocating a new slab for UMA Zones INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: UMA Hash(0xffffffc0789fd000) size 256(256) flags 0x20000000 ipers 15 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: 4 Bucket(0xffffffc0789fd740) size 32(32) flags 0x10000040 ipers 124 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) alloc_slab: Allocating a new slab for UMA Zones INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: 6 Bucket(0xffffffc0789fc000) size 48(48) flags 0x10000040 ipers 83 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: 8 Bucket(0xffffffc0789fc740) size 64(64) flags 0x10000040 ipers 62 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) alloc_slab: Allocating a new slab for UMA Zones INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: 12 Bucket(0xffffffc0789fb000) size 96(96) flags 0x10000040 ipers 41 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: 16 Bucket(0xffffffc0789fb740) size 128(128) flags 0x10000040 ipers 31 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) alloc_slab: Allocating a new slab for UMA Zones INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: 32 Bucket(0xffffffc0789fa000) size 256(256) flags 0x10000040 ipers 15 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: 64 Bucket(0xffffffc0789fa740) size 512(512) flags 0x10000040 ipers 7 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) alloc_slab: Allocating a new slab for UMA Zones INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA decided we need offpage slab headers for keg: 128 Bucket, calculated wastedspace = 912, maximum wasted space allowed = 409, calculated ipers = 4, new wasted space = 0 INTERNAL: Allocating one item from UMA Hash(0xffffffc0789fd000) alloc_slab: Allocating a new slab for UMA Hash UMA: 128 Bucket(0xffffffc0789f9000) size 1024(1024) flags 0x10000148 ipers 4 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA decided we need offpage slab headers for keg: 256 Bucket, calculated wastedspace = 1936, maximum wasted space allowed = 409, calculated ipers = 2, new wasted space = 0 INTERNAL: Allocating one item from UMA Hash(0xffffffc0789fd000) UMA: 256 Bucket(0xffffffc0789f9740) size 2048(2048) flags 0x10000148 ipers 2 ppera 1 out 0 free 0 UMA startup complete. INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) alloc_slab: Allocating a new slab for UMA Zones INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: vmem btag(0xffffffc0789f7000) size 56(56) flags 0x80000080 ipers 71 ppera 1 out 0 free 0 alloc_slab: Allocating a new slab for vmem btag INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: VM OBJECT(0xffffffc0789f7740) size 256(256) flags 0x20 ipers 15 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) alloc_slab: Allocating a new slab for UMA Zones INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) alloc_slab: Allocating a new slab for UMA Kegs UMA: RADIX NODE(0xffffffc0789f5000) size 144(144) flags 0x80000080 ipers 27 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: MAP(0xffffffc0789f5740) size 240(240) flags 0x20 ipers 16 ppera 1 out 0 free 0 alloc_slab: Allocating a new slab for MAP INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) alloc_slab: Allocating a new slab for UMA Zones INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: KMAP ENTRY(0xffffffc0789f2000) size 128(128) flags 0x800000c0 ipers 31 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: MAP ENTRY(0xffffffc0789f2740) size 128(128) flags 0 ipers 31 ppera 1 out 0 free 0 INTERNAL: Allocating one item from UMA Zones(0xffffff8000d1b000) alloc_slab: Allocating a new slab for UMA Zones INTERNAL: Allocating one item from UMA Kegs(0xffffff8000d1b140) UMA: VMSPACE(0xffffffc0789f1000) size 384(384) flags 0x20 ipers 10 ppera 1 out 0 free 0 Allocating one item from MAP(0xffffffc0789f5740) INTERNAL: Allocating one item from MAP(0xffffffc0789f5740) Allocating one item from KMAP ENTRY(0xffffffc0789f2000) INTERNAL: Allocating one item from KMAP ENTRY(0xffffffc0789f2000) alloc_slab: Allocating a new slab for KMAP ENTRY MST: in vmem_init() with param *vm == kernel_arena MST: in vmem_xalloc() with param *vm == kernel_arena Allocating one item from vmem btag(0xffffffc0789f7000) INTERNAL: Allocating one item from vmem btag(0xffffffc0789f7000) Allocating one item from vmem btag(0xffffffc0789f7000) INTERNAL: Allocating one item from vmem btag(0xffffffc0789f7000) alloc_slab: Allocating a new slab for vmem btag MST: in vmem_xalloc() with param *vm == kmem_arena panic: mtx_lock() of spin mutex (null) @ /usr/home/mst/freebsd_v8/kernel/sys/kern/subr_vmem.c:1165 cpuid = 0 KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at 0xffffff80001f4f80: db> Best regards, Michal Stanek From owner-freebsd-arm@FreeBSD.ORG Sun May 17 13:57:24 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC4CC84B for ; Sun, 17 May 2015 13:57:24 +0000 (UTC) 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 A742D1279 for ; Sun, 17 May 2015 13:57:24 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4HDvOGT015205 for ; Sun, 17 May 2015 13:57:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 199446] arm Raspberry Pi panic without ethernet connected on boot Date: Sun, 17 May 2015 13:57:24 +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 Only Me X-Bugzilla-Who: loos@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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, 17 May 2015 13:57:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199446 Luiz Otavio O Souza changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |loos@FreeBSD.org --- Comment #4 from Luiz Otavio O Souza --- Hi Steve, Can we close this PR ? This problem is not related to ethernet and ARM_NEW_PMAP is enabled by default now (which fix the l2_bucket issue). -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun May 17 13:59:46 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF1F48C4; Sun, 17 May 2015 13:59:46 +0000 (UTC) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.site.uottawa.ca", Issuer "PositiveSSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E5371291; Sun, 17 May 2015 13:59:46 +0000 (UTC) Received: from [10.0.2.15] (ppp-69-60-228-191.vianet.ca [69.60.228.191]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id t4HDxeOG098285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 17 May 2015 09:59:41 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Sun, 17 May 2015 09:59:39 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: Warner Losh cc: Daisuke Aoyama , freebsd-arm@freebsd.org, Ian Lepore Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] In-Reply-To: Message-ID: References: <1431822588.91685.48.camel@freebsd.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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, 17 May 2015 13:59:46 -0000 On Sat, 16 May 2015, Warner Losh wrote: > >> On May 16, 2015, at 8:40 PM, Keith White wrote: >> >> On Sun, 17 May 2015, Daisuke Aoyama wrote: >> >>> -------------------------------------------------- >>> From: "Ian Lepore" >>> Sent: Sunday, May 17, 2015 9:29 AM >>> To: "Svatopluk Kraus" >>> Cc: "Keith White" ; >>> Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] >>> >>>> On Fri, 2015-05-15 at 10:18 +0200, Svatopluk Kraus wrote: >>>>> On Fri, May 15, 2015 at 2:13 AM, Keith White wrote: >>>>>> On Thu, 14 May 2015, Svatopluk Kraus wrote: >>>>>> >>>>>>> On Thu, May 14, 2015 at 2:03 AM, Keith White >>>>>>> wrote: >>>>>>>> >>>>>>>> I get the following panic when trying to load an mfs_root on a >>>>>>>> reasonably current BBB image: >>>>>>>> >>>>>>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>>>>>> trapframe: 0xdd43fd50 >>>>>>>> FSR=00000005, FAR=01211ef0, spsr=20000113 >>>>>>>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 >>>>>>>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 >>>>>>>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 >>>>>>>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 >>>>>>>> >>>>>>>> [ thread pid 4 tid 100054 ] >>>>>>>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >>>>>>>> db> >>>>>>>> >>>>>>>> Hints, suggestions? >>>>>>>> >>>>>>>> ...keith >>>>>>>> >>>>>>>> --------------------------------- >>>>>>>> More (trimmed) details from boot: >>>>>>>> >>>>>>>> ... >>>>>>>> U-Boot 2014.10 (Mar 19 2015 - 18:29:51) >>>>>>>> ... >>>>>>>> FreeBSD/armv6hf U-Boot loader, Revision 1.2 >>>>>>>> (kwhite@freebsd11, Tue Mar 17 22:23:25 EDT 2015) >>>>>>>> ... >>>>>>>> Found U-Boot device: disk >>>>>>>> Checking unit=1 slice= partition=... good. >>>>>>>> /boot/kernel/kernel data=0x505c2c+0x923d4 syms=[0x4+0x606a0+0x4+0x65ed4] >>>>>>>> /boot/kernel/snd_uaudio.ko text=0xed3c data=0x620+0x10 >>>>>>>> syms=[0x4+0x1ec0+0x4+0x1a2f] >>>>>>>> ... >>>>>>>> Type '?' for a list of commands, 'help' for more detailed help. >>>>>>>> loader> load -t mfs_root /rootfs >>>>>>>> /rootfs size=0x858000 >>>>>>>> loader> boot -asv >>>>>>>> Booting... >>>>>>>> /boot/dtb/beaglebone-black.dtb size=0x24b4 >>>>>>>> Loaded DTB from file 'beaglebone-black.dtb'. >>>>>>>> Kernel entry at 0x80200100... >>>>>>>> Kernel args: -asv >>>>>>>> KDB: debugger backends: ddb >>>>>>>> KDB: current backend: ddb >>>>>>>> Copyright (c) 1992-2015 The FreeBSD Project. >>>>>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>>>>>>> The Regents of the University of California. All rights reserved. >>>>>>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>>>>>> FreeBSD 11.0-CURRENT #1 r282672M: Tue May 12 06:57:24 EDT 2015 >>>>>>>> >>>>>>>> kwhite@freebsd11:/usr/obj/arm.armv6hf/tank/RPI/head/sys/BEAGLEBONE-LOCAL >>>>>>>> arm >>>>>>>> FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 >>>>>>>> WARNING: WITNESS option enabled, expect reduced performance. >>>>>>>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc1219000. >>>>>>>> ... >>>>>>>> mmc0: Probing bus >>>>>>>> usbus0: 480Mbps High Speed USB v2.0 >>>>>>>> usbus1: 480Mbps High Speed USB v2.0 >>>>>>>> md0: Preloaded image 8749056 bytes at 0x9b9f00 >>>>>>>> ugen1.1: at usbus1 >>>>>>>> uhub0: >>>>>>>> on >>>>>>>> usbus1 >>>>>>>> ugen0.1: at usbus0 >>>>>>>> uhub1: >>>>>>>> on >>>>>>>> usbus0 >>>>>>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read >>>>>>>> trapframe: 0xdd43fd50 >>>>>>>> FSR=00000005, FAR=01211ef0, spsr=20000113 >>>>>>>> r0 =c35f4200, r1 =01211f00, r2 =000001e0, r3 =3dc1dd00 >>>>>>>> r4 =c3638930, r5 =c362d838, r6 =c362d810, r7 =c06037b8 >>>>>>>> r8 =0000002d, r9 =00000000, r10=c3638930, r11=dd43fdf0 >>>>>>>> r12=00000000, ssp=dd43fde0, slr=c0249918, pc =c05c6a68 >>>>>>>> >>>>>>>> [ thread pid 4 tid 100054 ] >>>>>>>> Stopped at memmove+0x29c: ldmdb r1!, {r3-r4, r12, r14} >>>>>>> >>>>>>> >>>>>>> >>>>>>> Well, FAR (fault address) points to user address space. System is >>>>>>> still in boot process and no user address should be used. The first >>>>>>> thing is to find out if arguments pushed to bcopy() in >>>>>>> mdstart_preload() are correct. Can you print them out? >>>>>>> ... >>>>>> >>>>>> >>>>>> Thanks for the hint! After a little digging with ddb, it appears >>>>>> that the fault address is missing an offset of KERNBASE (0xc0000000). >>>>>> The mfs_root being found at 0x9b9f00 ("md0: preloaded image at") + >>>>>> KERNBASE (0xc0000000). The following patch fixes the symptom, and >>>>>> allows a boot to successfully complete. The resulting md is also >>>>>> usable as /. >>>>>> >>>>>> I'm sure there's a more correct patch? >>>>>> >>>>>> Index: sys/dev/md/md.c >>>>>> =================================================================== >>>>>> --- sys/dev/md/md.c (revision 282672) >>>>>> +++ sys/dev/md/md.c (working copy) >>>>>> @@ -1590,7 +1590,11 @@ >>>>>> len = preload_fetch_size(mod); >>>>>> if (ptr != NULL && len != 0) { >>>>>> sx_xlock(&md_sx); >>>>>> +#ifdef __arm__ >>>>>> + md_preloaded(KERNBASE + ptr, len, name); >>>>>> +#else >>>>>> md_preloaded(ptr, len, name); >>>>>> +#endif >>>>>> sx_xunlock(&md_sx); >>>>>> } >>>>>> } >>>>> Thanks for debugging it. The preload_fetch_addr() already uses >>>>> preload_addr_relocate to adjust returned address. IMO, a patch should >>>>> either deal with preload_addr_relocate and init it correctly or fix >>>>> MODINFO_ADDR info in kernel modules. Now, preload_addr_relocate is set >>>>> only when FREEBSD_BOOT_LOADER is defined. In this moment, I know >>>>> nothing about how MODINFO_ADDR info is generated. >>>>> BTW, physical address space starts at 0x80000000 on BBB and KERNBASE >>>>> is 0xC0000000, so I would be expecting that preload_addr_relocate >>>>> should be set to 0x40000000. The FAR is 0x01211ef0, so it's not >>>>> physical address. And as your patch helps, it's an offset to either >>>>> physical or virtual address space. So it looks more like MODINFO_ADDR >>>>> info problem. >>>> I think the problem here is likely to be in ubldr. Today I tried to >>>> recreate this and all I could get was complete system lockup right after >>>> the kernel copyright displayed. Eventually I noticed that your root >>>> image is less than 10MB, so I created a little image about the same size >>>> as yours and put init(8) in it, and with that I get the same panic you >>>> do (different physical address, I'm doing it on a wandboard). >>>> I think there are at least two separate problems here. ubldr isn't >>>> setting the right metadata for the load address, and then separately >>>> from that, trying to load really big files corrupts memory somehow in a >>>> way that locks up the kernel. >>>> I'll keep poking at it. >>> >>> I posted about ubldr/mfsroot last year. no one interest it... >>> http://lists.freebsd.org/pipermail/freebsd-arm/2014-December/009839.html >>> I think ubldr should be fixed. >>> -- >>> Daisuke Aoyama >>> >>> >> >> Thanks Ian for looking at this! >> >> Based upon the comments by Daisuke Aoyama, the patch above using >> KERNBASE becomes this using preload_addr_relocate: >> >> ----------------- >> --- sys/dev/md/md.c (revision 282672) >> +++ sys/dev/md/md.c (working copy) >> @@ -1590,7 +1590,11 @@ >> len = preload_fetch_size(mod); >> if (ptr != NULL && len != 0) { >> sx_xlock(&md_sx); >> +#ifdef __arm__ >> + md_preloaded(ptr - preload_addr_relocate, len, name); >> +#else >> md_preloaded(ptr, len, name); >> +#endif >> sx_xunlock(&md_sx); >> } >> } > > This is almost certainly the wrong place to fix this. The right place to fix it is in ubldr. It says that all the ptrs are AFU only on arm, and this one is likely the first of many. > > Warner > > You're too generous, no "almost" about it. ubldr is well beyond my capabilities to fix. Sticky tape for md allows me to use an mfs_root in the meantime... ...keith From owner-freebsd-arm@FreeBSD.ORG Sun May 17 14:50:22 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E90EF4A for ; Sun, 17 May 2015 14:50:22 +0000 (UTC) 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 ED63F17F5 for ; Sun, 17 May 2015 14:50:21 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4HEoLlk094366 for ; Sun, 17 May 2015 14:50:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200269] Clang failed due to some internal error during buildworld on RPI2. Date: Sun, 17 May 2015 14:50:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new 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: jau@iki.fi X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: 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, 17 May 2015 14:50:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200269 Bug ID: 200269 Summary: Clang failed due to some internal error during buildworld on RPI2. Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: jau@iki.fi Created attachment 156854 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=156854&action=edit The last 150 lines of the build time messages I was maybe pushing things a bit, but I decided to try buildworld and buildkernel on my RPI2. It would have been nice to be able to say it is in principle self hosting. As it seems, it is not quite there yet. During buildworld while clang was compiling itself it failed with an error message which did not help me much. Obviously there was some sort of an internal error, but that was pretty much all. So, just in case someone knows clang better and has some interest in understanding what happened I attach the last 150 lines of the build time messages and the couple of files clang itself instructed to be attached to any bug reports. The cpp file was so big that it became necessary to compress it using xz. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun May 17 14:52:51 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 657BEFFD for ; Sun, 17 May 2015 14:52:51 +0000 (UTC) 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 5078B1816 for ; Sun, 17 May 2015 14:52:51 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4HEqpM4000209 for ; Sun, 17 May 2015 14:52:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200269] Clang failed due to some internal error during buildworld on RPI2. Date: Sun, 17 May 2015 14:52:51 +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: jau@iki.fi X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created 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, 17 May 2015 14:52:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200269 --- Comment #1 from jau@iki.fi --- Created attachment 156855 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=156855&action=edit 1st of the two files clang instructed to be attached -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun May 17 14:54:06 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DD1BD8 for ; Sun, 17 May 2015 14:54:06 +0000 (UTC) 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 48D8A1820 for ; Sun, 17 May 2015 14:54:06 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4HEs6hM000668 for ; Sun, 17 May 2015 14:54:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200269] Clang failed due to some internal error during buildworld on RPI2. Date: Sun, 17 May 2015 14:54:06 +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: jau@iki.fi X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created 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, 17 May 2015 14:54:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200269 --- Comment #2 from jau@iki.fi --- Created attachment 156856 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=156856&action=edit 2nd of the two files clang instructed to be attached -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun May 17 15:18:02 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1FC21AF7 for ; Sun, 17 May 2015 15:18:02 +0000 (UTC) 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 0AAF01A69 for ; Sun, 17 May 2015 15:18:02 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4HFI1lT095588 for ; Sun, 17 May 2015 15:18:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200269] Clang failed due to some internal error during buildworld on RPI2. Date: Sun, 17 May 2015 15:18:01 +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: loos@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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, 17 May 2015 15:18:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200269 Luiz Otavio O Souza changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |loos@FreeBSD.org --- Comment #3 from Luiz Otavio O Souza --- c++: error: unable to execute command: Killed This usually happens when you run out of memory, do you have any swap space set ? 1GB of RAM is not enough to build world with -jX on Rpi 2. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun May 17 15:44:21 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E962F81 for ; Sun, 17 May 2015 15:44:21 +0000 (UTC) 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 19D4D1D69 for ; Sun, 17 May 2015 15:44:21 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4HFiKV5021790 for ; Sun, 17 May 2015 15:44:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 199446] arm Raspberry Pi panic without ethernet connected on boot Date: Sun, 17 May 2015 15:44:21 +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 Only Me X-Bugzilla-Who: swills@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 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, 17 May 2015 15:44:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199446 Steve Wills changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED --- Comment #5 from Steve Wills --- (In reply to Luiz Otavio O Souza from comment #4) Yep, closing! -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun May 17 16:51:19 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47639324 for ; Sun, 17 May 2015 16:51:19 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (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 D8A7E1397 for ; Sun, 17 May 2015 16:51:18 +0000 (UTC) Received: by wgfl8 with SMTP id l8so10650796wgf.2 for ; Sun, 17 May 2015 09:51:17 -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=oU2xVJ1wQltqBUv7lRZQiyT3aCQ3HtsTcnJyHwuwV6I=; b=dN8GlbmMby5nbwifEnh2UlsgwEpNTgSPgvqltIEgjutOHKLc3jml9hCmHu46EeePI0 rU7XiTjaZa+4DsquNkj/tF8bobAT616olRoo4jiVWIbJX4VPIVdGXTW5d+dEV3hAXASZ 18h38bLQR32L9AM6Lgkk8/VtE5+wdUDE9Cb4WZ1UITW2N7ItBeh+dZ8D2VzSmKfwY16l aU6pUyJI0i5sQazNpMRG/lFcRcYJHBGNVZbsN6ePQx1N99OQ7neN6/j7/DZ8t/Kr8TLP 08TZmFQnnPnbWO3glxhDZ7FksjiKlV+KjyQPmQKjZj8tDSnhvAjkxEeG/Wm/NprttKr1 /92Q== MIME-Version: 1.0 X-Received: by 10.180.106.195 with SMTP id gw3mr14951603wib.25.1431881477309; Sun, 17 May 2015 09:51:17 -0700 (PDT) Received: by 10.194.88.165 with HTTP; Sun, 17 May 2015 09:51:17 -0700 (PDT) Date: Sun, 17 May 2015 17:51:17 +0100 Message-ID: Subject: USB Armory support From: "Sevan / Venture37" To: 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: Sun, 17 May 2015 16:51:19 -0000 Hi, Has anyone looked at running FreeBSD on the USB Armory device? https://inversepath.com/usbarmory.html https://media.ccc.de/browse/congress/2014/31c3_-_6541_-_en_-_saal_2_-_201412281730_-_forging_the_usb_armory_-_andrea_barisani.html#video Sevan / Venture37 From owner-freebsd-arm@FreeBSD.ORG Sun May 17 17:08:34 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B755815 for ; Sun, 17 May 2015 17:08:34 +0000 (UTC) Received: from outbound3.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) by mx1.freebsd.org (Postfix) with SMTP id 3B6CB162F for ; Sun, 17 May 2015 17:08:33 +0000 (UTC) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 17 May 2015 17:07:19 +0000 (UTC) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t4HH7OPI012678; Sun, 17 May 2015 11:07:24 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1431882444.91685.53.camel@freebsd.org> Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] From: Ian Lepore To: Keith White Cc: Warner Losh , freebsd-arm@freebsd.org Date: Sun, 17 May 2015 11:07:24 -0600 In-Reply-To: References: <1431822588.91685.48.camel@freebsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 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: Sun, 17 May 2015 17:08:34 -0000 On Sun, 2015-05-17 at 09:59 -0400, Keith White wrote: > On Sat, 16 May 2015, Warner Losh wrote: > > > > >> On May 16, 2015, at 8:40 PM, Keith White wrote: > >> > >> On Sun, 17 May 2015, Daisuke Aoyama wrote: > >> > >>> -------------------------------------------------- > >>> From: "Ian Lepore" > >>> Sent: Sunday, May 17, 2015 9:29 AM > >>> To: "Svatopluk Kraus" > >>> Cc: "Keith White" ; > >>> Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] > >>>[...] > >> > >> Thanks Ian for looking at this! > >> > >> Based upon the comments by Daisuke Aoyama, the patch above using > >> KERNBASE becomes this using preload_addr_relocate: > >> > >> ----------------- > >> --- sys/dev/md/md.c (revision 282672) > >> +++ sys/dev/md/md.c (working copy) > >> @@ -1590,7 +1590,11 @@ > >> len = preload_fetch_size(mod); > >> if (ptr != NULL && len != 0) { > >> sx_xlock(&md_sx); > >> +#ifdef __arm__ > >> + md_preloaded(ptr - preload_addr_relocate, len, name); > >> +#else > >> md_preloaded(ptr, len, name); > >> +#endif > >> sx_xunlock(&md_sx); > >> } > >> } > > > > This is almost certainly the wrong place to fix this. The right place to fix it is in ubldr. It says that all the ptrs are AFU only on arm, and this one is likely the first of many. > > > > Warner > > > > > > You're too generous, no "almost" about it. > > ubldr is well beyond my capabilities to fix. Sticky tape for md > allows me to use an mfs_root in the meantime... > > ...keith After much code archeology and some testing I've determined that the actual problem is that we're setting preload_addr_relocate to a non-zero value at all. That should only be done when ubldr passes physical addresses in metadata, but for arm it always passes virtual addresses. I think that changed (maybe by accident) a while back in ubldr and the kernel side didn't get fixed to match until now. So, as of r283033 it should work right. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun May 17 17:36:06 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D17E5BF7 for ; Sun, 17 May 2015 17:36:06 +0000 (UTC) Received: from outbound3.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) by mx1.freebsd.org (Postfix) with SMTP id B15C3192B for ; Sun, 17 May 2015 17:36:06 +0000 (UTC) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 17 May 2015 17:35:58 +0000 (UTC) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t4HHa35m012737; Sun, 17 May 2015 11:36:03 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1431884163.91685.55.camel@freebsd.org> Subject: Re: USB Armory support From: Ian Lepore To: Sevan / Venture37 Cc: freebsd-arm Date: Sun, 17 May 2015 11:36:03 -0600 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 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: Sun, 17 May 2015 17:36:06 -0000 On Sun, 2015-05-17 at 17:51 +0100, Sevan / Venture37 wrote: > Hi, > Has anyone looked at running FreeBSD on the USB Armory device? > > https://inversepath.com/usbarmory.html > https://media.ccc.de/browse/congress/2014/31c3_-_6541_-_en_-_saal_2_-_201412281730_-_forging_the_usb_armory_-_andrea_barisani.html#video > > > Sevan / Venture37 I've thought about it, but don't really have enough free time to buy one just to play with right now. I'd be willing to get one and put some effort into it if people have an interest in it. In theory it shouldn't take too much work since we already have basic support for other imx5x boards. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun May 17 17:59:02 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D37E11D for ; Sun, 17 May 2015 17:59:02 +0000 (UTC) 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 D17BD1B48 for ; Sun, 17 May 2015 17:59:01 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4HHx1jX008069 for ; Sun, 17 May 2015 17:59:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200271] lang/gcc "make install" fails with Malformed conditional error Date: Sun, 17 May 2015 17:59:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: john@jfloren.net X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc flagtypes.name Message-ID: 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, 17 May 2015 17:59:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200271 Bug ID: 200271 Summary: lang/gcc "make install" fails with Malformed conditional error Product: Ports & Packages Version: Latest Hardware: arm OS: Any Status: New Severity: Affects Many People Priority: --- Component: Individual Port(s) Assignee: gerald@FreeBSD.org Reporter: john@jfloren.net CC: freebsd-arm@FreeBSD.org CC: freebsd-arm@FreeBSD.org Assignee: gerald@FreeBSD.org Flags: maintainer-feedback?(gerald@FreeBSD.org) Running 10.1-STABLE on Raspberry Pi. Freshly installed system, attempted to build "news/cnews": ===> cnews-cr.g_12 depends on executable: gcc48 - not found ===> Verifying install for gcc48 in /usr/ports/lang/gcc make[2]: "/usr/ports/lang/gcc/Makefile" line 66: Malformed conditional (${COMPILER_TYPE} == clang) make[2]: Fatal errors encountered -- cannot continue make[2]: stopped in /usr/ports/lang/gcc *** Error code 1 Stop. make[1]: stopped in /usr/ports/news/cnews *** Error code 1 Stop. make: stopped in /usr/ports/news/cnews If I run "make install" in the /usr/ports/lang/gcc, I see the same "Malformed conditional" error. If I run "make install" in lang/gcc48, I see "===> gcc48-4.8.5.s20150423 is only for amd64 i386 powerpc powerpc64 sparc64, while you are running armv6." -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun May 17 18:02:15 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 116561AA for ; Sun, 17 May 2015 18:02:15 +0000 (UTC) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (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 CB4091C17 for ; Sun, 17 May 2015 18:02:14 +0000 (UTC) Received: by igbpi8 with SMTP id pi8so70220689igb.0 for ; Sun, 17 May 2015 11:02:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=Z6ffKcmn8ncnbtiH/jpFtfnjeEboxzYez2Z6JlWeckE=; b=aDCtEVCFac9p66TdGU2JjOXbKB+jCT20dYQNVsOVUv6Q7HzVF2+zKdLUny+VH9jgbS Dvy7V0Z1qbagw/CDEpbQj59mJDGT7lO2+dyULZ83SrHIdtRvsk7Lo79h3X7KroHAU25X vJetESH5DUu6XFgs0XMDeSk5T89ilX220ids8O88jWPFSDNkCMbJ5zZ0RvoZfSpm6pDI FoQYIASUmGpU+CJomFw+a7fFS7FD1Z2wLqefht8k3LxDEM0e29MiHI1Arzu9CSAyeVoZ xVWvBpopjEV1Imkig3G3R7YCSYkLcXuDP3WwFOHzHDX7VV+FUrxfy6x6Rwrojpc0rcHN YHhw== X-Gm-Message-State: ALoCoQlryvdzXdJczu8Qv0ZT4KXkYVhgEvzivoh6krHpWwhFisG6ClaTQkK6z2rytdjMT//EP/Mv X-Received: by 10.43.5.74 with SMTP id of10mr31254469icb.67.1431885733266; Sun, 17 May 2015 11:02:13 -0700 (PDT) Received: from netflix-mac-wired.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id av6sm3864969igc.17.2015.05.17.11.02.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 May 2015 11:02:12 -0700 (PDT) Sender: Warner Losh Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2EC75DEE-A1F7-4B39-B82D-AA9BF1C49FC7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: <1431882444.91685.53.camel@freebsd.org> Date: Sun, 17 May 2015 12:02:10 -0600 Cc: Keith White , freebsd-arm@freebsd.org Message-Id: <566BFACF-E9B2-4E8A-A36C-AB4F12A84168@bsdimp.com> References: <1431822588.91685.48.camel@freebsd.org> <1431882444.91685.53.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.2098) 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, 17 May 2015 18:02:15 -0000 --Apple-Mail=_2EC75DEE-A1F7-4B39-B82D-AA9BF1C49FC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 17, 2015, at 11:07 AM, Ian Lepore wrote: >=20 > On Sun, 2015-05-17 at 09:59 -0400, Keith White wrote: >> On Sat, 16 May 2015, Warner Losh wrote: >>=20 >>>=20 >>>> On May 16, 2015, at 8:40 PM, Keith White = wrote: >>>>=20 >>>> On Sun, 17 May 2015, Daisuke Aoyama wrote: >>>>=20 >>>>> -------------------------------------------------- >>>>> From: "Ian Lepore" >>>>> Sent: Sunday, May 17, 2015 9:29 AM >>>>> To: "Svatopluk Kraus" >>>>> Cc: "Keith White" ; = >>>>> Subject: Re: Translation Fault panic when trying to use an = mfs_root on BBB [solved?] [patch] >>>>> [...] >>>>=20 >>>> Thanks Ian for looking at this! >>>>=20 >>>> Based upon the comments by Daisuke Aoyama, the patch above using >>>> KERNBASE becomes this using preload_addr_relocate: >>>>=20 >>>> ----------------- >>>> --- sys/dev/md/md.c (revision 282672) >>>> +++ sys/dev/md/md.c (working copy) >>>> @@ -1590,7 +1590,11 @@ >>>> len =3D preload_fetch_size(mod); >>>> if (ptr !=3D NULL && len !=3D 0) { >>>> sx_xlock(&md_sx); >>>> +#ifdef __arm__ >>>> + md_preloaded(ptr - preload_addr_relocate, = len, name); >>>> +#else >>>> md_preloaded(ptr, len, name); >>>> +#endif >>>> sx_xunlock(&md_sx); >>>> } >>>> } >>>=20 >>> This is almost certainly the wrong place to fix this. The right = place to fix it is in ubldr. It says that all the ptrs are AFU only on = arm, and this one is likely the first of many. >>>=20 >>> Warner >>>=20 >>>=20 >>=20 >> You're too generous, no "almost" about it. >>=20 >> ubldr is well beyond my capabilities to fix. Sticky tape for md >> allows me to use an mfs_root in the meantime... >>=20 >> ...keith >=20 > After much code archeology and some testing I've determined that the > actual problem is that we're setting preload_addr_relocate to a = non-zero > value at all. That should only be done when ubldr passes physical > addresses in metadata, but for arm it always passes virtual addresses. > I think that changed (maybe by accident) a while back in ubldr and the > kernel side didn't get fixed to match until now. >=20 > So, as of r283033 it should work right. Thanks Ian! You rock! Warner --Apple-Mail=_2EC75DEE-A1F7-4B39-B82D-AA9BF1C49FC7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVWNejAAoJEGwc0Sh9sBEAGTcQAOBDHtdP0TtOmpjeUIoVP9Fq ESonKmNhLxWGDv9qouyLksqBzBdOJyZYOL2Q6lIjEUNSEjhkEZ+fAkgSvAVdoNhT KQ4xFfQyPVzEyrXdmNHo9+W+s7Bp9qP6g9E0hJKvShZJDF445Dlq/Ijzd796Wz3y 9e3iw+lmNdfOWo4eQUsBgZ8zy+UOD4IQ6ncz62HxK15hsEAN/iY5R79fyCNjqXqv 5npTecxIhD/ueh98jCR4zIwJb86PLKCMhHZRRwTwFOVsb3pqbCeg+tyNr0ppehR8 pgQNhZGNI0ONOUDbUI0bLJV5tmHAQB2pdsym+sZLIYLiVzKXAEwSjV8JpJAyt0aH BQXEyI8PvOO+45zbher0L7BRSShvhTELW1DyRYEv3nRi+k+wLyreru+M7pn9kxt7 1/fZAW4wFN74315Zrs80tMnhveXCuF/f8KVMaameQ0Jor6GqKhSsuEyBCVIdKQmt fNcRKkYty6EFRoh2HC4l2HhByvcKtrxfNKBFujMvrrYyS2S36BBBz8iOmwmAXPe9 7Koxjf9WY08MyXedwjGg8N+5d3riiskvGAwi4Sjg116ZtTcpC8faOVecXu7aNCxJ Dx9cUaoYdK36Oojl6MUxActpKSYr1LDLsubHgW6HYp1P/Qa/Hkbeg7g7nSI2YdEe TQnwEbo6YeX8eClNb+IL =TDbJ -----END PGP SIGNATURE----- --Apple-Mail=_2EC75DEE-A1F7-4B39-B82D-AA9BF1C49FC7-- From owner-freebsd-arm@FreeBSD.ORG Sun May 17 18:09:31 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C2DC3CB; Sun, 17 May 2015 18:09:31 +0000 (UTC) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.site.uottawa.ca", Issuer "PositiveSSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F4CE1C3D; Sun, 17 May 2015 18:09:30 +0000 (UTC) Received: from [10.0.2.15] (ppp-69-60-228-191.vianet.ca [69.60.228.191]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id t4HI9QWj009023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 17 May 2015 14:09:27 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Sun, 17 May 2015 14:09:24 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: Warner Losh cc: Ian Lepore , freebsd-arm@freebsd.org Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] In-Reply-To: <566BFACF-E9B2-4E8A-A36C-AB4F12A84168@bsdimp.com> Message-ID: References: <1431822588.91685.48.camel@freebsd.org> <1431882444.91685.53.camel@freebsd.org> <566BFACF-E9B2-4E8A-A36C-AB4F12A84168@bsdimp.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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, 17 May 2015 18:09:31 -0000 On Sun, 17 May 2015, Warner Losh wrote: > >> On May 17, 2015, at 11:07 AM, Ian Lepore wrote: >> >> On Sun, 2015-05-17 at 09:59 -0400, Keith White wrote: >>> On Sat, 16 May 2015, Warner Losh wrote: >>> >>>> >>>>> On May 16, 2015, at 8:40 PM, Keith White wrote: >>>>> >>>>> On Sun, 17 May 2015, Daisuke Aoyama wrote: >>>>> >>>>>> -------------------------------------------------- >>>>>> From: "Ian Lepore" >>>>>> Sent: Sunday, May 17, 2015 9:29 AM >>>>>> To: "Svatopluk Kraus" >>>>>> Cc: "Keith White" ; >>>>>> Subject: Re: Translation Fault panic when trying to use an mfs_root on BBB [solved?] [patch] >>>>>> [...] >>>>> >>>>> Thanks Ian for looking at this! >>>>> >>>>> Based upon the comments by Daisuke Aoyama, the patch above using >>>>> KERNBASE becomes this using preload_addr_relocate: >>>>> >>>>> ----------------- >>>>> --- sys/dev/md/md.c (revision 282672) >>>>> +++ sys/dev/md/md.c (working copy) >>>>> @@ -1590,7 +1590,11 @@ >>>>> len = preload_fetch_size(mod); >>>>> if (ptr != NULL && len != 0) { >>>>> sx_xlock(&md_sx); >>>>> +#ifdef __arm__ >>>>> + md_preloaded(ptr - preload_addr_relocate, len, name); >>>>> +#else >>>>> md_preloaded(ptr, len, name); >>>>> +#endif >>>>> sx_xunlock(&md_sx); >>>>> } >>>>> } >>>> >>>> This is almost certainly the wrong place to fix this. The right place to fix it is in ubldr. It says that all the ptrs are AFU only on arm, and this one is likely the first of many. >>>> >>>> Warner >>>> >>>> >>> >>> You're too generous, no "almost" about it. >>> >>> ubldr is well beyond my capabilities to fix. Sticky tape for md >>> allows me to use an mfs_root in the meantime... >>> >>> ...keith >> >> After much code archeology and some testing I've determined that the >> actual problem is that we're setting preload_addr_relocate to a non-zero >> value at all. That should only be done when ubldr passes physical >> addresses in metadata, but for arm it always passes virtual addresses. >> I think that changed (maybe by accident) a while back in ubldr and the >> kernel side didn't get fixed to match until now. >> >> So, as of r283033 it should work right. > > Thanks Ian! You rock! > > Warner Confirmation (if necessary!) that yes, after r283033, no sticky tape required. Thanks Ian! ...keith From owner-freebsd-arm@FreeBSD.ORG Sun May 17 18:19:39 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAF2C661 for ; Sun, 17 May 2015 18:19:39 +0000 (UTC) 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 D4F9D1D3D for ; Sun, 17 May 2015 18:19:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4HIJdF7001568 for ; Sun, 17 May 2015 18:19:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200271] lang/gcc "make install" fails with Malformed conditional error Date: Sun, 17 May 2015 18:19:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: kientzle@acm.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gerald@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc 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, 17 May 2015 18:19:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200271 kientzle@acm.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kientzle@acm.org --- Comment #1 from kientzle@acm.org --- >> If I run "make install" in lang/gcc48, I see "===> gcc48-4.8.5.s20150423 is only for amd64 i386 powerpc powerpc64 sparc64, while you are running armv6." I believe the gcc49 port has fixes for this that can probably be easily copied over. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun May 17 18:35:39 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FCC59A8 for ; Sun, 17 May 2015 18:35:39 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c: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 286111F02 for ; Sun, 17 May 2015 18:35:39 +0000 (UTC) Received: by wizk4 with SMTP id k4so53037441wiz.1 for ; Sun, 17 May 2015 11:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:hackerspace:user-agent; bh=ZYCAeFMh0++7BN5csj/vcUvO6Dk7+pz3HjJVTgfihFs=; b=rnLeQ/pEkZjSbBKOA8/o5AFZvGumc+//FIxpEFjuHpPFUn1FUvw9SppTSAaE7z0wks H6Iv22g3pdLzPGmHWNOhL8YoMFXZDWITHJ4niOCXUbgrZ5NWpKsi53LIIYXDeNUMYhBr 6Pqph7lwS2cmq82pMiiGxvl00zn4ceNif1t1hPsJjIC4BK4ZrRp4jVHzKO4jkwpTT/sT B/8emDwVrU4SY780e/S4Zng355mNOCK7Bv2FuHiqW+VbZ9R06roM5NFSbiSPCaZ28+/3 W62Ak7oZZbWjOhiJTfBeeRoZFQKYQXaWeB81z1w1omltJg1VccM07vIK6LsqBqGgFair UhOQ== X-Received: by 10.180.91.137 with SMTP id ce9mr15125320wib.76.1431887737446; Sun, 17 May 2015 11:35:37 -0700 (PDT) Received: from gmail.com (host81-159-207-134.range81-159.btcentralplus.com. [81.159.207.134]) by mx.google.com with ESMTPSA id ej5sm613488wjd.22.2015.05.17.11.35.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 May 2015 11:35:36 -0700 (PDT) Sender: Tom Jones Date: Sun, 17 May 2015 19:35:33 +0100 From: Tom Jones To: freebsd-arm@freebsd.org Subject: Re: USB Armory support Message-ID: <20150517183532.GA4059@gmail.com> References: <1431884163.91685.55.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1431884163.91685.55.camel@freebsd.org> Hackerspace: 57North Hacklab 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: Sun, 17 May 2015 18:35:39 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, May 17, 2015 at 11:36:03AM -0600, Ian Lepore wrote: > On Sun, 2015-05-17 at 17:51 +0100, Sevan / Venture37 wrote: > > Hi, > > Has anyone looked at running FreeBSD on the USB Armory device? > > > > https://inversepath.com/usbarmory.html > > https://media.ccc.de/browse/congress/2014/31c3_-_6541_-_en_-_saal_2_-_201412281730_-_forging_the_usb_armory_-_andrea_barisani.html#video > > > > > > Sevan / Venture37 > > I've thought about it, but don't really have enough free time to buy one > just to play with right now. I'd be willing to get one and put some > effort into it if people have an interest in it. In theory it shouldn't > take too much work since we already have basic support for other imx5x > boards. > I have one and started working on a port last week. I used modified the dts available here[1] and worked from the IMX53-QSB kernel config. I hit a translation fault on usbphy attach. [1]: https://github.com/inversepath/usbarmory/tree/master/software/kernel_conf -- Tom @adventureloop adventurist.me 'You realize night time makes up half of all time?' :wq --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline; filename=dmesg Content-Transfer-Encoding: 8bit Connected U-Boot 2015.04 (May 07 2015 - 15:19:06) CPU: Freescale i.MX53 rev2.1 at 800 MHz Reset cause: POR Board: Inverse Path USB armory MkI I2C: ready DRAM: 512 MiB MMC: FSL_SDHC: 0 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: CPU Net Initialization Failed No ethernet found. Hit any key to stop autoboot: 0 => loady 0x71000000 ## Ready for binary (ymodem) download to 0x71000000 at 115200 bps... C~CLocal command? lsz -Y kernel.bin Sending: kernel.bin Bytes Sent:5566464 BPS:11022 Sending: Ymodem sectors/kbytes sent: 0/ 0k Transfer complete xyzMµ- CRC mode, 2(SOH)/5436(STX)/0(CAN) packets, 3 retries ## Total Size = 0x0054ef9c = 5566364 Bytes => go 0x71000000 ## Starting application at 0x71000000 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #1 r282665M: Tue May 12 20:43:21 BST 2015 root@towel:/usr/obj/arm.armv6/usr/home/jones/code/usbarmory/sys/IMX53-ARMORY arm FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "kernel" at 0xc06cfab4. CPU: Cortex A8-r2 rev 5 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:3 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory = 536870912 (512 MB) avail memory = 514138112 (490 MB) Physical memory chunk(s): 0x70000000 - 0x8fffffff, 512 MB ( 131072 pages) Excluded memory regions: 0x71000000 - 0x71644fff, 6 MB ( 1605 pages) NoAlloc Static device mappings: 0x50000000 - 0x500fffff mapped at VA 0xffe00000 0x53f00000 - 0x53ffffff mapped at VA 0xffd00000 0x63f00000 - 0x63ffffff mapped at VA 0xffc00000 wlan: <802.11 Link Layer> random: entropy device infrastructure driver random: selecting highest priority adaptor random: SOFT: yarrow init() random: selecting highest priority adaptor mem: nfslock: pseudo-device null: openfirm: ofwbus0: simplebus0: on ofwbus0 simplebus1: mem 0x50000000-0x5fffffff on simplebus0 simplebus2: mem 0x50000000-0x5003ffff on simplebus1 simplebus3: mem 0x60000000-0x6fffffff on simplebus0 imxccm0: mem 0x53fd4000-0x53fd7fff irq 0,71,4,0,72,4 on simplebus1 simplebus1: no default resources for rid = 1, type = 3 imxccm0: could not allocate resources device_attach: imxccm0 attach returned 6 imx_iomux0: mem 0x53fa8000-0x53fabfff on simplebus1 Processing 1 pin-config node(s) in pinctrl-0 for esdhc@50004000 esdhc1grp: muxreg 0x02e4 muxval 0x00 inpreg 0x0000 inpval 0x00 padreg 0x066c padval 0x000001d5 esdhc1grp: muxreg 0x02e8 muxval 0x00 inpreg 0x0000 inpval 0x00 padreg 0x0670 padval 0x000001d5 esdhc1grp: muxreg 0x02f0 muxval 0x00 inpreg 0x0000 inpval 0x00 padreg 0x0678 padval 0x000001d5 esdhc1grp: muxreg 0x02f8 muxval 0x00 inpreg 0x0000 inpval 0x00 padreg 0x0680 padval 0x000001d5 esdhc1grp: muxreg 0x02ec muxval 0x00 inpreg 0x0000 inpval 0x00 padreg 0x0674 padval 0x000001d5 esdhc1grp: muxreg 0x02f4 muxval 0x00 inpreg 0x0000 inpval 0x00 padreg 0x067c padval 0x000001d5 Processing 1 pin-config node(s) in pinctrl-0 for iomuxc@53fa8000 hoggrp: muxreg 0x0314 muxval 0x03 inpreg 0x0000 inpval 0x00 padreg 0x06a4 padval 0x80000000 hoggrp: muxreg 0x0338 muxval 0x01 inpreg 0x0000 inpval 0x00 padreg 0x06c8 padval 0x80000000 hoggrp: muxreg 0x02dc muxval 0x01 inpreg 0x0000 inpval 0x00 padreg 0x0660 padval 0x80000000 hoggrp: muxreg 0x02e0 muxval 0x01 inpreg 0x0000 inpval 0x00 padreg 0x0664 padval 0x80000000 hoggrp: muxreg 0x01c8 muxval 0x01 inpreg 0x0000 inpval 0x00 padreg 0x0518 padval 0x80000000 hoggrp: muxreg 0x01cc muxval 0x01 inpreg 0x0000 inpval 0x00 padreg 0x051c padval 0x80000000 hoggrp: muxreg 0x0290 muxval 0x01 inpreg 0x0000 inpval 0x00 padreg 0x0610 padval 0x80000000 hoggrp: muxreg 0x0298 muxval 0x01 inpreg 0x0000 inpval 0x00 padreg 0x0618 padval 0x80000000 hoggrp: muxreg 0x033c muxval 0x01 inpreg 0x0000 inpval 0x00 padreg 0x06cc padval 0x80000000 Processing 1 pin-config node(s) in pinctrl-0 for serial@53fbc000 uart1grp: muxreg 0x00e8 muxval 0x02 inpreg 0x0000 inpval 0x00 padreg 0x0414 padval 0x000001e4 uart1grp: muxreg 0x00ec muxval 0x02 inpreg 0x0878 inpval 0x01 padreg 0x0418 padval 0x000001e4 Processing 1 pin-config node(s) in pinctrl-0 for leds led_gpio4_27@0: muxreg 0x0078 muxval 0x01 inpreg 0x0000 inpval 0x00 padreg 0x03a4 padval 0x80000000 imxccm0: mem 0x53fd4000-0x53fd7fff irq 0,71,4,0,72,4 on simplebus1 simplebus1: no default resources for rid = 1, type = 3 imxccm0: could not allocate resources device_attach: imxccm0 attach returned 6 tzic0: mem 0xfffc000-0xfffffff on ofwbus0 imxccm0: mem 0x53fd4000-0x53fd7fff irq 0,71,4,0,72,4 on simplebus1 simplebus1: no default resources for rid = 1, type = 3 imxccm0: could not allocate resources device_attach: imxccm0 attach returned 6 imx_gpt0: mem 0x53fa0000-0x53fa3fff irq 39 on simplebus1 imx_gpt0: Running on 0KHz clock, base freq 0Hz CR=0x0000027d, PR=0x00000000 Event timer "iMXGPT" quality 800 Timecounter "iMXGPT" frequency 0 Hz quality 1000 imxccm0: mem 0x53fd4000-0x53fd7fff irq 0,71,4,0,72,4 on simplebus1 simplebus1: no default resources for rid = 1, type = 3 imxccm0: could not allocate resources device_attach: imxccm0 attach returned 6 ofwbus0: compat fsl,imx-display-subsystem (no driver attached) simplebus0: mem 0x10000000-0x10000fff irq 28 disabled compat fsl,imx53-ahci (no driver attached) simplebus0: mem 0x18000000-0x1fffffff irq 11,10 compat fsl,imx53-ipu (no driver attached) simplebus2: mem 0x50004000-0x50007fff irq 1 compat fsl,imx53-esdhc (no driver attached) simplebus2: mem 0x50008000-0x5000bfff irq 2 disabled compat fsl,imx53-esdhc (no driver attached) simplebus2: mem 0x5000c000-0x5000ffff irq 33 disabled compat fsl,imx53-uart (no driver attached) simplebus2: mem 0x50010000-0x50013fff irq 36 disabled compat fsl,imx53-ecspi (no driver attached) simplebus2: mem 0x50014000-0x50017fff irq 30 disabled compat fsl,imx53-ssi (no driver attached) simplebus2: mem 0x50020000-0x50023fff irq 3 disabled compat fsl,imx53-esdhc (no driver attached) simplebus2: mem 0x50024000-0x50027fff irq 4 disabled compat fsl,imx53-esdhc (no driver attached) simplebus1: mem 0x53f00000-0x53f0005f compat fsl,imx53-aipstz (no driver attached) usbphy0: on simplebus1 Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xc070acd0 FSR=00000005, FAR=00000004, spsr=600001d3 r0 =00000000, r1 =c051bb0c, r2 =c0624524, r3 =c0624524 r4 =c06d035c, r5 =c28ac800, r6 =c28ac538, r7 =00000000 r8 =c058f67a, r9 =c28ac550, r10=8f565544, r11=c070ad68 r12=c06a0adc, ssp=c070ad60, slr=c051aee0, pc =c051aef4 [ thread pid 0 tid 100000 ] Stopped at imx_ccm_usbphy_enable+0x20: ldr r1, [r0, #0x004] db> --Qxx1br4bt0+wmkIi-- From owner-freebsd-arm@FreeBSD.ORG Sun May 17 19:42:16 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FBE2464 for ; Sun, 17 May 2015 19:42:16 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FF28161A for ; Sun, 17 May 2015 19:42:15 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Yu4Ce-0000Vf-Fu for freebsd-arm@freebsd.org; Sun, 17 May 2015 21:26:30 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: Random Kernel Panic on Dreamplug (FS related) References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com> <542A9EA4.70109@gmail.com> <20140930123010.GZ43300@funkthat.com> <542AB897.3020309@gmail.com> <1412086795.66615.363.camel@revolution.hippie.lan> <542ABE45.3020402@gmail.com> <1431814583.91685.39.camel@freebsd.org> Date: Sun, 17 May 2015 21:26:23 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <1431814583.91685.39.camel@freebsd.org> User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 04d3dbca5959de7ff55de8c5575fb43d 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, 17 May 2015 19:42:16 -0000 On Sun, 17 May 2015 00:16:23 +0200, Ian Lepore wrote: > On Tue, 2014-09-30 at 16:29 +0200, Mattia Rossi wrote: >> Am 30.09.2014 16:19, schrieb Ian Lepore: >> > On Tue, 2014-09-30 at 16:05 +0200, Mattia Rossi wrote: >> >> Am 30.09.2014 14:30, schrieb John-Mark Gurney: >> >>> Mattia Rossi wrote this message on Tue, Sep 30, 2014 at 14:14 +0200: >> >>>> Am 30.09.2014 13:29, schrieb John-Mark Gurney: >> >>>>> Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 >> +0200: >> >>>>>> Am 29.09.2014 06:01, schrieb John-Mark Gurney: >> >>>>>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 >> +0200: >> >>>>>>>> This might be part of the weird FFS issues the Dreamplug has >> and no-one >> >>>>>>>> knows why they're happening. >> >>>>>>> Are you running w/ FFS journaling? If so, try turning it off, >> but >> >>>>>>> keeping softupdates on.. >> >>>>>> No journaling, no softupdates. I'll try enabling softupdates >> next time. >> >>>>>> don't know if it will panic though >> >>>>>>>> data_abort_handler() at data_abort_handler+0x5c0 >> >>>>>>>> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) >> >>>>>>>> sp = 0xde019898 fp = 0xde019a20 >> >>>>>>>> r4 = 0xffffffff r5 = 0xffff1004 >> >>>>>>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >> >>>>>>>> r8 = 0xc443e880 r9 = 0x00000000 >> >>>>>>>> r10 = 0xc3d69000 >> >>>>>>>> exception_exit() at exception_exit >> >>>>>>>> pc = 0xc0dd711c lr = 0xc0d53828 >> (ffs_truncate+0xaa8) >> >>>>>>>> sp = 0xde0198e8 fp = 0xde019a20 >> >>>>>>>> r0 = 0xd0238120 r1 = 0x00000e60 >> >>>>>>>> r2 = 0x00000000 r3 = 0x00000000 >> >>>>>>>> r4 = 0x00000120 r5 = 0x00000000 >> >>>>>>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >> >>>>>>>> r8 = 0xc443e880 r9 = 0x00000000 >> >>>>>>>> r10 = 0xc3d69000 r12 = 0xd0238120 >> >>>>>>>> memset() at memset+0x48 >> >>>>>>>> pc = 0xc0de521c lr = 0xc0d53828 >> (ffs_truncate+0xaa8) >> >>>>>>>> sp = 0xde0198e8 fp = 0xde019a20 >> >>>>>>>> Unwind failure (no registers changed) >> >>>>>>> No more beyond this? If you could run addr2line on 0xc0d53828 >> so >> >>>>>>> that we know where in ffs_truncate it's failing, that'd be very >> >>>>>>> nice... >> >>>>>> So I was trying to save the coredump in order to reboot and run >> >>>>>> addr2line, but that failed: >> >>>>>> >> >>>>>> Physical memory: 504 MB >> >>>>>> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 >> d5 1f20 >> >>>>>> 00 00 01 00 >> >>>>>> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable >> >>>>>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted >> >>>>>> Aborting dump due to I/O error. >> >>>>>> >> >>>>>> ** DUMP FAILED (ERROR 5) ** >> >>>>>> >> >>>>>> So I guess this error is related to the CAM errors I'm getting >> from time >> >>>>>> to time. I was hoping that those errors were related to the >> INVARIANTS >> >>>>>> option that slowed down the system and thus might have triggered >> CAM >> >>>>>> errors, but obviously the SD Card seems to be the real issue >> here. >> >>>>>> So no crashdump for further analysis. >> >>>>> That's fine.. w/ the addr2line we have some lines to explore... >> >>>>> >> >>>>>> Interestingly the CAM errors didn't show up on the terminal as >> other >> >>>>>> times, the kernel just panicked straight away. >> >>>>> Hmm.. that is odd.. someone who knows the SD card layer should >> look >> >>>>> at this part... It could be that the SD card driver doesn't >> handle >> >>>>> dumping (there is this global flag that gets set) properly and >> the driver >> >>>>> needs to behave differently when it's set... >> >>>> I also need to grab a new SD card, just to make sure it's really >> not the >> >>>> card. >> >>>> >> >>>>>> But I've got the addr2line output, even though I'm not sure it >> makes any >> >>>>>> difference: >> >>>>>> >> >>>>>> addr2line -f -e /mnt/kernel.debug 0xc0d53828 >> >>>>>> >> >>>>>> ffs_truncate >> >>>>>> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321 >> >>>>> can you give me the contents of the line? and a few lines of >> context >> >>>>> around it? In HEAD's source, this is DOINGASYNC, and there is >> no call >> >>>>> to memset, nor a variable assignment that would result in memset >> being >> >>>>> called... >> >>>> Same here.. The file hasn't been changed in a while (Fri, 31 May >> 2013): >> >>>> >> >>>> ip->i_size = length; >> >>>> DIP_SET(ip, i_size, length); >> >>>> if (bp->b_bufsize == fs->fs_bsize) >> >>>> bp->b_flags |= B_CLUSTEROK; >> >>>> if (flags & IO_SYNC) >> >>>> bwrite(bp); >> >>>> 321: else if (DOINGASYNC(vp)) >> >>>> bdwrite(bp); >> >>>> else >> >>>> bawrite(bp); >> >>>> ip->i_flag |= IN_CHANGE | IN_UPDATE; >> >>>> return (ffs_update(vp, !DOINGASYNC(vp))); >> >>>> >> >>>> No idea what's going on. >> >>> ok, could you send me the output of objdump -dSl, but you only need >> >>> to include the part from XXXXX : to the next >> XXX: >> >>> line... probably off list as it'll be quite long... >> >> I'm sorry, but given that I just broke all my working worlds using >> fsck, >> >> I'm not going to be able to do that until I'm back from holidays.... >> >> currently working on the stuff remotely and after today's work day, >> I'm >> >> not going to be able to get my hands on the dreamplug. >> >> >> >> >> > BTW, for anyone playing with this problem, step one is to edit >> > your /etc/fstab and set the fsck pass number to 0 for all filesystems. >> > There's a risk of filesystem corruption after a crash, but it's >> smaller >> > than the 100% corruption rate of letting fsck run. :) >> > >> Of course! Great idea :-) Sometimes just can't think of the right tweak >> to save a lot of pain... >> >> Anyhow, I just found out, that I was rebooting the dreamplug from the sd >> card instead of the usb stick the whole time, and the usb stick hasn't >> been damaged enough by fsck, so it actually booted :-) I'll send the >> objdump soon. > > A (very) late update on this.... It looks like we may have tracked the > change that started all this down to the introduction of unmapped IO, > almost 2 years ago now. I still can't find the root cause, but I think > disabling unmapped IO on armv4/5 is a viable workaround, which Warner > committed this morning as r283014. > > --Ian This sounds promising for the use of my Sheevaplugs. I will try this soon. Thanks. Ronald. From owner-freebsd-arm@FreeBSD.ORG Sun May 17 20:17:32 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BB6FB3B for ; Sun, 17 May 2015 20:17:32 +0000 (UTC) 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 2579F190B for ; Sun, 17 May 2015 20:17:32 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4HKHWHh073732 for ; Sun, 17 May 2015 20:17:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200271] lang/gcc "make install" fails with Malformed conditional error Date: Sun, 17 May 2015 20:17:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: andreast@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: andreast@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc assigned_to 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, 17 May 2015 20:17:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200271 Andreas Tobler changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andreast@FreeBSD.org Assignee|gerald@FreeBSD.org |andreast@FreeBSD.org --- Comment #2 from Andreas Tobler --- lang/gcc48 is not supported for arm*. If you really need it, you can adapt the Makefile and copy the files from lang/gcc/files (patch-arm-support, patch-arm-libcpp) to lang/gcc48/files. But this will not help you with your "Malformed conditional" message. Can you build lang/gcc49? A try, you could change line 66 of the lang/gcc/Makefile to: . if ${COMPILER_TYPE} == "clang" Do you have some special settings in /etc/src.conf or /etc/make.conf? -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Sun May 17 22:02:38 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E5C52F8 for ; Sun, 17 May 2015 22:02:38 +0000 (UTC) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) (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 F40FE14BE for ; Sun, 17 May 2015 22:02:36 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 20B8D50F0B; Mon, 18 May 2015 07:02:27 +0900 (JST) Received: from artemis (unknown [172.18.0.21]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id EC2F950F05; Mon, 18 May 2015 07:02:26 +0900 (JST) Message-ID: <2D17B16DBC5F452D8DAC721E17BBF1B7@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Andreas Andersson" , References: <3AB5ECCF20894591B4DF5FCBA8CA49BB@ad.peach.ne.jp> In-Reply-To: Subject: Re: Performance issues with raspberry pi 2 Date: Mon, 18 May 2015 07:02:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP 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, 17 May 2015 22:02:38 -0000 > http://www.peach.ne.jp/archives/rpi/patch/dwc_otg-rpi2-20150516.patch > > This patch is subset of my USB patch of ODROID-C1 4x faster version on 1Gbps. Previous subset does not work correctly in ratecheck. I don't know a reason but same code from ODROID-C1 version works. I re-create the patch as dwc_otg-rpi2-20150518.patch. http://www.peach.ne.jp/archives/rpi/patch/dwc_otg-rpi2-20150518.patch Please use it instead. If you already applied 20150516, please remove it by: # patch -R < /path/to/dwc_otg-rpi2-20150516.patch Then, apply new version. Sorry for inconvenience. The below log is patched result on RPI2 using iperf3(/usr/ports/benchmarks/iperf3). Of course, powerd is enabled. ---------------------------------------------------------------------- # iperf3 -c 172.18.0.138 (sending) Connecting to host 172.18.0.138, port 5201 [ 4] local 172.18.0.159 port 33503 connected to 172.18.0.138 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 11.4 MBytes 96.0 Mbits/sec [ 4] 1.00-2.00 sec 11.2 MBytes 94.1 Mbits/sec [ 4] 2.00-3.00 sec 11.2 MBytes 94.1 Mbits/sec [ 4] 3.00-4.00 sec 11.2 MBytes 94.1 Mbits/sec [ 4] 4.00-5.00 sec 11.2 MBytes 94.1 Mbits/sec [ 4] 5.00-6.00 sec 11.2 MBytes 94.1 Mbits/sec [ 4] 6.00-7.00 sec 11.3 MBytes 95.1 Mbits/sec [ 4] 7.00-8.00 sec 11.2 MBytes 94.1 Mbits/sec [ 4] 8.00-9.00 sec 11.2 MBytes 94.1 Mbits/sec [ 4] 9.00-10.00 sec 11.2 MBytes 94.0 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 113 MBytes 94.4 Mbits/sec sender [ 4] 0.00-10.00 sec 112 MBytes 94.1 Mbits/sec receiver # iperf3 -c 172.18.0.138 -R (receiving) Connecting to host 172.18.0.138, port 5201 Reverse mode, remote host 172.18.0.138 is sending [ 4] local 172.18.0.159 port 35723 connected to 172.18.0.138 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 8.58 MBytes 72.0 Mbits/sec [ 4] 1.00-2.00 sec 8.81 MBytes 73.9 Mbits/sec [ 4] 2.00-3.00 sec 8.79 MBytes 73.8 Mbits/sec [ 4] 3.00-4.00 sec 8.87 MBytes 74.4 Mbits/sec [ 4] 4.00-5.00 sec 8.85 MBytes 74.2 Mbits/sec [ 4] 5.00-6.00 sec 8.89 MBytes 74.6 Mbits/sec [ 4] 6.00-7.00 sec 8.79 MBytes 73.7 Mbits/sec [ 4] 7.00-8.00 sec 8.86 MBytes 74.3 Mbits/sec [ 4] 8.00-9.00 sec 8.86 MBytes 74.3 Mbits/sec [ 4] 9.00-10.00 sec 8.80 MBytes 73.8 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 88.2 MBytes 74.0 Mbits/sec sender [ 4] 0.00-10.00 sec 88.2 MBytes 74.0 Mbits/sec receiver ---------------------------------------------------------------------- -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Sun May 17 23:21:54 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C2F9D20 for ; Sun, 17 May 2015 23:21:54 +0000 (UTC) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (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 64E721C36 for ; Sun, 17 May 2015 23:21:54 +0000 (UTC) Received: by ieczm2 with SMTP id zm2so86161552iec.1 for ; Sun, 17 May 2015 16:21:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=wN20SLQfy3Rn4JSgfMQeXQce2NH3WdFTs2i134W1ng0=; b=fSl8rGfYfLTF5O5iiJlrNgCteKzXR4yJnslC0T9QIzD3tgYJWxQgBj8Po/OaTjqPpk rS1EdkJ73M89da4/j2gCpkCgk3JIUU1sXcSFy7gyZU/Uv3eG9ApIB15R7212/ObQ6F9P aggHTXgyKU79PzL0NoFuDZU5tAaTGyCvYre3AIunLFKoZ4AwupVmjvFGMwH2vhbr+f6A Kan+OkXl3BUTaeV1GbbCvt7WEvs654eGYmM1jgA+xweslHFzoFTlm7ZPnjmzHEJK3pJD SH7Vk1glzfUJGPVVIzm5u6mZoJvWMaV6EB1lnPO6lNyDIKocDQDRMhdF98mwORlsoQQv lw7Q== X-Gm-Message-State: ALoCoQk4FxnUodVgQ1NieN15o+ZLlitq3lwCVjbP+bRvh3cJ+q9Qwpn7WvBzeQEk2zRN2rcK/AZL X-Received: by 10.50.6.37 with SMTP id x5mr10910988igx.45.1431903513562; Sun, 17 May 2015 15:58:33 -0700 (PDT) Received: from netflix-mac-wired.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id y124sm6459665iod.13.2015.05.17.15.58.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 May 2015 15:58:32 -0700 (PDT) Sender: Warner Losh Subject: Re: Random Kernel Panic on Dreamplug (FS related) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3604DB3D-4CA7-41A5-A991-759122A9A6CF"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: Date: Sun, 17 May 2015 16:58:31 -0600 Cc: freebsd-arm@freebsd.org Message-Id: <2D3CFA21-3DB5-41D3-9955-31E26151A54D@bsdimp.com> References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com> <542A9EA4.70109@gmail.com> <20140930123010.GZ43300@funkthat.com> <542AB897.3020309@gmail.com> <1412086795.66615.363.camel@revolution.hippie.lan> <542ABE45.3020402@gmail.com> <1431814583.91685.39.camel@freebsd.org> To: Ronald Klop X-Mailer: Apple Mail (2.2098) 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, 17 May 2015 23:21:54 -0000 --Apple-Mail=_3604DB3D-4CA7-41A5-A991-759122A9A6CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 17, 2015, at 1:26 PM, Ronald Klop wrote: >=20 > On Sun, 17 May 2015 00:16:23 +0200, Ian Lepore = wrote: >=20 >> On Tue, 2014-09-30 at 16:29 +0200, Mattia Rossi wrote: >>> Am 30.09.2014 16:19, schrieb Ian Lepore: >>> > On Tue, 2014-09-30 at 16:05 +0200, Mattia Rossi wrote: >>> >> Am 30.09.2014 14:30, schrieb John-Mark Gurney: >>> >>> Mattia Rossi wrote this message on Tue, Sep 30, 2014 at 14:14 = +0200: >>> >>>> Am 30.09.2014 13:29, schrieb John-Mark Gurney: >>> >>>>> Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 = +0200: >>> >>>>>> Am 29.09.2014 06:01, schrieb John-Mark Gurney: >>> >>>>>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at = 14:19 +0200: >>> >>>>>>>> This might be part of the weird FFS issues the Dreamplug = has and no-one >>> >>>>>>>> knows why they're happening. >>> >>>>>>> Are you running w/ FFS journaling? If so, try turning it = off, but >>> >>>>>>> keeping softupdates on.. >>> >>>>>> No journaling, no softupdates. I'll try enabling softupdates = next time. >>> >>>>>> don't know if it will panic though >>> >>>>>>>> data_abort_handler() at data_abort_handler+0x5c0 >>> >>>>>>>> pc =3D 0xc0de7a28 lr =3D 0xc0dd711c = (exception_exit) >>> >>>>>>>> sp =3D 0xde019898 fp =3D 0xde019a20 >>> >>>>>>>> r4 =3D 0xffffffff r5 =3D 0xffff1004 >>> >>>>>>>> r6 =3D 0xc3f3f6c0 r7 =3D 0x00001000 >>> >>>>>>>> r8 =3D 0xc443e880 r9 =3D 0x00000000 >>> >>>>>>>> r10 =3D 0xc3d69000 >>> >>>>>>>> exception_exit() at exception_exit >>> >>>>>>>> pc =3D 0xc0dd711c lr =3D 0xc0d53828 = (ffs_truncate+0xaa8) >>> >>>>>>>> sp =3D 0xde0198e8 fp =3D 0xde019a20 >>> >>>>>>>> r0 =3D 0xd0238120 r1 =3D 0x00000e60 >>> >>>>>>>> r2 =3D 0x00000000 r3 =3D 0x00000000 >>> >>>>>>>> r4 =3D 0x00000120 r5 =3D 0x00000000 >>> >>>>>>>> r6 =3D 0xc3f3f6c0 r7 =3D 0x00001000 >>> >>>>>>>> r8 =3D 0xc443e880 r9 =3D 0x00000000 >>> >>>>>>>> r10 =3D 0xc3d69000 r12 =3D 0xd0238120 >>> >>>>>>>> memset() at memset+0x48 >>> >>>>>>>> pc =3D 0xc0de521c lr =3D 0xc0d53828 = (ffs_truncate+0xaa8) >>> >>>>>>>> sp =3D 0xde0198e8 fp =3D 0xde019a20 >>> >>>>>>>> Unwind failure (no registers changed) >>> >>>>>>> No more beyond this? If you could run addr2line on = 0xc0d53828 so >>> >>>>>>> that we know where in ffs_truncate it's failing, that'd be = very >>> >>>>>>> nice... >>> >>>>>> So I was trying to save the coredump in order to reboot and = run >>> >>>>>> addr2line, but that failed: >>> >>>>>> >>> >>>>>> Physical memory: 504 MB >>> >>>>>> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 = 01 d5 1f20 >>> >>>>>> 00 00 01 00 >>> >>>>>> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable >>> >>>>>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted >>> >>>>>> Aborting dump due to I/O error. >>> >>>>>> >>> >>>>>> ** DUMP FAILED (ERROR 5) ** >>> >>>>>> >>> >>>>>> So I guess this error is related to the CAM errors I'm = getting from time >>> >>>>>> to time. I was hoping that those errors were related to the = INVARIANTS >>> >>>>>> option that slowed down the system and thus might have = triggered CAM >>> >>>>>> errors, but obviously the SD Card seems to be the real issue = here. >>> >>>>>> So no crashdump for further analysis. >>> >>>>> That's fine.. w/ the addr2line we have some lines to = explore... >>> >>>>> >>> >>>>>> Interestingly the CAM errors didn't show up on the terminal = as other >>> >>>>>> times, the kernel just panicked straight away. >>> >>>>> Hmm.. that is odd.. someone who knows the SD card layer should = look >>> >>>>> at this part... It could be that the SD card driver doesn't = handle >>> >>>>> dumping (there is this global flag that gets set) properly and = the driver >>> >>>>> needs to behave differently when it's set... >>> >>>> I also need to grab a new SD card, just to make sure it's = really not the >>> >>>> card. >>> >>>> >>> >>>>>> But I've got the addr2line output, even though I'm not sure = it makes any >>> >>>>>> difference: >>> >>>>>> >>> >>>>>> addr2line -f -e /mnt/kernel.debug 0xc0d53828 >>> >>>>>> >>> >>>>>> ffs_truncate >>> >>>>>> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321 >>> >>>>> can you give me the contents of the line? and a few lines of = context >>> >>>>> around it? In HEAD's source, this is DOINGASYNC, and there = is no call >>> >>>>> to memset, nor a variable assignment that would result in = memset being >>> >>>>> called... >>> >>>> Same here.. The file hasn't been changed in a while (Fri, 31 = May 2013): >>> >>>> >>> >>>> ip->i_size =3D length; >>> >>>> DIP_SET(ip, i_size, length); >>> >>>> if (bp->b_bufsize =3D=3D fs->fs_bsize) >>> >>>> bp->b_flags |=3D B_CLUSTEROK; >>> >>>> if (flags & IO_SYNC) >>> >>>> bwrite(bp); >>> >>>> 321: else if (DOINGASYNC(vp)) >>> >>>> bdwrite(bp); >>> >>>> else >>> >>>> bawrite(bp); >>> >>>> ip->i_flag |=3D IN_CHANGE | IN_UPDATE; >>> >>>> return (ffs_update(vp, !DOINGASYNC(vp))); >>> >>>> >>> >>>> No idea what's going on. >>> >>> ok, could you send me the output of objdump -dSl, but you only = need >>> >>> to include the part from XXXXX : to the next = XXX: >>> >>> line... probably off list as it'll be quite long... >>> >> I'm sorry, but given that I just broke all my working worlds = using fsck, >>> >> I'm not going to be able to do that until I'm back from = holidays.... >>> >> currently working on the stuff remotely and after today's work = day, I'm >>> >> not going to be able to get my hands on the dreamplug. >>> >> >>> >> >>> > BTW, for anyone playing with this problem, step one is to edit >>> > your /etc/fstab and set the fsck pass number to 0 for all = filesystems. >>> > There's a risk of filesystem corruption after a crash, but it's = smaller >>> > than the 100% corruption rate of letting fsck run. :) >>> > >>> Of course! Great idea :-) Sometimes just can't think of the right = tweak >>> to save a lot of pain... >>>=20 >>> Anyhow, I just found out, that I was rebooting the dreamplug from = the sd >>> card instead of the usb stick the whole time, and the usb stick = hasn't >>> been damaged enough by fsck, so it actually booted :-) I'll send the >>> objdump soon. >>=20 >> A (very) late update on this.... It looks like we may have tracked = the >> change that started all this down to the introduction of unmapped IO, >> almost 2 years ago now. I still can't find the root cause, but I = think >> disabling unmapped IO on armv4/5 is a viable workaround, which Warner >> committed this morning as r283014. >>=20 >> --Ian >=20 >=20 > This sounds promising for the use of my Sheevaplugs. > I will try this soon. Thanks. I plan on MFCing this change to 10 on Monday or Tuesday after fixing = some typos. Warner --Apple-Mail=_3604DB3D-4CA7-41A5-A991-759122A9A6CF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVWR0XAAoJEGwc0Sh9sBEAFIkP/14+TZbGifpy/Z3ef3BEO/rE k77JEIxuHxl5rw0b4uCyMuEapbFNUDR3nKc0w8Nb0veVGyX4MFvdxtZqFKWAOvS/ g4Ug45h4bBMkdqTM0BnYlu6/taVd71g3uV/2lWG8+IMNN/CfGTAV0gf+nI1yxCT7 zbJwlc82uzuBeKn9g0XxEyVG6soL2BGvmUJET7K1pxQwZXGxZUuRrjVW9iacD8q0 gPKhQMa8udtv44uCserNoO6H3OCbkpuY11QExDbPZBYRSAJFToiAYE5bbVXl7yiO /JVOAjIbAzC9W1BHrpWVOM3vlwlVwnyhgkYAehvhJ/6qUMrdX4L2yuhnD4G0X0tm 10+6cpzZ/vGfK7/L0r9fM2QM/WaAltNdIhj4Oy/+KRyUJySnrpUeXHPoipGgy6Vl ZvKDpyfr9FDiPyW9LNlaZqUBDnpGzXoBWv/GYcejajpqo17p+TSC4rOaP9nW0vVa SdYFEyKguTQoZbIKlMK0Aov1223Q/fPnTCxZz0dV+xYSxDPDMXQk7ftWtG0TPRWZ BSCEU3fbkGkegj49MMj6ZYYIpqvbok8bWh+MmKItlrgMH/BH9PIa0W7b5ZUvZLF+ dwaTr0vOcQG/3nkWn0ufrHTQ9vwaZKK2jYa80Zacr7ayFlwpHfzlCyMznroa4/cs hLT+RzMUb9vKYvo7pBTY =7kxJ -----END PGP SIGNATURE----- --Apple-Mail=_3604DB3D-4CA7-41A5-A991-759122A9A6CF-- From owner-freebsd-arm@FreeBSD.ORG Sun May 17 23:41:46 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4B28E90 for ; Sun, 17 May 2015 23:41:46 +0000 (UTC) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (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 9A6691DD7 for ; Sun, 17 May 2015 23:41:46 +0000 (UTC) Received: by qgfa7 with SMTP id a7so27811036qgf.1 for ; Sun, 17 May 2015 16:41:39 -0700 (PDT) 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:date :message-id:subject:from:to:content-type; bh=/70JGNyfA4POaeGYJ0G5Mk0wHMsrTsBaGp4XbQFWMIY=; b=Y1nBRfavi8v+NBidmux7lPoDgVwUnzH7CZ+QBnI5oy12cpZmMLKjGW8/+toJtkc1F5 v1cmAuKK0vumUJQeHD2+qtiSppV50Dfo00Pww/i3plTokeWZIVWCPpw9zd3GOBbRJQfN Zyti1Du80FrFxwWjJ+/8Y+o2WjndFwEPEE3vdHZk/4kSQ3KnFIypObRYccNvM/d3Oqct rNuCNLALeL1lmbkODnyRH0KvWWAG6+TBYVF/qGhCKam7Rw7J6no+MZhYujjN2U0hKwmS 3qDIFhxH9rurjLVel5MxGZdTIXtM0dyfy8Dv2bDgH5YhSXzyRW7zIg/KWMxatrOTchTI QHQA== X-Gm-Message-State: ALoCoQnE9Kr/gE8EevHXY+lvHjUqX5uDh64fnuEIK57P9ua8sAfSplPcY+erZ/ZjH8g5jiXB3E1k MIME-Version: 1.0 X-Received: by 10.55.53.72 with SMTP id c69mr42867536qka.67.1431905678935; Sun, 17 May 2015 16:34:38 -0700 (PDT) Received: by 10.229.15.6 with HTTP; Sun, 17 May 2015 16:34:38 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 May 2015 16:34:38 -0700 Message-ID: Subject: Re: FreeBSD 10.x on Raspberry Pi 2 From: Tim Gustafson 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: Sun, 17 May 2015 23:41:46 -0000 I just wanted to follow up with the group to say that I was able to get the 2015-05-05 Raspberry PI 2 image to work. I believe the problem was my SD card. The card checks out totally normally under Windows, but when you load the image onto it and then boot it, it panics right after trying to re-size the partition on the first book. On subsequent boots, I have to manually specify the boot device (it wants to boot off of mmscd0s2 but needs to boot off mmscd0s2a) and then I am not able to re-size the root partition anymore and I get occasional panics under heavy disk I/O. I switched to a different card and have had no problems so far. As an aside: does anyone have any recommendations for SD cards that are faster/better than others? The card that didn't work for me was a SanDisk 32GB Ultra, and the one that's working now is a SanDisk 16GB Pixtor. It's not terrible, but it's a bit slow and I was wondering if something else would be faster. Any recommendations at all are appreciated. Thanks! -- Tim Gustafson tjg@tgustafson.com From owner-freebsd-arm@FreeBSD.ORG Mon May 18 01:53:46 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BCD1DA4 for ; Mon, 18 May 2015 01:53:46 +0000 (UTC) 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 35D1B1A44 for ; Mon, 18 May 2015 01:53:46 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4I1rkZQ022838 for ; Mon, 18 May 2015 01:53:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200124] x11-wm/blackbox 0.70.1_4 does not build on ARM Date: Mon, 18 May 2015 01:53:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: A.J.Caines@halplant.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: flagtypes.name 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: Mon, 18 May 2015 01:53:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200124 Andrew J. Caines changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|maintainer-feedback?(A.J.Ca |maintainer-feedback+ |ines@halplant.com) | -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon May 18 16:53:01 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15396186 for ; Mon, 18 May 2015 16:53:01 +0000 (UTC) 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 F33C513A7 for ; Mon, 18 May 2015 16:53:00 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4IGr02X013662 for ; Mon, 18 May 2015 16:53:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200286] math/cgal: fails to build on armv6 Date: Mon, 18 May 2015 16:53:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mikael.urankar@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: wen@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform bug_file_loc op_sys bug_status bug_severity priority component assigned_to reporter cc flagtypes.name attachments.created Message-ID: 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: Mon, 18 May 2015 16:53:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200286 Bug ID: 200286 Summary: math/cgal: fails to build on armv6 Product: Ports & Packages Version: Latest Hardware: arm URL: http://chips.ysv.freebsd.org/data/11armv6-default/2015 -05-09_16h52m01s/logs/errors/cgal-4.4.log OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: wen@FreeBSD.org Reporter: mikael.urankar@gmail.com CC: freebsd-arm@FreeBSD.org Flags: maintainer-feedback?(wen@FreeBSD.org) CC: freebsd-arm@FreeBSD.org Assignee: wen@FreeBSD.org Created attachment 156883 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=156883&action=edit armv6 fix Hi, error message: /wrkdirs/usr/ports/math/cgal/work/CGAL-4.4/include/CGAL/config.h:214:4: error: Unknown endianness The attached patch fixes the problem. build log: http://mikael.urankar.free.fr/FreeBSD/arm/build_logs/cgal-4.4.log Thanks! -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon May 18 16:56:47 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 251BD232 for ; Mon, 18 May 2015 16:56:47 +0000 (UTC) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (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 E5FB113D6 for ; Mon, 18 May 2015 16:56:46 +0000 (UTC) Received: by iesa3 with SMTP id a3so88429368ies.2 for ; Mon, 18 May 2015 09:56:40 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=isGVQjdPN1DtA0IktU0b8jaKOWrKmjSB41EABAvDgk4=; b=I8ON2Us1BslgHDTbV4Zl1vZYKwIa3qbIue7O+IPcySw8EyfLFvohOjZ2TxSN2MpBPn xuDlPMPX+ojsJXRagPliPojEoMfYXH7RO5gEkxu/Kcv7McK6EBdHCR1V2JRVAyrA5KCY 2tUnHjg3jRLMlRtNDhU8OCa9X+Z76/IFkrfoWf7BcLfJ5UBH0X786C7PyrQd+OGBIAcN vfCoZjqGUUxRo/9zfLFWCaUiiHvYj3g7MAt5bpiIk2sQrHJsoGf3r7tIpYja5ISG77xX 9/ADPBvjme6Tan/+WxNpMRTVQMO4M5AnldZI+zSDgolZDzUmzRq6kAbJJjEo+2lVj/Tu +Gcw== X-Gm-Message-State: ALoCoQnycZ+doZeSbmxNYos5ZwC7MEhS7MkD0WWBVasCSqApWRcrgoa7Fs7tQpHt3uJSRq6WBnsO MIME-Version: 1.0 X-Received: by 10.42.81.201 with SMTP id a9mr36959340icl.9.1431968200006; Mon, 18 May 2015 09:56:40 -0700 (PDT) Received: by 10.36.28.201 with HTTP; Mon, 18 May 2015 09:56:39 -0700 (PDT) In-Reply-To: <2D17B16DBC5F452D8DAC721E17BBF1B7@ad.peach.ne.jp> References: <3AB5ECCF20894591B4DF5FCBA8CA49BB@ad.peach.ne.jp> <2D17B16DBC5F452D8DAC721E17BBF1B7@ad.peach.ne.jp> Date: Mon, 18 May 2015 18:56:39 +0200 Message-ID: Subject: Re: Performance issues with raspberry pi 2 From: Andreas Andersson To: Daisuke Aoyama Cc: freebsd-arm@freebsd.org 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: Mon, 18 May 2015 16:56:47 -0000 I can confirm the patch doubles the performance: ab -n10000 -c 100 -T "application/json" -p postfile http://172.16.0.113:8888/api/v1/alarm/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 172.16.0.113 (be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed 10000 requests Finished 10000 requests Server Software: TornadoServer/4.1 Server Hostname: 172.16.0.113 Server Port: 8888 Document Path: /api/v1/alarm/ Document Length: 16 bytes Concurrency Level: 100 Time taken for tests: 61.840 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Keep-Alive requests: 10000 Total transferred: 1830000 bytes Total POSTed: 2968200 HTML transferred: 160000 bytes Requests per second: 161.71 [#/sec] (mean) Time per request: 1236.790 [ms] (mean) Time per request: 6.184 [ms] (mean, across all concurrent requests) Transfer rate: 28.90 [Kbytes/sec] received 46.87 kb/s sent 75.77 kb/s total Connection Times (ms) min mean[+/-sd] median max Connect: 0 148 1426.2 0 22015 Processing: 14 1076 740.8 973 14251 Waiting: 14 1076 740.8 973 14251 Total: 14 1225 1535.7 999 22330 Percentage of the requests served within a certain time (ms) 50% 999 66% 1310 75% 1476 80% 1599 90% 1987 95% 2473 98% 3480 99% 8742 100% 22330 (longest request) 2015-05-18 0:02 GMT+02:00 Daisuke Aoyama : > http://www.peach.ne.jp/archives/rpi/patch/dwc_otg-rpi2-20150516.patch >> >> This patch is subset of my USB patch of ODROID-C1 4x faster version on >> 1Gbps. >> > > Previous subset does not work correctly in ratecheck. > I don't know a reason but same code from ODROID-C1 version works. > I re-create the patch as dwc_otg-rpi2-20150518.patch. > > http://www.peach.ne.jp/archives/rpi/patch/dwc_otg-rpi2-20150518.patch > > Please use it instead. If you already applied 20150516, please remove it > by: > > # patch -R < /path/to/dwc_otg-rpi2-20150516.patch > > Then, apply new version. Sorry for inconvenience. > > The below log is patched result on RPI2 using > iperf3(/usr/ports/benchmarks/iperf3). > Of course, powerd is enabled. > > ---------------------------------------------------------------------- > # iperf3 -c 172.18.0.138 (sending) > > Connecting to host 172.18.0.138, port 5201 > [ 4] local 172.18.0.159 port 33503 connected to 172.18.0.138 port 5201 > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-1.00 sec 11.4 MBytes 96.0 Mbits/sec > [ 4] 1.00-2.00 sec 11.2 MBytes 94.1 Mbits/sec > [ 4] 2.00-3.00 sec 11.2 MBytes 94.1 Mbits/sec > [ 4] 3.00-4.00 sec 11.2 MBytes 94.1 Mbits/sec > [ 4] 4.00-5.00 sec 11.2 MBytes 94.1 Mbits/sec > [ 4] 5.00-6.00 sec 11.2 MBytes 94.1 Mbits/sec > [ 4] 6.00-7.00 sec 11.3 MBytes 95.1 Mbits/sec > [ 4] 7.00-8.00 sec 11.2 MBytes 94.1 Mbits/sec > [ 4] 8.00-9.00 sec 11.2 MBytes 94.1 Mbits/sec > [ 4] 9.00-10.00 sec 11.2 MBytes 94.0 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-10.00 sec 113 MBytes 94.4 Mbits/sec > sender > [ 4] 0.00-10.00 sec 112 MBytes 94.1 Mbits/sec > receiver > > # iperf3 -c 172.18.0.138 -R (receiving) > > Connecting to host 172.18.0.138, port 5201 > Reverse mode, remote host 172.18.0.138 is sending > [ 4] local 172.18.0.159 port 35723 connected to 172.18.0.138 port 5201 > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-1.00 sec 8.58 MBytes 72.0 Mbits/sec > [ 4] 1.00-2.00 sec 8.81 MBytes 73.9 Mbits/sec > [ 4] 2.00-3.00 sec 8.79 MBytes 73.8 Mbits/sec > [ 4] 3.00-4.00 sec 8.87 MBytes 74.4 Mbits/sec > [ 4] 4.00-5.00 sec 8.85 MBytes 74.2 Mbits/sec > [ 4] 5.00-6.00 sec 8.89 MBytes 74.6 Mbits/sec > [ 4] 6.00-7.00 sec 8.79 MBytes 73.7 Mbits/sec > [ 4] 7.00-8.00 sec 8.86 MBytes 74.3 Mbits/sec > [ 4] 8.00-9.00 sec 8.86 MBytes 74.3 Mbits/sec > [ 4] 9.00-10.00 sec 8.80 MBytes 73.8 Mbits/sec > - - - - - - - - - - - - - - - - - - - - - - - - - > [ ID] Interval Transfer Bandwidth > [ 4] 0.00-10.00 sec 88.2 MBytes 74.0 Mbits/sec > sender > [ 4] 0.00-10.00 sec 88.2 MBytes 74.0 Mbits/sec > receiver > ---------------------------------------------------------------------- > > -- > Daisuke Aoyama > > From owner-freebsd-arm@FreeBSD.ORG Mon May 18 17:10:48 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58030551 for ; Mon, 18 May 2015 17:10:48 +0000 (UTC) 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 15ACB158F for ; Mon, 18 May 2015 17:10:48 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4IHAlKB059393 for ; Mon, 18 May 2015 17:10:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200287] audio/festival: fails to build on armv6 Date: Mon, 18 May 2015 17:10:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mikael.urankar@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc flagtypes.name attachments.created Message-ID: 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: Mon, 18 May 2015 17:10:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200287 Bug ID: 200287 Summary: audio/festival: fails to build on armv6 Product: Ports & Packages Version: Latest Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: freebsd-ports-bugs@FreeBSD.org Reporter: mikael.urankar@gmail.com CC: freebsd-arm@FreeBSD.org, mi@ALDAN.algebra.com CC: freebsd-arm@FreeBSD.org, mi@ALDAN.algebra.com Flags: maintainer-feedback?(mi@ALDAN.algebra.com) Created attachment 156884 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=156884&action=edit armv6 fix Hi, error message: creating config/config /bin/ln -s ix86_FreeBSD.mak /usr/ports/audio/festival/work/festival/config/systems/armv6_unknown.mak /usr/bin/sed -i.bak -e '/^CFLAGS *=/s|$| -O -pipe -mfloat-abi=softfp -fno-strict-aliasing|' -e '/^CXXFLAGS *=/s|$| -O -pipe -mfloat-abi=softfp -fno-strict-aliasing -DFTLIBDIR=/usr/local/share/festival/lib|' -e 's,^OPTIMI,#OPTIMI,' /usr/ports/audio/festival/work/speech_tools/config/compilers/gcc*.mak test -e /usr/ports/audio/festival/work/speech_tools/config/compilers/cc.mak || /bin/ln -s gcc_defaults.mak /usr/ports/audio/festival/work/speech_tools/config/compilers/cc.mak ===> Building for festival-2.1_1 gmake -C /usr/ports/audio/festival/work/speech_tools -f Makefile CC="cc" GCC="cc" CXX="c++" GXX="c++" EST_HOME=/usr/ports/audio/festival/work/speech_tools DESTDIR=/usr/ports/audio/festival/work/stage gmake[2]: Entering directory '/usr/ports/audio/festival/work/speech_tools' Check system type config/config:193: config/systems/arm_unknown.mak: No such file or directory ../config/config:193: ../config/systems/arm_unknown.mak: No such file or directory gmake[2]: *** No rule to make target '../config/systems/arm_unknown.mak'. Stop. The attached patch fixes the problem. build log: http://mikael.urankar.free.fr/FreeBSD/arm/build_logs/festival-2.1_1.log Thanks! -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon May 18 17:44:26 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E22D7285 for ; Mon, 18 May 2015 17:44:26 +0000 (UTC) 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 B230B1A65 for ; Mon, 18 May 2015 17:44:26 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4IHiQWK096042 for ; Mon, 18 May 2015 17:44:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200289] net/mediastreamer fails to build on armv6 Date: Mon, 18 May 2015 17:44:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mikael.urankar@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: tijl@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform bug_file_loc op_sys bug_status bug_severity priority component assigned_to reporter cc flagtypes.name attachments.created Message-ID: 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: Mon, 18 May 2015 17:44:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200289 Bug ID: 200289 Summary: net/mediastreamer fails to build on armv6 Product: Ports & Packages Version: Latest Hardware: arm URL: http://chips.ysv.freebsd.org/data/11armv6-default/2015 -05-09_16h52m01s/logs/errors/mediastreamer-2.11.1.log OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: tijl@FreeBSD.org Reporter: mikael.urankar@gmail.com CC: freebsd-arm@FreeBSD.org Flags: maintainer-feedback?(tijl@FreeBSD.org) CC: freebsd-arm@FreeBSD.org Assignee: tijl@FreeBSD.org Created attachment 156888 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=156888&action=edit armv6 fix Hi, I have the following error message when building net/mediastreamer on armv6: voip/stun.c:1282:7: error: Need some way to seed the random number generator Using arc4random fixes the problem, see attached patch. build logs for amd64, i386 and armv6: http://mikael.urankar.free.fr/FreeBSD/arm/build_logs/mediastreamer-2.11.1_101amd64.log http://mikael.urankar.free.fr/FreeBSD/arm/build_logs/mediastreamer-2.11.1_101i386.log http://mikael.urankar.free.fr/FreeBSD/arm/build_logs/mediastreamer-2.11.1_armv6.log Thanks. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon May 18 18:41:34 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A04DAA76 for ; Mon, 18 May 2015 18:41:34 +0000 (UTC) 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 8AAF11231 for ; Mon, 18 May 2015 18:41:34 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4IIfYb7024995 for ; Mon, 18 May 2015 18:41:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200289] net/mediastreamer fails to build on armv6 Date: Mon, 18 May 2015 18:41:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: tijl@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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: Mon, 18 May 2015 18:41:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200289 --- Comment #1 from commit-hook@freebsd.org --- A commit references this bug: Author: tijl Date: Mon May 18 18:41:17 UTC 2015 New revision: 386697 URL: https://svnweb.freebsd.org/changeset/ports/386697 Log: Fix non-x86 builds by using arc4random(3) instead of random(3) + rdtsc (x86 instruction). PR: 200289 Changes: head/net/mediastreamer/Makefile -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon May 18 18:42:39 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72340AF0 for ; Mon, 18 May 2015 18:42:39 +0000 (UTC) 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 5C5A61254 for ; Mon, 18 May 2015 18:42:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4IIgdnV026501 for ; Mon, 18 May 2015 18:42:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200289] net/mediastreamer fails to build on armv6 Date: Mon, 18 May 2015 18:42:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tijl@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: tijl@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_status 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: Mon, 18 May 2015 18:42:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200289 Tijl Coosemans changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon May 18 19:26:51 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40669C8 for ; Mon, 18 May 2015 19:26:51 +0000 (UTC) Received: from courriel.site.uottawa.ca (eecsmail.engineering.uottawa.ca [137.122.24.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.site.uottawa.ca", Issuer "PositiveSSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F209D187E for ; Mon, 18 May 2015 19:26:50 +0000 (UTC) Received: from [10.0.2.15] (ppp-66-225-169-32.vianet.ca [66.225.169.32]) (authenticated bits=0) by courriel.site.uottawa.ca (8.14.5/8.14.5) with ESMTP id t4IJQfST079211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 May 2015 15:26:42 -0400 (EDT) (envelope-from kwhite@site.uottawa.ca) Date: Mon, 18 May 2015 15:26:38 -0400 (EDT) From: Keith White X-X-Sender: kwhite@localhost.my.domain To: Luiz Otavio O Souza cc: Dan Raymond , "freebsd-arm@freebsd.org" Subject: Re: state of FreeBSD ARM (less stable than 6 months ago) In-Reply-To: Message-ID: References: <5550C252.6030001@foxvalley.net> <1431357226.2428197.265704673.6A544F74@webmail.messagingengine.com> <555177D9.8080001@foxvalley.net> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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, 18 May 2015 19:26:51 -0000 On Tue, 12 May 2015, Luiz Otavio O Souza wrote: > On 12 May 2015 at 00:47, Dan Raymond wrote: >> On 5/11/2015 9:13 AM, Mark Felder wrote: >>> >>> On Mon, May 11, 2015, at 09:53, Dan Raymond wrote: >>>> >>>> I've been running an email and web server using FreeBSD 11 on a >>>> Raspberry Pi B+ since November. It has crashed 3 times since then >>>> (roughly every two months). I'm currently running r277334. I thought >>>> I'd try the latest build to see if stability has improved. I purchased a >>>> Raspberry Pi 2 and used the latest crochet to built r282738. No >>>> problems building it and it booted up fine. However, it crashes about >>>> an hour into building some ports I use for my server (nginx, php, >>>> etc.). I tried twice last night and it crashed both times. Is anybody >>>> looking into these stability issues? >>>> >>> RPi2 support is something like less than a week old for SMP and DMA >>> transport. I'm not sure more than a handful of people have actually >>> tried it yet. The bugs here will be worked out in time, but if you have >>> any core dumps or info that can assist in tracking down issues you're >>> experiencing that would certainly be appreciated. >>> >> >> These panics always seem to be mmcsd related. I doubt it has anything to do >> with RPi2 or SMP. >> >> sdhci_bcm0-slot0: Controller timeout >> sdhci_bcm0-slot0: ============== REGISTER DUMP ============== >> sdhci_bcm0-slot0: Sys addr: 0x4d295a00 | Version: 0x00009902 >> sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000020 >> sdhci_bcm0-slot0: Argument: 0x002d19c0 | Trn mode: 0x0000193a >> sdhci_bcm0-slot0: Present: 0x01ff0506 | Host ctl: 0x00000003 >> sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >> sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000507 >> sdhci_bcm0-slot0: Timeout: 0x0000000e | Int stat: 0x00000010 >> sdhci_b >> >> >> >> mmcsd0: Error indicated: 1 Timeout >> g_vfs_done():mmcsd0s2a[WRITE(offset=1460830208, length=24576)]error = 5 >> panic: No b_bufobj 0xd767ca00 >> cpuid = 1 >> KDB: enter: panic >> [ thread pid 12 tid 100013 ] >> Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! >> db> > > Hm, I have seen this already, it is the sdhci software timeout. > > The 'happens at night' part rings a bell for me. > > In my case it happened only with a card that has failed a few weeks > later, so I thought it was a pre-fail case. > > But in certain cases (depending on the card) I think this timeout can > be triggered with normal usage. > > Please try the attached patch and let me know if it works for you. > > Luiz > > Index: sys/dev/sdhci/sdhci.c > =================================================================== > --- sys/dev/sdhci/sdhci.c (revision 282210) > +++ sys/dev/sdhci/sdhci.c (working copy) > @@ -872,7 +872,7 @@ > /* Start command. */ > WR2(slot, SDHCI_COMMAND_FLAGS, (cmd->opcode << 8) | (flags & 0xff)); > /* Start timeout callout. */ > - callout_reset(&slot->timeout_callout, 2*hz, sdhci_timeout, slot); > + callout_reset(&slot->timeout_callout, 10*hz, sdhci_timeout, slot); > } > > static void > _______________________________________________ > 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" Luiz, the patch works for me. Thanks! [Tested on BBB with a 2GB microSD that previously gave a WRITE timeout.] ...keith From owner-freebsd-arm@FreeBSD.ORG Mon May 18 19:36:42 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9F3A3E3 for ; Mon, 18 May 2015 19:36:42 +0000 (UTC) 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 9E2BA19FE for ; Mon, 18 May 2015 19:36:42 +0000 (UTC) Received: by igbsb11 with SMTP id sb11so56727548igb.0 for ; Mon, 18 May 2015 12:36:42 -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=fM7iuTue3T/Yyc6QlzMG4S2l7HUYoXkJ7S96r03/+p8=; b=MKYY0a2rM64BgOXhNENLAVzA9GbNda+2qG4f7OBVBXrE4q6ejn0csJjCCC6K6Zru3n WPgXI6ToGVzeNRCTWHiNW5K6BEkm98jZIC1xZ/sNQt5YmEWmK2W1Mi6/dQNr7FP/Er34 fwE8HLwlPqMbhtIjjVpazgmgg3c+XK5DyVYqcDhpk92LXr4H/DcwPQ0+NFpoh1IeWFry +Igs/QddtftSUyeeGZj02PsEN8AbTkJP4ALqlXQ22JEjn6f/Z9fR7/XD1mtaOk4aGeha 8wql564SelgRrI2momNIdWhoQ+1Y2NjqEKF9LKUZm2TDxJ+549DLDunb3V253cqWPvtP UQ0w== MIME-Version: 1.0 X-Received: by 10.107.47.21 with SMTP id j21mr32153398ioo.17.1431977801961; Mon, 18 May 2015 12:36:41 -0700 (PDT) Received: by 10.50.1.39 with HTTP; Mon, 18 May 2015 12:36:41 -0700 (PDT) Date: Mon, 18 May 2015 15:36:41 -0400 Message-ID: Subject: Building FreeBSD on RPI2 From: Paul Khavkine To: freebsd-arm@freebsd.org 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: Mon, 18 May 2015 19:36:42 -0000 Hi everyone. Just to mention that I was able to build world and kernel and boot FreeBSD on the Raspberry Pi2. I used an image I built using crochet (r283010), then built and booted r283019 on the RPI2 itself: root@rpi2:/usr/src # uname -a FreeBSD rpi2 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r283019: Mon May 18 10:18:05 EDT 2015 root@rpi2:/usr/obj/usr/src/sys/RPI2 arm The only problems were 1) It's slow 2) the /tmp partition of 30M was too small to installworld Good work guys. Cheers Paul From owner-freebsd-arm@FreeBSD.ORG Mon May 18 19:39:34 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 473315FE for ; Mon, 18 May 2015 19:39:34 +0000 (UTC) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (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 16BD81A2E for ; Mon, 18 May 2015 19:39:33 +0000 (UTC) Received: by iebgx4 with SMTP id gx4so179369513ieb.0 for ; Mon, 18 May 2015 12:39:27 -0700 (PDT) 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:date :message-id:subject:from:to:content-type; bh=YqxwYhOu1OCCfxbJel6sEjWDnqRIUzo+PSdRkXY1nic=; b=QkyoLpgyvIBKQUlUyTamcNgvAbGWYMaBjTKzSHEjdXiIgXXLbBHGfXrn1fIp5Ga1Ea 6TROlKpq5HFKvtUyMh5ZCxrwrOM1+qsGyOV+A1Gh0dF2j4dLAgs1t9qwfKqv8gyh2oli u4KHePt9AcykshJIuFFbKV+0ypYJChUbz2Sdk67E1WFItS0pO2wLGIkBeItkEK2zc+q9 aXx//2OoqnUYFeZpx1m95WQ9FCzb1lzdIK5eyQ+1S6d7Cu9EEOWBzB3gUh2IbJX79pik mabTF/ehEfkgnzGVyd1/1WA/QYzdjELnEHINqOlEjdWajNI95imLJ/0hOZtgFcnofzy5 kAcA== X-Gm-Message-State: ALoCoQk7vCTsQrAjIBN2YNI1A3hSqq6HXqjLgnKUr2lf6UUWI+OCWWMLOmRjrqW8r7zmV2dvAm/+ MIME-Version: 1.0 X-Received: by 10.42.81.201 with SMTP id a9mr37746344icl.9.1431977967228; Mon, 18 May 2015 12:39:27 -0700 (PDT) Received: by 10.36.28.201 with HTTP; Mon, 18 May 2015 12:39:27 -0700 (PDT) In-Reply-To: References: <5550C252.6030001@foxvalley.net> <1431357226.2428197.265704673.6A544F74@webmail.messagingengine.com> <555177D9.8080001@foxvalley.net> Date: Mon, 18 May 2015 21:39:27 +0200 Message-ID: Subject: Re: state of FreeBSD ARM (less stable than 6 months ago) From: Andreas Andersson To: "freebsd-arm@freebsd.org" 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: Mon, 18 May 2015 19:39:34 -0000 Also seeing this on RPI2 will try the attached patch to see if it get's better. 2015-05-18 21:26 GMT+02:00 Keith White : > On Tue, 12 May 2015, Luiz Otavio O Souza wrote: > > On 12 May 2015 at 00:47, Dan Raymond wrote: >> >>> On 5/11/2015 9:13 AM, Mark Felder wrote: >>> >>>> >>>> On Mon, May 11, 2015, at 09:53, Dan Raymond wrote: >>>> >>>>> >>>>> I've been running an email and web server using FreeBSD 11 on a >>>>> Raspberry Pi B+ since November. It has crashed 3 times since then >>>>> (roughly every two months). I'm currently running r277334. I thought >>>>> I'd try the latest build to see if stability has improved. I purchased >>>>> a >>>>> Raspberry Pi 2 and used the latest crochet to built r282738. No >>>>> problems building it and it booted up fine. However, it crashes about >>>>> an hour into building some ports I use for my server (nginx, php, >>>>> etc.). I tried twice last night and it crashed both times. Is anybody >>>>> looking into these stability issues? >>>>> >>>>> RPi2 support is something like less than a week old for SMP and DMA >>>> transport. I'm not sure more than a handful of people have actually >>>> tried it yet. The bugs here will be worked out in time, but if you have >>>> any core dumps or info that can assist in tracking down issues you're >>>> experiencing that would certainly be appreciated. >>>> >>>> >>> These panics always seem to be mmcsd related. I doubt it has anything >>> to do >>> with RPi2 or SMP. >>> >>> sdhci_bcm0-slot0: Controller timeout >>> sdhci_bcm0-slot0: ============== REGISTER DUMP ============== >>> sdhci_bcm0-slot0: Sys addr: 0x4d295a00 | Version: 0x00009902 >>> sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000020 >>> sdhci_bcm0-slot0: Argument: 0x002d19c0 | Trn mode: 0x0000193a >>> sdhci_bcm0-slot0: Present: 0x01ff0506 | Host ctl: 0x00000003 >>> sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >>> sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000507 >>> sdhci_bcm0-slot0: Timeout: 0x0000000e | Int stat: 0x00000010 >>> sdhci_b >>> >>> >>> >>> mmcsd0: Error indicated: 1 Timeout >>> g_vfs_done():mmcsd0s2a[WRITE(offset=1460830208, length=24576)]error = 5 >>> panic: No b_bufobj 0xd767ca00 >>> cpuid = 1 >>> KDB: enter: panic >>> [ thread pid 12 tid 100013 ] >>> Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! >>> db> >>> >> >> Hm, I have seen this already, it is the sdhci software timeout. >> >> The 'happens at night' part rings a bell for me. >> >> In my case it happened only with a card that has failed a few weeks >> later, so I thought it was a pre-fail case. >> >> But in certain cases (depending on the card) I think this timeout can >> be triggered with normal usage. >> >> Please try the attached patch and let me know if it works for you. >> >> Luiz >> >> Index: sys/dev/sdhci/sdhci.c >> =================================================================== >> --- sys/dev/sdhci/sdhci.c (revision 282210) >> +++ sys/dev/sdhci/sdhci.c (working copy) >> @@ -872,7 +872,7 @@ >> /* Start command. */ >> WR2(slot, SDHCI_COMMAND_FLAGS, (cmd->opcode << 8) | (flags & >> 0xff)); >> /* Start timeout callout. */ >> - callout_reset(&slot->timeout_callout, 2*hz, sdhci_timeout, slot); >> + callout_reset(&slot->timeout_callout, 10*hz, sdhci_timeout, slot); >> } >> >> static void >> _______________________________________________ >> 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" >> > > Luiz, the patch works for me. Thanks! > > [Tested on BBB with a 2GB microSD that previously gave a WRITE timeout.] > > ...keith > > > > _______________________________________________ > 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 Mon May 18 20:53:23 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 926A7D1A for ; Mon, 18 May 2015 20:53:23 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::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 2EE65139E for ; Mon, 18 May 2015 20:53:23 +0000 (UTC) Received: by wizk4 with SMTP id k4so93942951wiz.1 for ; Mon, 18 May 2015 13:53:21 -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=umgh//XRYmAXrN2PBzZ7kg9mLkoSkdn4aWasKAsK+eA=; b=WtD/1s6vJPgnUQd2CTtTQTnFABM1+WDV8+NNNQqXhdw9sDtWpVrb1U/4KRNRL0GYPx 7zFNNuEWdbPUhjDNH9HvRxUmQAMkO9/P3oFlkh3lygcPZhWgKtg0vSeslliOiBJ8Wdyr W6GG55Q8c9Ome1Ir+61RcGptVEikx9yr9+ZDTbzLX793eLJop4Ani1n5/Ico2Bjs5xpC OQ+UEQXXbPxYgQZzFwJWOcokts88MvpIRrXn5RHjUNhZw7k7HnGaz7ci4e+gESqY/qN3 ocjRTjFgASWIiuutSyZ09VvpuFwNWCG9O+EE2fqisiJqmVlbrqsLCauLuKV2l41SkXaH YCnA== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr25370001wib.60.1431982401706; Mon, 18 May 2015 13:53:21 -0700 (PDT) Received: by 10.27.219.14 with HTTP; Mon, 18 May 2015 13:53:21 -0700 (PDT) Date: Mon, 18 May 2015 17:53:21 -0300 Message-ID: Subject: Partition type without symbolic name, on gpart From: =?UTF-8?Q?Mat=C3=ADas_Perret_Cantoni?= To: freebsd-arm@freebsd.org 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: Mon, 18 May 2015 20:53:23 -0000 Hi! I was following this steps (https://wiki.freebsd.org/FreeBSD/arm/Zedboard) for building images for the ZedBorad. I came across with this command: gpart add -s64m -t \!14 md0 The -t indicates the type for the new partition. The gpart manual says: "Partition types are identified on disk by particular strings or magic values. The gpart utility uses symbolic names for common partition types..." So I guess that "-t \!14" indicates a type that doesn't have a symbolic name. Is this correct? Anyway.. what does it means the string "\!14"? Thanks in advance. Matias. From owner-freebsd-arm@FreeBSD.ORG Mon May 18 21:42:51 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 628E7F3F for ; Mon, 18 May 2015 21:42:51 +0000 (UTC) Received: from olinguito.schwarzes.net (olinguito.schwarzes.net [IPv6:2a01:4f8:7d:1b5::1]) (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 F060A1A02 for ; Mon, 18 May 2015 21:42:50 +0000 (UTC) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) (authenticated bits=0) by olinguito.schwarzes.net (8.14.9/8.14.9) with ESMTP id t4ILgldj053180 for ; Mon, 18 May 2015 23:42:47 +0200 (CEST) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Mon, 18 May 2015 23:42:46 +0200 (CEST) Message-ID: <464e39c890f.5a529d1@mail.schwarzes.net> In-Reply-To: References: User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: Re: Partition type without symbolic name, on gpart MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (olinguito.schwarzes.net [78.47.41.143]); Mon, 18 May 2015 23:42:47 +0200 (CEST) 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, 18 May 2015 21:42:51 -0000 On 18.05.15, Mat=EDas Perret Cantoni wrote: > So I guess that "-t \!14" indicates a type that doesn't have a symbolic > name. Is this correct? Yes. > Anyway.. what does it means the string "\!14"? According to = http://en.wikipedia.org/wiki/Partition_type it's "FAT16B with LBA". -asc From owner-freebsd-arm@FreeBSD.ORG Tue May 19 00:45:13 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 581CA81B for ; Tue, 19 May 2015 00:45:13 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id 15C5C1CE3 for ; Tue, 19 May 2015 00:45:12 +0000 (UTC) Received: (qmail 17044 invoked from network) for freebsd-arm@freebsd.org; 18 May 2015 19:45:05 -0500 Received: from 97-122-105-78.hlrn.qwest.net (HELO ?192.168.1.3?) (draymond@97.122.105.78) by mail.foxvalley.net with SMTP; 18 May 2015 19:45:05 -0500 Message-ID: <555A8792.9000809@foxvalley.net> Date: Mon, 18 May 2015 18:45:06 -0600 From: Dan Raymond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Keith White , Luiz Otavio O Souza CC: "freebsd-arm@freebsd.org" Subject: Re: state of FreeBSD ARM (less stable than 6 months ago) References: <5550C252.6030001@foxvalley.net> <1431357226.2428197.265704673.6A544F74@webmail.messagingengine.com> <555177D9.8080001@foxvalley.net> In-Reply-To: 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: Tue, 19 May 2015 00:45:13 -0000 On 5/18/2015 1:26 PM, Keith White wrote: > On Tue, 12 May 2015, Luiz Otavio O Souza wrote: > >> On 12 May 2015 at 00:47, Dan Raymond wrote: >>> On 5/11/2015 9:13 AM, Mark Felder wrote: >>>> >>>> On Mon, May 11, 2015, at 09:53, Dan Raymond wrote: >>>>> >>>>> I've been running an email and web server using FreeBSD 11 on a >>>>> Raspberry Pi B+ since November. It has crashed 3 times since then >>>>> (roughly every two months). I'm currently running r277334. I >>>>> thought >>>>> I'd try the latest build to see if stability has improved. I >>>>> purchased a >>>>> Raspberry Pi 2 and used the latest crochet to built r282738. No >>>>> problems building it and it booted up fine. However, it crashes >>>>> about >>>>> an hour into building some ports I use for my server (nginx, php, >>>>> etc.). I tried twice last night and it crashed both times. Is >>>>> anybody >>>>> looking into these stability issues? >>>>> >>>> RPi2 support is something like less than a week old for SMP and DMA >>>> transport. I'm not sure more than a handful of people have actually >>>> tried it yet. The bugs here will be worked out in time, but if you >>>> have >>>> any core dumps or info that can assist in tracking down issues you're >>>> experiencing that would certainly be appreciated. >>>> >>> >>> These panics always seem to be mmcsd related. I doubt it has >>> anything to do >>> with RPi2 or SMP. >>> >>> sdhci_bcm0-slot0: Controller timeout >>> sdhci_bcm0-slot0: ============== REGISTER DUMP ============== >>> sdhci_bcm0-slot0: Sys addr: 0x4d295a00 | Version: 0x00009902 >>> sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000020 >>> sdhci_bcm0-slot0: Argument: 0x002d19c0 | Trn mode: 0x0000193a >>> sdhci_bcm0-slot0: Present: 0x01ff0506 | Host ctl: 0x00000003 >>> sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >>> sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000507 >>> sdhci_bcm0-slot0: Timeout: 0x0000000e | Int stat: 0x00000010 >>> sdhci_b >>> >>> >>> >>> mmcsd0: Error indicated: 1 Timeout >>> g_vfs_done():mmcsd0s2a[WRITE(offset=1460830208, length=24576)]error = 5 >>> panic: No b_bufobj 0xd767ca00 >>> cpuid = 1 >>> KDB: enter: panic >>> [ thread pid 12 tid 100013 ] >>> Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! >>> db> >> >> Hm, I have seen this already, it is the sdhci software timeout. >> >> The 'happens at night' part rings a bell for me. >> >> In my case it happened only with a card that has failed a few weeks >> later, so I thought it was a pre-fail case. >> >> But in certain cases (depending on the card) I think this timeout can >> be triggered with normal usage. >> >> Please try the attached patch and let me know if it works for you. >> >> Luiz >> >> Index: sys/dev/sdhci/sdhci.c >> =================================================================== >> --- sys/dev/sdhci/sdhci.c (revision 282210) >> +++ sys/dev/sdhci/sdhci.c (working copy) >> @@ -872,7 +872,7 @@ >> /* Start command. */ >> WR2(slot, SDHCI_COMMAND_FLAGS, (cmd->opcode << 8) | (flags & >> 0xff)); >> /* Start timeout callout. */ >> - callout_reset(&slot->timeout_callout, 2*hz, sdhci_timeout, >> slot); >> + callout_reset(&slot->timeout_callout, 10*hz, sdhci_timeout, >> slot); >> } >> >> static void >> _______________________________________________ >> 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" > > Luiz, the patch works for me. Thanks! > > [Tested on BBB with a 2GB microSD that previously gave a WRITE timeout.] > > ...keith I was out of town for a few days but yesterday I tried the patch and I was able to build my ports without a panic. I'll continue to do some more testing. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 02:41:02 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D213913 for ; Tue, 19 May 2015 02:41:02 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id C05A417EE for ; Tue, 19 May 2015 02:41:01 +0000 (UTC) Received: (qmail 27736 invoked from network) for freebsd-arm@freebsd.org; 18 May 2015 21:41:00 -0500 Received: from 97-122-105-78.hlrn.qwest.net (HELO ?192.168.1.3?) (draymond@97.122.105.78) by mail.foxvalley.net with SMTP; 18 May 2015 21:41:00 -0500 Message-ID: <555AA2BE.4030008@foxvalley.net> Date: Mon, 18 May 2015 20:41:02 -0600 From: Dan Raymond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: state of FreeBSD ARM (less stable than 6 months ago) References: <5550C252.6030001@foxvalley.net> <1431357226.2428197.265704673.6A544F74@webmail.messagingengine.com> <555177D9.8080001@foxvalley.net> <555A8792.9000809@foxvalley.net> In-Reply-To: <555A8792.9000809@foxvalley.net> 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: Tue, 19 May 2015 02:41:02 -0000 >> On Tue, 12 May 2015, Luiz Otavio O Souza wrote: >> >>> On 12 May 2015 at 00:47, Dan Raymond wrote: >>>> >>>> sdhci_bcm0-slot0: Controller timeout >>>> sdhci_bcm0-slot0: ============== REGISTER DUMP ============== >>>> sdhci_bcm0-slot0: Sys addr: 0x4d295a00 | Version: 0x00009902 >>>> sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000020 >>>> sdhci_bcm0-slot0: Argument: 0x002d19c0 | Trn mode: 0x0000193a >>>> sdhci_bcm0-slot0: Present: 0x01ff0506 | Host ctl: 0x00000003 >>>> sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >>>> sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000507 >>>> sdhci_bcm0-slot0: Timeout: 0x0000000e | Int stat: 0x00000010 >>>> sdhci_b >>>> >>>> >>>> >>>> mmcsd0: Error indicated: 1 Timeout >>>> g_vfs_done():mmcsd0s2a[WRITE(offset=1460830208, length=24576)]error >>>> = 5 >>>> panic: No b_bufobj 0xd767ca00 >>>> cpuid = 1 >>>> KDB: enter: panic >>>> [ thread pid 12 tid 100013 ] >>>> Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! >>>> db> >>> >>> Hm, I have seen this already, it is the sdhci software timeout. >>> >>> The 'happens at night' part rings a bell for me. >>> >>> In my case it happened only with a card that has failed a few weeks >>> later, so I thought it was a pre-fail case. >>> >>> But in certain cases (depending on the card) I think this timeout can >>> be triggered with normal usage. >>> >>> Please try the attached patch and let me know if it works for you. >>> >>> Luiz >>> >>> Index: sys/dev/sdhci/sdhci.c >>> =================================================================== >>> --- sys/dev/sdhci/sdhci.c (revision 282210) >>> +++ sys/dev/sdhci/sdhci.c (working copy) >>> @@ -872,7 +872,7 @@ >>> /* Start command. */ >>> WR2(slot, SDHCI_COMMAND_FLAGS, (cmd->opcode << 8) | (flags & >>> 0xff)); >>> /* Start timeout callout. */ >>> - callout_reset(&slot->timeout_callout, 2*hz, sdhci_timeout, >>> slot); >>> + callout_reset(&slot->timeout_callout, 10*hz, sdhci_timeout, >>> slot); >>> } >>> >>> static void >> >> Luiz, the patch works for me. Thanks! >> >> [Tested on BBB with a 2GB microSD that previously gave a WRITE timeout.] >> >> ...keith > > I was out of town for a few days but yesterday I tried the patch and I > was able to build my ports without a panic. I'll continue to do some > more testing. > Now I hit a panic while running "restart" from a terminal: panic: vm_page_unwire: page 0xc0c63e30's wire count is zero cpuid = 1 KDB: enter: panic [ thread pid 502 tid 100081 ] Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! db> From owner-freebsd-arm@FreeBSD.ORG Tue May 19 02:51:25 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93B83ACD for ; Tue, 19 May 2015 02:51:25 +0000 (UTC) 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 7D6771A01 for ; Tue, 19 May 2015 02:51:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4J2pP8n007100 for ; Tue, 19 May 2015 02:51:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200286] math/cgal: fails to build on armv6 Date: Tue, 19 May 2015 02:51:25 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: wen@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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: Tue, 19 May 2015 02:51:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200286 --- Comment #1 from commit-hook@freebsd.org --- A commit references this bug: Author: wen Date: Tue May 19 02:50:55 UTC 2015 New revision: 386736 URL: https://svnweb.freebsd.org/changeset/ports/386736 Log: - Fix build on armv6 PR: 200286 Submitted by: mikael.urankar@gmail.com Changes: head/math/cgal/files/patch-include_CGAL_config.h -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 02:52:40 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E5DAB3B for ; Tue, 19 May 2015 02:52:40 +0000 (UTC) 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 785291A19 for ; Tue, 19 May 2015 02:52:40 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4J2qeZj008657 for ; Tue, 19 May 2015 02:52:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200286] math/cgal: fails to build on armv6 Date: Tue, 19 May 2015 02:52:40 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: wen@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: wen@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: resolution bug_status 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: Tue, 19 May 2015 02:52:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200286 Wen Heping changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 05:45:05 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 444B2CB6 for ; Tue, 19 May 2015 05:45:05 +0000 (UTC) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (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 10F7E1DB4 for ; Tue, 19 May 2015 05:45:04 +0000 (UTC) Received: by igbyr2 with SMTP id yr2so67345095igb.0 for ; Mon, 18 May 2015 22:44:58 -0700 (PDT) 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:date :message-id:subject:from:to:content-type; bh=AmxR3cjvd3OPZGbDZwC2g5wBnW1C4DHk/05ZnafC7m4=; b=axFw9k0r+1ioKiJuCleHKVWkZ8ePJz9SuRBR627jpOtXC3if5WJrk/FuYcoWh05vwS 5SJ5rW6CIpDYvKexjhpatSOTnSUvKsBXgodeif3RPcLXQe6hSRHSvllpS7dSBUKQryof o9GKPGWNM9tqaFH8X4QALUG+SSZiU6ZQFX8yUfr7y9DnQMSn9bNHUoS5T18rEN8Fb0Bc a4P9SujjhfPE1bGl1TFo9s+Z0euV6Ve0NLUr4PwT6BTDwlxm4vfjuu0LKaemNVN+mNrJ BJILyQwXp6k91C0oaa05kn+lnM5rKgu9YMFy8WvScl/0+4Drv6jbLMIqYTcJB+vWnHAU 2BLQ== X-Gm-Message-State: ALoCoQlaRfUW2rLq1cToyP/S7AR3/FypJwzZxv+Kt1CbRLPK2vokGWFq/gSz+aJq7UVPI7qNIXgB MIME-Version: 1.0 X-Received: by 10.42.204.14 with SMTP id fk14mr38260783icb.96.1432014297941; Mon, 18 May 2015 22:44:57 -0700 (PDT) Received: by 10.36.28.201 with HTTP; Mon, 18 May 2015 22:44:57 -0700 (PDT) In-Reply-To: <555AA2BE.4030008@foxvalley.net> References: <5550C252.6030001@foxvalley.net> <1431357226.2428197.265704673.6A544F74@webmail.messagingengine.com> <555177D9.8080001@foxvalley.net> <555A8792.9000809@foxvalley.net> <555AA2BE.4030008@foxvalley.net> Date: Tue, 19 May 2015 07:44:57 +0200 Message-ID: Subject: Re: state of FreeBSD ARM (less stable than 6 months ago) From: Andreas Andersson To: freebsd-arm@freebsd.org 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: Tue, 19 May 2015 05:45:05 -0000 I can confirm this patch works. I haven't gotten any kernel panics yet. 2015-05-19 4:41 GMT+02:00 Dan Raymond : > > On Tue, 12 May 2015, Luiz Otavio O Souza wrote: >>> >>> On 12 May 2015 at 00:47, Dan Raymond wrote: >>>> >>>>> >>>>> sdhci_bcm0-slot0: Controller timeout >>>>> sdhci_bcm0-slot0: ============== REGISTER DUMP ============== >>>>> sdhci_bcm0-slot0: Sys addr: 0x4d295a00 | Version: 0x00009902 >>>>> sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000020 >>>>> sdhci_bcm0-slot0: Argument: 0x002d19c0 | Trn mode: 0x0000193a >>>>> sdhci_bcm0-slot0: Present: 0x01ff0506 | Host ctl: 0x00000003 >>>>> sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >>>>> sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000507 >>>>> sdhci_bcm0-slot0: Timeout: 0x0000000e | Int stat: 0x00000010 >>>>> sdhci_b >>>>> >>>>> >>>>> >>>>> mmcsd0: Error indicated: 1 Timeout >>>>> g_vfs_done():mmcsd0s2a[WRITE(offset=1460830208, length=24576)]error = 5 >>>>> panic: No b_bufobj 0xd767ca00 >>>>> cpuid = 1 >>>>> KDB: enter: panic >>>>> [ thread pid 12 tid 100013 ] >>>>> Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! >>>>> db> >>>>> >>>> >>>> Hm, I have seen this already, it is the sdhci software timeout. >>>> >>>> The 'happens at night' part rings a bell for me. >>>> >>>> In my case it happened only with a card that has failed a few weeks >>>> later, so I thought it was a pre-fail case. >>>> >>>> But in certain cases (depending on the card) I think this timeout can >>>> be triggered with normal usage. >>>> >>>> Please try the attached patch and let me know if it works for you. >>>> >>>> Luiz >>>> >>>> Index: sys/dev/sdhci/sdhci.c >>>> =================================================================== >>>> --- sys/dev/sdhci/sdhci.c (revision 282210) >>>> +++ sys/dev/sdhci/sdhci.c (working copy) >>>> @@ -872,7 +872,7 @@ >>>> /* Start command. */ >>>> WR2(slot, SDHCI_COMMAND_FLAGS, (cmd->opcode << 8) | (flags & >>>> 0xff)); >>>> /* Start timeout callout. */ >>>> - callout_reset(&slot->timeout_callout, 2*hz, sdhci_timeout, >>>> slot); >>>> + callout_reset(&slot->timeout_callout, 10*hz, sdhci_timeout, >>>> slot); >>>> } >>>> >>>> static void >>>> >>> >>> Luiz, the patch works for me. Thanks! >>> >>> [Tested on BBB with a 2GB microSD that previously gave a WRITE timeout.] >>> >>> ...keith >>> >> >> I was out of town for a few days but yesterday I tried the patch and I >> was able to build my ports without a panic. I'll continue to do some more >> testing. >> >> > Now I hit a panic while running "restart" from a terminal: > > panic: vm_page_unwire: page 0xc0c63e30's wire count is zero > cpuid = 1 > KDB: enter: panic > [ thread pid 502 tid 100081 ] > Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! > db> > _______________________________________________ > 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 Tue May 19 07:44:36 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEA5BF9 for ; Tue, 19 May 2015 07:44:36 +0000 (UTC) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92BFF1B7E for ; Tue, 19 May 2015 07:44:36 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1YucCY-005irs-DS; Tue, 19 May 2015 09:44:34 +0200 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 From: Ralf Wenk To: "freebsd-arm@freebsd.org" Subject: Re: state of FreeBSD ARM (less stable than 6 months ago) In-reply-to: References: <5550C252.6030001@foxvalley.net> <1431357226.2428197.265704673.6A544F74@webmail.messagingengine.com> <555177D9.8080001@foxvalley.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 May 2015 09:44:34 +0200 Message-Id: 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, 19 May 2015 07:44:36 -0000 On Mon, 18 May 2015, at 21:39:27, Andreas Andersson wrote: > Also seeing this on RPI2 will try the attached patch to see if it get's > better. Meanwhile I also patched my RPi B and RPi B+ kernels but, as the panic occurs every two to three months only, it is too early for a positive statement. Ralf > 2015-05-18 21:26 GMT+02:00 Keith White : > > > On Tue, 12 May 2015, Luiz Otavio O Souza wrote: > > > > On 12 May 2015 at 00:47, Dan Raymond wrote: > >> > >>> On 5/11/2015 9:13 AM, Mark Felder wrote: > >>> > >>>> > >>>> On Mon, May 11, 2015, at 09:53, Dan Raymond wrote: > >>>> > >>>>> > >>>>> I've been running an email and web server using FreeBSD 11 on a > >>>>> Raspberry Pi B+ since November. It has crashed 3 times since then > >>>>> (roughly every two months). I'm currently running r277334. I thought > >>>>> I'd try the latest build to see if stability has improved. I purchased > >>>>> a > >>>>> Raspberry Pi 2 and used the latest crochet to built r282738. No > >>>>> problems building it and it booted up fine. However, it crashes about > >>>>> an hour into building some ports I use for my server (nginx, php, > >>>>> etc.). I tried twice last night and it crashed both times. Is anybody > >>>>> looking into these stability issues? > >>>>> > >>>>> RPi2 support is something like less than a week old for SMP and DMA > >>>> transport. I'm not sure more than a handful of people have actually > >>>> tried it yet. The bugs here will be worked out in time, but if you have > >>>> any core dumps or info that can assist in tracking down issues you're > >>>> experiencing that would certainly be appreciated. > >>>> > >>>> > >>> These panics always seem to be mmcsd related. I doubt it has anything > >>> to do > >>> with RPi2 or SMP. > >>> > >>> sdhci_bcm0-slot0: Controller timeout > >>> sdhci_bcm0-slot0: ============== REGISTER DUMP ============== > >>> sdhci_bcm0-slot0: Sys addr: 0x4d295a00 | Version: 0x00009902 > >>> sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000020 > >>> sdhci_bcm0-slot0: Argument: 0x002d19c0 | Trn mode: 0x0000193a > >>> sdhci_bcm0-slot0: Present: 0x01ff0506 | Host ctl: 0x00000003 > >>> sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 > >>> sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000507 > >>> sdhci_bcm0-slot0: Timeout: 0x0000000e | Int stat: 0x00000010 > >>> sdhci_b > >>> > >>> > >>> > >>> mmcsd0: Error indicated: 1 Timeout > >>> g_vfs_done():mmcsd0s2a[WRITE(offset=1460830208, length=24576)]error = 5 > >>> panic: No b_bufobj 0xd767ca00 > >>> cpuid = 1 > >>> KDB: enter: panic > >>> [ thread pid 12 tid 100013 ] > >>> Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! > >>> db> > >>> > >> > >> Hm, I have seen this already, it is the sdhci software timeout. > >> > >> The 'happens at night' part rings a bell for me. > >> > >> In my case it happened only with a card that has failed a few weeks > >> later, so I thought it was a pre-fail case. > >> > >> But in certain cases (depending on the card) I think this timeout can > >> be triggered with normal usage. > >> > >> Please try the attached patch and let me know if it works for you. > >> > >> Luiz > >> > >> Index: sys/dev/sdhci/sdhci.c > >> =================================================================== > >> --- sys/dev/sdhci/sdhci.c (revision 282210) > >> +++ sys/dev/sdhci/sdhci.c (working copy) > >> @@ -872,7 +872,7 @@ > >> /* Start command. */ > >> WR2(slot, SDHCI_COMMAND_FLAGS, (cmd->opcode << 8) | (flags & > >> 0xff)); > >> /* Start timeout callout. */ > >> - callout_reset(&slot->timeout_callout, 2*hz, sdhci_timeout, slot); > >> + callout_reset(&slot->timeout_callout, 10*hz, sdhci_timeout, slot); > >> } > >> > >> static void > >> _______________________________________________ > >> 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" > >> > > > > Luiz, the patch works for me. Thanks! > > > > [Tested on BBB with a 2GB microSD that previously gave a WRITE timeout.] > > > > ...keith > > > > > > > > _______________________________________________ > > 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 Tue May 19 08:39:41 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20758F51 for ; Tue, 19 May 2015 08:39:41 +0000 (UTC) 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 E5FB611D2 for ; Tue, 19 May 2015 08:39:40 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4J8deZm053009 for ; Tue, 19 May 2015 08:39:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200322] lang/erlang failes to build on armv6 with HiPE enabled Date: Tue, 19 May 2015 08:39:40 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: a.andersson.thn@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: olgeni@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc flagtypes.name Message-ID: 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: Tue, 19 May 2015 08:39:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200322 Bug ID: 200322 Summary: lang/erlang failes to build on armv6 with HiPE enabled Product: Ports & Packages Version: Latest Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: olgeni@FreeBSD.org Reporter: a.andersson.thn@gmail.com CC: freebsd-arm@FreeBSD.org CC: freebsd-arm@FreeBSD.org Flags: maintainer-feedback?(olgeni@FreeBSD.org) Assignee: olgeni@FreeBSD.org On a Raspberry PI 2 the lang/erlang port fails to build with HiPE enabled. Disabling HiPE and build works. CC obj/armv6-portbld-freebsd11.0/opt/smp/erl_bif_info.o beam/erl_bif_info.c:2109:10: error: use of undeclared identifier 'am_arm'; did you mean 'alarm'? BIF_RET(hipe_arch_name); ^~~~~~~~~~~~~~ alarm hipe/hipe_arm.h:39:24: note: expanded from macro 'hipe_arch_name' #define hipe_arch_name am_arm ^ beam/bif.h:118:28: note: expanded from macro 'BIF_RET' #define BIF_RET(x) return (x) ^ /usr/include/unistd.h:323:15: note: 'alarm' declared here unsigned int alarm(unsigned int); ^ 1 error generated. armv6-portbld-freebsd11.0/Makefile:685: recipe for target 'obj/armv6-portbld-freebsd11.0/opt/smp/erl_bif_info.o' failed gmake[5]: *** [obj/armv6-portbld-freebsd11.0/opt/smp/erl_bif_info.o] Error 1 gmake[5]: Leaving directory '/usr/ports/lang/erlang/work/otp_src_17.5/erts/emulator' /usr/ports/lang/erlang/work/otp_src_17.5/make/run_make.mk:34: recipe for target 'opt' failed gmake[4]: *** [opt] Error 2 gmake[4]: Leaving directory '/usr/ports/lang/erlang/work/otp_src_17.5/erts/emulator' Makefile:60: recipe for target 'smp' failed gmake[3]: *** [smp] Error 2 gmake[3]: Leaving directory '/usr/ports/lang/erlang/work/otp_src_17.5/erts' Makefile:443: recipe for target 'emulator' failed gmake[2]: *** [emulator] Error 2 gmake[2]: Leaving directory '/usr/ports/lang/erlang/work/otp_src_17.5' *** Error code 1 -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 09:28:42 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D167325 for ; Tue, 19 May 2015 09:28:42 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 0EC311871 for ; Tue, 19 May 2015 09:28:42 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4J9SfEl017031 for ; Tue, 19 May 2015 09:28:41 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4J9Sf6T017030; Tue, 19 May 2015 09:28:41 GMT (envelope-from daemon-user) Date: Tue, 19 May 2015 09:28:41 +0000 To: freebsd-arm@freebsd.org From: "jpa-semihalf.com (Jakub Palider)" Subject: [Differential] [Request, 1, 557 lines] D2579: PCI support for Alpine platform from Annapurna Labs Message-ID: X-Priority: 3 Thread-Topic: D2579: PCI support for Alpine platform from Annapurna Labs X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: NjYxMzQxMmI2MjBmNTRlMzhjMzBkMTMzMmNh Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_5b195ef0c6e36ed87c42d297273477fd" 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: Tue, 19 May 2015 09:28:42 -0000 --b1_5b195ef0c6e36ed87c42d297273477fd Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit jpa-semihalf.com created this revision. jpa-semihalf.com added reviewers: andrew, ian, imp. jpa-semihalf.com added a subscriber: freebsd-arm. REVISION SUMMARY This is a continuation of https://reviews.freebsd.org/D2340 and follows Andrew's suggestion to extract code related to PCI support into a separate review. This is an intermediate step between the first commit and adding MSIx support (including transition towards Linux dts). REVISION DETAIL https://reviews.freebsd.org/D2579 AFFECTED FILES sys/arm/annapurna/alpine/alpine_pci.c sys/arm/annapurna/alpine/alpine_pci.h sys/arm/annapurna/alpine/files.alpine sys/arm/conf/ALPINE EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: jpa-semihalf.com, andrew, ian, imp Cc: freebsd-arm --b1_5b195ef0c6e36ed87c42d297273477fd Content-Type: text/x-patch; charset=utf-8; name="D2579.5470.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D2579.5470.patch" ZGlmZiAtLWdpdCBhL3N5cy9hcm0vY29uZi9BTFBJTkUgYi9zeXMvYXJtL2NvbmYvQUxQSU5FCi0t LSBhL3N5cy9hcm0vY29uZi9BTFBJTkUKKysrIGIvc3lzL2FybS9jb25mL0FMUElORQpAQCAtNjMs OCArNjMsMTMgQEAKICMgU2VyaWFsIHBvcnRzCiBkZXZpY2UJCXVhcnQKIAorI1BDSS9QQ0lFCitk ZXZpY2UJCXBjaQorCiAjIEV0aGVybmV0CiBkZXZpY2UJCWV0aGVyCitkZXZpY2UJCXJlCitkZXZp Y2UJCWVtCiBkZXZpY2UJCW1paQogZGV2aWNlCQlicGYKIG9wdGlvbnMgCURFVklDRV9QT0xMSU5H CmRpZmYgLS1naXQgYS9zeXMvYXJtL2FubmFwdXJuYS9hbHBpbmUvZmlsZXMuYWxwaW5lIGIvc3lz L2FybS9hbm5hcHVybmEvYWxwaW5lL2ZpbGVzLmFscGluZQotLS0gYS9zeXMvYXJtL2FubmFwdXJu YS9hbHBpbmUvZmlsZXMuYWxwaW5lCisrKyBiL3N5cy9hcm0vYW5uYXB1cm5hL2FscGluZS9maWxl cy5hbHBpbmUKQEAgLTExLDYgKzExLDggQEAKIGRldi91YXJ0L3VhcnRfZGV2X25zODI1MC5jCQkJ b3B0aW9uYWwJdWFydAogZGV2L29mdy9vZndfY3B1LmMJCQkJc3RhbmRhcmQKIAorYXJtL2FubmFw dXJuYS9hbHBpbmUvYWxwaW5lX3BjaS5jCQlvcHRpb25hbAlwY2kKK2FybS9hbm5hcHVybmEvYWxw aW5lL2hhbC9hbF9oYWxfcGNpZS5jCQlvcHRpb25hbAlwY2kKIGFybS9hbm5hcHVybmEvYWxwaW5l L2NvbW1vbi5jCQkJc3RhbmRhcmQKIGFybS9hbm5hcHVybmEvYWxwaW5lL2FscGluZV9tYWNoZGVw LmMJCXN0YW5kYXJkCiBhcm0vYW5uYXB1cm5hL2FscGluZS9hbHBpbmVfbWFjaGRlcF9tcC5jCW9w dGlvbmFsCXNtcApkaWZmIC0tZ2l0IGEvc3lzL2FybS9hbm5hcHVybmEvYWxwaW5lL2FscGluZV9w Y2kuaCBiL3N5cy9hcm0vYW5uYXB1cm5hL2FscGluZS9hbHBpbmVfcGNpLmgKbmV3IGZpbGUgbW9k ZSAxMDA2NDQKLS0tIC9kZXYvbnVsbAorKysgYi9zeXMvYXJtL2FubmFwdXJuYS9hbHBpbmUvYWxw aW5lX3BjaS5oCkBAIC0wLDAgKzEsNDUgQEAKKy8qLQorKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK K0NvcHlyaWdodCAoQykgMjAxNSBBbm5hcHVybmEgTGFicyBMdGQuCisKK1RoaXMgZmlsZSBtYXkg YmUgbGljZW5zZWQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBBbm5hcHVybmEgTGFicyBDb21tZXJj aWFsCitMaWNlbnNlIEFncmVlbWVudC4KKworQWx0ZXJuYXRpdmVseSwgdGhpcyBmaWxlIGNhbiBi ZSBkaXN0cmlidXRlZCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsCitQdWJsaWMg TGljZW5zZSBWMiBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiBh bmQgY2FuIGJlCitmb3VuZCBhdCBodHRwOi8vd3d3LmdudS5vcmcvbGljZW5zZXMvZ3BsLTIuMC5o dG1sCisKK0FsdGVybmF0aXZlbHksIHJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFu ZCBiaW5hcnkgZm9ybXMsIHdpdGggb3IKK3dpdGhvdXQgbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0 dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zIGFyZQorbWV0OgorCisg ICAgKiAgICAgUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBh Ym92ZSBjb3B5cmlnaHQgbm90aWNlLAordGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBm b2xsb3dpbmcgZGlzY2xhaW1lci4KKworICAgICogICAgIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5h cnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0Citub3RpY2UsIHRoaXMg bGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4KK3RoZSBk b2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUKK2Rp c3RyaWJ1dGlvbi4KKworVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQ09QWVJJR0hU IEhPTERFUlMgQU5EIENPTlRSSUJVVE9SUyAiQVMgSVMiIEFORAorQU5ZIEVYUFJFU1MgT1IgSU1Q TElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFIElNUExJ RUQKK1dBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJ Q1VMQVIgUFVSUE9TRSBBUkUKK0RJU0NMQUlNRUQuIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBDT1BZ UklHSFQgT1dORVIgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRSBGT1IKK0FOWSBESVJFQ1QsIElO RElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwg REFNQUdFUworKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBT VUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOworTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJ VFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OCitBTlkg VEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElU WSwgT1IgVE9SVAorKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJ TiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMKK1NPRlRXQVJFLCBFVkVOIElGIEFEVklT RUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgorCisqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqLworCisjaWZuZGVmIEFMUElORV9QQ0lfSF8KKyNkZWZpbmUgQUxQSU5FX1BDSV9IXwor CisjZGVmaW5lIEFMX1BDSV9SQU5HRV9NQVgJCTMKKyNkZWZpbmUgQUxfUENJX1JBTkdFX0JSSURH RQkJMAorI2RlZmluZSBBTF9QQ0lfUkFOR0VfTUVNCQkxCisjZGVmaW5lIEFMX1BDSV9SQU5HRV9J TwkJCTIKKworI2VuZGlmIC8qIEFMUElORV9QQ0lfSF8gKi8KZGlmZiAtLWdpdCBhL3N5cy9hcm0v YW5uYXB1cm5hL2FscGluZS9hbHBpbmVfcGNpLmMgYi9zeXMvYXJtL2FubmFwdXJuYS9hbHBpbmUv YWxwaW5lX3BjaS5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0Ci0tLSAvZGV2L251bGwKKysrIGIvc3lz L2FybS9hbm5hcHVybmEvYWxwaW5lL2FscGluZV9wY2kuYwpAQCAtMCwwICsxLDE1MDUgQEAKKy8q LQorICogQ29weXJpZ2h0IChjKSAyMDA4IE1BUlZFTEwgSU5URVJOQVRJT05BTCBMVEQuCisgKiBD b3B5cmlnaHQgKGMpIDIwMTAgVGhlIEZyZWVCU0QgRm91bmRhdGlvbgorICogQ29weXJpZ2h0IChj KSAyMDEwLTIwMTUgU2VtaWhhbGYKKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogRGV2 ZWxvcGVkIGJ5IFNlbWloYWxmLgorICoKKyAqIFBvcnRpb25zIG9mIHRoaXMgc29mdHdhcmUgd2Vy ZSBkZXZlbG9wZWQgYnkgU2VtaWhhbGYKKyAqIHVuZGVyIHNwb25zb3JzaGlwIGZyb20gdGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJj ZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJl IHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJl IG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0 aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25z IGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4g YmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90 aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVy IGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3Zp ZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqIDMuIE5laXRoZXIgdGhlIG5hbWUgb2YgTUFS VkVMTCBub3IgdGhlIG5hbWVzIG9mIGNvbnRyaWJ1dG9ycworICogICAgbWF5IGJlIHVzZWQgdG8g ZW5kb3JzZSBvciBwcm9tb3RlIHByb2R1Y3RzIGRlcml2ZWQgZnJvbSB0aGlzIHNvZnR3YXJlCisg KiAgICB3aXRob3V0IHNwZWNpZmljIHByaW9yIHdyaXR0ZW4gcGVybWlzc2lvbi4KKyAqCisgKiBU SElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMg SVMnJyBBTkQKKyAqIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5H LCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNI QU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UKKyAqIEFSRSBE SVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBM SUFCTEUKKyAqIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwg RVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBO T1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUworICogT1IgU0VS VklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJV UFRJT04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFks IFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNM VURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQorICogT1VU IE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NT SUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKgorICovCisKKy8qCisgKiBBbHBpbmUgUENJ L1BDSS1FeHByZXNzIGNvbnRyb2xsZXIgZHJpdmVyLgorICovCisKKyNpbmNsdWRlIDxzeXMvY2Rl ZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRCQiKTsKKworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgor I2luY2x1ZGUgPHN5cy9zeXN0bS5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRl IDxzeXMvbG9jay5oPgorI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KKyNpbmNsdWRlIDxzeXMvbW9k dWxlLmg+CisjaW5jbHVkZSA8c3lzL211dGV4Lmg+CisjaW5jbHVkZSA8c3lzL3F1ZXVlLmg+Cisj aW5jbHVkZSA8c3lzL2J1cy5oPgorI2luY2x1ZGUgPHN5cy9ybWFuLmg+CisjaW5jbHVkZSA8c3lz L2VuZGlhbi5oPgorI2luY2x1ZGUgPHN5cy9rZGIuaD4KKworI2luY2x1ZGUgPG1hY2hpbmUvaW50 ci5oPgorI2luY2x1ZGUgPG1hY2hpbmUvZmR0Lmg+CisKKyNpbmNsdWRlIDx2bS92bS5oPgorI2lu Y2x1ZGUgPHZtL3BtYXAuaD4KKworI2luY2x1ZGUgPGRldi9mZHQvZmR0X2NvbW1vbi5oPgorI2lu Y2x1ZGUgPGRldi9vZncvb2Z3X3BjaS5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1cy5oPgor I2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1c19zdWJyLmg+CisjaW5jbHVkZSA8ZGV2L3BjaS9wY2l2 YXIuaD4KKyNpbmNsdWRlIDxkZXYvcGNpL3BjaXJlZy5oPgorI2luY2x1ZGUgPGRldi9wY2kvcGNp Yl9wcml2YXRlLmg+CisKKyNpbmNsdWRlICJvZndfYnVzX2lmLmgiCisjaW5jbHVkZSAicGNpYl9p Zi5oIgorI2luY2x1ZGUgImFscGluZV9wY2kuaCIKKyNpbmNsdWRlICJoYWwvYWxfaGFsX3VuaXRf YWRhcHRlcl9yZWdzLmgiCisjaW5jbHVkZSAiaGFsL2FsX2hhbF9wY2llLmgiCisKKyNpbmNsdWRl ICJvcHRfYWxwaW5lLmgiCisKKy8qIE1pbmltdW0gUENJIE1lbW9yeSBhbmQgSS9PIGFsbG9jYXRp b25zIHRha2VuIGZyb20gUENJIHNwZWMgKGluIGJ5dGVzKSAqLworI2RlZmluZQlQQ0lfTUlOX0lP X0FMTE9DCTQKKyNkZWZpbmUJUENJX01JTl9NRU1fQUxMT0MJMTYKKworI2RlZmluZQlQQ0lfTUFY X0JVU19OVU1CRVIJMjU1CisKKyNkZWZpbmUJUENJRV9NSU5fTVBTCTEyOAorI2RlZmluZQlQQ0lF X01BWF9NUFMJNDA5NgorCisjZGVmaW5lCVBDSUVfTUlOX01SUlMJMTI4CisjZGVmaW5lCVBDSUVf TUFYX01SUlMJNDA5NgorCisjZGVmaW5lCUFMX1BDSV9QT1JUUyA0CisKKy8qIE1heGltdW0gUENJ L1BDSUUgTWVtb3J5ICovCisjZGVmaW5lCUFMX1BDSV9NRU1fU0laRQkJKDB4MTAwMDAwMDAwKQor I2RlZmluZQlBTF9QQ0lfTUVNX1NMSUNFX1NJWkUJKEFMX1BDSV9NRU1fU0laRSAvIEFMX1BDSV9Q T1JUUykKKworLyogTWF4aW11bSBQQ0kvUENJRSBJL08gKi8KKyNkZWZpbmUJQUxfUENJX0lPX1NJ WkUJCSgweDEwMDAwMCkJLyogMU1CICovCisjZGVmaW5lCUFMX1BDSV9JT19TTElDRV9TSVpFCShB TF9QQ0lfSU9fU0laRSAvIEFMX1BDSV9QT1JUUykKKworI2RlZmluZQlBTF9QQ0lfTUFYX1NMT1RT CTE2CisjZGVmaW5lCUJJVFNfUEVSX1VJTlQzMgkJKE5CQlkgKiBzaXplb2YodWludDMyX3QpKQor I2RlZmluZQlBTF9NQVhfU1VQUE9SVEVEX01QUwkxMjgKKworI2RlZmluZQlBTF9JTlRFUk5BTF9C UklER0VfRUNBTV9CQVNFCTB4MjAwMAorCisjZGVmaW5lCVBDSUVNX0NUTF9NQVhfUEFZTE9BRF9F TVBUWV9CSVRTCTUKKyNkZWZpbmUJUENJRU1fQ1RMX01BWF9SRUFEX1JFUVVFU1RfRU1QVFlfQklU UwkxMgorCisjZGVmaW5lCUZEVF9SQU5HRVNfQ0VMTFMJKCgzICsgMyArIDIpICogMykKKyNkZWZp bmUJRkRUX1JBTkdFX01FTQkJMHgwMjAwMDAwMAorI2RlZmluZQlGRFRfUkFOR0VfSU8JCTB4MDEw MDAwMDAKKworI2RlZmluZQlBTF9BWElfU0xPVAkxNQorI2RlZmluZQlBTF9BWElfRlVOQwkxMgor CisjZGVmaW5lCUNPTkZJR19BRERSRVNTX1pFUk9fQklUU19NQVNLCQkweDMKKyNkZWZpbmUJQ09O RklHX0FERFJFU1NfQllURV9TRUxFQ1RPUl9NQVNLCTB4MworCisjZGVmaW5lCUJBUl9TSVpFX0lO XzMyQklUX1VOSVRTKGJhcikJKCgoYmFyICYgNykgPT0gNCkgPyAyIDogMSkKKwordHlwZWRlZiBl bnVtIHsKKwlBTF9QQ0lfVFlQRV9JTlRFUk5BTCA9IDEsCisJQUxfUENJX1RZUEVfRVhURVJOQUwg PSAyLAorfSBhbF9wY2lfdHlwZTsKKworc3RhdGljIHN0cnVjdCBvZndfY29tcGF0X2RhdGEgY29t cGF0X2RhdGFbXSA9IHsKKwl7ImFubmFwdXJuYS1sYWJzLGFsLWludGVybmFsLXBjaWUiLCBBTF9Q Q0lfVFlQRV9JTlRFUk5BTH0sCisJeyJhbm5hcHVybmEtbGFicyxhbC1leHRlcm5hbC1wY2llIiwg QUxfUENJX1RZUEVfRVhURVJOQUx9LAorCXtOVUxMLCAwfQorfTsKKworCitzdHJ1Y3QgYWxfcGNp X3JhbmdlIHsKKwl1X2xvbmcJYmFzZV9wY2k7CisJdV9sb25nCWJhc2VfcGFyZW50OworCXVfbG9u ZwlsZW47Cit9OworCit0eXBlZGVmIHN0cnVjdCB7CisJZGV2aWNlX3QJc2NfZGV2OworCWFsX3Bj aV90eXBlCXNjX3R5cGU7CisJdWludDMyX3QJc2NfYnVzbnI7CisJYnVzX2FkZHJfdAllY2FtX2hh bmRsZTsKKwlzdHJ1Y3QgYWxfcGNpZV9wb3J0CXBjaWVfcG9ydDsKKwlidXNfYWRkcl90CXJlZ19o YW5kbGU7CisJdWludDMyX3QJaW5kZXg7CisJc3RydWN0IGFsX3BjaWVfbGlua19zdGF0dXMJc3Rh dHVzOworCXN0cnVjdCBtdHgJY29uZl9sb2NrOworCXVpbnQzMl90CXRhcmdldF9idXM7CisJc3Ry dWN0IGFsX3BjaV9yYW5nZQlwY2lfcmFuZ2VbQUxfUENJX1JBTkdFX01BWF07CisJc3RydWN0IHJt YW4Jc2NfbWVtX3JtYW47CisJc3RydWN0IHJtYW4Jc2NfaW9fcm1hbjsKKwl1aW50MzJfdAlzY19p b19tYXBbQUxfUENJX0lPX1NMSUNFX1NJWkUgLworCSAgICAoUENJX01JTl9JT19BTExPQyAqIEJJ VFNfUEVSX1VJTlQzMildOworCXVpbnQzMl90CXNjX21lbV9tYXBbQUxfUENJX01FTV9TTElDRV9T SVpFIC8KKwkgICAgKFBDSV9NSU5fTUVNX0FMTE9DICogQklUU19QRVJfVUlOVDMyKV07CisJc3Ry dWN0IG9md19idXNfaWluZm8Jc2NfcGNpX2lpbmZvOworfSBhbF9wY2liX3NvZnRjOworCisvKiBG b3J3YXJkIHByb3RvdHlwZXMgKi8KK3N0YXRpYyBpbnQgYWxfcGNpYl9wcm9iZShkZXZpY2VfdCk7 CitzdGF0aWMgaW50IGFsX3BjaWJfYXR0YWNoKGRldmljZV90KTsKKworc3RhdGljIHN0cnVjdCBy ZXNvdXJjZSAqYWxfcGNpYl9hbGxvY19yZXNvdXJjZShkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwK KyAgICBpbnQgKiwgdV9sb25nLCB1X2xvbmcsIHVfbG9uZywgdV9pbnQpOworc3RhdGljIGludCBh bF9wY2liX3JlbGVhc2VfcmVzb3VyY2UoZGV2aWNlX3QsIGRldmljZV90LCBpbnQsIGludCwKKyAg ICBzdHJ1Y3QgcmVzb3VyY2UgKik7CitzdGF0aWMgaW50IGFsX3BjaWJfcmVhZF9pdmFyKGRldmlj ZV90LCBkZXZpY2VfdCwgaW50LCB1aW50cHRyX3QgKik7CitzdGF0aWMgaW50IGFsX3BjaWJfd3Jp dGVfaXZhcihkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwgdWludHB0cl90KTsKK3N0YXRpYyBpbnQg YWxfcGNpYl9pbml0KGFsX3BjaWJfc29mdGMgKnNjLCBpbnQgYnVzLCBpbnQgbWF4c2xvdCk7Citz dGF0aWMgdm9pZCBhbF9wY2liX2VuYWJsZShhbF9wY2liX3NvZnRjICpzYyk7CitzdGF0aWMgaW50 IGFsX3BjaWJfd3JpdGVfaXZhcihkZXZpY2VfdCBkZXYsIGRldmljZV90IGNoaWxkLCBpbnQgd2hp Y2gsCisgICAgdWludHB0cl90IHZhbHVlKTsKK3N0YXRpYyBpbnQgYWxfcGNpYl9tYXhzbG90cyhk ZXZpY2VfdCk7CitzdGF0aWMgdWludDMyX3QgYWxfcGNpYl9yZWFkX2NvbmZpZyhkZXZpY2VfdCwg dV9pbnQsIHVfaW50LCB1X2ludCwgdV9pbnQsCisgICAgaW50KTsKK3N0YXRpYyB2b2lkIGFsX3Bj aWJfd3JpdGVfY29uZmlnKGRldmljZV90LCB1X2ludCwgdV9pbnQsIHVfaW50LCB1X2ludCwKKyAg ICB1aW50MzJfdCwgaW50KTsKK3N0YXRpYyBpbnQgYWxfcGNpYl9yb3V0ZV9pbnRlcnJ1cHQoZGV2 aWNlX3QgcGNpYiwgZGV2aWNlX3QgZGV2LCBpbnQgcGluKTsKK3N0YXRpYyB2b2lkIGFsX3BjaWJf Zml4dXAoYWxfcGNpYl9zb2Z0YyAqc2MsIGludCBidXMsIGludCBzbG90LCBpbnQgZnVuYyk7Citz dGF0aWMgaW50IGFsX3BjaWJfbWVtX2luaXQoYWxfcGNpYl9zb2Z0YyAqc2MpOworc3RhdGljIHVp bnQzMl90IHBjaWJfYml0X2dldCh1aW50MzJfdCAqbWFwLCB1aW50MzJfdCBiaXQpOworc3RhdGlj IHZvaWQgcGNpYl9iaXRfc2V0KHVpbnQzMl90ICptYXAsIHVpbnQzMl90IGJpdCk7CitzdGF0aWMg dWludDMyX3QgcGNpYl9tYXBfY2hlY2sodWludDMyX3QgKm1hcCwgdWludDMyX3Qgc3RhcnQsIHVp bnQzMl90IGJpdHMpOworc3RhdGljIHZvaWQgcGNpYl9tYXBfc2V0KHVpbnQzMl90ICptYXAsIHVp bnQzMl90IHN0YXJ0LCB1aW50MzJfdCBiaXRzKTsKK3N0YXRpYyBidXNfYWRkcl90IHBjaWJfYWxs b2MoYWxfcGNpYl9zb2Z0YyAqc2MsIHVpbnQzMl90IHNtYXNrKTsKK3N0YXRpYyBpbnQgYWxfcGNp Yl9pbml0X2JhcihhbF9wY2liX3NvZnRjICpzYywgaW50IGJ1cywgaW50IHNsb3QsIGludCBmdW5j LAorICAgIGludCBiYXJubyk7CitzdGF0aWMgaW50IGFsX3BjaWJfaW5pdF9hbGxfYmFycyhhbF9w Y2liX3NvZnRjICpzYywgaW50IGJ1cywgaW50IHNsb3QsCisgICAgaW50IGZ1bmMsIGludCBoZHJ0 eXBlKTsKK3N0YXRpYyB2b2lkIGFsX3BjaWJfaW5pdF9icmlkZ2UoYWxfcGNpYl9zb2Z0YyAqc2Ms IGludCBidXMsIGludCBzbG90LCBpbnQgZnVuYyk7CisKK3N0YXRpYyBpbnQgcGNpZV9zZXRfbXBz KGFsX3BjaWJfc29mdGMgKnNjLCBpbnQgbXBzLCBpbnQgYnVzLCBpbnQgc2xvdCwKKyAgICBpbnQg ZnVuYyk7CitzdGF0aWMgaW50IHBjaWVfZ2V0X21wcyhhbF9wY2liX3NvZnRjICpzYywgaW50IGJ1 cywgaW50IHNsb3QsIGludCBmdW5jKTsKK3N0YXRpYyB1aW50MTZfdCBnZXRfcGNpZV9tYXhfcGF5 bG9hZChhbF9wY2liX3NvZnRjICpzYywgaW50IGJ1cywgaW50IHNsb3QsCisgICAgaW50IGZ1bmMp Oworc3RhdGljIHVpbnQxNl90IGdldF9wY2llX2dldF90eXBlKGFsX3BjaWJfc29mdGMgKnNjLCBp bnQgYnVzLCBpbnQgc2xvdCwKKyAgICBpbnQgZnVuYyk7CitzdGF0aWMgdm9pZCBwY2llX3dyaXRl X21wcyhhbF9wY2liX3NvZnRjICpzYywgaW50IG1wcywgaW50IGJ1cywgaW50IHNsb3QsCisgICAg aW50IGZ1bmMpOworc3RhdGljIHVpbnQxNl90IHBjaWVfZ2V0X3JlYWRycShhbF9wY2liX3NvZnRj ICpzYywgaW50IGJ1cywgaW50IHNsb3QsIGludCBmdW5jKTsKK3N0YXRpYyBpbnQgcGNpZV9zZXRf cmVhZHJxKGFsX3BjaWJfc29mdGMgKnNjLCBpbnQgcnEsIGludCBidXMsIGludCBzbG90LAorICAg IGludCBmdW5jKTsKK3N0YXRpYyB2b2lkIHBjaWVfd3JpdGVfbXJycyhhbF9wY2liX3NvZnRjICpz YywgaW50IGJ1cywgaW50IHNsb3QsIGludCBmdW5jKTsKK3N0YXRpYyBpbnQgcGNpZV9idXNfY29u ZmlndXJlX3NldChhbF9wY2liX3NvZnRjICpzYywgaW50IGJ1cywgaW50IHNsb3QsCisgICAgaW50 IGZ1bmMsIHVpbnQ4X3QgKmRhdGEpOworc3RhdGljIGludCBhbF9wY2llX2NmZ19wcmVwYXJlKGFs X3BjaWJfc29mdGMgKnNjKTsKK3N0YXRpYyBpbnQgYWxfcGNpZV9jZmdfYWRkcihkZXZpY2VfdCBk ZXYsIHVfaW50IGJ1cywgdV9pbnQgc2xvdCwgdV9pbnQgZnVuYywKKyAgICB1X2ludCByZWcsICBp bnQgYnl0ZXMsIGJ1c19hZGRyX3QgKmhhbmRsZSwgYnVzX2FkZHJfdCAqYWRkcik7CitzdGF0aWMg aW50IGFsX3BjaWVfZW5hYmxlX2NvbnRyb2xsZXIoYWxfcGNpYl9zb2Z0YyAqc2MpOworc3RhdGlj IGludCBhbF9wY2llX3BvcnRfY2hlY2tfbGluayhhbF9wY2liX3NvZnRjICpzYyk7CitzdGF0aWMg aW50IGFsX3BjaWVfY2ZnX3ByZXBhcmUoYWxfcGNpYl9zb2Z0YyAqc2MpOworc3RhdGljIGludCBh bF9wY2llX2lvX3ByZXBhcmUoYWxfcGNpYl9zb2Z0YyAqc2MpOworCitzdGF0aWMgaW50IGFsX2Zp bmRfY2FwKGRldmljZV90IGNoaWxkLCB1X2ludCBidXMsIHVfaW50IHNsb3QsIHVfaW50IGZ1bmMs CisgICAgaW50IGNhcGFiaWxpdHksIGludCAqY2FwcmVnKTsKK3N0YXRpYyBpbnQgYWxfZmR0X3Bj aV9yYW5nZXNfZGVjb2RlKHBoYW5kbGVfdCBub2RlLAorICAgIHN0cnVjdCBhbF9wY2lfcmFuZ2Ug KmJyaWRnZV9zcGFjZSwgc3RydWN0IGFsX3BjaV9yYW5nZSAqaW9fc3BhY2UsCisgICAgc3RydWN0 IGFsX3BjaV9yYW5nZSAqbWVtX3NwYWNlKTsKKy8qCisgKiBCdXMgaW50ZXJmYWNlIGRlZmluaXRp b25zLgorICovCitzdGF0aWMgZGV2aWNlX21ldGhvZF90IGFsX3BjaWJfbWV0aG9kc1tdID0gewor CS8qIERldmljZSBpbnRlcmZhY2UgKi8KKwlERVZNRVRIT0QoZGV2aWNlX3Byb2JlLAkJCWFsX3Bj aWJfcHJvYmUpLAorCURFVk1FVEhPRChkZXZpY2VfYXR0YWNoLAkJYWxfcGNpYl9hdHRhY2gpLAor CisJLyogQnVzIGludGVyZmFjZSAqLworCURFVk1FVEhPRChidXNfcmVhZF9pdmFyLAkJYWxfcGNp Yl9yZWFkX2l2YXIpLAorCURFVk1FVEhPRChidXNfd3JpdGVfaXZhciwJCWFsX3BjaWJfd3JpdGVf aXZhciksCisJREVWTUVUSE9EKGJ1c19hbGxvY19yZXNvdXJjZSwJCWFsX3BjaWJfYWxsb2NfcmVz b3VyY2UpLAorCURFVk1FVEhPRChidXNfcmVsZWFzZV9yZXNvdXJjZSwJCWFsX3BjaWJfcmVsZWFz ZV9yZXNvdXJjZSksCisJREVWTUVUSE9EKGJ1c19hY3RpdmF0ZV9yZXNvdXJjZSwJYnVzX2dlbmVy aWNfYWN0aXZhdGVfcmVzb3VyY2UpLAorCURFVk1FVEhPRChidXNfZGVhY3RpdmF0ZV9yZXNvdXJj ZSwJYnVzX2dlbmVyaWNfZGVhY3RpdmF0ZV9yZXNvdXJjZSksCisJREVWTUVUSE9EKGJ1c19zZXR1 cF9pbnRyLAkJYnVzX2dlbmVyaWNfc2V0dXBfaW50ciksCisJREVWTUVUSE9EKGJ1c190ZWFyZG93 bl9pbnRyLAkJYnVzX2dlbmVyaWNfdGVhcmRvd25faW50ciksCisKKwkvKiBwY2liIGludGVyZmFj ZSAqLworCURFVk1FVEhPRChwY2liX21heHNsb3RzLAkJYWxfcGNpYl9tYXhzbG90cyksCisJREVW TUVUSE9EKHBjaWJfcmVhZF9jb25maWcsCQlhbF9wY2liX3JlYWRfY29uZmlnKSwKKwlERVZNRVRI T0QocGNpYl93cml0ZV9jb25maWcsCQlhbF9wY2liX3dyaXRlX2NvbmZpZyksCisJREVWTUVUSE9E KHBjaWJfcm91dGVfaW50ZXJydXB0LAkJYWxfcGNpYl9yb3V0ZV9pbnRlcnJ1cHQpLAorCisjaWZk ZWYgQUxQSU5FX1BDSV9NU0kKKwlERVZNRVRIT0QocGNpYl9hbGxvY19tc2ksCQlhbF9wY2liX2Fs bG9jX21zaSksCisJREVWTUVUSE9EKHBjaWJfcmVsZWFzZV9tc2ksCQlhbF9wY2liX3JlbGVhc2Vf bXNpKSwKKwlERVZNRVRIT0QocGNpYl9tYXBfbXNpLAkJCWFsX3BjaWJfbWFwX21zaSksCisjZW5k aWYKKworCS8qIE9GVyBidXMgaW50ZXJmYWNlICovCisJREVWTUVUSE9EKG9md19idXNfZ2V0X2Nv bXBhdCwJCW9md19idXNfZ2VuX2dldF9jb21wYXQpLAorCURFVk1FVEhPRChvZndfYnVzX2dldF9t b2RlbCwJCW9md19idXNfZ2VuX2dldF9tb2RlbCksCisJREVWTUVUSE9EKG9md19idXNfZ2V0X25h bWUsCQlvZndfYnVzX2dlbl9nZXRfbmFtZSksCisJREVWTUVUSE9EKG9md19idXNfZ2V0X25vZGUs CQlvZndfYnVzX2dlbl9nZXRfbm9kZSksCisJREVWTUVUSE9EKG9md19idXNfZ2V0X3R5cGUsCQlv ZndfYnVzX2dlbl9nZXRfdHlwZSksCisKKwlERVZNRVRIT0RfRU5ECit9OworCitzdGF0aWMgZHJp dmVyX3QgYWxfcGNpYl9kcml2ZXIgPSB7CisJInBjaWIiLAorCWFsX3BjaWJfbWV0aG9kcywKKwlz aXplb2YoYWxfcGNpYl9zb2Z0YyksCit9OworCitkZXZjbGFzc190IHBjaWJfZGV2Y2xhc3M7CisK K0RSSVZFUl9NT0RVTEUocGNpYiwgb2Z3YnVzLCBhbF9wY2liX2RyaXZlciwgcGNpYl9kZXZjbGFz cywgMCwgMCk7CisKK3N0YXRpYyBpbnQKK2FsX2ZkdF9wY2lfcmFuZ2VzX2RlY29kZShwaGFuZGxl X3Qgbm9kZSwgc3RydWN0IGFsX3BjaV9yYW5nZSAqYnJpZGdlX3NwYWNlLAorICAgIHN0cnVjdCBh bF9wY2lfcmFuZ2UgKmlvX3NwYWNlLCBzdHJ1Y3QgYWxfcGNpX3JhbmdlICptZW1fc3BhY2UpCit7 CisJcGNlbGxfdCByYW5nZXNbRkRUX1JBTkdFU19DRUxMU107CisJc3RydWN0IGFsX3BjaV9yYW5n ZSAqcGNpX3NwYWNlOworCXBjZWxsX3QgYWRkcl9jZWxscywgc2l6ZV9jZWxscywgcGFyX2FkZHJf Y2VsbHM7CisJcGNlbGxfdCAqcmFuZ2VzcHRyOworCXBjZWxsX3QgY2VsbDAsIGNlbGwxLCBjZWxs MjsKKwlpbnQgdHVwbGVfc2l6ZSwgdHVwbGVzLCBpLCBydiwgb2Zmc2V0X2NlbGxzLCBsZW47CisK KwkvKgorCSAqIFJldHJpZXZlICdyYW5nZXMnIHByb3BlcnR5LgorCSAqLworCWlmICgoZmR0X2Fk ZHJzaXplX2NlbGxzKG5vZGUsICZhZGRyX2NlbGxzLCAmc2l6ZV9jZWxscykpICE9IDApCisJCXJl dHVybiAoRUlOVkFMKTsKKwlpZiAoYWRkcl9jZWxscyAhPSAzIHx8IHNpemVfY2VsbHMgIT0gMikg eworCQlyZXR1cm4gKEVSQU5HRSk7CisJfQorCisJcGFyX2FkZHJfY2VsbHMgPSBmZHRfcGFyZW50 X2FkZHJfY2VsbHMobm9kZSk7CisJaWYgKHBhcl9hZGRyX2NlbGxzID4gMykgeworCQlyZXR1cm4g KEVSQU5HRSk7CisJfQorCisJbGVuID0gT0ZfZ2V0cHJvcGxlbihub2RlLCAicmFuZ2VzIik7CisJ aWYgKGxlbiA+IHNpemVvZihyYW5nZXMpKQorCQlyZXR1cm4gKEVOT01FTSk7CisKKwlpZiAoT0Zf Z2V0cHJvcChub2RlLCAicmFuZ2VzIiwgcmFuZ2VzLCBzaXplb2YocmFuZ2VzKSkgPD0gMCkKKwkJ cmV0dXJuIChFSU5WQUwpOworCisJdHVwbGVfc2l6ZSA9IHNpemVvZihwY2VsbF90KSAqIChhZGRy X2NlbGxzICsgcGFyX2FkZHJfY2VsbHMgKworCSAgICBzaXplX2NlbGxzKTsKKwl0dXBsZXMgPSBs ZW4gLyB0dXBsZV9zaXplOworCisJLyoKKwkgKiBJbml0aWFsaXplIHRoZSByYW5nZXMgc28gdGhh dCB3ZSBkb24ndCBoYXZlIHRvIHdvcnJ5IGFib3V0CisJICogaGF2aW5nIHRoZW0gYWxsIGRlZmlu ZWQgaW4gdGhlIEZEVC4gSW4gcGFydGljdWxhciwgaXQgaXMKKwkgKiBwZXJmZWN0bHkgZmluZSBu b3QgdG8gd2FudCBJL08gc3BhY2Ugb24gUENJIGJ1c3Nlcy4KKwkgKi8KKwliemVybyhpb19zcGFj ZSwgc2l6ZW9mKCppb19zcGFjZSkpOworCWJ6ZXJvKG1lbV9zcGFjZSwgc2l6ZW9mKCptZW1fc3Bh Y2UpKTsKKwliemVybyhicmlkZ2Vfc3BhY2UsIHNpemVvZigqYnJpZGdlX3NwYWNlKSk7CisKKwly YW5nZXNwdHIgPSAmcmFuZ2VzWzBdOworCW9mZnNldF9jZWxscyA9IDA7CisJZm9yIChpID0gMDsg aSA8IHR1cGxlczsgaSsrKSB7CisJCWNlbGwwID0gZmR0X2RhdGFfZ2V0KCh2b2lkICopcmFuZ2Vz cHRyLCAxKTsKKwkJcmFuZ2VzcHRyKys7CisJCWNlbGwxID0gZmR0X2RhdGFfZ2V0KCh2b2lkICop cmFuZ2VzcHRyLCAxKTsKKwkJcmFuZ2VzcHRyKys7CisJCWNlbGwyID0gZmR0X2RhdGFfZ2V0KCh2 b2lkICopcmFuZ2VzcHRyLCAxKTsKKwkJcmFuZ2VzcHRyKys7CisKKwkJaWYgKChjZWxsMCAmIEZE VF9SQU5HRV9NRU0pICE9IDApIHsKKwkJCXBjaV9zcGFjZSA9IG1lbV9zcGFjZTsKKwkJfSBlbHNl IGlmICgoY2VsbDAgJiBGRFRfUkFOR0VfSU8pICE9IDApIHsKKwkJCXBjaV9zcGFjZSA9IGlvX3Nw YWNlOworCQl9IGVsc2UgaWYgKGNlbGwwID09IDApIHsKKwkJCXBjaV9zcGFjZSA9IGJyaWRnZV9z cGFjZTsKKwkJfSBlbHNlIHsKKwkJCXJ2ID0gRVJBTkdFOworCQkJZ290byBvdXQ7CisJCX0KKwor CQlpZiAocGFyX2FkZHJfY2VsbHMgPT0gMykgeworCQkJLyoKKwkJCSAqIFRoaXMgaXMgYSBQQ0kg c3Vibm9kZSAncmFuZ2VzJy4gU2tpcCBjZWxsMCBhbmQKKwkJCSAqIGNlbGwxIG9mIHRoaXMgZW50 cnkgYW5kIG9ubHkgdXNlIGNlbGwyLgorCQkJICovCisJCQlvZmZzZXRfY2VsbHMgPSAyOworCQkJ cmFuZ2VzcHRyICs9IG9mZnNldF9jZWxsczsKKwkJfQorCisJCXBjaV9zcGFjZS0+YmFzZV9wYXJl bnQgPSBmZHRfZGF0YV9nZXQoKHZvaWQgKilyYW5nZXNwdHIsCisJCSAgICBwYXJfYWRkcl9jZWxs cyAtIG9mZnNldF9jZWxscyk7CisJCXJhbmdlc3B0ciArPSBwYXJfYWRkcl9jZWxscyAtIG9mZnNl dF9jZWxsczsKKworCQlwY2lfc3BhY2UtPmxlbiA9IGZkdF9kYXRhX2dldCgodm9pZCAqKXJhbmdl c3B0ciwgc2l6ZV9jZWxscyk7CisJCXJhbmdlc3B0ciArPSBzaXplX2NlbGxzOworCisJCXBjaV9z cGFjZS0+YmFzZV9wY2kgPSBjZWxsMjsKKwl9CisJcnYgPSAwOworb3V0OgorCXJldHVybiAocnYp OworfQorCitzdGF0aWMgaW50CithbF9wY2llX2VuYWJsZV9jb250cm9sbGVyKGFsX3BjaWJfc29m dGMgKnNjKQoreworCWlmIChzYy0+c2NfdHlwZSA9PSBBTF9QQ0lfVFlQRV9JTlRFUk5BTCkKKwkJ cmV0dXJuICgwKTsKKworCS8qIEluaXRpYWxpemUgUENJZSBIQUwgd2l0aCByZWdpc3RlciB0YWcg YW5kIGhhbmRsZSAqLworCWFsX3BjaWVfcG9ydF9oYW5kbGVfaW5pdCgmc2MtPnBjaWVfcG9ydCwg YWxfYnVzX2RtYV90b192YShmZHRidXNfYnNfdGFnLAorCSAgICBzYy0+cmVnX2hhbmRsZSksIE5V TEwgLyogZml4bWUgKi8sIHNjLT5pbmRleCk7CisJaWYgKGFsX3BjaWVfb3BlcmF0aW5nX21vZGVf Z2V0KCZzYy0+cGNpZV9wb3J0KSAhPQorCSAgICBBTF9QQ0lFX09QRVJBVElOR19NT0RFX1JDKSB7 CisJCWRldmljZV9wcmludGYoc2MtPnNjX2RldiwKKwkJICAgICJjb250cm9sbGVyIGlzIG5vdCBj b25maWd1cmVkIHRvIFJvb3QtQ29tcGxleCBtb2RlXG4iKTsKKwkJcmV0dXJuIChFTk9TWVMpOwor CX0KKworCXJldHVybiAoMCk7Cit9CisKKy8qIEdldCBFQ0FNIGFkZHJlc3MgYWNjb3JkaW5nIHRv IGJ1cywgZGV2aWNlLCBmdW5jdGlvbiwgYW5kIG9mZnNldCAqLworc3RhdGljIGludAorYWxfcGNp ZV9jZmdfYWRkcihkZXZpY2VfdCBkZXYsIHVfaW50IGJ1cywgdV9pbnQgc2xvdCwgdV9pbnQgZnVu YywgdV9pbnQgcmVnLAorICAgIGludCBieXRlcywgYnVzX2FkZHJfdCAqaGFuZGxlLCBidXNfYWRk cl90ICphZGRyKQoreworCWFsX3BjaWJfc29mdGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYp OworCWJ1c19hZGRyX3QgcmV0X3ZhbCA9IChidXNfYWRkcl90KU5VTEw7CisKKwkvKiBUcmFwIG91 dCBpbGxlZ2FsIHZhbHVlcyAqLworCWlmIChidXMgPiBQQ0lfTUFYX0JVU19OVU1CRVIpCisJCXJl dHVybiAoRUZBVUxUKTsKKworCXJldF92YWwgPSAoYnVzX2FkZHJfdCkoKChzbG90IDw8IEFMX0FY SV9TTE9UKSB8IChmdW5jIDw8IEFMX0FYSV9GVU5DKSB8IHJlZykpOworCWlmIChzYy0+c2NfdHlw ZSA9PSBBTF9QQ0lfVFlQRV9JTlRFUk5BTCkgeworCQkqYWRkciA9IHJldF92YWw7CisJCSpoYW5k bGUgPSBzYy0+ZWNhbV9oYW5kbGU7CisJCXJldHVybiAoMCk7CisJfQorCisJLyogTm9ybWFsaXpl IGJ1cyBudW1iZXIgdG8gdGhlIGJhc2Ugb2YgcGFyZW50IGJyaWRnZSAqLworCWJ1cyAtPSBzYy0+ c2NfYnVzbnI7CisKKwkvKiBJZiB0aGVyZSBpcyBubyBsaW5rLCBqdXN0IHNob3cgdGhlIFBDSSBi cmlkZ2UuICovCisJaWYgKHNjLT5zdGF0dXMubGlua191cCA9PSBBTF9GQUxTRSkKKwkJcmV0dXJu IChFRkFVTFQpOworCWlmIChidXMgPT0gMCkgeworCQlpZiAoc2xvdCA+IDApIHsKKwkJCXJldHVy biAoRUZBVUxUKTsKKwkJfQorCQlyZXRfdmFsID0gKGJ1c19hZGRyX3QpKEFMX0lOVEVSTkFMX0JS SURHRV9FQ0FNX0JBU0UgKyByZWcpOworCQkqaGFuZGxlID0gc2MtPnJlZ19oYW5kbGU7CisJCSph ZGRyID0gcmV0X3ZhbDsKKwkJcmV0dXJuICgwKTsKKwl9IGVsc2UgeworCQkvKgorCQkgKiBXb3Jr YXJvdW5kOiBpdCBlbnVtZXJhdGVzIG9uIGFsbCBpbnRlcm5hbCBidXMgbnVtYmVycyBzbworCQkg KiBjb21tdW5pY2F0ZSBvbmx5IHdpdGggdGhlIGZpcnN0IGRldmljZSBvbiB0aGUgYnVzCisJCSAq LworCQlpZiAoc2xvdCA+IDApCisJCQlyZXR1cm4gKEVGQVVMVCk7CisKKwkJaWYgKChidXMpICE9 IHNjLT50YXJnZXRfYnVzKSB7CisJCQlpZiAoYm9vdHZlcmJvc2UpCisJCQkJZGV2aWNlX3ByaW50 ZihzYy0+c2NfZGV2LAorCQkJCSAgICAiY2hhbmdlIHRhcmdldCBidXMgbnVtYmVyIGZyb20gJWQg dG8gJWRcbiIsCisJCQkJICAgICBzYy0+dGFyZ2V0X2J1cywgYnVzKTsKKwkJCXNjLT50YXJnZXRf YnVzID0gYnVzOworCQkJYWxfcGNpZV90YXJnZXRfYnVzX3NldCgmc2MtPnBjaWVfcG9ydCwgc2Mt PnRhcmdldF9idXMsCisJCQkgICAgMHhGRik7CisJCX0KKwl9CisKKwkqYWRkciA9IHJldF92YWw7 CisJKmhhbmRsZSA9IHNjLT5lY2FtX2hhbmRsZTsKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMg aW50CithbF9wY2llX3BvcnRfY2hlY2tfbGluayhhbF9wY2liX3NvZnRjICpzYykKK3sKKworCXN0 cnVjdCBhbF9wY2llX2xpbmtfc3RhdHVzICpzdGF0dXMgPSAmc2MtPnN0YXR1czsKKwlpbnQgcmM7 CisKKwlpZiAoc2MtPnNjX3R5cGUgPT0gQUxfUENJX1RZUEVfSU5URVJOQUwpCisJCXJldHVybiAo MSk7CisKKwlyYyA9IGFsX3BjaWVfbGlua19zdGF0dXMoJnNjLT5wY2llX3BvcnQsIHN0YXR1cyk7 CisJaWYgKHJjIDwgMCkgeworCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsICJmYWlsZWQgdG8g Z2V0IHBjaWUgbGluayBzdGF0dXNcbiIpOworCQlyZXR1cm4gKDApOworCX0KKworCWlmIChzdGF0 dXMtPmxpbmtfdXAgPT0gQUxfRkFMU0UpIHsKKwkJZGV2aWNlX3ByaW50ZihzYy0+c2NfZGV2LCAi bGluayAldSBkb3duXG4iLCBzYy0+aW5kZXgpOworCQlyZXR1cm4gKDApOworCX0KKwlkZXZpY2Vf cHJpbnRmKHNjLT5zY19kZXYsICJsaW5rIHVwOiBzcGVlZCBHZW4gJWQgd2lkdGggeCV4XG4iLAor CSAgICBzdGF0dXMtPnNwZWVkLCBzdGF0dXMtPmxhbmVzKTsKKworCXJldHVybiAoMSk7CisKK30K KworLyogcHJlcGFyZSBjb250cm9sbGVyIGZvciBpc3N1aW5nIENGRyB0cmFuc2FjdGlvbnMqLwor c3RhdGljIGludAorYWxfcGNpZV9jZmdfcHJlcGFyZShhbF9wY2liX3NvZnRjICpzYykKK3sKKwor CWlmIChzYy0+c2NfdHlwZSA9PSBBTF9QQ0lfVFlQRV9JTlRFUk5BTCkKKwkJcmV0dXJuICgwKTsK KworCXNjLT50YXJnZXRfYnVzID0gMTsKKwkvKgorCSAqIGZvcmNlIHRoZSBjb250cm9sbGVyIHRv IHNldCB0aGUgcGNpIGJ1cyBpbiB0aGUgVExQIHRvCisJICogcGNpZS0+dGFyZ2V0X2J1cyBubyBt YXR0ZXIgd2hhdCBpcyB0aGUgYnVzIHBvcnRpb24gb2YgdGhlIEVDQU0gYWRkZXNzCisJICogaXMu CisJICovCisJYWxfcGNpZV90YXJnZXRfYnVzX3NldCgmc2MtPnBjaWVfcG9ydCwgc2MtPnRhcmdl dF9idXMsIDB4RkYpOworCisJLyogdGhlIGJ1cyBjb25uZWN0ZWQgdG8gdGhlIGNvbnRyb2xsZXIg YWx3YXlzIGVudW1lcmF0ZWQgYXMgYnVzIDEqLworCWFsX3BjaWVfc2Vjb25kYXJ5X2J1c19zZXQo JnNjLT5wY2llX3BvcnQsIDEpOworCS8qIHNldCBzdWJvcmRpbmFyeSB0byBtYXggdmFsdWUgKi8K KwlhbF9wY2llX3N1Ym9yZGluYXJ5X2J1c19zZXQoJnNjLT5wY2llX3BvcnQsIDB4ZmYpOworCisJ cmV0dXJuICgwKTsKK30KKworc3RhdGljIGludAorYWxfcGNpYl9wcm9iZShkZXZpY2VfdCBkZXYp Cit7CisJY29uc3QgY2hhciAqZHR5cGU7CisJYWxfcGNpX3R5cGUgcGNpdDsKKworCWR0eXBlID0g b2Z3X2J1c19nZXRfdHlwZShkZXYpOworCWlmIChkdHlwZSA9PSBOVUxMIHx8IHN0cmNtcChkdHlw ZSwgInBjaSIpICE9IDApIHsKKwkJcmV0dXJuIChFTlhJTyk7CisJfQorCisJcGNpdCA9IG9md19i dXNfc2VhcmNoX2NvbXBhdGlibGUoZGV2LCBjb21wYXRfZGF0YSktPm9jZF9kYXRhOworCisJc3dp dGNoIChwY2l0KSB7CisJY2FzZSBBTF9QQ0lfVFlQRV9JTlRFUk5BTDoKKwkJZGV2aWNlX3NldF9k ZXNjKGRldiwKKwkJICAgICJBbm5hcHVybmEtTGFicyBJbnRlZ3JhdGVkIEludGVybmFsIFBDSS1F IENvbnRyb2xsZXIiKTsKKwkJcmV0dXJuIChCVVNfUFJPQkVfREVGQVVMVCk7CisJY2FzZSBBTF9Q Q0lfVFlQRV9FWFRFUk5BTDoKKwkJZGV2aWNlX3NldF9kZXNjKGRldiwKKwkJICAgICJBbm5hcHVy bmEtTGFicyBJbnRlZ3JhdGVkIEV4dGVybmFsIFBDSS1FIENvbnRyb2xsZXIiKTsKKwkJcmV0dXJu IChCVVNfUFJPQkVfREVGQVVMVCk7CisJZGVmYXVsdDoKKwkJYnJlYWs7CisJfQorCisJcmV0dXJu IChFTlhJTyk7Cit9CisKKworLyogcHJlcGFyZSBjb250cm9sbGVyIGZvciBpc3N1aW5nIElPIHRy YW5zYWN0aW9ucyovCitzdGF0aWMgaW50CithbF9wY2llX2lvX3ByZXBhcmUoYWxfcGNpYl9zb2Z0 YyAqc2MpCit7CisKKwlpZiAoc2MtPnNjX3R5cGUgPT0gQUxfUENJX1RZUEVfSU5URVJOQUwpCisJ CXJldHVybiAoMCk7CisKKwlzdHJ1Y3QgYWxfcGNpZV9hdHVfcmVnaW9uIGlvX2F0dV9yZWdpb24g PSB7CisJCS5lbmFibGUgPSBBTF9UUlVFLAorCQkuZGlyZWN0aW9uID0gQUxfUENJRV9BVFVfRElS X09VVEJPVU5ELAorCQkuaW5kZXggPSAwLAorCQkuYmFzZV9hZGRyID0gc2MtPnBjaV9yYW5nZVtB TF9QQ0lfUkFOR0VfSU9dLmJhc2VfcGFyZW50LAorCQkubGltaXQgPSBzYy0+cGNpX3JhbmdlW0FM X1BDSV9SQU5HRV9JT10uYmFzZV9wYXJlbnQgKworCQkgICAgc2MtPnBjaV9yYW5nZVtBTF9QQ0lf UkFOR0VfSU9dLmxlbiAtIDEsCisJCS8qIHRoZSBhZGRyZXNzIHRoYXQgbWF0Y2hlcyB3aWxsIGJl IHRyYW5zbGF0ZWQgdG8gdGhpcyBhZGRyZXNzICsgb2Zmc2V0ICovCisJCS50YXJnZXRfYWRkciA9 IHNjLT5wY2lfcmFuZ2VbQUxfUENJX1JBTkdFX0lPXS5iYXNlX3BjaSwKKwkJLmludmVydF9tYXRj aGluZyA9IEFMX0ZBTFNFLAorCQkudGxwX3R5cGUgPSBBTF9QQ0lFX1RMUF9UWVBFX0lPLCAvKiBw Y2llIHRscCB0eXBlKi8KKwkJLmF0dHIgPSAwLCAvKiBwY2llIGZyYW1lIGhlYWRlciBhdHRyIGZp ZWxkKi8KKwkJLyogb3V0Ym91bmQgc3BlY2lmaWMgcGFyYW1zICovCisJCS5tc2dfY29kZSA9IDAs IC8qIHBjaWUgbWVzc2FnZSBjb2RlICovCisJCS5jZmdfc2hpZnRfbW9kZSA9IEFMX0ZBTFNFLAor CQkvKiBpbmJvdW5kIHNwZWNpZmljIHBhcmFtcyovCisJfTsKKworCWRldmljZV9wcmludGYoc2Mt PnNjX2RldiwgIiVzOiBiYXNlICVsbHgsIGxpbWl0ICVsbHgsIHRhcmdldCAlbGx4XG4iLAorCSAg ICBfX2Z1bmNfXywgaW9fYXR1X3JlZ2lvbi5iYXNlX2FkZHIsCisJICAgIGlvX2F0dV9yZWdpb24u bGltaXQsIGlvX2F0dV9yZWdpb24udGFyZ2V0X2FkZHIpOworCWFsX3BjaWVfYXR1X3JlZ2lvbl9z ZXQoJnNjLT5wY2llX3BvcnQsICZpb19hdHVfcmVnaW9uKTsKKworCXJldHVybiAoMCk7Cit9CisK K3N0YXRpYyBpbnQKK2FsX3BjaWJfbWVtX2luaXQoYWxfcGNpYl9zb2Z0YyAqc2MpCit7CisJaW50 IGVycjsKKworCS8qCisJICogTWVtb3J5IG1hbmFnZW1lbnQuCisJICovCisJc2MtPnNjX21lbV9y bWFuLnJtX3R5cGUgPSBSTUFOX0FSUkFZOworCWVyciA9IHJtYW5faW5pdCgmc2MtPnNjX21lbV9y bWFuKTsKKwlpZiAoZXJyKQorCQlyZXR1cm4gKGVycik7CisKKwlzYy0+c2NfaW9fcm1hbi5ybV90 eXBlID0gUk1BTl9BUlJBWTsKKwllcnIgPSBybWFuX2luaXQoJnNjLT5zY19pb19ybWFuKTsKKwlp ZiAoZXJyKSB7CisJCXJtYW5fZmluaSgmc2MtPnNjX21lbV9ybWFuKTsKKwkJcmV0dXJuIChlcnIp OworCX0KKworCWVyciA9IHJtYW5fbWFuYWdlX3JlZ2lvbigmc2MtPnNjX21lbV9ybWFuLAorCSAg ICBzYy0+cGNpX3JhbmdlW0FMX1BDSV9SQU5HRV9NRU1dLmJhc2VfcGNpLAorCSAgICBzYy0+cGNp X3JhbmdlW0FMX1BDSV9SQU5HRV9NRU1dLmJhc2VfcGNpICsKKwkgICAgc2MtPnBjaV9yYW5nZVtB TF9QQ0lfUkFOR0VfTUVNXS5sZW4gLSAxKTsKKwlpZiAoZXJyKQorCQlnb3RvIGVycm9yOworCisJ ZXJyID0gcm1hbl9tYW5hZ2VfcmVnaW9uKCZzYy0+c2NfaW9fcm1hbiwKKwkgICAgc2MtPnBjaV9y YW5nZVtBTF9QQ0lfUkFOR0VfSU9dLmJhc2VfcGNpLAorCSAgICBzYy0+cGNpX3JhbmdlW0FMX1BD SV9SQU5HRV9JT10uYmFzZV9wY2kgKyBzYy0+cGNpX3JhbmdlW0FMX1BDSV9SQU5HRV9JT10ubGVu IC0gMSk7CisJaWYgKGVycikKKwkJZ290byBlcnJvcjsKKworCXJldHVybiAoMCk7CisKK2Vycm9y OgorCXJtYW5fZmluaSgmc2MtPnNjX21lbV9ybWFuKTsKKwlybWFuX2ZpbmkoJnNjLT5zY19pb19y bWFuKTsKKworCXJldHVybiAoZXJyKTsKK30KKworc3RhdGljIGlubGluZSB1aW50MzJfdAorcGNp Yl9iaXRfZ2V0KHVpbnQzMl90ICptYXAsIHVpbnQzMl90IGJpdCkKK3sKKwl1aW50MzJfdCBuID0g Yml0IC8gQklUU19QRVJfVUlOVDMyOworCisJYml0ID0gYml0ICUgQklUU19QRVJfVUlOVDMyOwor CXJldHVybiAobWFwW25dICYgKDEgPDwgYml0KSk7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZAor cGNpYl9iaXRfc2V0KHVpbnQzMl90ICptYXAsIHVpbnQzMl90IGJpdCkKK3sKKwl1aW50MzJfdCBu ID0gYml0IC8gQklUU19QRVJfVUlOVDMyOworCisJYml0ID0gYml0ICUgQklUU19QRVJfVUlOVDMy OworCW1hcFtuXSB8PSAoMSA8PCBiaXQpOworfQorCitzdGF0aWMgaW5saW5lIHVpbnQzMl90Citw Y2liX21hcF9jaGVjayh1aW50MzJfdCAqbWFwLCB1aW50MzJfdCBzdGFydCwgdWludDMyX3QgYml0 cykKK3sKKwl1aW50MzJfdCBpOworCisJZm9yIChpID0gc3RhcnQ7IGkgPCBzdGFydCArIGJpdHM7 IGkrKykKKwkJaWYgKHBjaWJfYml0X2dldChtYXAsIGkpKQorCQkJcmV0dXJuICgwKTsKKworCXJl dHVybiAoMSk7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZAorcGNpYl9tYXBfc2V0KHVpbnQzMl90 ICptYXAsIHVpbnQzMl90IHN0YXJ0LCB1aW50MzJfdCBiaXRzKQoreworCXVpbnQzMl90IGk7CisK Kwlmb3IgKGkgPSBzdGFydDsgaSA8IHN0YXJ0ICsgYml0czsgaSsrKQorCQlwY2liX2JpdF9zZXQo bWFwLCBpKTsKK30KKworc3RhdGljIGJ1c19hZGRyX3QKK3BjaWJfYWxsb2MoYWxfcGNpYl9zb2Z0 YyAqc2MsIHVpbnQzMl90IHNtYXNrKQoreworCXVpbnQzMl90IGJpdHMsIGJpdHNfbGltaXQsIGks ICptYXAsIG1pbl9hbGxvYywgc2l6ZTsKKwlidXNfYWRkcl90IGFkZHIgPSAwOworCWJ1c19hZGRy X3QgYmFzZTsKKworCWlmIChzbWFzayAmIDEpIHsKKwkJYmFzZSA9IHNjLT5wY2lfcmFuZ2VbQUxf UENJX1JBTkdFX0lPXS5iYXNlX3BjaTsKKwkJbWluX2FsbG9jID0gUENJX01JTl9JT19BTExPQzsK KwkJYml0c19saW1pdCA9IHNjLT5wY2lfcmFuZ2VbQUxfUENJX1JBTkdFX0lPXS5sZW4gLyBtaW5f YWxsb2M7CisJCW1hcCA9IHNjLT5zY19pb19tYXA7CisJCXNtYXNrICY9IH4weDM7CisJfSBlbHNl IHsKKwkJYmFzZSA9IHNjLT5wY2lfcmFuZ2VbQUxfUENJX1JBTkdFX01FTV0uYmFzZV9wY2k7CisJ CW1pbl9hbGxvYyA9IFBDSV9NSU5fTUVNX0FMTE9DOworCQliaXRzX2xpbWl0ID0gc2MtPnBjaV9y YW5nZVtBTF9QQ0lfUkFOR0VfTUVNXS5sZW4gLyBtaW5fYWxsb2M7CisJCW1hcCA9IHNjLT5zY19t ZW1fbWFwOworCQlzbWFzayAmPSB+MHhGOworCX0KKworCXNpemUgPSB+c21hc2sgKyAxOworCWJp dHMgPSBzaXplIC8gbWluX2FsbG9jOworCisJZm9yIChpID0gMDsgaSArIGJpdHMgPD0gYml0c19s aW1pdDsgaSArPSBiaXRzKQorCQlpZiAocGNpYl9tYXBfY2hlY2sobWFwLCBpLCBiaXRzKSkgewor CQkJcGNpYl9tYXBfc2V0KG1hcCwgaSwgYml0cyk7CisJCQlhZGRyID0gYmFzZSArIChpICogbWlu X2FsbG9jKTsKKwkJCWdvdG8gZW5kOworCQl9CisKK2VuZDoKKwlyZXR1cm4gKGFkZHIpOworfQor CitzdGF0aWMgaW50CithbF9wY2liX2luaXRfYmFyKGFsX3BjaWJfc29mdGMgKnNjLCBpbnQgYnVz LCBpbnQgc2xvdCwgaW50IGZ1bmMsCisgICAgaW50IGJhcm5vKQoreworCXVpbnQzMl90IGFkZHIs IGJhcjsKKwlpbnQgcmVnLCB3aWR0aDsKKworCXJlZyA9IFBDSVJfQkFSKGJhcm5vKTsKKworCS8q CisJICogTmVlZCB0byBpbml0IHRoZSBCQVIgcmVnaXN0ZXIgd2l0aCAweGZmZmZmZmZmIGJlZm9y ZSBjb3JyZWN0CisJICogdmFsdWUgY2FuIGJlIHJlYWQuCisJICovCisJYWxfcGNpYl93cml0ZV9j b25maWcoc2MtPnNjX2RldiwgYnVzLCBzbG90LCBmdW5jLCByZWcsIDB4ZmZmZmZmZmZ1bCwgNCk7 CisJYmFyID0gYWxfcGNpYl9yZWFkX2NvbmZpZyhzYy0+c2NfZGV2LCBidXMsIHNsb3QsIGZ1bmMs IHJlZywgNCk7CisJaWYgKGJhciA9PSAwKQorCQlyZXR1cm4gKDEpOworCisJLyogQ2FsY3VsYXRl IEJBUiBzaXplOiA2NCBvciAzMiBiaXQgKGluIDMyLWJpdCB1bml0cykgKi8KKwl3aWR0aCA9IEJB Ul9TSVpFX0lOXzMyQklUX1VOSVRTKGJhcik7CisKKwlhZGRyID0gcGNpYl9hbGxvYyhzYywgYmFy KTsKKwlpZiAoYWRkciA9PSAwKQorCQlyZXR1cm4gKC0xKTsKKworCWlmIChib290dmVyYm9zZSkK KwkJcHJpbnRmKCJQQ0kgJXU6JXU6JXU6IHJlZyAleDogc21hc2s9JTA4eDogYWRkcj0lMDh4XG4i LAorCQkgICAgYnVzLCBzbG90LCBmdW5jLCByZWcsIGJhciwgYWRkcik7CisKKwlhbF9wY2liX3dy aXRlX2NvbmZpZyhzYy0+c2NfZGV2LCBidXMsIHNsb3QsIGZ1bmMsIHJlZywgYWRkciwgNCk7CisJ aWYgKHdpZHRoID09IDIpCisJCWFsX3BjaWJfd3JpdGVfY29uZmlnKHNjLT5zY19kZXYsIGJ1cywg c2xvdCwgZnVuYywgcmVnICsgNCwKKwkJICAgIDAsIDQpOworCisJcmV0dXJuICh3aWR0aCk7Cit9 CisKK3N0YXRpYyBpbnQKK2FsX3BjaWJfaW5pdF9hbGxfYmFycyhhbF9wY2liX3NvZnRjICpzYywg aW50IGJ1cywgaW50IHNsb3QsCisgICAgaW50IGZ1bmMsIGludCBoZHJ0eXBlKQoreworCWludCBt YXhiYXIsIGJhciwgaTsKKworCW1heGJhciA9IChoZHJ0eXBlICYgUENJTV9IRFJUWVBFKSAhPSAw ID8gMCA6IDY7CisJYmFyID0gMDsKKworCS8qIFByb2dyYW0gdGhlIGJhc2UgYWRkcmVzcyByZWdp c3RlcnMgKi8KKwl3aGlsZSAoYmFyIDwgbWF4YmFyKSB7CisJCWkgPSBhbF9wY2liX2luaXRfYmFy KHNjLCBidXMsIHNsb3QsIGZ1bmMsIGJhcik7CisJCWJhciArPSBpOworCQlpZiAoaSA8IDApIHsK KwkJCWRldmljZV9wcmludGYoc2MtPnNjX2RldiwKKwkJCSAgICAiUENJIElPL01lbW9yeSBzcGFj ZSBleGhhdXN0ZWRcbiIpOworCQkJcmV0dXJuIChFTk9NRU0pOworCQl9CisJfQorCisJcmV0dXJu ICgwKTsKK30KKworc3RhdGljIHZvaWQKK2FsX3BjaWJfaW5pdF9icmlkZ2UoYWxfcGNpYl9zb2Z0 YyAqc2MsIGludCBidXMsIGludCBzbG90LCBpbnQgZnVuYykKK3sKKwlidXNfYWRkcl90IGlvX2Jh c2UsIG1lbV9iYXNlOworCXVpbnQzMl90IGlvX2xpbWl0LCBtZW1fbGltaXQ7CisJaW50IHNlY2J1 czsKKworCWlvX2Jhc2UgPSBzYy0+cGNpX3JhbmdlW0FMX1BDSV9SQU5HRV9JT10uYmFzZV9wY2k7 CisJaW9fbGltaXQgPSBpb19iYXNlICsgc2MtPnBjaV9yYW5nZVtBTF9QQ0lfUkFOR0VfSU9dLmxl biAtIDE7CisJbWVtX2Jhc2UgPSBzYy0+cGNpX3JhbmdlW0FMX1BDSV9SQU5HRV9NRU1dLmJhc2Vf cGNpOworCW1lbV9saW1pdCA9IG1lbV9iYXNlICsgc2MtPnBjaV9yYW5nZVtBTF9QQ0lfUkFOR0Vf TUVNXS5sZW4gLSAxOworCisJLyogQ29uZmlndXJlIEkvTyBkZWNvZGUgcmVnaXN0ZXJzICovCisJ YWxfcGNpYl93cml0ZV9jb25maWcoc2MtPnNjX2RldiwgYnVzLCBzbG90LCBmdW5jLCBQQ0lSX0lP QkFTRUxfMSwKKwkgICAgaW9fYmFzZSA+PiA4LCAxKTsKKwlhbF9wY2liX3dyaXRlX2NvbmZpZyhz Yy0+c2NfZGV2LCBidXMsIHNsb3QsIGZ1bmMsIFBDSVJfSU9CQVNFSF8xLAorCSAgICBpb19iYXNl ID4+IDE2LCAyKTsKKwlhbF9wY2liX3dyaXRlX2NvbmZpZyhzYy0+c2NfZGV2LCBidXMsIHNsb3Qs IGZ1bmMsIFBDSVJfSU9MSU1JVExfMSwKKwkgICAgaW9fbGltaXQgPj4gOCwgMSk7CisJYWxfcGNp Yl93cml0ZV9jb25maWcoc2MtPnNjX2RldiwgYnVzLCBzbG90LCBmdW5jLCBQQ0lSX0lPTElNSVRI XzEsCisJICAgIGlvX2xpbWl0ID4+IDE2LCAyKTsKKworCS8qIENvbmZpZ3VyZSBtZW1vcnkgZGVj b2RlIHJlZ2lzdGVycyAqLworCWFsX3BjaWJfd3JpdGVfY29uZmlnKHNjLT5zY19kZXYsIGJ1cywg c2xvdCwgZnVuYywgUENJUl9NRU1CQVNFXzEsCisJICAgIG1lbV9iYXNlID4+IDE2LCAyKTsKKwlh bF9wY2liX3dyaXRlX2NvbmZpZyhzYy0+c2NfZGV2LCBidXMsIHNsb3QsIGZ1bmMsIFBDSVJfTUVN TElNSVRfMSwKKwkgICAgbWVtX2xpbWl0ID4+IDE2LCAyKTsKKworCS8qIERpc2FibGUgbWVtb3J5 IHByZWZldGNoIGRlY29kZSAqLworCWFsX3BjaWJfd3JpdGVfY29uZmlnKHNjLT5zY19kZXYsIGJ1 cywgc2xvdCwgZnVuYywgUENJUl9QTUJBU0VMXzEsCisJICAgIDB4MTAsIDIpOworCWFsX3BjaWJf d3JpdGVfY29uZmlnKHNjLT5zY19kZXYsIGJ1cywgc2xvdCwgZnVuYywgUENJUl9QTUJBU0VIXzEs CisJICAgIDB4MCwgNCk7CisJYWxfcGNpYl93cml0ZV9jb25maWcoc2MtPnNjX2RldiwgYnVzLCBz bG90LCBmdW5jLCBQQ0lSX1BNTElNSVRMXzEsCisJICAgIDB4RiwgMik7CisJYWxfcGNpYl93cml0 ZV9jb25maWcoc2MtPnNjX2RldiwgYnVzLCBzbG90LCBmdW5jLCBQQ0lSX1BNTElNSVRIXzEsCisJ ICAgIDB4MCwgNCk7CisKKwlzZWNidXMgPSBhbF9wY2liX3JlYWRfY29uZmlnKHNjLT5zY19kZXYs IGJ1cywgc2xvdCwgZnVuYywKKwkgICAgUENJUl9TRUNCVVNfMSwgMSk7CisKKwkvKiBDb25maWd1 cmUgYnVzZXMgYmVoaW5kIHRoZSBicmlkZ2UgKi8KKwlhbF9wY2liX2luaXQoc2MsIHNlY2J1cywg UENJX1NMT1RNQVgpOworfQorCitzdGF0aWMgaW50CithbF9maW5kX2NhcChkZXZpY2VfdCBjaGls ZCwgdV9pbnQgYnVzLCB1X2ludCBzbG90LCB1X2ludCBmdW5jLAorICAgIGludCBjYXBhYmlsaXR5 LCBpbnQgKmNhcHJlZykKK3sKKwl1aW50MzJfdCBzdGF0dXM7CisJdWludDhfdCBwdHI7CisJdWlu dDE2X3QgaGRydHlwZTsKKworCS8qCisJICogQ2hlY2sgdGhlIENBUF9MSVNUIGJpdCBvZiB0aGUg UENJIHN0YXR1cyByZWdpc3RlciBmaXJzdC4KKwkgKi8KKwlzdGF0dXMgPSBhbF9wY2liX3JlYWRf Y29uZmlnKGNoaWxkLCBidXMsIHNsb3QsIGZ1bmMsIFBDSVJfU1RBVFVTLCAyKTsKKwlpZiAoKHN0 YXR1cyAmIFBDSU1fU1RBVFVTX0NBUFBSRVNFTlQpICE9IFBDSU1fU1RBVFVTX0NBUFBSRVNFTlQp CisJCXJldHVybiAoRU5YSU8pOworCisJaGRydHlwZSA9IGFsX3BjaWJfcmVhZF9jb25maWcoY2hp bGQsIGJ1cywgc2xvdCwgZnVuYywgUENJUl9IRFJUWVBFLCAxKTsKKworCS8qCisJICogRGV0ZXJt aW5lIHRoZSBzdGFydCBwb2ludGVyIG9mIHRoZSBjYXBhYmlsaXRpZXMgbGlzdC4KKwkgKi8KKwlz d2l0Y2ggKGhkcnR5cGUgJiBQQ0lNX0hEUlRZUEUpIHsKKwljYXNlIFBDSU1fSERSVFlQRV9OT1JN QUw6CisJY2FzZSBQQ0lNX0hEUlRZUEVfQlJJREdFOgorCQlwdHIgPSBQQ0lSX0NBUF9QVFI7CisJ CWJyZWFrOworCWNhc2UgUENJTV9IRFJUWVBFX0NBUkRCVVM6CisJCXB0ciA9IFBDSVJfQ0FQX1BU Ul8yOworCQlicmVhazsKKwlkZWZhdWx0OgorCQlkZXZpY2VfcHJpbnRmKGNoaWxkLCAiYWxfZmlu ZF9jYXA6IGludmFsaWQgaGRydHlwZSAleFxuIiwKKwkJICAgIGhkcnR5cGUgJiBQQ0lNX0hEUlRZ UEUpOworCQlyZXR1cm4gKEVOWElPKTsJCS8qIG5vIGV4dGVuZGVkIGNhcGFiaWxpdGllcyBzdXBw b3J0ICovCisJfQorCXB0ciA9IGFsX3BjaWJfcmVhZF9jb25maWcoY2hpbGQsIGJ1cywgc2xvdCwg ZnVuYywgcHRyLCAxKTsKKworCS8qCisJICogVHJhdmVyc2UgdGhlIGNhcGFiaWxpdGllcyBsaXN0 LgorCSAqLworCXdoaWxlIChwdHIgIT0gMCkgeworCQlpZiAoYWxfcGNpYl9yZWFkX2NvbmZpZyhj aGlsZCwgYnVzLCBzbG90LCBmdW5jLAorCQkgICAgcHRyICsgUENJQ0FQX0lELCAxKSA9PSBjYXBh YmlsaXR5KSB7CisJCQlpZiAoY2FwcmVnICE9IE5VTEwpCisJCQkJKmNhcHJlZyA9IHB0cjsKKwkJ CXJldHVybiAoMCk7CisJCX0KKwkJcHRyID0gYWxfcGNpYl9yZWFkX2NvbmZpZyhjaGlsZCwgYnVz LCBzbG90LCBmdW5jLAorCQkgICAgcHRyICsgUENJQ0FQX05FWFRQVFIsIDEpOworCX0KKworCXJl dHVybiAoRU5PRU5UKTsKK30KKworLyoqCisgKiBwY2llX2dldF9tcHMgLSBnZXQgUENJIEV4cHJl c3MgbWF4aW11bSBwYXlsb2FkIHNpemUgY29uZmlndXJlZAorICogQGRldjogUENJIGRldmljZSB0 byBxdWVyeQorICoKKyAqIFJldHVybnMgbWF4aW11bSBwYXlsb2FkIHNpemUgaW4gYnl0ZXMKKyAq ICAgIG9yIGFwcHJvcHJpYXRlIGVycm9yIHZhbHVlLgorICovCitzdGF0aWMgaW50CitwY2llX2dl dF9tcHMoYWxfcGNpYl9zb2Z0YyAqc2MsIGludCBidXMsIGludCBzbG90LCBpbnQgZnVuYykKK3sK Kwl1aW50MTZfdCBjdGw7CisJaW50IHJlZzsKKworCWlmIChhbF9maW5kX2NhcChzYy0+c2NfZGV2 LGJ1cywgc2xvdCwgZnVuYywgUENJWV9FWFBSRVNTLCAmcmVnKSAhPSAwKSB7CisJCWRldmljZV9w cmludGYoc2MtPnNjX2RldiwgIkZhaWVsZCB0byBmaW5kIFBDSVlfRVhQUkVTUyBjYXBcbiIpOwor CQlyZXR1cm4gKDApOworCX0KKworCWN0bCA9IGFsX3BjaWJfcmVhZF9jb25maWcoc2MtPnNjX2Rl diwgYnVzLCBzbG90LCBmdW5jLAorCSAgICByZWcgKyBQQ0lFUl9ERVZJQ0VfQ1RMLCAyKTsKKwor CXJldHVybiAoUENJRV9NSU5fTVBTIDw8ICgoY3RsICYgUENJRU1fQ1RMX01BWF9QQVlMT0FEKSA+ PiA1KSk7Cit9CisKKy8qKgorICogZ2V0X3BjaWVfbWF4X3BheWxvYWQgLSBnZXQgUENJIEV4cHJl c3MgbWF4aW11bSBzdXBwb3J0ZWQgcGF5bG9hZCBzaXplCisgKiBAZGV2OiBQQ0kgZGV2aWNlIHRv IHF1ZXJ5CisgKgorICogUmV0dXJucyBtYXhpbXVtIHBheWxvYWQgc2l6ZSBpbiBieXRlcworICog ICAgb3IgYXBwcm9wcmlhdGUgZXJyb3IgdmFsdWUuCisgKi8KK3N0YXRpYyB1aW50MTZfdAorZ2V0 X3BjaWVfbWF4X3BheWxvYWQoYWxfcGNpYl9zb2Z0YyAqc2MsIGludCBidXMsIGludCBzbG90LCBp bnQgZnVuYykKK3sKKwl1aW50MTZfdCByZWcxNjsKKwlpbnQgcmVnOworCisJaWYgKGFsX2ZpbmRf Y2FwKHNjLT5zY19kZXYsYnVzLCBzbG90LCBmdW5jLCBQQ0lZX0VYUFJFU1MsICZyZWcpICE9IDAp CisJCXJldHVybiAoMCk7CisKKwlyZWcxNiA9IGFsX3BjaWJfcmVhZF9jb25maWcoc2MtPnNjX2Rl diwgYnVzLCBzbG90LAorCSAgICBmdW5jLCByZWcgKyBQQ0lFUl9ERVZJQ0VfQ0FQLCAyKTsKKwly ZXR1cm4gKHJlZzE2ICYgUENJRU1fQ0FQX01BWF9QQVlMT0FEKTsKK30KKworLyoqCisgKiBnZXRf cGNpZV9nZXRfdHlwZSAtIGdldCBQQ0kgRXhwcmVzcyBkZXZpY2UgdHlwZSAoZGV2aWNlIG9yIGJy aWRnZSkKKyAqIEBkZXY6IFBDSSBkZXZpY2UgdG8gcXVlcnkKKyAqCisgKiBSZXR1cm5zIG1heGlt dW0gcGF5bG9hZCBzaXplIGluIGJ5dGVzCisgKiAgICBvciBhcHByb3ByaWF0ZSBlcnJvciB2YWx1 ZS4KKyAqLworc3RhdGljIHVpbnQxNl90CitnZXRfcGNpZV9nZXRfdHlwZShhbF9wY2liX3NvZnRj ICpzYywgaW50IGJ1cywgaW50IHNsb3QsIGludCBmdW5jKQoreworCXVpbnQxNl90IHJlZzE2Owor CWludCByZWc7CisKKwlpZiAoYWxfZmluZF9jYXAoc2MtPnNjX2RldixidXMsIHNsb3QsIGZ1bmMs IFBDSVlfRVhQUkVTUywgJnJlZykgIT0gMCkKKwkJcmV0dXJuICgwKTsKKworCXJlZzE2ID0gYWxf cGNpYl9yZWFkX2NvbmZpZyhzYy0+c2NfZGV2LCBidXMsIHNsb3QsCisJICAgIGZ1bmMsIHJlZyAr IFBDSUVSX0ZMQUdTLCAyKTsKKwlyZXR1cm4gKHJlZzE2ICYgUENJRU1fRkxBR1NfVFlQRSk7Cit9 CisKKy8qKgorICogcGNpZV9zZXRfbXBzIC0gc2V0IFBDSSBFeHByZXNzIG1heGltdW0gcGF5bG9h ZCBzaXplCisgKiBAZGV2OiBQQ0kgZGV2aWNlIHRvIHF1ZXJ5CisgKiBAbXBzOiBtYXhpbXVtIHBh eWxvYWQgc2l6ZSBpbiBieXRlcworICogICAgdmFsaWQgdmFsdWVzIGFyZSAxMjgsIDI1NiwgNTEy LCAxMDI0LCAyMDQ4LCA0MDk2CisgKgorICogSWYgcG9zc2libGUgc2V0cyBtYXhpbXVtIHBheWxv YWQgc2l6ZQorICovCitzdGF0aWMgaW50CitwY2llX3NldF9tcHMoYWxfcGNpYl9zb2Z0YyAqc2Ms IGludCBtcHMsIGludCBidXMsIGludCBzbG90LCBpbnQgZnVuYykKK3sKKwl1aW50MTZfdCB2Owor CWludCByZWc7CisJdWludDE2X3QgdG1wOworCisJaWYgKG1wcyA8IFBDSUVfTUlOX01QUyB8fCBt cHMgPiBQQ0lFX01BWF9NUFMgfHwKKwkgICAgIXBvd2Vyb2YyKG1wcykpCisJCXJldHVybiAoRUZB VUxUKTsKKworCXYgPSBmZnMobXBzKSAtIDg7CisJaWYgKHYgPiBnZXRfcGNpZV9tYXhfcGF5bG9h ZChzYywgYnVzLCBzbG90LCBmdW5jKSkKKwkJcmV0dXJuIChFRkFVTFQpOworCXYgPDw9IFBDSUVN X0NUTF9NQVhfUEFZTE9BRF9FTVBUWV9CSVRTOworCisJaWYgKGFsX2ZpbmRfY2FwKHNjLT5zY19k ZXYsYnVzLCBzbG90LCBmdW5jLCBQQ0lZX0VYUFJFU1MsICZyZWcpICE9IDApCisJCXJldHVybiAo RUZBVUxUKTsKKworCXRtcCA9IGFsX3BjaWJfcmVhZF9jb25maWcoc2MtPnNjX2RldiwgYnVzLCBz bG90LCBmdW5jLAorCSAgICByZWcgKyBQQ0lFUl9ERVZJQ0VfQ1RMLCAyKTsKKwl0bXAgJj0gflBD SUVNX0NUTF9NQVhfUEFZTE9BRDsKKwl0bXAgfD0gKHYgJiBQQ0lFTV9DVExfTUFYX1BBWUxPQUQp OworCWFsX3BjaWJfd3JpdGVfY29uZmlnKHNjLT5zY19kZXYsIGJ1cywgc2xvdCwgZnVuYywKKwkg ICAgcmVnICsgUENJRVJfREVWSUNFX0NUTCwgdG1wLCAyKTsKKworCXJldHVybiAoMCk7Cit9CisK K3N0YXRpYyB2b2lkCitwY2llX3dyaXRlX21wcyhhbF9wY2liX3NvZnRjICpzYywgaW50IG1wcywg aW50IGJ1cywgaW50IHNsb3QsIGludCBmdW5jKQoreworCWludCByYzsKKwlkZXZpY2VfdCBwYXJl bnQ7CisJdWludDE2X3QgdHlwZTsKKworCW1wcyA9IFBDSUVfTUlOX01QUyA8PCBnZXRfcGNpZV9t YXhfcGF5bG9hZChzYywgYnVzLCBzbG90LAorCSAgICBmdW5jKTsKKworCXBhcmVudCA9IGRldmlj ZV9nZXRfcGFyZW50KHNjLT5zY19kZXYpOworCXR5cGUgPSBnZXRfcGNpZV9nZXRfdHlwZShzYywg YnVzLCBzbG90LCBmdW5jKTsKKworCW1wcyA9IG1pbihtcHMsIEFMX01BWF9TVVBQT1JURURfTVBT KTsKKworCXJjID0gcGNpZV9zZXRfbXBzKHNjLCBtcHMsIGJ1cywgc2xvdCwgZnVuYyk7CisJaWYg KHJjICE9IDApCisJCWRldmljZV9wcmludGYoc2MtPnNjX2RldiwKKwkJICAgICJGYWlsZWQgYXR0 ZW1wdGluZyB0byBzZXQgdGhlIE1QUyAlZFxuIiwgbXBzKTsKK30KKworc3RhdGljIHVpbnQxNl90 CitwY2llX2dldF9yZWFkcnEoYWxfcGNpYl9zb2Z0YyAqc2MsIGludCBidXMsIGludCBzbG90LCBp bnQgZnVuYykKK3sKKwl1aW50MTZfdCBjdGw7CisJaW50IHJlZzsKKworCWlmIChhbF9maW5kX2Nh cChzYy0+c2NfZGV2LGJ1cywgc2xvdCwgZnVuYywgUENJWV9FWFBSRVNTLCAmcmVnKSAhPSAwKQor CQlyZXR1cm4gKDApOworCisJY3RsID0gYWxfcGNpYl9yZWFkX2NvbmZpZyhzYy0+c2NfZGV2LCBi dXMsIHNsb3QsIGZ1bmMsCisJICAgIHJlZyArIFBDSUVSX0RFVklDRV9DVEwsIDIpOworCisJcmV0 dXJuIChQQ0lFX01JTl9NUlJTIDw8ICgoY3RsICYgUENJRU1fQ1RMX01BWF9SRUFEX1JFUVVFU1Qp ID4+IDEyKSk7Cit9CisKKy8qKgorICogcGNpZV9zZXRfcmVhZHJxIC0gc2V0IFBDSSBFeHByZXNz IG1heGltdW0gbWVtb3J5IHJlYWQgcmVxdWVzdAorICogQGRldjogUENJIGRldmljZSB0byBxdWVy eQorICogQHJxOiBtYXhpbXVtIG1lbW9yeSByZWFkIGNvdW50IGluIGJ5dGVzCisgKiAgICB2YWxp ZCB2YWx1ZXMgYXJlIDEyOCwgMjU2LCA1MTIsIDEwMjQsIDIwNDgsIDQwOTYKKyAqCisgKiBJZiBw b3NzaWJsZSBzZXRzIG1heGltdW0gbWVtb3J5IHJlYWQgcmVxdWVzdCBpbiBieXRlcworICovCitz dGF0aWMgaW50CitwY2llX3NldF9yZWFkcnEoYWxfcGNpYl9zb2Z0YyAqc2MsIGludCBycSwgaW50 IGJ1cywgaW50IHNsb3QsIGludCBmdW5jKQoreworCXVpbnQxNl90IHY7CisJaW50IG1wczsKKwlp bnQgcmVnOworCXVpbnQxNl90IHRtcDsKKworCWlmIChycSA8IFBDSUVfTUlOX01SUlMgfHwgcnEg PiBQQ0lFX01BWF9NUlJTCisJICAgIHx8ICFwb3dlcm9mMihycSkpCisJCXJldHVybiAoRUlOVkFM KTsKKworCW1wcyA9IHBjaWVfZ2V0X21wcyhzYywgYnVzLCBzbG90LCBmdW5jKTsKKworCWlmICht cHMgPCAwKQorCQlyZXR1cm4gKG1wcyk7CisJaWYgKG1wcyA8IHJxKQorCQlycSA9IG1wczsKKwor CXYgPSAoZmZzKHJxKSAtIDgpIDw8IFBDSUVNX0NUTF9NQVhfUkVBRF9SRVFVRVNUX0VNUFRZX0JJ VFM7CisKKwlpZiAoYWxfZmluZF9jYXAoc2MtPnNjX2RldixidXMsIHNsb3QsIGZ1bmMsIFBDSVlf RVhQUkVTUywgJnJlZykgIT0gMCkKKwkJcmV0dXJuIChFRkFVTFQpOworCisJdG1wID0gYWxfcGNp Yl9yZWFkX2NvbmZpZyhzYy0+c2NfZGV2LCBidXMsIHNsb3QsCisJICAgIGZ1bmMsIHJlZyArIFBD SUVSX0RFVklDRV9DVEwsIDIpOworCXRtcCAmPSB+UENJRU1fQ1RMX01BWF9SRUFEX1JFUVVFU1Q7 CisJdG1wIHw9ICh2ICYgUENJRU1fQ1RMX01BWF9SRUFEX1JFUVVFU1QpOworCWFsX3BjaWJfd3Jp dGVfY29uZmlnKHNjLT5zY19kZXYsIGJ1cywgc2xvdCwKKwkgICAgZnVuYywgcmVnICsgUENJRVJf REVWSUNFX0NUTCwgdG1wLCAyKTsKKworCXJldHVybiAoMCk7Cit9CisKK3N0YXRpYyB2b2lkCitw Y2llX3dyaXRlX21ycnMoYWxfcGNpYl9zb2Z0YyAqc2MsIGludCBidXMsIGludCBzbG90LCBpbnQg ZnVuYykKK3sKKwlpbnQgcmMsIG1ycnM7CisKKwkvKiBGb3IgTWF4IHBlcmZvcm1hbmNlLCB0aGUg TVJSUyBtdXN0IGJlIHNldCB0byB0aGUgbGFyZ2VzdCBzdXBwb3J0ZWQKKwkgKiB2YWx1ZS4gIEhv d2V2ZXIsIGl0IGNhbm5vdCBiZSBjb25maWd1cmVkIGxhcmdlciB0aGFuIHRoZSBNUFMgdGhlCisJ ICogZGV2aWNlIG9yIHRoZSBidXMgY2FuIHN1cHBvcnQuICBUaGlzIHNob3VsZCBhbHJlYWR5IGJl IHByb3Blcmx5CisJICogY29uZmlndXJlZCBieSBhIHByaW9yIGNhbGwgdG8gcGNpZV93cml0ZV9t cHMuCisJICovCisJbXJycyA9IHBjaWVfZ2V0X21wcyhzYywgYnVzLCBzbG90LCBmdW5jKTsKKwor CS8qIE1SUlMgaXMgYSBSL1cgcmVnaXN0ZXIuICBJbnZhbGlkIHZhbHVlcyBjYW4gYmUgd3JpdHRl biwgYnV0IGEKKwkgKiBzdWJzZXF1ZW50IHJlYWQgd2lsbCB2ZXJpZnkgaWYgdGhlIHZhbHVlIGlz IGFjY2VwdGFibGUgb3Igbm90LgorCSAqIElmIHRoZSBNUlJTIHZhbHVlIHByb3ZpZGVkIGlzIG5v dCBhY2NlcHRhYmxlIChlLmcuLCB0b28gbGFyZ2UpLAorCSAqIHNocmluayB0aGUgdmFsdWUgdW50 aWwgaXQgaXMgYWNjZXB0YWJsZSB0byB0aGUgSFcuCisJICovCisJd2hpbGUgKG1ycnMgIT0gcGNp ZV9nZXRfcmVhZHJxKHNjLCBidXMsIHNsb3QsIGZ1bmMpICYmIG1ycnMgPj0gUENJRV9NSU5fTVJS UykgeworCQlyYyA9IHBjaWVfc2V0X3JlYWRycShzYywgbXJycywgYnVzLCBzbG90LCBmdW5jKTsK KwkJaWYgKCFyYykKKwkJCWJyZWFrOworCisJCWRldmljZV9wcmludGYoc2MtPnNjX2RldiwgIkZh aWxlZCBhdHRlbXB0aW5nIHRvIHNldCB0aGUgTVJSU1xuIik7CisJCW1ycnMgLz0gMjsKKwl9CisK KwlpZiAobXJycyA8IFBDSUVfTUlOX01SUlMpCisJCWRldmljZV9wcmludGYoc2MtPnNjX2Rldiwg Ik1SUlMgd2FzIHVuYWJsZSB0byBiZSBjb25maWd1cmVkIHdpdGggYSAiCisJCSAgICAic2FmZSB2 YWx1ZS4gIElmIHByb2JsZW1zIGFyZSBleHBlcmllbmNlZCwgdHJ5IHJ1bm5pbmcgIgorCQkgICAg IndpdGggcGNpPXBjaWVfYnVzX3NhZmUuXG4iKTsKK30KKworc3RhdGljIGludAorcGNpZV9idXNf Y29uZmlndXJlX3NldChhbF9wY2liX3NvZnRjICpzYywgaW50IGJ1cywgaW50IHNsb3QsIGludCBm dW5jLAorICAgIHVpbnQ4X3QgKmRhdGEpCit7CisJaW50IG1wcywgb3JpZ19tcHM7CisKKwltcHMg PSBQQ0lFX01JTl9NUFMgPDwgKih1aW50OF90ICopZGF0YTsKKworCW9yaWdfbXBzID0gcGNpZV9n ZXRfbXBzKHNjLCBidXMsIHNsb3QsIGZ1bmMpOworCisJcGNpZV93cml0ZV9tcHMoc2MsIG1wcywg YnVzLCBzbG90LCBmdW5jKTsKKwlwY2llX3dyaXRlX21ycnMoc2MsIGJ1cywgc2xvdCwgZnVuYyk7 CisKKwlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsCisJICAgICJQQ0ktRSBNYXggUGF5bG9hZCBT aXplIHNldCB0byAlNGQvJTRkICh3YXMgJTRkKSwgIgorCSAgICAiTWF4IFJlYWQgUnEgJTRkXG4i LCBwY2llX2dldF9tcHMoc2MsIGJ1cywgc2xvdCwgZnVuYyksCisJICAgIFBDSUVfTUlOX01QUyA8 PCBnZXRfcGNpZV9tYXhfcGF5bG9hZChzYywgYnVzLCBzbG90LCBmdW5jKSwKKwkgICAgb3JpZ19t cHMsIHBjaWVfZ2V0X3JlYWRycShzYywgYnVzLCBzbG90LCBmdW5jKSk7CisKKwlyZXR1cm4gKDAp OworfQorCitzdGF0aWMgdm9pZAorYWxfcGNpYl9maXh1cChhbF9wY2liX3NvZnRjICpzYywgaW50 IGJ1cywgaW50IHNsb3QsIGludCBmdW5jKQoreworCXVpbnQ4X3Qgc21wc3MgPSAwOworCXVpbnQz Ml90IHZhbDsKKwlwY2llX2J1c19jb25maWd1cmVfc2V0KHNjLCBidXMsIHNsb3QsIGZ1bmMsICZz bXBzcyk7CisKKwkvKiBEbyBub3QgcnVuIGZpeHVwcyBvbiBleHRlcm5hbCBQQ0llIGJ1cyAqLwor CWlmIChidXMgIT0gMCkKKwkJcmV0dXJuOworCisJdmFsID0gYWxfcGNpYl9yZWFkX2NvbmZpZyhz Yy0+c2NfZGV2LCBidXMsIHNsb3QsIGZ1bmMsIEFMX1BDSV9BWElfQ0ZHX0FORF9DVFJfMCwgNCk7 CisJdmFsIHw9IFBDSUVfQVhJX1BGX0FYSV9BVFRSX09WUkRfRlVOQ19DVFJMXzJfUEZfVkVDX1BI X1ZFQ19PVlJEX0ZST01fQVhVU0VSX01BU0s7CisJYWxfcGNpYl93cml0ZV9jb25maWcoc2MtPnNj X2RldiwgYnVzLCBzbG90LCBmdW5jLCBBTF9QQ0lfQVhJX0NGR19BTkRfQ1RSXzAsIHZhbCwgNCk7 CisKKwl2YWwgPSBhbF9wY2liX3JlYWRfY29uZmlnKHNjLT5zY19kZXYsIGJ1cywgc2xvdCwgZnVu YywgQUxfUENJX0FQUF9DT05UUk9MICwgNCk7CisJdmFsICY9IH4weGZmZmY7CisJdmFsIHw9IFBD SUVfQVhJX1BGX0FYSV9BVFRSX09WUkRfRlVOQ19DVFJMXzRfUEZfVkVDX01FTV9BRERSNTRfNjNf U0VMX1ZNSURfTUFTSzsKKwlhbF9wY2liX3dyaXRlX2NvbmZpZyhzYy0+c2NfZGV2LCBidXMsIHNs b3QsIGZ1bmMsIEFMX1BDSV9BUFBfQ09OVFJPTCAsIHZhbCwgNCk7Cit9CisKK3N0YXRpYyBpbnQK K2FsX3BjaWJfaW5pdChhbF9wY2liX3NvZnRjICpzYywgaW50IGJ1cywgaW50IG1heHNsb3QpCit7 CisJaW50IHNsb3QsIGZ1bmMsIG1heGZ1bmMsIGVycm9yOworCXVpbnQ4X3QgaGRydHlwZSwgY29t bWFuZCwgY2xhc3MsIHN1YmNsYXNzOworCWludCBidXNjbnQgPSBzYy0+c2NfYnVzbnI7CisKKwlm b3IgKHNsb3QgPSAwOyBzbG90IDw9IG1heHNsb3Q7IHNsb3QrKykgeworCQltYXhmdW5jID0gMDsK KwkJZm9yIChmdW5jID0gMDsgZnVuYyA8PSBtYXhmdW5jOyBmdW5jKyspIHsKKwkJCWhkcnR5cGUg PSBhbF9wY2liX3JlYWRfY29uZmlnKHNjLT5zY19kZXYsIGJ1cywgc2xvdCwKKwkJCSAgICBmdW5j LCBQQ0lSX0hEUlRZUEUsIDEpOworCisJCQlpZiAoKGhkcnR5cGUgJiBQQ0lNX0hEUlRZUEUpID4g UENJX01BWEhEUlRZUEUpCisJCQkJY29udGludWU7CisKKwkJCWlmIChmdW5jID09IDAgJiYgKGhk cnR5cGUgJiBQQ0lNX01GREVWKSkKKwkJCQltYXhmdW5jID0gUENJX0ZVTkNNQVg7CisKKwkJCWNv bW1hbmQgPSBhbF9wY2liX3JlYWRfY29uZmlnKHNjLT5zY19kZXYsIGJ1cywgc2xvdCwKKwkJCSAg ICBmdW5jLCBQQ0lSX0NPTU1BTkQsIDEpOworCQkJY29tbWFuZCAmPSB+KFBDSU1fQ01EX01FTUVO IHwgUENJTV9DTURfUE9SVEVOKTsKKwkJCWFsX3BjaWJfd3JpdGVfY29uZmlnKHNjLT5zY19kZXYs IGJ1cywgc2xvdCwgZnVuYywKKwkJCSAgICBQQ0lSX0NPTU1BTkQsIGNvbW1hbmQsIDEpOworCisJ CQllcnJvciA9IGFsX3BjaWJfaW5pdF9hbGxfYmFycyhzYywgYnVzLCBzbG90LCBmdW5jLAorCQkJ ICAgIGhkcnR5cGUpOworCisJCQlpZiAoZXJyb3IpCisJCQkJcmV0dXJuIChlcnJvcik7CisKKwkJ CWNvbW1hbmQgfD0gUENJTV9DTURfUE9SVEVOOworCQkJYWxfcGNpYl93cml0ZV9jb25maWcoc2Mt PnNjX2RldiwgYnVzLCBzbG90LCBmdW5jLAorCQkJICAgIFBDSVJfQ09NTUFORCwgY29tbWFuZCwg MSk7CisKKwkJCS8qIEhhbmRsZSBQQ0ktUENJIGJyaWRnZXMgKi8KKwkJCWNsYXNzID0gYWxfcGNp Yl9yZWFkX2NvbmZpZyhzYy0+c2NfZGV2LCBidXMsIHNsb3QsCisJCQkgICAgZnVuYywgUENJUl9D TEFTUywgMSk7CisJCQlzdWJjbGFzcyA9IGFsX3BjaWJfcmVhZF9jb25maWcoc2MtPnNjX2Rldiwg YnVzLCBzbG90LAorCQkJICAgIGZ1bmMsIFBDSVJfU1VCQ0xBU1MsIDEpOworCisJCQlhbF9wY2li X2ZpeHVwKHNjLCBidXMsIHNsb3QsIGZ1bmMpOworCisJCQlpZiAoY2xhc3MgIT0gUENJQ19CUklE R0UgfHwKKwkJCSAgICBzdWJjbGFzcyAhPSBQQ0lTX0JSSURHRV9QQ0kpCisJCQkJY29udGludWU7 CisKKwkJCS8qIFdyaXRlIGFwcHJvcHJpYXRlIGJ1cyBudW1iZXIgKi8KKwkJCWJ1c2NudCsrOwor CQkJYWxfcGNpYl93cml0ZV9jb25maWcoc2MtPnNjX2RldiwgYnVzLDAsMCwKKwkJCSAgICBQQ0lS X1NFQ0JVU18xLCBidXNjbnQsIDEpOworCQkJYWxfcGNpYl93cml0ZV9jb25maWcoc2MtPnNjX2Rl diwgYnVzLDAsMCwKKwkJCSAgICBQQ0lSX1NVQkJVU18xLCBidXNjbnQsIDEpOworCisJCQlhbF9w Y2liX2luaXRfYnJpZGdlKHNjLCBidXMsIHNsb3QsIGZ1bmMpOworCQl9CisJfQorCisJcmV0dXJu ICgwKTsKK30KKworc3RhdGljIHZvaWQKK2FsX3BjaWJfZW5hYmxlKGFsX3BjaWJfc29mdGMgKnNj KQoreworCXVpbnQzMl90IHZhbDsKKworCS8qCisJICogRW5hYmxlIFBDSSBicmlkZ2UuCisJICov CisJdmFsID0gYWxfcGNpYl9yZWFkX2NvbmZpZyhzYy0+c2NfZGV2LCBzYy0+c2NfYnVzbnIsIDAs IDAsCisJICAgIFBDSVJfQ09NTUFORCwgNCk7CisJdmFsIHw9IFBDSU1fQ01EX1NFUlJFU1BFTiB8 IFBDSU1fQ01EX0JVU01BU1RFUkVOIHwKKwkgICAgUENJTV9DTURfTUVNRU4gfCBQQ0lNX0NNRF9Q T1JURU47CisJYWxfcGNpYl93cml0ZV9jb25maWcoc2MtPnNjX2Rldiwgc2MtPnNjX2J1c25yLCAw LCAwLAorCSAgICBQQ0lSX0NPTU1BTkQsIHZhbCwgNCk7Cit9CisKK3N0YXRpYyBpbnQKK2FsX3Bj aWJfYXR0YWNoKGRldmljZV90IGRldikKK3sKKwlhbF9wY2liX3NvZnRjCSpzYzsKKwlwaGFuZGxl X3QJbm9kZTsKKwlpbnQJCXJldDsKKwl1aW50NjRfdAlyZWdfYmFzZTsKKwl1aW50NjRfdAlyZWdf c2l6ZTsKKworCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCW5vZGUgPSBvZndfYnVzX2dl dF9ub2RlKGRldik7CisJc2MtPnNjX2RldiA9IGRldjsKKwlzYy0+c2NfYnVzbnIgPSBkZXZpY2Vf Z2V0X3VuaXQoZGV2KTsKKwlzYy0+aW5kZXggPSBkZXZpY2VfZ2V0X3VuaXQoZGV2KTsKKwlzYy0+ c2NfdHlwZSA9IG9md19idXNfc2VhcmNoX2NvbXBhdGlibGUoZGV2LCBjb21wYXRfZGF0YSktPm9j ZF9kYXRhOworCisJbXR4X2luaXQoJnNjLT5jb25mX2xvY2ssICJBTFBDSUNGRyIsIE5VTEwsIE1U WF9ERUYpOworCisJLyogTWFwIHJlZ2lzdGVyIHNwYWNlICovCisJcmVnX2Jhc2UgPSAwOworCXJl Z19zaXplID0gMDsKKwlyZXQgPSBmZHRfcmVnc2l6ZShub2RlLCAodV9sb25nKikmcmVnX2Jhc2Us ICh1X2xvbmcqKSZyZWdfc2l6ZSk7CisJaWYgKHJldCA9PSAwICYmIHJlZ19zaXplID4gMCkgewor CQlkZXZpY2VfcHJpbnRmKGRldiwgInJlZ2lzdGVyIGJhc2UgPSAweCVsbHgsIHNpemUgPSAweCVs eFxuIiwKKwkJICAgIHJlZ19iYXNlLCAodV9sb25nKXJlZ19zaXplKTsKKwkJcmV0ID0gYnVzX3Nw YWNlX21hcChmZHRidXNfYnNfdGFnLCAoYnVzX2FkZHJfdClyZWdfYmFzZSwKKwkJICAgIChidXNf c2l6ZV90KXJlZ19zaXplLCAwLCAmc2MtPnJlZ19oYW5kbGUpOworCQlpZiAocmV0KSB7CisJCQlk ZXZpY2VfcHJpbnRmKGRldiwgIkZhaWxlZCB0byBtYXAgcmVnaXN0ZXIgc3BhY2VcbiIpOworCQkJ cmV0dXJuIChFRkFVTFQpOworCQl9CisJfQorCisJLyogTWFwIFBDSSByZWdpb25zICovCisJcmV0 ID0gYWxfZmR0X3BjaV9yYW5nZXNfZGVjb2RlKG5vZGUsICZzYy0+cGNpX3JhbmdlW0FMX1BDSV9S QU5HRV9CUklER0VdLAorCSAgICAmc2MtPnBjaV9yYW5nZVtBTF9QQ0lfUkFOR0VfSU9dLCAmc2Mt PnBjaV9yYW5nZVtBTF9QQ0lfUkFOR0VfTUVNXSk7CisJaWYgKHJldCkgeworCQlkZXZpY2VfcHJp bnRmKGRldiwgIkRlY29kZSBQQ0kgcmFuZ2VzIGZhaWxlZCwgcmV0PSVkXG4iLCByZXQpOworCQly ZXR1cm4gKEVGQVVMVCk7CisJfQorCisJLyogR2V0IFBDSSBpbnRlcnJ1cHQgaW5mby4gKi8KKwlv ZndfYnVzX3NldHVwX2lpbmZvKG5vZGUsICZzYy0+c2NfcGNpX2lpbmZvLCBzaXplb2YocGNlbGxf dCkpOworCisJaWYgKGJvb3R2ZXJib3NlKSB7CisJCWRldmljZV9wcmludGYoZGV2LAorCQkgICAg ImJyaWRnZSBzcGFjZTogYmFzZV9wYXJlbnQgPSAweCVseCwgYmFzZV9wY2kgPSAweCVseCAiCisJ CSAgICAibGVuID0gJWx4XG4iLCBzYy0+cGNpX3JhbmdlW0FMX1BDSV9SQU5HRV9CUklER0VdLmJh c2VfcGFyZW50LAorCQkgICAgc2MtPnBjaV9yYW5nZVtBTF9QQ0lfUkFOR0VfQlJJREdFXS5iYXNl X3BjaSwKKwkJICAgIHNjLT5wY2lfcmFuZ2VbQUxfUENJX1JBTkdFX0JSSURHRV0ubGVuKTsKKwkJ ZGV2aWNlX3ByaW50ZihkZXYsCisJCSAgICAibWVtb3J5IHNwYWNlOiBiYXNlX3BhcmVudCA9IDB4 JWx4LCBiYXNlX3BjaSA9IDB4JWx4ICIKKwkJICAgICJsZW4gPSAlbHhcbiIsIHNjLT5wY2lfcmFu Z2VbQUxfUENJX1JBTkdFX01FTV0uYmFzZV9wYXJlbnQsCisJCSAgICBzYy0+cGNpX3JhbmdlW0FM X1BDSV9SQU5HRV9NRU1dLmJhc2VfcGNpLAorCQkgICAgc2MtPnBjaV9yYW5nZVtBTF9QQ0lfUkFO R0VfTUVNXS5sZW4pOworCQlkZXZpY2VfcHJpbnRmKGRldiwKKwkJICAgICJJTyBzcGFjZTogYmFz ZV9wYXJlbnQgPSAweCVseCwgYmFzZV9wY2kgPSAweCVseCAiCisJCSAgICAibGVuID0gJWx4XG4i LCBzYy0+cGNpX3JhbmdlW0FMX1BDSV9SQU5HRV9JT10uYmFzZV9wYXJlbnQsCisJCSAgICBzYy0+ cGNpX3JhbmdlW0FMX1BDSV9SQU5HRV9JT10uYmFzZV9wY2ksCisJCSAgICBzYy0+cGNpX3Jhbmdl W0FMX1BDSV9SQU5HRV9JT10ubGVuKTsKKwl9CisKKwlpZiAoYnVzX3NwYWNlX21hcChmZHRidXNf YnNfdGFnLAorCSAgICBzYy0+cGNpX3JhbmdlW0FMX1BDSV9SQU5HRV9CUklER0VdLmJhc2VfcGFy ZW50LAorCSAgICBzYy0+cGNpX3JhbmdlW0FMX1BDSV9SQU5HRV9CUklER0VdLmxlbiwgMCwgJnNj LT5lY2FtX2hhbmRsZSkpIHsKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJGYWlsZWQgdG8gbWFwIGJy aWRnZSBidXMgYWRkcmVzc1xuIik7CisJCXJldHVybiAoRUZBVUxUKTsKKwl9CisKKwlpZiAoYm9v dHZlcmJvc2UpCisJCWRldmljZV9wcmludGYoZGV2LCAiZWNhbV9iYWRkciA9IDB4JXBcbiIsCisJ CSAgICAodm9pZCopc2MtPmVjYW1faGFuZGxlKTsKKworCXJldCA9IGFsX3BjaWVfZW5hYmxlX2Nv bnRyb2xsZXIoc2MpOworCWlmIChyZXQpIHsKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJGYWlsZWQg dG8gZW5hYmxlIFBDSUUgY29udHJvbGxlclxuIik7CisJCXJldHVybiAoRUZBVUxUKTsKKwl9CisK KwlyZXQgPSBhbF9wY2llX3BvcnRfY2hlY2tfbGluayhzYyk7CisJaWYgKHJldCA9PSAwKSB7CisJ CWRldmljZV9wcmludGYoZGV2LCAiRmFpbGVkIHRvIGNoZWNrIGxpbmtcbiIpOworCQlyZXR1cm4g KEVGQVVMVCk7CisJfQorCisJcmV0ID0gYWxfcGNpZV9jZmdfcHJlcGFyZShzYyk7CisJaWYgKHJl dCkgeworCQlkZXZpY2VfcHJpbnRmKGRldiwgIkZhaWxlZCB0byBwcmVwYXJlIGNvbmZpZ1xuIik7 CisJCXJldHVybiAoRUZBVUxUKTsKKwl9CisKKwlyZXQgPSBhbF9wY2llX2lvX3ByZXBhcmUoc2Mp OworCWlmIChyZXQpIHsKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJGYWlsZWQgdG8gcHJlcGFyZSBJ T1xuIik7CisJCXJldHVybiAoRUZBVUxUKTsKKwl9CisKKwkvKiBDb25maWd1cmUgSU9DQyBmb3Ig ZXh0ZXJuYWwgUENJRSAqLworCWlmIChzYy0+c2NfdHlwZSAhPSBBTF9QQ0lfVFlQRV9JTlRFUk5B TCkgeworCQlhbF9wY2llX3BvcnRfc25vb3BfY29uZmlnKCZzYy0+cGNpZV9wb3J0LCAxKTsKKwkJ YWxfcGNpYl9lbmFibGUoc2MpOworCX0KKworCXJldCA9IGFsX3BjaWJfbWVtX2luaXQoc2MpOwor CWlmIChyZXQpIHsKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJGYWlsZWQgdG8gYWxfcGNpYl9tZW1f aW5pdFxuIik7CisJCXJldHVybiAoRUZBVUxUKTsKKwl9CisKKwlyZXQgPSBhbF9wY2liX2luaXQo c2MsIHNjLT5zY19idXNuciwKKwkgICAgYWxfcGNpYl9tYXhzbG90cyhzYy0+c2NfZGV2KSk7CisJ aWYgKHJldCkKKwkJcmV0dXJuIHJldDsKKworCWRldmljZV9hZGRfY2hpbGQoZGV2LCAicGNpIiwg LTEpOworCisJcmV0dXJuIChidXNfZ2VuZXJpY19hdHRhY2goZGV2KSk7Cit9CisKK3N0YXRpYyBz dHJ1Y3QgcmVzb3VyY2UgKgorYWxfcGNpYl9hbGxvY19yZXNvdXJjZShkZXZpY2VfdCBkZXYsIGRl dmljZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50ICpyaWQsCisgICAgdV9sb25nIHN0YXJ0LCB1X2xv bmcgZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKQoreworCWFsX3BjaWJfc29mdGMgKnNj ID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCXN0cnVjdCBybWFuICpybSA9IE5VTEw7CisJc3Ry dWN0IHJlc291cmNlICpyZXM7CisJdV9sb25nIGJ1c19zdGFydCA9IDAsIGJ1c19zaXplID0gMDsK KworCWlmIChib290dmVyYm9zZSkKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJhbF9wY2liX2FsbG9j X3Jlc291cmNlIGJlZ2luLCBzdGFydD0weCVseCwgIgorCQkgICAgImVuZD0weCVseCwgY291bnQ9 MHglbHgsIHR5cGU9JWRcbiIsCisJCSAgICBzdGFydCwgZW5kLCBjb3VudCwgdHlwZSk7CisKKwlz d2l0Y2ggKHR5cGUpIHsKKwljYXNlIFNZU19SRVNfSU9QT1JUOgorCQlybSA9ICZzYy0+c2NfaW9f cm1hbjsKKwkJYnVzX3N0YXJ0ID0gc2MtPnBjaV9yYW5nZVtBTF9QQ0lfUkFOR0VfSU9dLmJhc2Vf cGNpOworCQlidXNfc2l6ZSA9IHNjLT5wY2lfcmFuZ2VbQUxfUENJX1JBTkdFX0lPXS5sZW47CisJ CWJyZWFrOworCWNhc2UgU1lTX1JFU19NRU1PUlk6CisJCXJtID0gJnNjLT5zY19tZW1fcm1hbjsK KwkJYnVzX3N0YXJ0ID0gc2MtPnBjaV9yYW5nZVtBTF9QQ0lfUkFOR0VfTUVNXS5iYXNlX3BjaTsK KwkJYnVzX3NpemUgPSBzYy0+cGNpX3JhbmdlW0FMX1BDSV9SQU5HRV9NRU1dLmxlbjsKKwkJYnJl YWs7CisJZGVmYXVsdDoKKwkJcmV0dXJuIChCVVNfQUxMT0NfUkVTT1VSQ0UoZGV2aWNlX2dldF9w YXJlbnQoZGV2KSwgZGV2LAorCQkJdHlwZSwgcmlkLCBzdGFydCwgZW5kLCBjb3VudCwgZmxhZ3Mp KTsKKwl9OworCisJaWYgKChzdGFydCA9PSAwVUwpICYmIChlbmQgPT0gfjBVTCkpIHsKKwkJc3Rh cnQgPSBidXNfc3RhcnQ7CisJCWVuZCA9IGJ1c19zdGFydCArIGJ1c19zaXplIC0gMTsKKwkJY291 bnQgPSBidXNfc2l6ZTsKKwl9CisKKwlpZiAoKHN0YXJ0IDwgYnVzX3N0YXJ0KSB8fCAoc3RhcnQg KyBjb3VudCAtIDEgIT0gZW5kKSB8fAorCQkoZW5kID4gYnVzX3N0YXJ0ICsgYnVzX3NpemUgLSAx KSkgeworCQlkZXZpY2VfcHJpbnRmKGRldiwgInJhbmdlIGZhaWxlZFxuIik7CisJCXJldHVybiAo TlVMTCk7CisJfQorCisJcmVzID0gcm1hbl9yZXNlcnZlX3Jlc291cmNlKHJtLCBzdGFydCwgZW5k LCBjb3VudCwgZmxhZ3MsIGNoaWxkKTsKKwlpZiAocmVzID09IE5VTEwpIHsKKwkJZGV2aWNlX3By aW50ZihkZXYsICJybWFuX3Jlc2VydmVfcmVzb3VyY2UgZmFpbGVkXG4iKTsKKwkJcmV0dXJuIChO VUxMKTsKKwl9CisKKwlybWFuX3NldF9yaWQocmVzLCAqcmlkKTsKKwlybWFuX3NldF9idXN0YWco cmVzLCBmZHRidXNfYnNfdGFnKTsKKwlybWFuX3NldF9idXNoYW5kbGUocmVzLCBzdGFydCk7CisK KwlpZiAoZmxhZ3MgJiBSRl9BQ1RJVkUpCisJCWlmIChidXNfYWN0aXZhdGVfcmVzb3VyY2UoY2hp bGQsIHR5cGUsICpyaWQsIHJlcykpIHsKKwkJCXJtYW5fcmVsZWFzZV9yZXNvdXJjZShyZXMpOwor CQkJZGV2aWNlX3ByaW50ZihkZXYsICJidXNfYWN0aXZhdGVfcmVzb3VyY2UgZmFpbGVkXG4iKTsK KwkJCXJldHVybiAoTlVMTCk7CisJCX0KKworCXJldHVybiAocmVzKTsKK30KKworc3RhdGljIGlu dAorYWxfcGNpYl9yZWxlYXNlX3Jlc291cmNlKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQs IGludCB0eXBlLCBpbnQgcmlkLAorICAgIHN0cnVjdCByZXNvdXJjZSAqcmVzKQoreworCisJcmV0 dXJuICgwKTsKK30KKworc3RhdGljIGludAorYWxfcGNpYl9yZWFkX2l2YXIoZGV2aWNlX3QgZGV2 LCBkZXZpY2VfdCBjaGlsZCwgaW50IHdoaWNoLCB1aW50cHRyX3QgKnJlc3VsdCkKK3sKKwlhbF9w Y2liX3NvZnRjICpzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKKworCXN3aXRjaCAod2hpY2gp IHsKKwljYXNlIFBDSUJfSVZBUl9CVVM6CisJCSpyZXN1bHQgPSBzYy0+c2NfYnVzbnI7CisJCXJl dHVybiAoMCk7CisJY2FzZSBQQ0lCX0lWQVJfRE9NQUlOOgorCQkqcmVzdWx0ID0gZGV2aWNlX2dl dF91bml0KGRldik7CisJCXJldHVybiAoMCk7CisJfQorCisJcmV0dXJuIChFTk9FTlQpOworfQor CitzdGF0aWMgaW50CithbF9wY2liX3dyaXRlX2l2YXIoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBj aGlsZCwgaW50IHdoaWNoLCB1aW50cHRyX3QgdmFsdWUpCit7CisJYWxfcGNpYl9zb2Z0YyAqc2Mg PSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisKKwlzd2l0Y2ggKHdoaWNoKSB7CisJY2FzZSBQQ0lC X0lWQVJfQlVTOgorCQlzYy0+c2NfYnVzbnIgPSB2YWx1ZTsKKwkJcmV0dXJuICgwKTsKKwl9CisK KwlyZXR1cm4gKEVOT0VOVCk7Cit9CisKK3N0YXRpYyBpbnQKK2FsX3BjaWJfbWF4c2xvdHMoZGV2 aWNlX3QgZGV2KQoreworCisJcmV0dXJuIChBTF9QQ0lfTUFYX1NMT1RTKTsKK30KKworc3RhdGlj IHVpbnQzMl90CithbF9wY2liX3JlYWRfY29uZmlnKGRldmljZV90IGRldiwgdV9pbnQgYnVzLCB1 X2ludCBzbG90LCB1X2ludCBmdW5jLAorICAgIHVfaW50IHJlZywgaW50IGJ5dGVzKQoreworCWJ1 c19hZGRyX3QgYWRkcjsKKwl1aW50MzJfdCB2YWwgPSAweGZmZmZmZmZmOworCWFsX3BjaWJfc29m dGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCWJ1c19hZGRyX3QgaGFuZGxlID0gMDsK KwlpbnQgcmV0OworCisJbXR4X2xvY2soJnNjLT5jb25mX2xvY2spOworCisJcmV0ID0gYWxfcGNp ZV9jZmdfYWRkcihkZXYsIGJ1cywgc2xvdCwgZnVuYywKKwkgICAgcmVnICYgfkNPTkZJR19BRERS RVNTX1pFUk9fQklUU19NQVNLLCBieXRlcywgJmhhbmRsZSwgJmFkZHIpOworCisJaWYgKHJldCkK KwkJZ290byBlbmQ7CisKKwl2YWwgPSBidXNfc3BhY2VfcmVhZF80KGZkdGJ1c19ic190YWcsIGhh bmRsZSwgYWRkcik7CisJc3dpdGNoIChieXRlcykgeworCWNhc2UgMToKKwkJdmFsID0gKHZhbCA+ PiAoKHJlZyAmIENPTkZJR19BRERSRVNTX0JZVEVfU0VMRUNUT1JfTUFTSykgKiBOQkJZKSkgJiAw eGZmOworCQlicmVhazsKKwljYXNlIDI6CisJCXZhbCA9ICh2YWwgPj4gKChyZWcgJiBDT05GSUdf QUREUkVTU19CWVRFX1NFTEVDVE9SX01BU0spICogTkJCWSkpICYgMHhmZmZmOworCQlicmVhazsK KwlkZWZhdWx0OgorCQlicmVhazsKKwl9CisKK2VuZDoKKwltdHhfdW5sb2NrKCZzYy0+Y29uZl9s b2NrKTsKKworCWlmIChib290dmVyYm9zZSkKKwkJZGV2aWNlX3ByaW50ZihzYy0+c2NfZGV2LAor CQkgICAgImFsX3BjaWJfcmVhZF9jb25maWcgYmVnaW4gYWRkcj0lcCBidXM9JWQsIHNsb3Q9JWQs ICIKKwkJICAgICJmdW5jPSVkIHJlZz0lZCBieXRlcz0lZCB2YWw9JXhcbiIsCisJCSAgICAodm9p ZCopYWRkciwgYnVzLCBzbG90LCBmdW5jLCByZWcsIGJ5dGVzLCB2YWwpOworCisJcmV0dXJuICh2 YWwpOworfQorCitzdGF0aWMgdm9pZAorYWxfcGNpYl93cml0ZV9jb25maWcoZGV2aWNlX3QgZGV2 LCB1X2ludCBidXMsIHVfaW50IHNsb3QsIHVfaW50IGZ1bmMsCisgICAgdV9pbnQgcmVnLCB1aW50 MzJfdCB2YWwsIGludCBieXRlcykKK3sKKwlidXNfYWRkcl90IGFkZHI7CisJYWxfcGNpYl9zb2Z0 YyAqc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJYnVzX2FkZHJfdCBoYW5kbGUgPSAwOwor CWludCByZXQ7CisKKwltdHhfbG9jaygmc2MtPmNvbmZfbG9jayk7CisKKwlyZXQgPSBhbF9wY2ll X2NmZ19hZGRyKGRldiwgYnVzLCBzbG90LCBmdW5jLCByZWcsCisJICAgIGJ5dGVzLCAmaGFuZGxl LCAmYWRkcik7CisJaWYgKHJldCkKKwkJZ290byBlbmQ7CisKKwlzd2l0Y2ggKGJ5dGVzKSB7CisJ Y2FzZSAxOgorCQlidXNfc3BhY2Vfd3JpdGVfMShmZHRidXNfYnNfdGFnLCBoYW5kbGUsIGFkZHIs CisJCSAgICAodWludDhfdCl2YWwpOworCQlicmVhazsKKwljYXNlIDI6CisJCWJ1c19zcGFjZV93 cml0ZV8yKGZkdGJ1c19ic190YWcsIGhhbmRsZSwgYWRkciwKKwkJICAgICh1aW50MTZfdCl2YWwp OworCQlicmVhazsKKwljYXNlIDQ6CisJCWJ1c19zcGFjZV93cml0ZV80KGZkdGJ1c19ic190YWcs IGhhbmRsZSwgYWRkciwKKwkJICAgICh1aW50MzJfdCl2YWwpOworCQlicmVhazsKKwlkZWZhdWx0 OgorCQlicmVhazsKKwl9CisKK2VuZDoKKwltdHhfdW5sb2NrKCZzYy0+Y29uZl9sb2NrKTsKKwor CWlmIChib290dmVyYm9zZSkKKwkJZGV2aWNlX3ByaW50ZihzYy0+c2NfZGV2LAorCQkgICAgImFs X3BjaWJfd3JpdGVfY29uZmlnIGJlZ2luIGFkZHI9JXAgYnVzPSVkLCBzbG90PSVkLCAiCisJCSAg ICAiZnVuYz0lZCByZWc9JWQgYnl0ZXM9JWQgdmFsPSV4XG4iLAorCQkgICAgKHZvaWQqKWFkZHIs IGJ1cywgc2xvdCwgZnVuYywgcmVnLCBieXRlcywgdmFsKTsKKworCXJldHVybjsKK30KKworc3Rh dGljIGludAorYWxfcGNpYl9yb3V0ZV9pbnRlcnJ1cHQoZGV2aWNlX3QgcGNpYiwgZGV2aWNlX3Qg ZGV2LCBpbnQgcGluKQoreworCWFsX3BjaWJfc29mdGMgKnNjOworCXN0cnVjdCBvZndfcGNpX3Jl Z2lzdGVyIHJlZzsKKwl1aW50MzJfdCBwaW50ciwgbWludHJbNF07CisJaW50IGljZWxsczsKKwlw aGFuZGxlX3QgaXBhcmVudDsKKworCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhwY2liKTsKKwlwaW50 ciA9IHBpbjsKKworCS8qIEZhYnJpY2F0ZSBpbWFwIGluZm9ybWF0aW9uIGluIGNhc2UgdGhpcyBp c24ndCBhbiBPRlcgZGV2aWNlICovCisJYnplcm8oJnJlZywgc2l6ZW9mKHJlZykpOworCXJlZy5w aHlzX2hpID0gKHBjaV9nZXRfYnVzKGRldikgPDwgT0ZXX1BDSV9QSFlTX0hJX0JVU1NISUZUKSB8 CisJICAgIChwY2lfZ2V0X3Nsb3QoZGV2KSA8PCBPRldfUENJX1BIWVNfSElfREVWSUNFU0hJRlQp IHwKKwkgICAgKHBjaV9nZXRfZnVuY3Rpb24oZGV2KSA8PCBPRldfUENJX1BIWVNfSElfRlVOQ1RJ T05TSElGVCk7CisKKwlpY2VsbHMgPSBvZndfYnVzX2xvb2t1cF9pbWFwKG9md19idXNfZ2V0X25v ZGUoZGV2KSwgJnNjLT5zY19wY2lfaWluZm8sCisJICAgICZyZWcsIHNpemVvZihyZWcpLCAmcGlu dHIsIHNpemVvZihwaW50ciksIG1pbnRyLCBzaXplb2YobWludHIpLAorCSAgICAmaXBhcmVudCk7 CisJaWYgKGljZWxscyA+IDApCisJCXJldHVybiAob2Z3X2J1c19tYXBfaW50cihkZXYsIGlwYXJl bnQsIGljZWxscywgbWludHIpKTsKKworCS8qIE1heWJlIGl0J3MgYSByZWFsIGludGVycnVwdCwg bm90IGFuIGludHBpbiAqLworCWlmIChwaW4gPiA0KQorCQlyZXR1cm4gKHBpbik7CisKKwlkZXZp Y2VfcHJpbnRmKHBjaWIsICJjb3VsZCBub3Qgcm91dGUgcGluICVkIGZvciBkZXZpY2UgJWQuJWRc biIsCisJICAgIHBpbiwgcGNpX2dldF9zbG90KGRldiksIHBjaV9nZXRfZnVuY3Rpb24oZGV2KSk7 CisJcmV0dXJuIChQQ0lfSU5WQUxJRF9JUlEpOworfQorCgo= --b1_5b195ef0c6e36ed87c42d297273477fd-- From owner-freebsd-arm@FreeBSD.ORG Tue May 19 09:36:18 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30D1F6CF for ; Tue, 19 May 2015 09:36:18 +0000 (UTC) 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 1B5C71985 for ; Tue, 19 May 2015 09:36:18 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4J9aHxv085966 for ; Tue, 19 May 2015 09:36:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200287] audio/festival: fails to build on armv6 Date: Tue, 19 May 2015 09:36:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marino@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: mi@ALDAN.algebra.com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: assigned_to 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: Tue, 19 May 2015 09:36:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200287 John Marino changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-ports-bugs@FreeBSD. |mi@ALDAN.algebra.com |org | -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 09:39:47 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5905C934 for ; Tue, 19 May 2015 09:39:47 +0000 (UTC) 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 432E71A21 for ; Tue, 19 May 2015 09:39:47 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4J9dlWn087174 for ; Tue, 19 May 2015 09:39:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200102] lang/ocaml fails to build on armv6 Date: Tue, 19 May 2015 09:39:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marino@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: cc 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: Tue, 19 May 2015 09:39:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200102 John Marino changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marino@FreeBSD.org --- Comment #3 from John Marino --- Is this PR still valid? If so, do the patches still apply? Can any obsolete patch be marked "obsolete" so they don't confused others? -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 09:52:52 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 517D3FA2 for ; Tue, 19 May 2015 09:52:52 +0000 (UTC) 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 3B7451CF1 for ; Tue, 19 May 2015 09:52:52 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4J9qqQq003788 for ; Tue, 19 May 2015 09:52:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200102] lang/ocaml fails to build on armv6 Date: Tue, 19 May 2015 09:52:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mikael.urankar@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: attachments.isobsolete 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: Tue, 19 May 2015 09:52:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200102 mikael.urankar@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #156613|0 |1 is obsolete| | -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 09:53:37 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B126B6 for ; Tue, 19 May 2015 09:53:37 +0000 (UTC) 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 752DD1D02 for ; Tue, 19 May 2015 09:53:37 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4J9rbgS003999 for ; Tue, 19 May 2015 09:53:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200102] lang/ocaml fails to build on armv6 Date: Tue, 19 May 2015 09:53:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mikael.urankar@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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: Tue, 19 May 2015 09:53:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200102 --- Comment #4 from mikael.urankar@gmail.com --- Yes this PR is still valid. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 09:55:45 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F0FF334 for ; Tue, 19 May 2015 09:55:45 +0000 (UTC) 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 0981F1D40 for ; Tue, 19 May 2015 09:55:45 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4J9titM005263 for ; Tue, 19 May 2015 09:55:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200102] lang/ocaml fails to build on armv6 Date: Tue, 19 May 2015 09:55:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marino@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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: Tue, 19 May 2015 09:55:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200102 --- Comment #5 from John Marino --- It took 1 second of looking at the PR to realize that patch will not apply. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 10:15:14 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1EB1180 for ; Tue, 19 May 2015 10:15:14 +0000 (UTC) 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 0973012D4 for ; Tue, 19 May 2015 10:15:14 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JAFDEm056073 for ; Tue, 19 May 2015 10:15:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200099] net/pvm fails to build on armv6 Date: Tue, 19 May 2015 10:15:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Tue, 19 May 2015 10:15:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200099 --- Comment #2 from commit-hook@freebsd.org --- A commit references this bug: Author: marino Date: Tue May 19 10:14:57 UTC 2015 New revision: 386762 URL: https://svnweb.freebsd.org/changeset/ports/386762 Log: net/pvm3: Fix build on armv6 PR: 200099 Submitted by: Mikael Urankar Changes: head/net/pvm/files/patch-pvmgetarch -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 10:16:33 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6C2B124 for ; Tue, 19 May 2015 10:16:33 +0000 (UTC) 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 C0DD112ED for ; Tue, 19 May 2015 10:16:33 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JAGXIt056826 for ; Tue, 19 May 2015 10:16:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200099] net/pvm fails to build on armv6 Date: Tue, 19 May 2015 10:16:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marino@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution cc 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: Tue, 19 May 2015 10:16:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200099 John Marino changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED CC| |marino@FreeBSD.org --- Comment #3 from John Marino --- This was just a patch to a patch. When I regenerated the patch, it didn't match. The offsets were different. So next time it's better to regenerate the patch. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 12:39:00 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F13EA248 for ; Tue, 19 May 2015 12:39:00 +0000 (UTC) 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 DBC091453 for ; Tue, 19 May 2015 12:39:00 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JCd0Zn081287 for ; Tue, 19 May 2015 12:39:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200102] lang/ocaml fails to build on armv6 Date: Tue, 19 May 2015 12:39:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mikael.urankar@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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: Tue, 19 May 2015 12:39:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200102 --- Comment #6 from mikael.urankar@gmail.com --- Hi John, As you can see, I've opened the PR the 2015-05-10 and you have updated lang/ocaml the 2015-05-13 (r386233). You're commit 'broke' my first patch and I've forgotten to update my ports tree before submitting the second one so I agree with you my patch doesn't apply now. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 12:42:25 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52B7D4A4 for ; Tue, 19 May 2015 12:42:25 +0000 (UTC) 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 3D5681566 for ; Tue, 19 May 2015 12:42:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JCgPMN060205 for ; Tue, 19 May 2015 12:42:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200102] lang/ocaml fails to build on armv6 Date: Tue, 19 May 2015 12:42:25 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marino@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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: Tue, 19 May 2015 12:42:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200102 --- Comment #7 from John Marino --- but I did ask you if it still applied today. You didn't answer that but rather the other part of the question, so you reasonably implied it did still apply. In any case, the patch needs an update. (or somebody needs to see the intent and do it manually as it is not hard to do that) -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 13:01:18 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92953950 for ; Tue, 19 May 2015 13:01:18 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 7744B1719 for ; Tue, 19 May 2015 13:01:18 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JD1IHj015764 for ; Tue, 19 May 2015 13:01:18 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4JD1I2s015763; Tue, 19 May 2015 13:01:18 GMT (envelope-from daemon-user) Date: Tue, 19 May 2015 13:01:18 +0000 To: freebsd-arm@freebsd.org From: "andrew (Andrew Turner)" Subject: [Differential] [Updated] D2579: PCI support for Alpine platform from Annapurna Labs Message-ID: <710c664cf05eb310be96af7f8827b4d1@localhost.localdomain> X-Priority: 3 Thread-Topic: D2579: PCI support for Alpine platform from Annapurna Labs X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NjYxMzQxMmI2MjBmNTRlMzhjMzBkMTMzMmNhIFVbNB4= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" 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: Tue, 19 May 2015 13:01:18 -0000 andrew added a comment. This is from my first pass over the driver. INLINE COMMENTS sys/arm/annapurna/alpine/alpine_pci.c:247 When would not be defined? sys/arm/annapurna/alpine/alpine_pci.c:284-307 This code looks similar to `sys/powerpc/ofw/ofw_pci.c` `ofw_pci_nranges` but using fdt_* in place of the correct OF_* functions. It would be nice to not hve to do the same parsing each time. sys/arm/annapurna/alpine/alpine_pci.c:414 Why the else given the return above? sys/arm/annapurna/alpine/alpine_pci.c:422 (bus)? sys/arm/annapurna/alpine/alpine_pci.c:429 What is magic about 0xff? sys/arm/annapurna/alpine/alpine_pci.c:441 Extra newline. sys/arm/annapurna/alpine/alpine_pci.c:450 Should these be under `bootverbose`? sys/arm/annapurna/alpine/alpine_pci.c:479 0xff? sys/arm/annapurna/alpine/alpine_pci.c:496 No need for the brace, and is this check needed? When would `ofw_bus_search_compatible` match something that's not a pci device? sys/arm/annapurna/alpine/alpine_pci.c:527 This doesn't look how we would normally structure this, it would be something like: struct al_pcie_atu_region io_atu_region; if (sc->sc_type == AL_PCI_TYPE_INTERNAL) return (0); io_atu_region.enable = AL_TRUE; io_atu_region.direction = AL_PCIE_ATU_DIR_OUTBOUND; ... sys/arm/annapurna/alpine/alpine_pci.c:547 Should this be under bootverbose? sys/arm/annapurna/alpine/alpine_pci.c:596 We have `setbit`, `clrbit`, `isset`, and `isclr` in `sys/param.h` for this sort of thing. sys/arm/annapurna/alpine/alpine_pci.c:679 What's special about that value and why does it need to be written before the value can be read? sys/arm/annapurna/alpine/alpine_pci.c:733 Shouldn't this be a `bus_size_t`? sys/arm/annapurna/alpine/alpine_pci.c:847 What's special about 5? sys/arm/annapurna/alpine/alpine_pci.c:962 Why 12? sys/arm/annapurna/alpine/alpine_pci.c:979 You can combine `v` and `tmp` on one line, and `mps` and `reg` on another. sys/arm/annapurna/alpine/alpine_pci.c:1098 `(hdrtype & PCIM_MFDEV) != 0` sys/arm/annapurna/alpine/alpine_pci.c:1180 This looks wrong, why are you parsing the fdt data in the clikd class? It should be being provided by the parent, then you use `bus_alloc_resource` or similar to get the resource. sys/arm/annapurna/alpine/alpine_pci.c:1221 Don't use `fdtbus_bs_tag` in this driver, it should come from the parent. `fdtbus_bs_tag` should only be used by the early console. sys/arm/annapurna/alpine/alpine_pci.c:1240 Doesn't this leave the hardware partially configuredon failure? sys/arm/annapurna/alpine/alpine_pci.c:1391 Why `0xffffffff`? sys/arm/annapurna/alpine/alpine_pci.c:1470 Unneeded REVISION DETAIL https://reviews.freebsd.org/D2579 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: jpa-semihalf.com, ian, imp, andrew Cc: freebsd-arm From owner-freebsd-arm@FreeBSD.ORG Tue May 19 13:01:41 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C4E79AA for ; Tue, 19 May 2015 13:01:41 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 5094517C7 for ; Tue, 19 May 2015 13:01:41 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JD1f9t017015 for ; Tue, 19 May 2015 13:01:41 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4JD1ffN017014; Tue, 19 May 2015 13:01:41 GMT (envelope-from daemon-user) Date: Tue, 19 May 2015 13:01:41 +0000 To: freebsd-arm@freebsd.org From: "andrew (Andrew Turner)" Subject: [Differential] [Updated] D2579: PCI support for Alpine platform from Annapurna Labs Message-ID: <0a43b61dfa537fe40fe32559f04a5702@localhost.localdomain> X-Priority: 3 Thread-Topic: D2579: PCI support for Alpine platform from Annapurna Labs X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NjYxMzQxMmI2MjBmNTRlMzhjMzBkMTMzMmNhIFVbNDU= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" 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: Tue, 19 May 2015 13:01:41 -0000 andrew added a reviewer: jhb. REVISION DETAIL https://reviews.freebsd.org/D2579 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: jpa-semihalf.com, ian, imp, andrew, jhb Cc: freebsd-arm From owner-freebsd-arm@FreeBSD.ORG Tue May 19 13:35:24 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1963A23E for ; Tue, 19 May 2015 13:35:24 +0000 (UTC) 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 033D51C17 for ; Tue, 19 May 2015 13:35:24 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JDZNJV061988 for ; Tue, 19 May 2015 13:35:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200322] lang/erlang failes to build on armv6 with HiPE enabled Date: Tue, 19 May 2015 13:35:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: a.andersson.thn@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: olgeni@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: attachments.created 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: Tue, 19 May 2015 13:35:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200322 --- Comment #1 from a.andersson.thn@gmail.com --- Created attachment 156940 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=156940&action=edit make configure output Log from make configure as requested by port maintainer. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 13:36:33 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 078D12CA for ; Tue, 19 May 2015 13:36:33 +0000 (UTC) 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 E5D5C1C34 for ; Tue, 19 May 2015 13:36:32 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JDaWZo062514 for ; Tue, 19 May 2015 13:36:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200322] lang/erlang failes to build on armv6 with HiPE enabled Date: Tue, 19 May 2015 13:36:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: a.andersson.thn@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: olgeni@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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: Tue, 19 May 2015 13:36:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200322 --- Comment #2 from a.andersson.thn@gmail.com --- Port maintainer wanted to know the following in previous email: Output from uname -m: arm "Does it compile without HiPE enable?" Yes Let me know if you want more information. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 13:56:05 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A220F6B1 for ; Tue, 19 May 2015 13:56:05 +0000 (UTC) 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 8C9911E90 for ; Tue, 19 May 2015 13:56:05 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JDu5IU081975 for ; Tue, 19 May 2015 13:56:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200322] lang/erlang failes to build on armv6 with HiPE enabled Date: Tue, 19 May 2015 13:56:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mikael.urankar@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: olgeni@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: attachments.created 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: Tue, 19 May 2015 13:56:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200322 --- Comment #3 from mikael.urankar@gmail.com --- Created attachment 156941 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=156941&action=edit armv6 fix Hi, Can you try the attached patch? -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 13:56:34 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E7B670B for ; Tue, 19 May 2015 13:56:34 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 4C1931EA1 for ; Tue, 19 May 2015 13:56:34 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JDuYKK033969 for ; Tue, 19 May 2015 13:56:34 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4JDuYGM033968; Tue, 19 May 2015 13:56:34 GMT (envelope-from daemon-user) Date: Tue, 19 May 2015 13:56:34 +0000 To: freebsd-arm@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Changed Subscribers] D2579: PCI support for Alpine platform from Annapurna Labs Message-ID: <441fa1e250fb58fe0c196d8f5820d809@localhost.localdomain> X-Priority: 3 Thread-Topic: D2579: PCI support for Alpine platform from Annapurna Labs X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NjYxMzQxMmI2MjBmNTRlMzhjMzBkMTMzMmNhIFVbQRI= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" 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: Tue, 19 May 2015 13:56:34 -0000 emaste added a subscriber: emaste. INLINE COMMENTS sys/arm/annapurna/alpine/alpine_pci.c:450 Does this represent a hardware error, or a normal operating condition e.g. with nothing installed in a PCIe slot? sys/arm/annapurna/alpine/alpine_pci.c:547 Yes, in my opinion. REVISION DETAIL https://reviews.freebsd.org/D2579 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: jpa-semihalf.com, ian, imp, andrew, jhb Cc: emaste, freebsd-arm From owner-freebsd-arm@FreeBSD.ORG Tue May 19 14:19:39 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4743AFC for ; Tue, 19 May 2015 14:19:39 +0000 (UTC) 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 BEEC011BE for ; Tue, 19 May 2015 14:19:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JEJdBL036832 for ; Tue, 19 May 2015 14:19:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200322] lang/erlang failes to build on armv6 with HiPE enabled Date: Tue, 19 May 2015 14:19:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: a.andersson.thn@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: olgeni@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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: Tue, 19 May 2015 14:19:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200322 --- Comment #4 from a.andersson.thn@gmail.com --- (In reply to mikael.urankar from comment #3) Got the same error with that patch. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 15:02:38 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 378D9DA9 for ; Tue, 19 May 2015 15:02:38 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 1B6B0186A for ; Tue, 19 May 2015 15:02:38 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JF2bIx056331 for ; Tue, 19 May 2015 15:02:37 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4JF2bPw056330; Tue, 19 May 2015 15:02:37 GMT (envelope-from daemon-user) Date: Tue, 19 May 2015 15:02:37 +0000 To: freebsd-arm@freebsd.org From: "jpa-semihalf.com (Jakub Palider)" Subject: [Differential] [Updated] D2579: PCI support for Alpine platform from Annapurna Labs Message-ID: <7341f846a7b7848d97db917c0b78c006@localhost.localdomain> X-Priority: 3 Thread-Topic: D2579: PCI support for Alpine platform from Annapurna Labs X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NjYxMzQxMmI2MjBmNTRlMzhjMzBkMTMzMmNhIFVbUI0= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" 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: Tue, 19 May 2015 15:02:38 -0000 jpa-semihalf.com marked 15 inline comments as done. INLINE COMMENTS sys/arm/annapurna/alpine/alpine_pci.c:247 Its an options flag for MSI, instead of wired one. sys/arm/annapurna/alpine/alpine_pci.c:414 I don't understand, could you elaborate? sys/arm/annapurna/alpine/alpine_pci.c:679 I think this is the way to learn the size (PCI 3.0 spec, sec 6.2.5.1) REVISION DETAIL https://reviews.freebsd.org/D2579 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: jpa-semihalf.com, ian, imp, andrew, jhb Cc: emaste, freebsd-arm From owner-freebsd-arm@FreeBSD.ORG Tue May 19 15:22:43 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7288F2C7 for ; Tue, 19 May 2015 15:22:43 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 5650C1B7F for ; Tue, 19 May 2015 15:22:43 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JFMh4T061901 for ; Tue, 19 May 2015 15:22:43 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4JFMhq3061900; Tue, 19 May 2015 15:22:43 GMT (envelope-from daemon-user) Date: Tue, 19 May 2015 15:22:43 +0000 To: freebsd-arm@freebsd.org From: "jpa-semihalf.com (Jakub Palider)" Subject: [Differential] [Updated] D2579: PCI support for Alpine platform from Annapurna Labs Message-ID: X-Priority: 3 Thread-Topic: D2579: PCI support for Alpine platform from Annapurna Labs X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NjYxMzQxMmI2MjBmNTRlMzhjMzBkMTMzMmNhIFVbVUM= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" 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: Tue, 19 May 2015 15:22:43 -0000 jpa-semihalf.com marked 3 inline comments as done. INLINE COMMENTS sys/arm/annapurna/alpine/alpine_pci.c:450 The 'funny' thing is that the al_pcie_link_status never returns values < 0. But right, I must verify whether presence != link down. REVISION DETAIL https://reviews.freebsd.org/D2579 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: jpa-semihalf.com, ian, imp, andrew, jhb Cc: emaste, freebsd-arm From owner-freebsd-arm@FreeBSD.ORG Tue May 19 15:49:45 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 33E832A7 for ; Tue, 19 May 2015 15:49:45 +0000 (UTC) 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 1EC1A1EA2 for ; Tue, 19 May 2015 15:49:45 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JFnibF010450 for ; Tue, 19 May 2015 15:49:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200322] lang/erlang failes to build on armv6 with HiPE enabled Date: Tue, 19 May 2015 15:49:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: a.andersson.thn@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: olgeni@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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: Tue, 19 May 2015 15:49:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200322 --- Comment #5 from a.andersson.thn@gmail.com --- Maybe I applied it incorrectly? root@rpi2:/usr/ports/lang/erlang # patch < test.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- /dev/null |+++ files/patch-erts_configure.in -------------------------- Patching file files/patch-erts_configure.in using Plan A... Empty context always matches. Hunk #1 succeeded at 1. done -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 15:50:56 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63B81306 for ; Tue, 19 May 2015 15:50:56 +0000 (UTC) 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 4E6531F46 for ; Tue, 19 May 2015 15:50:56 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JFoumK013293 for ; Tue, 19 May 2015 15:50:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200322] lang/erlang failes to build on armv6 with HiPE enabled Date: Tue, 19 May 2015 15:50:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: olgeni@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: olgeni@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: bug_status 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: Tue, 19 May 2015 15:50:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200322 Jimmy Olgeni changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress --- Comment #6 from Jimmy Olgeni --- (In reply to a.andersson.thn from comment #5) Hi, can you check if the patch file ended up in files/ or in the main port directory? -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 16:05:10 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88826A40 for ; Tue, 19 May 2015 16:05:10 +0000 (UTC) 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 738C71113 for ; Tue, 19 May 2015 16:05:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JG5Aq1060053 for ; Tue, 19 May 2015 16:05:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200322] lang/erlang failes to build on armv6 with HiPE enabled Date: Tue, 19 May 2015 16:05:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: a.andersson.thn@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: olgeni@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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: Tue, 19 May 2015 16:05:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200322 --- Comment #7 from a.andersson.thn@gmail.com --- The patch created this file: files/patch-erts_configure.in -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue May 19 16:30:54 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 888F83AE for ; Tue, 19 May 2015 16:30:54 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 506A013BD for ; Tue, 19 May 2015 16:30:54 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JGUsEu092089 for ; Tue, 19 May 2015 16:30:54 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4JGUswM092088; Tue, 19 May 2015 16:30:54 GMT (envelope-from daemon-user) Date: Tue, 19 May 2015 16:30:54 +0000 To: freebsd-arm@freebsd.org From: "andrew (Andrew Turner)" Subject: [Differential] [Updated] D2579: PCI support for Alpine platform from Annapurna Labs Message-ID: X-Priority: 3 Thread-Topic: D2579: PCI support for Alpine platform from Annapurna Labs X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NjYxMzQxMmI2MjBmNTRlMzhjMzBkMTMzMmNhIFVbZT4= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" 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: Tue, 19 May 2015 16:30:54 -0000 andrew added a reviewer: ARM. INLINE COMMENTS sys/arm/annapurna/alpine/alpine_pci.c:247 So is it needed or is it always defined? sys/arm/annapurna/alpine/alpine_pci.c:414 You have: if (bus == 0) { ... return (0); } else { ... } The `else` case isn't needed as there is no way to get to past the if case. You could rewrite it as: if (bus == 0) { ... return (0); } ... REVISION DETAIL https://reviews.freebsd.org/D2579 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: jpa-semihalf.com, ian, imp, andrew, jhb, onwahe-gmail-com, meloun-miracle-cz, br, sson, loos, sbruno, rpaulo Cc: emaste, freebsd-arm From owner-freebsd-arm@FreeBSD.ORG Tue May 19 16:37:52 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 125FD573 for ; Tue, 19 May 2015 16:37:52 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 E6345151B for ; Tue, 19 May 2015 16:37:51 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4JGbpJ8092950 for ; Tue, 19 May 2015 16:37:51 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4JGbpQl092949; Tue, 19 May 2015 16:37:51 GMT (envelope-from daemon-user) Date: Tue, 19 May 2015 16:37:51 +0000 To: freebsd-arm@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Commented On] D2579: PCI support for Alpine platform from Annapurna Labs Message-ID: <8aba59ef998647039c1186c83c825f5a@localhost.localdomain> X-Priority: 3 Thread-Topic: D2579: PCI support for Alpine platform from Annapurna Labs X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NjYxMzQxMmI2MjBmNTRlMzhjMzBkMTMzMmNhIFVbZt8= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" 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: Tue, 19 May 2015 16:37:52 -0000 emaste added inline comments. INLINE COMMENTS sys/arm/annapurna/alpine/alpine_pci.c:414 See e.g. this discussion from LLVM's coding standards doc: http://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code We don't have this explicitly documented in FreeBSD, but in general prefer early returns. REVISION DETAIL https://reviews.freebsd.org/D2579 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: jpa-semihalf.com, ian, imp, andrew, jhb, onwahe-gmail-com, meloun-miracle-cz, br, sson, loos, sbruno, rpaulo Cc: emaste, freebsd-arm From owner-freebsd-arm@FreeBSD.ORG Wed May 20 08:00:06 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C5AB2CD for ; Wed, 20 May 2015 08:00:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (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 6CEDC1F51 for ; Wed, 20 May 2015 08:00:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t4K806BO074894 for ; Wed, 20 May 2015 08:00:06 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t4K806gH074893; Wed, 20 May 2015 08:00:06 GMT (envelope-from daemon-user) Date: Wed, 20 May 2015 08:00:06 +0000 To: freebsd-arm@freebsd.org From: "jpa-semihalf.com (Jakub Palider)" Subject: [Differential] [Updated] D2579: PCI support for Alpine platform from Annapurna Labs Message-ID: <83b4e9af975b6d698d1d88bc9cae8d08@localhost.localdomain> X-Priority: 3 Thread-Topic: D2579: PCI support for Alpine platform from Annapurna Labs X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NjYxMzQxMmI2MjBmNTRlMzhjMzBkMTMzMmNhIFVcPwY= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" 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: Wed, 20 May 2015 08:00:06 -0000 jpa-semihalf.com marked 5 inline comments as done. INLINE COMMENTS sys/arm/annapurna/alpine/alpine_pci.c:247 Actually, it is MSIx that will be the default option. If you opt for making it always on, I am OK about that. sys/arm/annapurna/alpine/alpine_pci.c:414 I am sorry, I looked at it but didn't see it. I will also remove the double test against (slot >0). REVISION DETAIL https://reviews.freebsd.org/D2579 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: jpa-semihalf.com, ian, imp, andrew, jhb, onwahe-gmail-com, meloun-miracle-cz, br, sson, loos, sbruno, rpaulo Cc: emaste, freebsd-arm From owner-freebsd-arm@FreeBSD.ORG Wed May 20 13:33:59 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0D56935; Wed, 20 May 2015 13:33:59 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8AF1B1960; Wed, 20 May 2015 13:33:59 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 93D0594D; Wed, 20 May 2015 13:33:59 +0000 (UTC) Date: Wed, 20 May 2015 13:33:59 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-arm@freebsd.org, ae@FreeBSD.org, glebius@FreeBSD.org, bapt@FreeBSD.org, emaste@FreeBSD.org, ngie@FreeBSD.org, trasz@FreeBSD.org Message-ID: <445653728.21.1432128839572.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD_arm64 #174 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE 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: Wed, 20 May 2015 13:33:59 -0000 See Changes: [emaste] Avoid trying to build cxbge on 32-bit MIPS It lacks required 64-bit atomics. Reviewed by:=09imp (earlier version) Sponsored by:=09The FreeBSD Foundation Differential Revision:=09https://reviews.freebsd.org/D2585 [ngie] Articulate all dependencies for lib/libproc to squash build races af= ter r283139 on !arm64 and !sparc64 Pointyhat to: bapt Sponsored by: EMC / Isilon Storage Division [ngie] Build cddl/{sbin,usr.bin,usr.sbin} in parallel as all of the applica= tions are freestanding (they require libraries build via make libraries in buildworld= ) MFC after: 1 week Sponsored by: EMC / Isilon Storage Division [ae] In the reply to SADB_X_SPDGET message use the same sequence number tha= t was in the request. Some IKE deamons expect it will the same. Linux and NetBSD also follow this behaviour. PR:=09=09137309 MFC after:=092 weeks [ngie] Add dependencies for libzfs_core and libzpool I missed on my first p= ass on this Makefile MFC with: r283144 Sponsored by: EMC / Isilon Storage Division [ngie] Articulate dependencies for cddl/lib/libdtrace and cddl/lib/libzfs Parallelize the build in this subdirectory MFC after: 1 week Sponsored by: EMC / Isilon Storage Division [ngie] Remove usr/share/dtrace/{tcpconn,tcpstate,tcptrack,udptrack} if MK_C= DDL =3D=3D no Sponsored by: EMC / Isilon Storage Division [glebius] EVENTHANDLER_REGISTER() doesn't fail. [trasz] Remove the warning about invalid PE checksum; apparently nothing cares about those checksums anyway. MFC after:=091 month Sponsored by:=09The FreeBSD Foundation [ngie] Only build sys/boot/usb/tools if MK_USB !=3D no Sponsored by: EMC / Isilon Storage Division [bapt] Fix buildworld by adding libproc and librtld_db to the _prebuild_lib= s Those are needed to build libdtrace ------------------------------------------ [...truncated 65894 lines...] --- pam_debug_log.o --- cc -B/usr/local/aarch64-freebsd/bin/ -DOPENPAM_STATIC_MODULES -O2 -pipe -= I = -I -DLIB_MAJ=3D5 -DOPENPAM_MODULES_DIRECTORY= =3D'"/usr/lib/"' -DHAVE_DLFUNC=3D1 -DHAVE_FDLOPEN=3D1 -DHAVE_FPURGE=3D1 -DH= AVE_STRLCAT=3D1 -DHAVE_STRLCPY=3D1 -DOPENPAM_DEBUG -std=3Diso9899:1999 -fst= ack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused= -parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wretur= n-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wc= ast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wo= ld-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthr= ead-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Qunused-arguments -c -o pam_debug_log.o --- lib/ncurses/ncurses__L --- --- lib_scanw.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I. -I -I -I= -I -I -W= all -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstac= k-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-p= arameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-unin= itialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unuse= d-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parenthes= es-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typ= edef -Qunused-arguments -c -o lib_scanw.o --- lib/libtacplus__L --- --- obj --- --- .depend --- rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -std= =3Dgnu99 --- lib/libpam__L --- --- openpam_static.o --- cc -B/usr/local/aarch64-freebsd/bin/ -DOPENPAM_STATIC_MODULES -O2 -pipe -= I = -I -DLIB_MAJ=3D5 -DOPENPAM_MODULES_DIRECTORY= =3D'"/usr/lib/"' -DHAVE_DLFUNC=3D1 -DHAVE_FDLOPEN=3D1 -DHAVE_FPURGE=3D1 -DH= AVE_STRLCAT=3D1 -DHAVE_STRLCPY=3D1 -DOPENPAM_DEBUG -std=3Diso9899:1999 -fst= ack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused= -parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wretur= n-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wc= ast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wo= ld-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthr= ead-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Qunused-arguments -c -= o openpam_static.o --- lib/ncurses/ncursesw__L --- --- lib_mvwin.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -D_XOPEN_SOURCE_EXTENDED = -DENABLE_WIDEC -I. -I -I -I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H= -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstack-protector -Wsystem-headers= -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes= -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c <= https://jenkins.freebsd.org/job/FreeBSD_HEAD_arm64/ws/lib/ncurses/ncursesw/= ../../../contrib/ncurses/ncurses/base/lib_mvwin.c> -o lib_mvwin.o --- lib/ncurses/ncurses__L --- --- lib_scanw.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -I. -I -I -= I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3D= gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -= Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ari= th -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-in= t -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -W= no-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unus= ed-local-typedef -Qunused-arguments -c -o lib_scanw.So --- lib/libpam__L --- --- libpam.so.5 --- building shared library libpam.so.5 cc -B/usr/local/aarch64-freebsd/bin/ -fstack-protector -shared -Wl,-x -Wl,= --fatal-warnings -Wl,--warn-shared-textrel -o libpam.so.5 -Wl,-soname,libp= am.so.5 `NM=3D'/usr/local/aarch64-freebsd/bin/nm' lorder openpam_asprintf.= So openpam_borrow_cred.So openpam_check_owner_perms.So openpam_configure.So= openpam_constants.So openpam_dispatch.So openpam_dynamic.So openpam_featur= es.So openpam_findenv.So openpam_free_data.So openpam_free_envlist.So openp= am_get_feature.So openpam_get_option.So openpam_load.So openpam_log.So open= pam_nullconv.So openpam_readline.So openpam_readlinev.So openpam_readword.S= o openpam_restore_cred.So openpam_set_feature.So openpam_set_option.So open= pam_straddch.So openpam_strlcat.So openpam_strlcpy.So openpam_strlset.So op= enpam_subst.So openpam_ttyconv.So openpam_vasprintf.So pam_acct_mgmt.So pam= _authenticate.So pam_chauthtok.So pam_close_session.So pam_end.So pam_error= .So pam_get_authtok.So pam_get_data.So pam_get_item.So pam_get_user.So pam_= getenv.So pam_getenvlist.So pam_info.So pam_open_session.So pam_prompt.So p= am_putenv.So pam_set_data.So pam_set_item.So pam_setcred.So pam_setenv.So p= am_start.So pam_strerror.So pam_verror.So pam_vinfo.So pam_vprompt.So pam_d= ebug_log.So | tsort -q`=20 --- lib/ncurses/ncursesw__L --- --- lib_mvwin.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -D_XOPEN_SOUR= CE_EXTENDED -DENABLE_WIDEC -I. -I -I -I -I -I -Wall -DNDEBUG -DH= AVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstack-protector -Wsy= stem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstric= t-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-p= ointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable= -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno= -unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-ar= guments -c -o lib_mvwin= .So --- lib/libtacplus__L --- echo libtacplus.so.5: >> .depend --- lib/ncurses/ncurses__L --- --- lib_screen.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I. -I -I -I= -I -I -W= all -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstac= k-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-p= arameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-unin= itialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unuse= d-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parenthes= es-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typ= edef -Qunused-arguments -c -o lib_screen.o --- lib/libtacplus__L --- --- taclib.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -Wall -std=3D= gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno= -uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-= unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-pare= ntheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-loca= l-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused= -arguments -c -o taclib.So --- lib/ncurses/ncursesw__L --- --- lib_newterm.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -D_XOPEN_SOURCE_EXTENDED = -DENABLE_WIDEC -I. -I -I -I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H= -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstack-protector -Wsystem-headers= -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes= -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c <= https://jenkins.freebsd.org/job/FreeBSD_HEAD_arm64/ws/lib/ncurses/ncursesw/= ../../../contrib/ncurses/ncurses/base/lib_newterm.c> -o lib_newterm.o --- lib/libpam__L --- --- openpam_static_modules.o --- /usr/local/aarch64-freebsd/bin/ld -o openpam_static_modules.o -r --whole-ar= chive openpam_static.o ../modules/pam_chroot/libpam_chroot.a ../modules/pam= _deny/libpam_deny.a ../modules/pam_echo/libpam_echo.a ../modules/pam_exec/l= ibpam_exec.a ../modules/pam_ftpusers/libpam_ftpusers.a ../modules/pam_group= /libpam_group.a ../modules/pam_guest/libpam_guest.a ../modules/pam_krb5/lib= pam_krb5.a ../modules/pam_ksu/libpam_ksu.a ../modules/pam_lastlog/libpam_la= stlog.a ../modules/pam_login_access/libpam_login_access.a ../modules/pam_no= login/libpam_nologin.a ../modules/pam_opie/libpam_opie.a ../modules/pam_opi= eaccess/libpam_opieaccess.a ../modules/pam_passwdqc/libpam_passwdqc.a ../mo= dules/pam_permit/libpam_permit.a ../modules/pam_radius/libpam_radius.a ../m= odules/pam_rhosts/libpam_rhosts.a ../modules/pam_rootok/libpam_rootok.a ../= modules/pam_securetty/libpam_securetty.a ../modules/pam_self/libpam_self.a = ../modules/pam_ssh/libpam_ssh.a ../modules/pam_tacplus/libpam_tacplus.a ../= modules/pam_unix/libpam_unix.a --- libpam.a --- building static pam library --- lib/ncurses/ncurses__L --- --- lib_screen.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -I. -I -I -= I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3D= gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -= Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ari= th -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-in= t -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -W= no-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unus= ed-local-typedef -Qunused-arguments -c -o lib_screen.So --- lib/libpam__L --- /usr/local/aarch64-freebsd/bin/ranlib -D libpam.a --- lib/ncurses/ncursesw__L --- --- lib_newterm.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -D_XOPEN_SOUR= CE_EXTENDED -DENABLE_WIDEC -I. -I -I -I -I -I -Wall -DNDEBUG -DH= AVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstack-protector -Wsy= stem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstric= t-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-p= ointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable= -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno= -unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-ar= guments -c -o lib_new= term.So --- lib/libpam__L --- --- _sub.realinstall --- =3D=3D=3D> lib/libpam/modules (install) --- _sub.realinstall --- =3D=3D=3D> lib/libpam/modules/pam_chroot (install) --- lib/ncurses/ncurses__L --- --- lib_scroll.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I. -I -I -I= -I -I -W= all -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstac= k-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-p= arameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-unin= itialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unuse= d-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parenthes= es-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typ= edef -Qunused-arguments -c -o lib_scroll.o --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_deny (install) --- lib/ncurses/ncursesw__L --- --- lib_newwin.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -D_XOPEN_SOURCE_EXTENDED = -DENABLE_WIDEC -I. -I -I -I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H= -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstack-protector -Wsystem-headers= -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes= -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c <= https://jenkins.freebsd.org/job/FreeBSD_HEAD_arm64/ws/lib/ncurses/ncursesw/= ../../../contrib/ncurses/ncurses/base/lib_newwin.c> -o lib_newwin.o --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_echo (install) =3D=3D=3D> lib/libpam/modules/pam_exec (install) --- lib/ncurses/ncurses__L --- --- lib_scroll.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -I. -I -I -= I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3D= gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -= Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ari= th -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-in= t -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -W= no-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unus= ed-local-typedef -Qunused-arguments -c -o lib_scroll.So --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_ftpusers (install) =3D=3D=3D> lib/libpam/modules/pam_group (install) --- lib/libtacplus__L --- --- taclib.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -Wall -std=3Dgnu99 -fstac= k-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitializ= ed -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const= -variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equa= lity -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -W= no-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -= c -o taclib.o --- lib/ncurses/ncursesw__L --- --- lib_newwin.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -D_XOPEN_SOUR= CE_EXTENDED -DENABLE_WIDEC -I. -I -I -I -I -I -Wall -DNDEBUG -DH= AVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstack-protector -Wsy= stem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstric= t-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-p= ointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable= -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno= -unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-ar= guments -c -o lib_neww= in.So --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_guest (install) --- lib/ncurses/ncurses__L --- --- lib_scrollok.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I. -I -I -I= -I -I -W= all -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstac= k-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-p= arameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-unin= itialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unuse= d-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parenthes= es-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typ= edef -Qunused-arguments -c -o lib_scrollok.o --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_krb5 (install) =3D=3D=3D> lib/libpam/modules/pam_ksu (install) --- lib/ncurses/ncurses__L --- --- lib_scrollok.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -I. -I -I -= I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3D= gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -= Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ari= th -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-in= t -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -W= no-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unus= ed-local-typedef -Qunused-arguments -c -o lib_scrollok.So --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_lastlog (install) =3D=3D=3D> lib/libpam/modules/pam_login_access (install) --- lib/ncurses/ncursesw__L --- --- lib_nl.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -D_XOPEN_SOURCE_EXTENDED = -DENABLE_WIDEC -I. -I -I -I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H= -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstack-protector -Wsystem-headers= -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes= -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c <= https://jenkins.freebsd.org/job/FreeBSD_HEAD_arm64/ws/lib/ncurses/ncursesw/= ../../../contrib/ncurses/ncurses/base/lib_nl.c> -o lib_nl.o --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_nologin (install) --- lib/ncurses/ncurses__L --- --- lib_scrreg.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I. -I -I -I= -I -I -W= all -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstac= k-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-p= arameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-unin= itialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unuse= d-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parenthes= es-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typ= edef -Qunused-arguments -c -o lib_scrreg.o --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_opie (install) --- lib/ncurses/ncursesw__L --- --- lib_nl.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -D_XOPEN_SOUR= CE_EXTENDED -DENABLE_WIDEC -I. -I -I -I -I -I -Wall -DNDEBUG -DH= AVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstack-protector -Wsy= stem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstric= t-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-p= ointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable= -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno= -unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-ar= guments -c -o lib_nl.So --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_opieaccess (install) --- lib/ncurses/ncurses__L --- --- lib_scrreg.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -I. -I -I -= I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3D= gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -= Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ari= th -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-in= t -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -W= no-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unus= ed-local-typedef -Qunused-arguments -c -o lib_scrreg.So --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_passwdqc (install) =3D=3D=3D> lib/libpam/modules/pam_permit (install) --- lib/ncurses/ncursesw__L --- --- lib_overlay.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -D_XOPEN_SOURCE_EXTENDED = -DENABLE_WIDEC -I. -I -I -I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H= -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstack-protector -Wsystem-headers= -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes= -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c <= https://jenkins.freebsd.org/job/FreeBSD_HEAD_arm64/ws/lib/ncurses/ncursesw/= ../../../contrib/ncurses/ncurses/base/lib_overlay.c> -o lib_overlay.o --- lib/ncurses/ncurses__L --- --- lib_set_term.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I. -I -I -I= -I -I -W= all -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstac= k-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-p= arameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-unin= itialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unuse= d-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parenthes= es-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typ= edef -Qunused-arguments -c -o lib_set_term.o --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_radius (install) --- lib/libtacplus__L --- --- libtacplus.so.5 --- building shared library libtacplus.so.5 cc -B/usr/local/aarch64-freebsd/bin/ -fstack-protector -shared -Wl,-x -Wl,= --fatal-warnings -Wl,--warn-shared-textrel -o libtacplus.so.5 -Wl,-soname,= libtacplus.so.5 `NM=3D'/usr/local/aarch64-freebsd/bin/nm' lorder taclib.So= | tsort -q` -lmd --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_rhosts (install) --- lib/libtacplus__L --- --- libtacplus.a --- building static tacplus library --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_rootok (install) --- lib/libtacplus__L --- /usr/local/aarch64-freebsd/bin/ranlib -D libtacplus.a --- lib/ncurses/ncursesw__L --- --- lib_overlay.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -D_XOPEN_SOUR= CE_EXTENDED -DENABLE_WIDEC -I. -I -I -I -I -I -Wall -DNDEBUG -DH= AVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstack-protector -Wsy= stem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstric= t-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-p= ointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable= -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno= -unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-ar= guments -c -o lib_ove= rlay.So --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_securetty (install) --- lib/libtacplus__L --- --- _libinstall --- sh = -C -o root -g wheel -m 444 libtacplus.a sh = -s -o root -g wheel -m 444 libtacplus.so.5 sh = -l s libtacplus.so.5 --- _INCSINS --- sh = -C -o root -g wheel -m 444 --- lib/libgeom__L --- =3D=3D=3D> lib/libgeom (obj,depend,all,install) --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_self (install) --- lib/ncurses/ncurses__L --- --- lib_set_term.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -I. -I -I -= I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3D= gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -= Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ari= th -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-in= t -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -W= no-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unus= ed-local-typedef -Qunused-arguments -c -o lib_set_term.So --- lib/libgeom__L --- --- obj --- --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_ssh (install) --- lib/libgeom__L --- --- .depend --- rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -I -std=3Dgnu99= --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_tacplus (install) --- lib/ncurses/ncursesw__L --- --- lib_pad.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -D_XOPEN_SOURCE_EXTENDED = -DENABLE_WIDEC -I. -I -I -I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H= -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstack-protector -Wsystem-headers= -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes= -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c <= https://jenkins.freebsd.org/job/FreeBSD_HEAD_arm64/ws/lib/ncurses/ncursesw/= ../../../contrib/ncurses/ncurses/base/lib_pad.c> -o lib_pad.o --- lib/libpam__L --- =3D=3D=3D> lib/libpam/modules/pam_unix (install) =3D=3D=3D> lib/libpam/libpam (install) --- lib/ncurses/ncurses__L --- --- lib_slk.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I. -I -I -I= -I -I -W= all -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstac= k-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-p= arameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-unin= itialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unuse= d-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parenthes= es-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typ= edef -Qunused-arguments -c = -o lib_slk.o --- lib/libpam__L --- --- _libinstall --- sh = -C -o root -g wheel -m 444 libpam.a sh = -s -o root -g wheel -m 444 libpam.so.5 sh = -l s libpam.so.5 --- lib/ncurses/ncursesw__L --- --- lib_pad.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -D_XOPEN_SOUR= CE_EXTENDED -DENABLE_WIDEC -I. -I -I -I -I -I -Wall -DNDEBUG -DH= AVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstack-protector -Wsy= stem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstric= t-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-p= ointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable= -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno= -unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-ar= guments -c -o lib_pad.So --- lib/libpam__L --- --- _INCSINS --- sh = -C -o root -g wheel -m 444 --- lib/librtld_db__L --- =3D=3D=3D> lib/librtld_db (obj,depend,all,install) --- lib/libgeom__L --- echo libgeom.so.5: >> .depend --- lib/librtld_db__L --- --- obj --- created for --- lib/ncurses/ncurses__L --- --- lib_slk.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -I. -I -I -= I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3D= gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -= Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-ari= th -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-in= t -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -W= no-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unus= ed-local-typedef -Qunused-arguments -c -o lib_slk.So --- lib/librtld_db__L --- --- .depend --- rm -f .depend CC=3D'cc -B/usr/local/aarch64-freebsd/bin/ ' mkdep -f .depend -a -I -std=3Dgn= u99 --- lib/libgeom__L --- --- geom_getxml.So --- cc -B/usr/local/aarch64-freebsd/bin/ -fpic -DPIC -O2 -pipe -I -std=3Dgnu99 -fsta= ck-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-= parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uni= nitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unus= ed-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parenthe= ses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-ty= pedef -Qunused-arguments -c -o geom_getxml.So --- lib/ncurses/ncursesw__L --- --- lib_printw.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -D_XOPEN_SOURCE_EXTENDED = -DENABLE_WIDEC -I. -I -I -I -I -I -Wall -DNDEBUG -DHAVE_CONFIG_H= -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 -fstack-protector -Wsystem-headers= -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes= -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautol= ogical-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-func= tion -Wno-enum-conversion -Wno-unused-local-typedef -Qunused-arguments -c <= https://jenkins.freebsd.org/job/FreeBSD_HEAD_arm64/ws/lib/ncurses/ncursesw/= ../../../contrib/ncurses/ncurses/base/lib_printw.c> -o lib_printw.o --- lib/librtld_db__L --- :41:10: fatal error: 'libproc.h' file not found #include ^ 1 error generated. mkdep: compile failed *** [.depend] Error code 1 make[4]: stopped in 1 error make[4]: stopped in --- lib/libgeom__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in --- lib/ncurses/ncurses__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in --- lib/ncurses/ncursesw__L --- A failure has been detected in another branch of the parallel make make[4]: stopped in A failure has been detected in another branch of the parallel make make[3]: stopped in *** [libraries] Error code 2 make[2]: stopped in 1 error make[2]: stopped in *** [_libraries] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-arm@FreeBSD.ORG Wed May 20 16:44:09 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB9A2C6B for ; Wed, 20 May 2015 16:44:09 +0000 (UTC) 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 67D2412B2 for ; Wed, 20 May 2015 16:44:09 +0000 (UTC) Received: by qkgw4 with SMTP id w4so35518915qkg.3 for ; Wed, 20 May 2015 09:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=4Z3+doL3rLuT/7SkPGpclZqLykFe2wsNvslqpqxhjG8=; b=hOXS//DEFjscvS8OitnFeazQ5YskboayX96n8HHh40prL4uNXUlYY0R0qLK1i8ZCt9 b/Lz0Cwr46ecdx8Edh/B4E6ivQy5XwwWPl2yFoTTGCBVWkzImoV3inTb1H1JlSDC3XkM XwIEsdNVqsu6v0g/3QW4za7pa8Ca1GVfxlTnU4k2cbE3AhWz27QrhgR3EKPo4Hu+odlQ IEzu4SOTtrTMVaRuBMglsHWQSkkluyPM9DnJ+62xbEKsIwJVdY7k4pIHwYosZoNVxqn0 pi9yQIMAvAIyH6oB1FaDmkSk38br435n2NcgIGs1WZP6UtcFyC+yZHIhNUpySLPMp7yc gYEw== X-Received: by 10.229.4.200 with SMTP id 8mr46836984qcs.0.1432140248561; Wed, 20 May 2015 09:44:08 -0700 (PDT) Received: from [10.0.0.5] (96-39-105-86.static.oxfr.ma.charter.com. [96.39.105.86]) by mx.google.com with ESMTPSA id t77sm11465453qgt.42.2015.05.20.09.44.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 09:44:08 -0700 (PDT) From: Arjan van der Velde Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 Date: Wed, 20 May 2015 12:44:06 -0400 Message-Id: <81FF0940-10BF-4771-B982-C1D1D3C83941@gmail.com> To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) 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: Wed, 20 May 2015 16:44:09 -0000 Hello. Have you been able to solve this problem? I'm stuck with the same = thing. I seem unable to boot the 10.1 image from emmc. U-Boot 2014.04 (Apr 28 2015 - 04:56:05) I2C: ready DRAM: 512 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 Card did not respond to voltage select! mmc0(part 0) is current device Card did not respond to voltage select! mmc1(part 0) is current device SD/MMC found on device 1 reading bb-uEnv.txt 19 bytes read in 3 ms (5.9 KiB/s) Loaded environment from bb-uEnv.txt Importing environment from mmc ... reading bbubldr 251606 bytes read in 16 ms (15 MiB/s) reading bboneblk.dtb 16284 bytes read in 4 ms (3.9 MiB/s) ## Starting application at 0x88000054 ... Consoles: U-Boot console Compatible U-Boot API signature found @9f635510 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@releng1.nyi.freebsd.org, Tue Apr 28 04:56:01 UTC 2015) DRAM: 512MB Card did not respond to voltage select! Card did not respond to voltage select! Number of U-Boot devices: 1 U-Boot env: loaderdev=3D'mmc1:2.0' Found U-Boot device: net No boot device found! ## Application terminated, rc =3D 0xbadef1ce ## Error: "nandboot" not defined U-Boot# From owner-freebsd-arm@FreeBSD.ORG Wed May 20 17:02:14 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C94446D for ; Wed, 20 May 2015 17:02:14 +0000 (UTC) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::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 566C3153B for ; Wed, 20 May 2015 17:02:14 +0000 (UTC) Received: by qcir1 with SMTP id r1so26377736qci.3 for ; Wed, 20 May 2015 10:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=hUVdjODohg4SDdc2ycP0TWrSwO3uT1OIqE9XbXZcWr8=; b=dlcj4Y4/QMetI9Pj+q6KKbE1ivS3PSIHH+G1wjR3sf9IzyePdKQ/ddWaRd1oxwChZa t2COY/riu1B6J3R4aDGFeFtROEuJHA4pCjXj/pmIkvwhnbEREs6D3WT67uccpxlPH7UB 7XUWZ82zelxx6zf5f9J2OaDwEs+/ipNJ0MIjOPfwMOPHK10/Vc0zT/1s0Y4iOq+BCByc iJs5Xkp8rs5hgu018mQOcpIvE/ao+yo9c0lbAMPaFnbT0DKas3FDl+EDVo3h7Dqcrg5n 2oniktRp41cj4m4wMBRWavZbmF9LQPal2xsAzKf+FqRb1YuxGvdN1onBZfriWMGuShzm NBkQ== X-Received: by 10.140.236.73 with SMTP id h70mr46729079qhc.20.1432141333521; Wed, 20 May 2015 10:02:13 -0700 (PDT) Received: from [10.0.0.5] (96-39-105-86.static.oxfr.ma.charter.com. [96.39.105.86]) by mx.google.com with ESMTPSA id f64sm11418875qhc.37.2015.05.20.10.02.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 10:02:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) Subject: Re: [Patch v1] [BeagleBone Black] port the latest u-boot-2014-01 From: Arjan van der Velde In-Reply-To: <81FF0940-10BF-4771-B982-C1D1D3C83941@gmail.com> Date: Wed, 20 May 2015 13:02:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81FF0940-10BF-4771-B982-C1D1D3C83941@gmail.com> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1085) 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: Wed, 20 May 2015 17:02:14 -0000 Im sorry, this was in response to an old thread. I have used the latest = beaglebone FreeBSD snapshot (of 10.1) and copied the image to eMMC of my = beaglebone black, using the copy-to-emms.sh script. However, u-boot = seems unable to find the boot device. I'm not sure as to where I should = start looking. Thanks for your help. -- Arjan My partitions are as follows: root@beaglebone:~ # gpart show mmcsd1 =3D> 63 7552961 mmcsd1 MBR (3.6G) 63 4095 1 !12 [active] (2.0M) 4158 7548849 2 freebsd (3.6G) 7553007 17 - free - (8.5K) root@beaglebone:~ # mount -t msdosfs /dev/mmcsd1s1 /mnt root@beaglebone:~ # ll /mnt total 729 -rwxr-xr-x 1 root wheel 357652 May 20 11:40 bb-uboot.img* -rwxr-xr-x 1 root wheel 19 May 20 12:35 bb-uenv.txt* -rwxr-xr-x 1 root wheel 15838 May 20 11:40 bbone.dtb* -rwxr-xr-x 1 root wheel 10051 May 20 11:40 bbone.dts* -rwxr-xr-x 1 root wheel 16284 May 20 11:40 bboneblk.dtb* -rwxr-xr-x 1 root wheel 10548 May 20 11:40 bboneblk.dts* -rwxr-xr-x 1 root wheel 251606 May 20 11:40 bbubldr* -rwxr-xr-x 1 root wheel 82136 May 20 11:40 mlo* root@beaglebone:~ # umount /mnt/ root@beaglebone:~ # mount /dev/mmcsd1s2a /mnt root@beaglebone:~ # ll /mnt total 29620 -rw-r--r-- 2 root wheel 964 Apr 28 00:57 .cshrc -rw-r--r-- 2 root wheel 252 Apr 28 00:57 .profile drwxrwxr-x 2 root operator 512 Apr 28 00:56 .snap/ -r-------- 1 root wheel 30212096 May 20 11:40 .sujournal -r--r--r-- 1 root wheel 6195 Apr 28 00:57 COPYRIGHT drwxr-xr-x 2 root wheel 1024 Apr 28 00:56 bin/ drwxr-xr-x 9 root wheel 1024 Apr 28 00:57 boot/ dr-xr-xr-x 2 root wheel 512 May 20 11:42 dev/ etc. On May 20, 2015, at 12:44 PM, Arjan van der Velde wrote: > Hello. Have you been able to solve this problem? I'm stuck with the = same thing. I seem unable to boot the 10.1 image from emmc. >=20 > U-Boot 2014.04 (Apr 28 2015 - 04:56:05) >=20 > I2C: ready > DRAM: 512 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Using default environment >=20 > Net: not set. Validating first E-fuse MAC > cpsw, usb_ether > Hit any key to stop autoboot: 0 > Card did not respond to voltage select! > mmc0(part 0) is current device > Card did not respond to voltage select! > mmc1(part 0) is current device > SD/MMC found on device 1 > reading bb-uEnv.txt > 19 bytes read in 3 ms (5.9 KiB/s) > Loaded environment from bb-uEnv.txt > Importing environment from mmc ... > reading bbubldr > 251606 bytes read in 16 ms (15 MiB/s) > reading bboneblk.dtb > 16284 bytes read in 4 ms (3.9 MiB/s) > ## Starting application at 0x88000054 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @9f635510 >=20 > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@releng1.nyi.freebsd.org, Tue Apr 28 04:56:01 UTC 2015) >=20 > DRAM: 512MB > Card did not respond to voltage select! > Card did not respond to voltage select! > Number of U-Boot devices: 1 > U-Boot env: loaderdev=3D'mmc1:2.0' > Found U-Boot device: net > No boot device found! > ## Application terminated, rc =3D 0xbadef1ce > ## Error: "nandboot" not defined > U-Boot# >=20 >=20 From owner-freebsd-arm@FreeBSD.ORG Wed May 20 18:43:02 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4B2DD7; Wed, 20 May 2015 18:43:02 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 87AB61554; Wed, 20 May 2015 18:43:02 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 0B54F9BE; Wed, 20 May 2015 18:43:01 +0000 (UTC) Date: Wed, 20 May 2015 18:43:00 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-arm@freebsd.org, ae@FreeBSD.org, glebius@FreeBSD.org, bapt@FreeBSD.org, emaste@FreeBSD.org, ngie@FreeBSD.org, trasz@FreeBSD.org, kib@FreeBSD.org Message-ID: <647261175.24.1432147380945.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <445653728.21.1432128839572.JavaMail.jenkins@jenkins-9.freebsd.org> References: <445653728.21.1432128839572.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD_arm64 #175 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS 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: Wed, 20 May 2015 18:43:02 -0000 See From owner-freebsd-arm@FreeBSD.ORG Wed May 20 18:44:26 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2372215 for ; Wed, 20 May 2015 18:44:26 +0000 (UTC) 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 CC79B157B for ; Wed, 20 May 2015 18:44:26 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4KIiQCN044127 for ; Wed, 20 May 2015 18:44:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200322] lang/erlang failes to build on armv6 with HiPE enabled Date: Wed, 20 May 2015 18:44:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: a.andersson.thn@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: olgeni@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Wed, 20 May 2015 18:44:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200322 --- Comment #8 from a.andersson.thn@gmail.com --- Created attachment 156980 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D156980&action= =3Dedit Fix for HiPe in lang/erlang Turns out the fix was rather easy. Mika=C3=ABl Urankar told me he got it to= compile with: .if ${ARCH} =3D=3D armv6 MAKE_ARGS+=3D ARCH=3Darm .endif This allows HiPE in erlang to be compiled on arm. Tested and verified to wo= rk as well. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-arm@FreeBSD.ORG Wed May 20 19:02:43 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7CD07DA for ; Wed, 20 May 2015 19:02:43 +0000 (UTC) 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 A1EEF1792 for ; Wed, 20 May 2015 19:02:43 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4KJ2hvc093169 for ; Wed, 20 May 2015 19:02:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200322] lang/erlang failes to build on armv6 with HiPE enabled Date: Wed, 20 May 2015 19:02:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: a.andersson.thn@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: olgeni@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Wed, 20 May 2015 19:02:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200322 --- Comment #9 from a.andersson.thn@gmail.com --- Created attachment 156981 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D156981&action= =3Dedit Erlang patch As per Mika=C3=ABl Urankars direction I am submitting a cleaned up diff. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-arm@FreeBSD.ORG Wed May 20 19:09:11 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E1A8A90 for ; Wed, 20 May 2015 19:09:11 +0000 (UTC) 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 38D5C1811 for ; Wed, 20 May 2015 19:09:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4KJ9BlM095165 for ; Wed, 20 May 2015 19:09:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200322] lang/erlang failes to build on armv6 with HiPE enabled Date: Wed, 20 May 2015 19:09:11 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: olgeni@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: olgeni@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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: Wed, 20 May 2015 19:09:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200322 --- Comment #10 from Jimmy Olgeni --- (In reply to a.andersson.thn from comment #9) Great news - are you able to build erlang-runtime15 and 16 with this patch? -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Wed May 20 19:52:14 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56282D3 for ; Wed, 20 May 2015 19:52:14 +0000 (UTC) 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 408EC1E50 for ; Wed, 20 May 2015 19:52:14 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4KJqEOs038181 for ; Wed, 20 May 2015 19:52:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200322] lang/erlang failes to build on armv6 with HiPE enabled Date: Wed, 20 May 2015 19:52:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: a.andersson.thn@gmail.com X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: olgeni@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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: Wed, 20 May 2015 19:52:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200322 --- Comment #11 from a.andersson.thn@gmail.com --- (In reply to Jimmy Olgeni from comment #10) Nope, I only tried lang/erlang. I can check tomorrow though. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Wed May 20 20:10:55 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1EA1432 for ; Wed, 20 May 2015 20:10:55 +0000 (UTC) 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 DCBC410C5 for ; Wed, 20 May 2015 20:10:55 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4KKAtfG084998 for ; Wed, 20 May 2015 20:10:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200322] lang/erlang failes to build on armv6 with HiPE enabled Date: Wed, 20 May 2015 20:10:55 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: olgeni@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: 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: Wed, 20 May 2015 20:10:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200322 --- Comment #12 from commit-hook@freebsd.org --- A commit references this bug: Author: olgeni Date: Wed May 20 20:09:55 UTC 2015 New revision: 386887 URL: https://svnweb.freebsd.org/changeset/ports/386887 Log: Unbreak build on armv6. PR: 200322 Submitted by: a.andersson.thn@gmail.com Changes: head/lang/erlang/Makefile head/lang/erlang-runtime17/Makefile -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-arm@FreeBSD.ORG Wed May 20 22:20:42 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C5D3491 for ; Wed, 20 May 2015 22:20:42 +0000 (UTC) Received: from mail.egr.msu.edu (boomhauer.egr.msu.edu [35.9.37.167]) by mx1.freebsd.org (Postfix) with ESMTP id 47DA91EC8 for ; Wed, 20 May 2015 22:20:41 +0000 (UTC) Received: from boomhauer (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 4A8243D862 for ; Wed, 20 May 2015 18:20:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by boomhauer (boomhauer.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcAYrySEUFqq for ; Wed, 20 May 2015 18:20:34 -0400 (EDT) Received: from EGR authenticated sender mcdouga9 Message-ID: <555D08B1.2070808@egr.msu.edu> Date: Wed, 20 May 2015 18:20:33 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Change serial speed on raspberry pi? 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: Wed, 20 May 2015 22:20:42 -0000 I have been experimenting and googling for at least a half hour but am getting seemingly nowhere. Is it possible to make a raspberry pi with a serial adapter board run at a speed less than 115200? I am getting serial corruption during uboot and after the system has booted. My usual instinct is to try a slower speed but I have no idea how. I'd like it to work for the uboot environment as well as after the kernel. I should try the FreeBSD side of it but I need to switch tasks right now. Can anyone give me a hint? Is it compiled into uboot? Thanks. I have: http://www.52pi.com/en/raspberry-pi/56-original-raspberry-pi-bb-plus-accessories-rpi-uart-expand-module-uart-extend-board-.html? I've tried both I got, on two different pis, with different serial adapters and cables. From owner-freebsd-arm@FreeBSD.ORG Wed May 20 22:41:24 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DCDB839 for ; Wed, 20 May 2015 22:41:24 +0000 (UTC) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::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 EC4ED11A8 for ; Wed, 20 May 2015 22:41:23 +0000 (UTC) Received: by wghq2 with SMTP id q2so67592907wgh.1 for ; Wed, 20 May 2015 15:41:22 -0700 (PDT) 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=cGe0AOZI/zepqplLqktuEbqSpMw2OllVNXrbQDrgCmc=; b=s2yeKK7EDo+fuRxwnPiEuzHDt9avFXR+AWuX+o/EOkOxwli2Fzg5DWVkadEwbdCslJ RQbcjpPbz+pfcVhUZ641IgkJuekp3NN08VCOVLI5MCCRIGVNYn4ctpvivhXi/VPC8Nrl p9+j05U+yIpyTHfwljV2iYtn8fffwh//QTsONtSMvFA/ba6MIKU0LqzZMKd25roNd84C rlLV7sOsD8QKfNrUveAzYbNcxqmVtLB066Z0i++PJBGg+zAdTltwZdMUyru2VJ5Og006 CVe9bsULQd9nMREdQx8DpIu0wQTsQBSkqRBf0fHHQAQelP/3whpgGHpD1dFG/r6H4H2j f8Gw== MIME-Version: 1.0 X-Received: by 10.194.95.2 with SMTP id dg2mr23635126wjb.53.1432161682509; Wed, 20 May 2015 15:41:22 -0700 (PDT) Received: by 10.194.38.104 with HTTP; Wed, 20 May 2015 15:41:22 -0700 (PDT) In-Reply-To: <555D08B1.2070808@egr.msu.edu> References: <555D08B1.2070808@egr.msu.edu> Date: Thu, 21 May 2015 01:41:22 +0300 Message-ID: Subject: Re: Change serial speed on raspberry pi? From: Andrey Fesenko To: Adam McDougall 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: Wed, 20 May 2015 22:41:24 -0000 On Thu, May 21, 2015 at 1:20 AM, Adam McDougall wrote: > I have been experimenting and googling for at least a half hour but am > getting seemingly nowhere. Is it possible to make a raspberry pi with a > serial adapter board run at a speed less than 115200? I am getting > serial corruption during uboot and after the system has booted. My > usual instinct is to try a slower speed but I have no idea how. I'd > like it to work for the uboot environment as well as after the kernel. > I should try the FreeBSD side of it but I need to switch tasks right > now. Can anyone give me a hint? Is it compiled into uboot? Thanks. > > I have: > http://www.52pi.com/en/raspberry-pi/56-original-raspberry-pi-bb-plus-accessories-rpi-uart-expand-module-uart-extend-board-.html? > > I've tried both I got, on two different pis, with different serial > adapters and cables. Not quite sure which side you want to adjust the speed of the port and at what point. If side raspberrypi, you seem to help this link for FreeBSD /etc/ttys http://raspberrypi.stackexchange.com/questions/1094/how-do-you-set-the-uart-speed If you have a problem and can not be connected in any way, try a standard number 9600, 57600 ... for cu -s From owner-freebsd-arm@FreeBSD.ORG Wed May 20 22:42:58 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84CDE994 for ; Wed, 20 May 2015 22:42:58 +0000 (UTC) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EEC711C4 for ; Wed, 20 May 2015 22:42:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1432161759; l=1282; s=domk; d=ulrich-grey.de; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References: In-Reply-To:Subject:Cc:To:From:Date; bh=eClx+SqwMRXU5SgX0UzTSVhHmPj3O3sxN/lOGuOKD/g=; b=SnIrdo3WZRuvQiA49BW5+NjN0KNuPKmCy9njcv281cTZgACKI+98L+1/oWMttOGL/SU DZ0UVJkQ+x9SKKKpyChVSf9+yVZQpK7+kPGZr4JdXdgOywGQCirBKX0f1HeKj3vFihlTR gjXQy0bn6gIfp0yvLkSql3xGoPSC+C7Dow0= X-RZG-AUTH: :OX8Be0W8W+pMC3rDLL/lo2xV/LZTbZkYhOcjg8suic3iYr/B8J9Lzp3TJg48sMv/wSLh X-RZG-CLASS-ID: mo00 Received: from quad (p54869470.dip0.t-ipconnect.de [84.134.148.112]) by smtp.strato.de (RZmta 37.6 DYNA|AUTH) with ESMTPSA id h01313r4KMgdNVr (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve sect571r1 with 571 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Thu, 21 May 2015 00:42:39 +0200 (CEST) Date: Wed, 20 May 2015 22:42:37 +0000 From: Ulrich Grey To: Adam McDougall Cc: freebsd-arm@freebsd.org Subject: Re: Change serial speed on raspberry pi? Message-Id: <20150520224237.ae19ac81378b480ff3d41022@ulrich-grey.de> In-Reply-To: <555D08B1.2070808@egr.msu.edu> References: <555D08B1.2070808@egr.msu.edu> Organization: - X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.25; armv6-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Wed, 20 May 2015 22:42:58 -0000 This works for me: cu -l/dev/cuaU0 -s115200 In /etc/ttys: ttyu0 "/usr/libexec/getty 3wire.115200" dialup on secure ---------------------------------- On Wed, 20 May 2015 18:20:33 -0400 Adam McDougall wrote: > I have been experimenting and googling for at least a half hour but am > getting seemingly nowhere. Is it possible to make a raspberry pi with a > serial adapter board run at a speed less than 115200? I am getting > serial corruption during uboot and after the system has booted. My > usual instinct is to try a slower speed but I have no idea how. I'd > like it to work for the uboot environment as well as after the kernel. > I should try the FreeBSD side of it but I need to switch tasks right > now. Can anyone give me a hint? Is it compiled into uboot? Thanks. > > I have: > http://www.52pi.com/en/raspberry-pi/56-original-raspberry-pi-bb-plus-accessories-rpi-uart-expand-module-uart-extend-board-.html? > > I've tried both I got, on two different pis, with different serial > adapters and cables. > _______________________________________________ > 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 Thu May 21 04:05:45 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 888B35F2 for ; Thu, 21 May 2015 04:05:45 +0000 (UTC) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::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 24ACF16CB for ; Thu, 21 May 2015 04:05:45 +0000 (UTC) Received: by wicmc15 with SMTP id mc15so568976wic.1 for ; Wed, 20 May 2015 21:05:43 -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=0cnVJ2kA65Kfoaai0nEbTkz+4mCgIm0wt6+dTYzo0zw=; b=wqA+avCRCxUlbErv76OJ3KZ03gw06zl07oqBsODfAShkF3QaITLtQFL5dPH4sHFtbN LLxoP3qEq+zdI9aujBwyci9m3kVQJoIb4UMj6LHfCXgayCv0Xqtxu7bPi+MiIgcE/gf6 +pIGsNgL0/ltO+YbhAsLlGXUiSlQDbZ+D7tTHLYOKVXMURFoywZgGeR/9lUZqoW2l0zF eE9BhoG1IZT4cJJyLsY54tyijeEuKm9OBvYwGKois1uLKNMb/r7uIA4KRmZETqSjBmi2 wcqI5yEnAn7fU1rX9J0xlyxoZ3R8tU4btzIejroVdhNLz39IGq4uDISlGMObTtJUKmEe sqMQ== MIME-Version: 1.0 X-Received: by 10.180.160.169 with SMTP id xl9mr24854936wib.42.1432181143695; Wed, 20 May 2015 21:05:43 -0700 (PDT) Received: by 10.27.219.14 with HTTP; Wed, 20 May 2015 21:05:43 -0700 (PDT) Date: Thu, 21 May 2015 01:05:43 -0300 Message-ID: Subject: /dev/openfirm From: =?UTF-8?Q?Mat=C3=ADas_Perret_Cantoni?= To: freebsd-arm@freebsd.org 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, 21 May 2015 04:05:45 -0000 Hi! Can someone give me an idea of what the node /dev/openfirm is for? I tried manuals for "openfirm" and "ofw" but I didn't succeed. My system is 10.1-RELEASE FreeBSD armv6 Thanks! From owner-freebsd-arm@FreeBSD.ORG Thu May 21 05:53:11 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77551B6D for ; Thu, 21 May 2015 05:53:11 +0000 (UTC) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (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 4919A1244 for ; Thu, 21 May 2015 05:53:10 +0000 (UTC) Received: by igbyr2 with SMTP id yr2so1687608igb.0 for ; Wed, 20 May 2015 22:53:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=rAsZtKSqXt+HSUVr8VVA2zrjRh0VJQvdriQJcLQthME=; b=VDjuRWai8CNn9XxAgit5+8h3DB+FFJT3HLJhqEJkxsBcy5VddP130CEPWnewJ6q+YC lqBm81kUvIHcNQ+xJ3KIWFs0GenDMD8OhjTCesqjeAf/2nIyuPCNzYMOFg/DT8amx/UR omgv9BNhhW4A5t7KdWRH3RhkXufxmV1Jto2pOHj/By3M13T4yN8FXJM9EucCr8z0lnr1 euWRQYmAXp6j4bpIFAsnqur2bDClWyDUxFtGvVN49Hc4CJJQw+0RB+mClgc1prTSv3u5 zn8xmL1lX02rKhJAATQLxETTLo5ih4ewXHoef8kNVhse0SjTBaWKR9J/vNhIly9WPs0A DsNw== X-Gm-Message-State: ALoCoQkWScwA7GEfj37CV09dqcj3CiWk+6+T87ncQ9Ju2x9QlG0/xLCms7XtdnNKbTBbtu7Q1bbC MIME-Version: 1.0 X-Received: by 10.43.167.137 with SMTP id ne9mr1464731icc.7.1432187589900; Wed, 20 May 2015 22:53:09 -0700 (PDT) Received: by 10.36.28.201 with HTTP; Wed, 20 May 2015 22:53:09 -0700 (PDT) Date: Thu, 21 May 2015 07:53:09 +0200 Message-ID: Subject: smsc0 driver on rpi2 From: Andreas Andersson To: freebsd-arm@freebsd.org 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, 21 May 2015 05:53:11 -0000 I am getting alot of: smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to read register 0x114 smsc0: warning: MII read timeout smsc0: warning: Failed to read register 0x114 smsc0: warning: MII read timeout smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII read timeout smsc0: warning: Failed to write register 0x114 smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII read timeout smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy . This happends when the rpi2 has been turned on for some while. And the raspberry becomes pretty slow and laggy when this error occurs. CPU when looking at top is pretty much idle across all cores, but load averages are: 7:23AM up 13:51, 5 users, load averages: 3.70, 3.37, 3.24 Can I somehow debug this to give you more information? From owner-freebsd-arm@FreeBSD.ORG Thu May 21 05:57:47 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93B45C40 for ; Thu, 21 May 2015 05:57:47 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 7D234127C for ; Thu, 21 May 2015 05:57:47 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t4L5kU0F023582 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 May 2015 22:46:31 -0700 Message-ID: <555D7136.9050303@freebsd.org> Date: Wed, 20 May 2015 22:46:30 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: /dev/openfirm References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVYPc9tvp0eAcc1Q3m6vV87iZ4Gs0Jxfv6I738vxmStkdngnbQBP1aF7IwpxmMZTP0XuGR8Pi7vDd+dB42hJDGgf0GTYU4dNiA4= X-Sonic-ID: C;+Lj5unz/5BG+MfjYVPtzAg== M;xhJeu3z/5BG+MfjYVPtzAg== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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, 21 May 2015 05:57:47 -0000 It allows you to dump the contents of the flattened device tree. "ofwdump" is the tool that uses it. -Nathan On 05/20/15 21:05, Matías Perret Cantoni wrote: > Hi! > > Can someone give me an idea of what the node /dev/openfirm is for? > > I tried manuals for "openfirm" and "ofw" but I didn't succeed. > > My system is 10.1-RELEASE FreeBSD armv6 > > Thanks! > _______________________________________________ > 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 Thu May 21 13:01:04 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7727F2AC; Thu, 21 May 2015 13:01:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 624211964; Thu, 21 May 2015 13:01:04 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id E3AF8B7C; Thu, 21 May 2015 13:01:04 +0000 (UTC) Date: Thu, 21 May 2015 13:01:04 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-arm@freebsd.org, bapt@FreeBSD.org Message-ID: <1994297852.33.1432213264834.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_HEAD_arm64 #180 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE 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, 21 May 2015 13:01:04 -0000 See Changes: [bapt] Drop libmandoc and incorporate it into the main mandoc Makefile This simplifies maintainance of mandoc(1). Note that the same direction was taken on OpenBSD ------------------------------------------ [...truncated 22589 lines...] --- usr.sbin.cleandir__D --- --- cleanobj --- --- lib.cleandir__D --- (cd && make -f Makefile _RECURSING_PROGS= SUBDIR= PROG=getitimer_test DEPENDFILE=.depend.getitimer_test .MAKE.DEPENDFILE=.depend.getitimer_test cleandepend) --- usr.sbin.cleandir__D --- --- cleandir_subdir_syslogd --- ===> usr.sbin/syslogd (cleandir) --- usr.bin.cleandir__D --- --- clean --- --- lib.cleandir__D --- --- _sub.cleandir --- --- clean --- --- usr.bin.cleandir__D --- rm -f cut_test cut_test.tmp Kyuafile.auto Kyuafile.auto.tmp --- lib.cleandir__D --- rm -f Kyuafile.auto Kyuafile.auto.tmp wcspbrk_test t_wcspbrk.o --- cleandepend --- --- usr.bin.cleandir__D --- --- scripts.cleandepend --- --- lib.cleandir__D --- rm -f .depend.wcspbrk_test GPATH GRTAGS GSYMS GTAGS --- usr.bin.cleandir__D --- (cd && make -f Makefile SUBDIR= _RECURSING_PROGS= cleandepend) --- lib.cleandir__D --- --- cleanobj --- (cd && make -f Makefile _RECURSING_PROGS= SUBDIR= PROG=wcsspn_test DEPENDFILE=.depend.wcsspn_test .MAKE.DEPENDFILE=.depend.wcsspn_test cleandir) --- usr.sbin.cleandir__D --- --- cleanobj --- --- lib.cleandir__D --- --- _sub.cleandepend --- --- cleandepend --- rm -f .depend.getitimer_test GPATH GRTAGS GSYMS GTAGS --- usr.sbin.cleandir__D --- --- cleandir_subdir_sysrc --- ===> usr.sbin/sysrc (cleandir) --- lib.cleandir__D --- (cd && make -f Makefile _RECURSING_PROGS= SUBDIR= PROG=getlogin_test DEPENDFILE=.depend.getlogin_test .MAKE.DEPENDFILE=.depend.getlogin_test cleandepend) --- usr.bin.cleandir__D --- --- scripts.cleanobj --- (cd && make -f Makefile SUBDIR= _RECURSING_PROGS= cleanobj) --- lib.cleandir__D --- --- _sub.cleandir --- --- clean --- rm -f Kyuafile.auto Kyuafile.auto.tmp wcsspn_test t_wcsspn.o --- cleandepend --- rm -f .depend.wcsspn_test GPATH GRTAGS GSYMS GTAGS --- cleanobj --- (cd && make -f Makefile _RECURSING_PROGS= SUBDIR= PROG=wcstod_test DEPENDFILE=.depend.wcstod_test .MAKE.DEPENDFILE=.depend.wcstod_test cleandir) --- usr.sbin.cleandir__D --- --- cleanobj --- --- usr.bin.cleandir__D --- --- clean --- rm -f cut_test cut_test.tmp Kyuafile.auto Kyuafile.auto.tmp --- usr.sbin.cleandir__D --- --- cleandir_subdir_tcpdchk --- ===> usr.sbin/tcpdchk (cleandir) --- usr.bin.cleandir__D --- --- cleanobj --- --- lib.cleandir__D --- --- _sub.cleandepend --- --- cleandepend --- rm -f .depend.getlogin_test GPATH GRTAGS GSYMS GTAGS --- usr.bin.cleandir__D --- --- scripts.cleandir --- (cd && make -f Makefile SUBDIR= _RECURSING_PROGS= cleandir) --- lib.cleandir__D --- (cd && make -f Makefile _RECURSING_PROGS= SUBDIR= PROG=getpid_test DEPENDFILE=.depend.getpid_test .MAKE.DEPENDFILE=.depend.getpid_test cleandepend) --- _sub.cleandir --- --- clean --- rm -f Kyuafile.auto Kyuafile.auto.tmp wcstod_test t_wcstod.o --- cleandepend --- rm -f .depend.wcstod_test GPATH GRTAGS GSYMS GTAGS --- cleanobj --- --- usr.sbin.cleandir__D --- --- cleanobj --- --- usr.bin.cleandir__D --- --- clean --- rm -f cut_test cut_test.tmp Kyuafile.auto Kyuafile.auto.tmp --- lib.cleandir__D --- --- _sub.cleandepend --- --- cleandepend --- rm -f .depend.getpid_test GPATH GRTAGS GSYMS GTAGS --- _sub.cleandir --- (cd && make -f Makefile _RECURSING_PROGS= SUBDIR= PROG=wctomb_test DEPENDFILE=.depend.wctomb_test .MAKE.DEPENDFILE=.depend.wctomb_test cleandir) --- usr.bin.cleandir__D --- --- cleanobj --- --- usr.sbin.cleandir__D --- --- cleandir_subdir_tcpdmatch --- ===> usr.sbin/tcpdmatch (cleandir) --- lib.cleandir__D --- --- _sub.cleandepend --- (cd && make -f Makefile _RECURSING_PROGS= SUBDIR= PROG=getrusage_test DEPENDFILE=.depend.getrusage_test .MAKE.DEPENDFILE=.depend.getrusage_test cleandepend) --- usr.bin.cleandir__D --- --- clean --- rm -f cut_test cut_test.tmp Kyuafile.auto Kyuafile.auto.tmp --- cleanobj --- --- cleandir_subdir_cxxfilt --- ===> usr.bin/cxxfilt (cleandir) --- lib.cleandir__D --- --- _sub.cleandir --- --- clean --- rm -f Kyuafile.auto Kyuafile.auto.tmp wctomb_test t_wctomb.o --- usr.sbin.cleandir__D --- --- cleanobj --- --- lib.cleandir__D --- --- cleandepend --- rm -f .depend.wctomb_test GPATH GRTAGS GSYMS GTAGS --- cleanobj --- --- usr.sbin.cleandir__D --- --- cleandir_subdir_tcpdrop --- ===> usr.sbin/tcpdrop (cleandir) --- lib.cleandir__D --- rm -f Kyuafile.auto Kyuafile.auto.tmp --- usr.bin.cleandir__D --- --- cleanobj --- --- lib.cleandir__D --- --- _sub.cleandepend --- --- cleandepend --- rm -f .depend.getrusage_test GPATH GRTAGS GSYMS GTAGS --- _sub.cleandir --- ===> lib/libc/tests/ssp (cleandir) --- _sub.cleandepend --- (cd && make -f Makefile _RECURSING_PROGS= SUBDIR= PROG=getsid_test DEPENDFILE=.depend.getsid_test .MAKE.DEPENDFILE=.depend.getsid_test cleandepend) --- usr.bin.cleandir__D --- --- cleandir_subdir_dc --- ===> usr.bin/dc (cleandir) --- usr.sbin.cleandir__D --- --- cleanobj --- --- cleandir_subdir_tcpdump --- ===> usr.sbin/tcpdump (cleandir) --- usr.bin.cleandir__D --- --- cleanobj --- --- lib.cleandir__D --- --- cleandepend --- --- _sub.cleandir --- (cd && make -f Makefile _RECURSING_PROGS= SUBDIR= PROG=h_fgets DEPENDFILE=.depend.h_fgets .MAKE.DEPENDFILE=.depend.h_fgets clean) --- _sub.cleandepend --- rm -f .depend.getsid_test GPATH GRTAGS GSYMS GTAGS (cd && make -f Makefile _RECURSING_PROGS= SUBDIR= PROG=gettimeofday_test DEPENDFILE=.depend.gettimeofday_test .MAKE.DEPENDFILE=.depend.gettimeofday_test cleandepend) --- usr.bin.cleandir__D --- --- cleandir_subdir_demandoc --- ===> usr.bin/demandoc (cleandir) --- usr.sbin.cleandir__D --- --- _sub.cleandir --- ===> usr.sbin/tcpdump/tcpdump (cleandir) --- lib.cleandir__D --- --- _sub.cleandir --- --- clean --- rm -f ssp_test ssp_test.tmp Kyuafile.auto Kyuafile.auto.tmp h_fgets h_fgets.o (cd && make -f Makefile _RECURSING_PROGS= SUBDIR= PROG=h_gets DEPENDFILE=.depend.h_gets .MAKE.DEPENDFILE=.depend.h_gets clean) --- _sub.cleandepend --- --- cleandepend --- --- usr.bin.cleandir__D --- make[4]: " line 303: Missing DPADD_mandoc variable add "mandoc" to _LIBRARIES, _INTERNALLIBS, or _PRIVATELIBS and define "LIBMANDOC". --- lib.cleandir__D --- rm -f .depend.gettimeofday_test GPATH GRTAGS GSYMS GTAGS --- usr.bin.cleandir__D --- *** [cleandir_subdir_demandoc] Error code 1 make[3]: stopped in 1 error make[3]: stopped in --- lib.cleandir__D --- A failure has been detected in another branch of the parallel make make[7]: stopped in *** [gettimeofday_test.cleandepend] Error code 2 make[6]: stopped in 1 error make[6]: stopped in --- usr.bin.cleandir__D --- *** [usr.bin.cleandir__D] Error code 2 make[2]: stopped in --- lib.cleandir__D --- *** [_sub.cleandepend] Error code 2 make[5]: stopped in --- _sub.cleandir --- A failure has been detected in another branch of the parallel make make[7]: stopped in *** [h_gets.clean] Error code 2 make[6]: stopped in 1 error make[6]: stopped in *** [_sub.cleandir] Error code 2 make[5]: stopped in 2 errors make[5]: stopped in *** [_sub.cleandir] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [cleandir_subdir_libc] Error code 2 make[3]: stopped in 1 error make[3]: stopped in --- usr.sbin.cleandir__D --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [_sub.cleandir] Error code 2 make[4]: stopped in 1 error make[4]: stopped in --- lib.cleandir__D --- *** [lib.cleandir__D] Error code 2 make[2]: stopped in --- usr.sbin.cleandir__D --- *** [cleandir_subdir_tcpdump] Error code 2 make[3]: stopped in 1 error make[3]: stopped in *** [usr.sbin.cleandir__D] Error code 2 make[2]: stopped in 3 errors make[2]: stopped in *** [_cleanobj] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-arm@FreeBSD.ORG Thu May 21 18:54:19 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07F3861B; Thu, 21 May 2015 18:54:19 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id E9001183A; Thu, 21 May 2015 18:54:18 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 4F057C00; Thu, 21 May 2015 18:54:19 +0000 (UTC) Date: Thu, 21 May 2015 18:54:19 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-arm@freebsd.org, jhb@FreeBSD.org, bapt@FreeBSD.org, jmg@FreeBSD.org, pfg@FreeBSD.org, imp@FreeBSD.org Message-ID: <141226194.35.1432234459174.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1994297852.33.1432213264834.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1994297852.33.1432213264834.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_HEAD_arm64 #181 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Instance-Identity: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkKKb2VAfYQKfu1t7qk4nR5qzUBEI+UqT4BPec4qHVhqUy0FFdq50sMH+3y9bCDNOufctov6VqTNffZ3YXArnZK95YF0OX97fh+E9txYOUX1adc+TikcKjuYpHmL5dE62eaZTI+4A5jnRonskQ1PaoIFz0Kbu4mWzkFsmdiXTraGzomXq4cHUCATA2+K4eDYgjXEQI30z3GOMmmZ4t/+6QGk1cMb/BqMWHbn80AsRCb4tU7Hpd72XLDpsuO7YRP1Q0CjmNAuBOTj+sFiiOe6U9HpqOlQN+iFUvBdZo/ybuy5Kh71cAaYQNL68cYdZJ6binH/DkG3KY/fS7DFYAeuwjwIDAQAB X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS 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, 21 May 2015 18:54:19 -0000 See From owner-freebsd-arm@FreeBSD.ORG Fri May 22 01:06:01 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 620D57E6 for ; Fri, 22 May 2015 01:06:01 +0000 (UTC) Received: from shadow.sentry.org (shadow.sentry.org [220.233.87.20]) (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 D759D1183 for ; Fri, 22 May 2015 01:06:00 +0000 (UTC) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.14.9/8.14.9) with ESMTP id t4M15uvP011243 for ; Fri, 22 May 2015 11:05:56 +1000 (AEST) (envelope-from trev@sentry.org) Message-ID: <555E80F4.7030300@sentry.org> Date: Fri, 22 May 2015 11:05:56 +1000 From: Trevor Roydhouse Organization: Sentry User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Raspberry Pi 2 - Xorg issues Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (shadow.sentry.org [127.0.0.1]); Fri, 22 May 2015 11:05:56 +1000 (AEST) 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, 22 May 2015 01:06:01 -0000 uname: FreeBSD 11.0-CURRENT #0 r282694: Sun May 10 04:33:02 UTC 2015 dmesg: fb0: on ofwbus0 fbd0 on fb0 VT: initialize with new VT driver "fb". fb0: 1824x984(1824x984@0,0) 24bpp fb0: fbswap: 1, pitch 5472, base 0x3d359000, screen_size 5428224 Xorg.conf: Section "Screen" Identifier "Screen" Device "Generic FB" Monitor "Monitor" DefaultDepth 16 SubSection "Display" Depth 16 EndSubsection EndSection Produces Xorg.0.log: [ 1051.191] (II) scfb: driver for wsdisplay framebuffer: scfb [ 1051.272] (--) Using syscons driver with X support (version 2.0) [ 1051.272] (--) using VT number 5 [ 1051.272] (WW) Falling back to old probe method for scfb [ 1051.272] scfb trace: probe start [ 1051.272] (II) scfb(0): using default device [ 1051.273] scfb trace: probe done [ 1051.273] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 1051.273] scfb: PreInit 0 [ 1051.273] (II) scfb(0): Using: depth (24), width (1824), height (984) [ 1051.273] (EE) scfb(0): specified depth (16) or bpp (16) doesn't match framebuffer depth (24) [ 1051.273] (II) UnloadModule: "scfb" [ 1051.273] (EE) Screen(s) found, but none have a usable configuration. Xorg.conf: Section "Screen" Identifier "Screen" Device "Generic FB" Monitor "Monitor" DefaultDepth 24 SubSection "Display" Depth 24 EndSubsection EndSection Produces Xorg.0.log: [ 1286.519] (II) scfb: driver for wsdisplay framebuffer: scfb [ 1286.640] (--) Using syscons driver with X support (version 2.0) [ 1286.640] (--) using VT number 5 [ 1286.640] (WW) Falling back to old probe method for scfb [ 1286.641] scfb trace: probe start [ 1286.641] (II) scfb(0): using default device [ 1286.641] scfb trace: probe done [ 1286.641] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 1286.641] scfb: PreInit 0 [ 1286.641] (II) scfb(0): Using: depth (24), width (1824), height (984) [ 1286.641] (EE) scfb(0): specified depth (24) or bpp (32) doesn't match framebuffer depth (24) [ 1286.641] (II) UnloadModule: "scfb" [ 1286.642] (EE) Screen(s) found, but none have a usable configuration. Solution to get X up: Leave out DefaultDepth nn in the Screen section, but this yields very slow motion screen draws and long cursor tails. However, if I run a find / in an xterm, screen draws return to normal until find finishes... weird. Any other solutions? -- Trevor Roydhouse BJuris, LLB, LLM (UNSW) Systems Developer Australasian Legal Information Institute Web : www.austlii.edu.au From owner-freebsd-arm@FreeBSD.ORG Fri May 22 04:17:56 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5B57252 for ; Fri, 22 May 2015 04:17:56 +0000 (UTC) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) (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 7F518152F for ; Fri, 22 May 2015 04:17:55 +0000 (UTC) Received: from [208.184.220.60] (helo=macbook-air-2.dolby.net) by id.bluezbox.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YvdoU-000ITQ-Vg for freebsd-arm@freebsd.org; Thu, 21 May 2015 20:40:01 -0700 From: Oleksandr Tymoshenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: TI platforms code update: switching to vendor FDT data Message-Id: Date: Thu, 21 May 2015 20:37:29 -0700 To: "freebsd-arm@freebsd.org List" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Sender: gonzo@id.bluezbox.com X-Spam-Level: - X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hello, I've just committed (r283276) major code update for TI platforms support. It gets rid of custom-baked .dts files for Beaglebone/Pandaboard and switches to using FDT data provided by TI and/or boards/capes manufacturers. [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% [score: 0.2338] 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, 22 May 2015 04:17:56 -0000 Hello, I've just committed (r283276) major code update for TI platforms support. It gets rid of custom-baked .dts files for Beaglebone/Pandaboard and switches to using FDT data provided by TI and/or boards/capes manufacturers. Filenames for dtb files are the same but content is quite different so make sure to install new files as a part of kernel update process. I tried to maintain compatibility with existing systems as much as possible but difference is too large so several incompatibilities were introduced after all: GPIO addressing was changed: instead of one global /dev/gpioc0 there are per-bank instances of /dev/gpiocX. Each bank has 32 pins so for instance pin 121 on /dev/gpioc0 in old addressing scheme is now pin 25 on /dev/gpioc3. The reason for this is that each bank presented as FDT node and we do not have way to "glue" multiple GPIO controllers into one addressing space (at least yet). It affects both Pandaboard and Beaglebone-based systems. On Pandaboard serial console devices was changed from /dev/ttyu0 to /dev/ttyu2 so you'll have to update /etc/ttys to get login prompt on serial port in multiuser mode. Single user mode serial console should work as-is My testing was quite limited and real-life deployments may reveal more problems. If you happen to run into one - please send report to this mailing list (freebsd-arm) Thank you -- gonzo From owner-freebsd-arm@FreeBSD.ORG Fri May 22 15:43:32 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2CF9CC7 for ; Fri, 22 May 2015 15:43:32 +0000 (UTC) Received: from mail-vn0-x236.google.com (mail-vn0-x236.google.com [IPv6:2607:f8b0:400c:c0f::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 4B179166C for ; Fri, 22 May 2015 15:43:32 +0000 (UTC) Received: by vnbf190 with SMTP id f190so1537375vnb.5 for ; Fri, 22 May 2015 08:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=xce5hk1G+zl9P0ZBFyfDyIm5jBSseWlEsaNZDDHxrn8=; b=nPBd7J84rNpM622wX/RCRyuZtioBl9H8+BYctBmLaKoTnwG29P3ByyReGGVLkMTOc9 FD5q0sBZ5F3Lmeznw6eDuOP6JX2jyJsv585LdgKYaRrxisMcnam1gfKmP7boFlACl1fm 1wI1r1wBdmhY2i21ormNT+ghOGaxw+fMYCJSMK8yk99UnPCO5YebKMUdXzX77GVuHzGn YnMe/NaMUSgrkhiNEZbYwlDI3IdDx3Y567jDLWex8RzaUUt4KV3Oe53S8mcQY79gsOo0 A+JHA4xOeYoxcqaxb1NNvtBlF9Or/fuME+e9pLrEjyht8wYN39Pyw4hUPRALIMkPEs0G 100Q== X-Received: by 10.52.5.2 with SMTP id o2mr7585275vdo.97.1432309411266; Fri, 22 May 2015 08:43:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.185.134 with HTTP; Fri, 22 May 2015 08:43:10 -0700 (PDT) From: Pratik Singhal Date: Fri, 22 May 2015 21:13:10 +0530 Message-ID: Subject: Lock order traversal while running ~head on cubieboard To: "freebsd-arm@freebsd.org" 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, 22 May 2015 15:43:32 -0000 I am getting the following lock order traversal error on running ~head on cubieboard All buffers synced. lock order reversal: 1st 0xc3e54b74 ufs (ufs) @ /root/pratiksinghal/cubie-head/sys/kern/vfs_mount.c:1229 2nd 0xc3e55154 devfs (devfs) @ /root/pratiksinghal/cubie-head/sys/kern/vfs_subr.c:2176 KDB: stack backtrace: lock order reversal: (sleepable after non-sleepable) 1st 0xc3e55174 vnode interlock (vnode interlock) @ /root/pratiksinghal/cubie-head/sys/fs/devfs/devfs_vnops.c:434 2nd 0xc0706d50 kernel linker (kernel linker) @ /root/pratiksinghal/cubie-head/sys/kern/kern_linker.c:552 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc05c2aa8 lr = 0xc0234b2c (db_fetch_ksymtab+0x16c) sp = 0xd84c67b0 fp = 0xd84c68c8 r10 = 0xc06136e6 db_fetch_ksymtab() at db_fetch_ksymtab+0x16c pc = 0xc0234b2c lr = 0xc03c18a0 (witness_checkorder+0xf0c) sp = 0xd84c68d0 fp = 0xd84c6918 r4 = 0xc0619e8f r5 = 0xc0706d50 r6 = 0xc0619a85 r7 = 0xc06136e6 witness_checkorder() at witness_checkorder+0xf0c pc = 0xc03c18a0 lr = 0xc036f7ec (_sx_xlock+0x80) sp = 0xd84c6920 fp = 0xd84c6950 r4 = 0x00000228 r5 = 0xc0619a85 r6 = 0xc0706d60 r7 = 0xc0706d50 r8 = 0x00000000 r9 = 0xc064cb88 r10 = 0xc06136e6 _sx_xlock() at _sx_xlock+0x80 pc = 0xc036f7ec lr = 0xc0346354 (linker_file_foreach+0x34) sp = 0xd84c6958 fp = 0xd84c6970 r4 = 0xc0706d30 r5 = 0xd84c6978 r6 = 0xc05d9eb0 r7 = 0xc05c2aa8 r8 = 0xc0706d50 r10 = 0xc06136e6 linker_file_foreach() at linker_file_foreach+0x34 pc = 0xc0346354 lr = 0xc05d9acc (unwind_stack_one+0x5c) sp = 0xd84c6978 fp = 0xd84c69a0 r4 = 0xd84c69e0 r5 = 0xd84c6978 r6 = 0x00000000 r7 = 0xc05c2aa8 r8 = 0xc06becfc r10 = 0xc06136e6 unwind_stack_one() at unwind_stack_one+0x5c pc = 0xc05d9acc lr = 0xc05c2940 (db_trace_thread+0xac) sp = 0xd84c69a8 fp = 0xd84c69d8 r4 = 0xd84c69e0 r5 = 0xc062e9ce r6 = 0x00000000 r7 = 0xc061e377 r8 = 0xc3e54b74 r9 = 0xc064cb88 r10 = 0xc06136e6 db_trace_thread() at db_trace_thread+0xac pc = 0xc05c2940 lr = 0xc05c2ad8 (db_trace_self+0x30) sp = 0xd84c69e0 fp = 0xd84c6a38 r4 = 0x00000000 r5 = 0xd84c6a44 r6 = 0xc062eb02 r7 = 0xc06136e6 r8 = 0xc3e54b74 r9 = 0xc0747ee4 r10 = 0xc06136e6 db_trace_self() at db_trace_self+0x30 pc = 0xc05c2ad8 lr = 0xc0234b2c (db_fetch_ksymtab+0x16c) sp = 0xd84c6a40 fp = 0xd84c6b58 r10 = 0xc06136e6 db_fetch_ksymtab() at db_fetch_ksymtab+0x16c pc = 0xc0234b2c lr = 0xc03c18a0 (witness_checkorder+0xf0c) sp = 0xd84c6b60 fp = 0xd84c6ba8 r4 = 0xc0619583 r5 = 0xc3e55154 r6 = 0xc062eb02 r7 = 0xc06136e6 witness_checkorder() at witness_checkorder+0xf0c pc = 0xc03c18a0 lr = 0xc0349ef0 (__lockmgr_args+0x82c) sp = 0xd84c6bb0 fp = 0xd84c6c18 r4 = 0xc062eb02 r5 = 0xc0619583 r6 = 0x00080500 r7 = 0x00000100 r8 = 0xc3e55154 r9 = 0xc3f31660 r10 = 0x00080000 __lockmgr_args() at __lockmgr_args+0x82c pc = 0xc0349ef0 lr = 0xc04052e0 (vop_stdlock+0x3c) sp = 0xd84c6c20 fp = 0xd84c6c30 r4 = 0xd84c6c50 r5 = 0xc06e3938 r6 = 0x00000000 r7 = 0x00080500 r8 = 0xd84c6c50 r9 = 0x00000880 r10 = 0xc060ca74 vop_stdlock() at vop_stdlock+0x3c pc = 0xc04052e0 lr = 0xc05e62c8 (VOP_LOCK1_APV+0xe8) sp = 0xd84c6c38 fp = 0xd84c6c48 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xe8 pc = 0xc05e62c8 lr = 0xc04236b4 (_vn_lock+0x48) sp = 0xd84c6c50 fp = 0xd84c6c80 r4 = 0xc3e55120 r5 = 0xc3d34bc0 r6 = 0xc062eb02 r10 = 0xc060ca74 _vn_lock() at _vn_lock+0x48 pc = 0xc04236b4 lr = 0xc0414394 (vget+0x60) sp = 0xd84c6c88 fp = 0xd84c6ca8 r4 = 0xc3e55120 r5 = 0xc3d34bc0 r6 = 0x00080500 r7 = 0xc3d34bd4 r8 = 0xc3f31660 r9 = 0x00080500 r10 = 0xc060ca74 vget() at vget+0x60 pc = 0xc0414394 lr = 0xc0296b48 (devfs_allocv+0xfc) sp = 0xd84c6cb0 fp = 0xd84c6ce0 r4 = 0xc07781e4 r5 = 0xc3d34bc0 r6 = 0xc3f2b400 r7 = 0xc3d34bd4 r8 = 0xc3e55120 r10 = 0xc060ca74 devfs_allocv() at devfs_allocv+0xfc pc = 0xc0296b48 lr = 0xc02965f4 (devfs_unmount_final+0x4ec) sp = 0xd84c6ce8 fp = 0xd84c6d00 r4 = 0xd84c6d20 r5 = 0xc3f6c560 r6 = 0xc3d34bc0 r7 = 0x00000000 r8 = 0xc3e54b40 r9 = 0x00080000 r10 = 0xc3f31660 devfs_unmount_final() at devfs_unmount_final+0x4ec pc = 0xc02965f4 lr = 0xc040d888 (dounmount+0x3b8) sp = 0xd84c6d08 fp = 0xd84c6d50 r4 = 0x00000000 r5 = 0x00080000 r6 = 0xc062e0cb r10 = 0xc3f31660 dounmount() at dounmount+0x3b8 pc = 0xc040d888 lr = 0xc0416658 (vfs_unmountall+0x58) sp = 0xd84c6d58 fp = 0xd84c6d78 r4 = 0xc3f31660 r5 = 0xc0619583 r6 = 0xd9114eb0 r7 = 0xc3f6c560 r8 = 0xc06e3be0 r9 = 0xc063efaa r10 = 0xc062f19b vfs_unmountall() at vfs_unmountall+0x58 pc = 0xc0416658 lr = 0xc03677a8 (kern_reboot+0x4f0) sp = 0xd84c6d80 fp = 0xd84c6dd8 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xd9114eb0 r7 = 0xd9114eb0 r8 = 0x00000000 r9 = 0xc06f3a24 r10 = 0xc07798c4 kern_reboot() at kern_reboot+0x4f0 pc = 0xc03677a8 lr = 0xc03672b8 (kern_reboot) sp = 0xd84c6de0 fp = 0xd84c6de8 r4 = 0xd84c6e08 r5 = 0xc3f28000 r6 = 0x60000013 r7 = 0x00000000 r8 = 0xd84c6e00 r9 = 0x00000000 r10 = 0x00000004 kern_reboot() at kern_reboot pc = 0xc03672b8 lr = 0xc05d8628 (swi_handler+0x29c) sp = 0xd84c6df0 fp = 0xd84c6e50 r4 = 0xd84c6e00 r5 = 0x00000000 r6 = 0x00000004 r7 = 0xd84c6de8 r8 = 0xc03672b8 r9 = 0xc3f31660 r10 = 0x00000004 swi_handler() at swi_handler+0x29c pc = 0xc05d8628 lr = 0xc05c40c0 (swi_exit) sp = 0xd84c6e58 fp = 0xbfbffe00 r4 = 0x00000004 r5 = 0x00000002 r6 = 0xbfbffddc r7 = 0x00000037 r8 = 0x00000000 r9 = 0x00000000 r10 = 0x00000004 swi_exit() at swi_exit pc = 0xc05c40c0 lr = 0xc05c40c0 (swi_exit) sp = 0xd84c6e58 fp = 0xbfbffe00 db_trace_self() at db_trace_self pc = 0xc05c2aa8 lr = 0xc0234b2c (db_fetch_ksymtab+0x16c) sp = 0xd84c6a40 fp = 0xd84c6b58 r10 = 0xc06136e6 db_fetch_ksymtab() at db_fetch_ksymtab+0x16c pc = 0xc0234b2c lr = 0xc03c18a0 (witness_checkorder+0xf0c) sp = 0xd84c6b60 fp = 0xd84c6ba8 r4 = 0xc0619583 r5 = 0xc3e55154 r6 = 0xc062eb02 r7 = 0xc06136e6 witness_checkorder() at witness_checkorder+0xf0c pc = 0xc03c18a0 lr = 0xc0349ef0 (__lockmgr_args+0x82c) sp = 0xd84c6bb0 fp = 0xd84c6c18 r4 = 0xc062eb02 r5 = 0xc0619583 r6 = 0x00080500 r7 = 0x00000100 r8 = 0xc3e55154 r9 = 0xc3f31660 r10 = 0x00080000 __lockmgr_args() at __lockmgr_args+0x82c pc = 0xc0349ef0 lr = 0xc04052e0 (vop_stdlock+0x3c) sp = 0xd84c6c20 fp = 0xd84c6c30 r4 = 0xd84c6c50 r5 = 0xc06e3938 r6 = 0x00000000 r7 = 0x00080500 r8 = 0xd84c6c50 r9 = 0x00000880 r10 = 0xc060ca74 vop_stdlock() at vop_stdlock+0x3c pc = 0xc04052e0 lr = 0xc05e62c8 (VOP_LOCK1_APV+0xe8) sp = 0xd84c6c38 fp = 0xd84c6c48 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xe8 pc = 0xc05e62c8 lr = 0xc04236b4 (_vn_lock+0x48) sp = 0xd84c6c50 fp = 0xd84c6c80 r4 = 0xc3e55120 r5 = 0xc3d34bc0 r6 = 0xc062eb02 r10 = 0xc060ca74 _vn_lock() at _vn_lock+0x48 pc = 0xc04236b4 lr = 0xc0414394 (vget+0x60) sp = 0xd84c6c88 fp = 0xd84c6ca8 r4 = 0xc3e55120 r5 = 0xc3d34bc0 r6 = 0x00080500 r7 = 0xc3d34bd4 r8 = 0xc3f31660 r9 = 0x00080500 r10 = 0xc060ca74 vget() at vget+0x60 pc = 0xc0414394 lr = 0xc0296b48 (devfs_allocv+0xfc) sp = 0xd84c6cb0 fp = 0xd84c6ce0 r4 = 0xc07781e4 r5 = 0xc3d34bc0 r6 = 0xc3f2b400 r7 = 0xc3d34bd4 r8 = 0xc3e55120 r10 = 0xc060ca74 devfs_allocv() at devfs_allocv+0xfc pc = 0xc0296b48 lr = 0xc02965f4 (devfs_unmount_final+0x4ec) sp = 0xd84c6ce8 fp = 0xd84c6d00 r4 = 0xd84c6d20 r5 = 0xc3f6c560 r6 = 0xc3d34bc0 r7 = 0x00000000 r8 = 0xc3e54b40 r9 = 0x00080000 r10 = 0xc3f31660 devfs_unmount_final() at devfs_unmount_final+0x4ec pc = 0xc02965f4 lr = 0xc040d888 (dounmount+0x3b8) sp = 0xd84c6d08 fp = 0xd84c6d50 r4 = 0x00000000 r5 = 0x00080000 r6 = 0xc062e0cb r10 = 0xc3f31660 dounmount() at dounmount+0x3b8 pc = 0xc040d888 lr = 0xc0416658 (vfs_unmountall+0x58) sp = 0xd84c6d58 fp = 0xd84c6d78 r4 = 0xc3f31660 r5 = 0xc0619583 r6 = 0xd9114eb0 r7 = 0xc3f6c560 r8 = 0xc06e3be0 r9 = 0xc063efaa r10 = 0xc062f19b vfs_unmountall() at vfs_unmountall+0x58 pc = 0xc0416658 lr = 0xc03677a8 (kern_reboot+0x4f0) sp = 0xd84c6d80 fp = 0xd84c6dd8 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xd9114eb0 r7 = 0xd9114eb0 r8 = 0x00000000 r9 = 0xc06f3a24 r10 = 0xc07798c4 kern_reboot() at kern_reboot+0x4f0 pc = 0xc03677a8 lr = 0xc03672b8 (kern_reboot) sp = 0xd84c6de0 fp = 0xd84c6de8 r4 = 0xd84c6e08 r5 = 0xc3f28000 r6 = 0x60000013 r7 = 0x00000000 r8 = 0xd84c6e00 r9 = 0x00000000 r10 = 0x00000004 kern_reboot() at kern_reboot pc = 0xc03672b8 lr = 0xc05d8628 (swi_handler+0x29c) sp = 0xd84c6df0 fp = 0xd84c6e50 r4 = 0xd84c6e00 r5 = 0x00000000 r6 = 0x00000004 r7 = 0xd84c6de8 r8 = 0xc03672b8 r9 = 0xc3f31660 r10 = 0x00000004 swi_handler() at swi_handler+0x29c pc = 0xc05d8628 lr = 0xc05c40c0 (swi_exit) sp = 0xd84c6e58 fp = 0xbfbffe00 r4 = 0x00000004 r5 = 0x00000002 r6 = 0xbfbffddc r7 = 0x00000037 r8 = 0x00000000 r9 = 0x00000000 r10 = 0x00000004 swi_exit() at swi_exit pc = 0xc05c40c0 lr = 0xc05c40c0 (swi_exit) sp = 0xd84c6e58 fp = 0xbfbffe00 Uptime: 3m40s Rebooting... Why is this commng ? From owner-freebsd-arm@FreeBSD.ORG Fri May 22 19:05:44 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED39F8CE for ; Fri, 22 May 2015 19:05:44 +0000 (UTC) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (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 928A71ECC for ; Fri, 22 May 2015 19:05:44 +0000 (UTC) Received: by lagv1 with SMTP id v1so18701146lag.3 for ; Fri, 22 May 2015 12:05:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=t0EQHg+sL8fSWRSdaGl4ApVlGvf/5Up2Nxtsn00eDko=; b=CcES9TGht3BKiZHoM1S6A89WRRG2sYf0aiNcp87v+jlKIkZZYyMG/iLPPDd+TyHzvt keb62/d5vSo6mUrq2U+WW7ykCd3TaB4UBQWuwi1R8lrj6jzRRNuWFIe5mFaYhmkgzeV0 9WkldchUkCfVoTCMTbP64xXY9xe2L1osdQNVOCq+XCHt5WEUElHgbOymDT1pM/JjYVnr F1386vxZjP5BJXzz23VzQBgfs0cTVRqNy8B0P4LlHCQPEbXXyb2+ixVi84+p0f4NAZeS pzztwVKLF1ykC9Wjl+TqEA+A+te3wuMPaan9Ut5Rfo2c3/DevkCMfT+OfPIjkNsRe9ps VR4w== X-Gm-Message-State: ALoCoQm2zpxzdBbiJLSOb+X9YVba50uLDjJ9rHHZcDZzGRn5EvCAMeklOLwDBPKk30TWpyEXvajj MIME-Version: 1.0 X-Received: by 10.152.203.233 with SMTP id kt9mr7479135lac.21.1432319895279; Fri, 22 May 2015 11:38:15 -0700 (PDT) Received: by 10.25.201.72 with HTTP; Fri, 22 May 2015 11:38:15 -0700 (PDT) Date: Fri, 22 May 2015 20:38:15 +0200 Message-ID: Subject: Re: Fwd: UMA initialization failure with 48 core ARM64 From: =?UTF-8?Q?Micha=C5=82_Stanek?= To: Konstantin Belousov Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org 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, 22 May 2015 19:05:45 -0000 2015-05-22 16:36 GMT+02:00 Konstantin Belousov : > On Fri, May 22, 2015 at 04:14:13PM +0200, Micha?? Stanek wrote: > > Success! I am finally able to boot 48 cores. I have been trying out > > different values given to uma_prealloc() and uma_zone_reserve(). It > started > > working when I increased the parameter in uma_prealloc() 32 times and > left > > uma_zone_reserve() as it was originally. UMA_BOOT_PAGES also needs to be > > set to 512. > > > > Thank you very much for your help. Do you know how the value to > > uma_prealloc() should scale with the number of CPUs? If it is not > obvious, > > then maybe for now we should make a #define with a value to multiply > > BT_MAXALLOC by, with a comment that a higher number is required on > > platforms with many CPUs. What do you think the final fix should look > like? > > I suspect it is not only the number of CPUs which makes the play. Note > that the number of tags is already scaled with the number of CPUs. > > It is also the question of how much the given architecture needs to > allocate > before the normal uma/vmem mechanisms start working. My quess is that > arm64 > performes more kva_alloc()s on early stages than other architectures. > I am forwarding the result of my conversation with Konstantin Belousov. With his help I was able to boot 48 cores on an arm64 platform. I needed to set UMA_BOOT_PAGES=512 and increase the parameter given to uma_prealloc() in vmem_startup() 32 times (giving 32 * BT_MAXALLOC). It looks like this should be made configurable to avoid running out of space for initial allocations on some platforms. In our case, the panic happened still in SI_SUB_VM sysinit. Best regards, Michal Stanek From owner-freebsd-arm@FreeBSD.ORG Sat May 23 02:41:15 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AED98807 for ; Sat, 23 May 2015 02:41:15 +0000 (UTC) Received: from mail.egr.msu.edu (boomhauer.egr.msu.edu [35.9.37.167]) by mx1.freebsd.org (Postfix) with ESMTP id 882C51FAE for ; Sat, 23 May 2015 02:41:14 +0000 (UTC) Received: from boomhauer (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 582794C908 for ; Fri, 22 May 2015 22:41:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by boomhauer (boomhauer.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti5toJsvOog1 for ; Fri, 22 May 2015 22:41:07 -0400 (EDT) Received: from EGR authenticated sender mcdouga9 Message-ID: <555FE8C1.2090609@egr.msu.edu> Date: Fri, 22 May 2015 22:41:05 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Change serial speed on raspberry pi? References: <555D08B1.2070808@egr.msu.edu> <20150520224237.ae19ac81378b480ff3d41022@ulrich-grey.de> In-Reply-To: <20150520224237.ae19ac81378b480ff3d41022@ulrich-grey.de> Content-Type: text/plain; charset=windows-1252 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: Sat, 23 May 2015 02:41:15 -0000 On 05/20/2015 18:42, Ulrich Grey wrote: > This works for me: > cu -l/dev/cuaU0 -s115200 > > In /etc/ttys: > ttyu0 "/usr/libexec/getty 3wire.115200" dialup on secure > ---------------------------------- > On Wed, 20 May 2015 18:20:33 -0400 > Adam McDougall wrote: > >> I have been experimenting and googling for at least a half hour but am >> getting seemingly nowhere. Is it possible to make a raspberry pi with a >> serial adapter board run at a speed less than 115200? I am getting >> serial corruption during uboot and after the system has booted. My >> usual instinct is to try a slower speed but I have no idea how. I'd >> like it to work for the uboot environment as well as after the kernel. >> I should try the FreeBSD side of it but I need to switch tasks right >> now. Can anyone give me a hint? Is it compiled into uboot? Thanks. >> >> I have: >> http://www.52pi.com/en/raspberry-pi/56-original-raspberry-pi-bb-plus-accessories-rpi-uart-expand-module-uart-extend-board-.html? >> >> I've tried both I got, on two different pis, with different serial >> adapters and cables. I was able to change the speed to 9600 in /etc/ttys and use cu -l /dev/cuaU0 without line noise. I do not want to use 115200 because of the line noise, and I don't need the speed. How do I get uboot to use 9600? I still want a usable uboot environment before the kernel boots. I've tried setting CONFIG_BAUDRATE=9600 in the source in various ways, recompiled it and replaced U-BOOT.BIN on the flash but I didn't make any useful progress. I tried putting init_uart_baud=9600 in config.txt on the flash but it did not make any difference. Thanks. From owner-freebsd-arm@FreeBSD.ORG Sat May 23 15:18:57 2015 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36C0B424 for ; Sat, 23 May 2015 15:18:57 +0000 (UTC) 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 085FB1A42 for ; Sat, 23 May 2015 15:18:57 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4NFIuC0064270 for ; Sat, 23 May 2015 15:18:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200415] System crashes when copying multiple files from ZFS to UFS Date: Sat, 23 May 2015 15:18:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new 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 Only Me X-Bugzilla-Who: jsmith@resonatingmedia.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: 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: Sat, 23 May 2015 15:18:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200415 Bug ID: 200415 Summary: System crashes when copying multiple files from ZFS to UFS Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: jsmith@resonatingmedia.com FreeBSD version: 11-Current (armv6) Hardware: Raspberry Pi 2 Problem: When attempting to copy multiple files (or a ditectory tree) from a ZFS volume to a UFS partition, FreeBSD crashes and requires a power cycle.When the OS crashes it is completely unresponsive to either keyboard input or network pings. I have experimented with multiple devices formatted with ZFS. In each case I can import the ZFS pool, browse direcotires and copy files one at a time from the ZFS volume to a UFS partition. Howver, trying to copy more than three or four files at a time using the "cp" command causes FreeBSD to freeze. Copying files from the UFS partition to the ZFS partition works, even when dealing with large directory trees. Only ZFS-to-UFS appears to trigger the crash. Copying large numbers of files within the boundaries of the ZFS volume works. Copying many files within the boundary of the UFS volume also works. The bug is only triggered when copying multiple files from ZFS to UFS. A discussion on this issue is ongoing in the FreeBSD forum: https://forums.freebsd.org/threads/raspberry-pi-2.50291/page-2 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat May 23 15:50:26 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FF36E3A for ; Sat, 23 May 2015 15:50:26 +0000 (UTC) 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 D54291DBF for ; Sat, 23 May 2015 15:50:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t4NFoPO6097643 for ; Sat, 23 May 2015 15:50:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 200417] Contents of Makefiles disappear when running "make" on ZFS volume Date: Sat, 23 May 2015 15:50:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new 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 Only Me X-Bugzilla-Who: jsmith@resonatingmedia.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: 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: Sat, 23 May 2015 15:50:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200417 Bug ID: 200417 Summary: Contents of Makefiles disappear when running "make" on ZFS volume Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: jsmith@resonatingmedia.com FreeBSD version: 11-Current (armv6) Hardware: Raspberry Pi 2 Problem: When running the "make" command on a Makefile in a source tree on a ZFS volume, the contents of the Makefile disappear (the file appears to be truncated). Description: I have FreeBSD 11-Current running on a Raspberry Pi 2. When I go to compile a port or a kernel module on an attached ZFS volume, the contents of the Makefile seem to disappear until I unmount and re-mount the ZFS volume. As a quick example: zfs mount tank cd /tank/sys/modules/opensolaris cat Makefile (Contents of the Makefile is displayed) make (make command reports no target found) cat Makefile (No output is shown) ls -l Makefile (ls -l shows file "Makefile" exists and is of the proper size, over 1k) cd / zfs umount tank zfs mount tank cd /tank/sys/modules/opensolaris cat Makefile (full contents of Makefile is restored and displays properly) make (make command reports no target found and cat shows no data in the Makefile) Work around: Compile all ports/modules on UFS volume instead. Side note: Exporting the ZFS volume and attaching it to a machine running on x86 shows the data is available and a port/module can be compiled from the x86 machine. So this bug appears to be limited in scope to the ARM architecture. -- You are receiving this mail because: You are the assignee for the bug.