From owner-freebsd-ppc@freebsd.org Sun Dec 24 04:00:48 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59457E940D5 for ; Sun, 24 Dec 2017 04:00:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-154.reflexion.net [208.70.210.154]) (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 1147566437 for ; Sun, 24 Dec 2017 04:00:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25968 invoked from network); 24 Dec 2017 04:00:46 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 24 Dec 2017 04:00:46 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 23 Dec 2017 23:00:46 -0500 (EST) Received: (qmail 9107 invoked from network); 24 Dec 2017 04:00:45 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Dec 2017 04:00:45 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4FF1CEC7803; Sat, 23 Dec 2017 20:00:45 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: TARGET_ARCH=powerpc64 jump from head -r326192 to -r327075: g_event crashes with "instruction storage interrupt" [kldload -n filemon crashes the system] Date: Sat, 23 Dec 2017 20:00:44 -0800 References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Hackers In-Reply-To: <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> Message-Id: <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Dec 2017 04:00:48 -0000 [I note some odd consequences when trying to build in geom_label to the kernel. filemon being built-in work fine for my use.] On 2017-Dec-22, at 10:33 PM, Mark Millard wrote: > [I attempted something that involved kldload -n filemon . > That gives a similar system crash (by the virtual address > reported and the type of exception). It seems similar to > geom_label_load="YES" in /boot/loader.conf getting a > crash.] > > On 2017-Dec-22, at 9:58 PM, Mark Millard wrote: > >> [Avoiding referencing partitions via labels >> avoided the crash.] >> >> On 2017-Dec-22, at 9:26 PM, Mark Millard wrote: >> >>> [Note: I experiment with using clang as the build and >>> system compiler for TARGET_ARCH=powerpc64 .] >>> >>> I attempted to update a old so-called PowerMac "Quad Core" >>> from head -r326192 to -r328075, noting special instructions >>> that have been published. (This was a non-debug kernel >>> build.) >>> >>> Unfortunately around the: >>> >>> . . . >>> cd0: 66.700MB/s transfers (UDMA4, ATPI 12bytes, PIO 65534bytes) >>> cd0: Attempt >>> Trying to mount from ufs:/dev/ufs/FBSDG5Lrootfs [rw,noatime]. . . >>> >>> There ends up being a repeatable kernel trap: >>> (transcribed from pictures, but with notes added) >>> >>> fatal kernel trap: >>> (NOTE: The above can be the line before the "Trying to mount" line, >>> after the "cd0: Attempt" line.) >>> >>> exception = 0x400 (instruction storage interrupt) >>> virtual address = 0x3c4c009438427518 >>> srr0 = 0x3c4c009438427518 >>> srr1 = 0x9000000040009032 >>> lr = 0x14234e8 >>> curthread = 0x3d52a80 >>> pid = 13, comm = g_event >>> >>> [ thread pid 13 tid 100019 ] >>> Stopped at 0x3c4c009438427518 >>> >>> It reports: >>> >>> Tracing command geom pid 13 tid 100019 td 0x3d52a80 (CPU 0) >>> 0xC0000000032966b0: at g_new_provider_event+0x144 >>> 0xC0000000032966f0: at g_run_events+0x530 >>> 0xC000000003296830: at g_event_procbody+0x94 >>> 0xC000000003296860: at fork_exit+0xd8 >>> 0xC0000000032968f0: at fork_trampoline+0x18 >>> 0xC000000003296920: at blocked_loop+0x38 >>> >>> These details do not vary between attempts. >>> >>> From what I gather the code jumped to 0x3c4c009438427518 >>> but that is not from an executable page for the context >>> at the time. >>> >>> On the -r326192 powerpc system /dev/ufs/FBSDG5Lrootfs >>> mounts just fine. >>> >> >> I adjusted: >> >> /boot/loader.conf >> /etc/rc.conf >> >> /etc/fstab >> >> to avoid use of: >> >> geom_label_load="YES" >> dumpdev="/dev/label/FBSDG5Lswap" >> >> /dev/ufs/FBSDG5Lrootfs / ufs rw,noatime 1 1 >> /dev/label/FBSDG5Lswap none swap sw 0 0 >> >> Using instead: >> >> dumpdev="/dev/ada0s4" >> >> /dev/ada0s3 / ufs rw,noatime 1 1 >> /dev/ada0s4 none swap sw 0 0 >> >> This allowed the boot to work normally. > > The use of filemon was tied to buildworld/buildkernel > related activity. > > But it was kldload that was listed in the crash from > the attempted kldload -n filemon. > > This would seem similar to having: > > geom_label_load="YES" > > in /boot/loader.conf I added: device filemon device geom_label to the kernel configuration files that I use. After booting, both work fine, including allowing explicit kldload -n NAME use (that avoids dynamically loading what is already present). But the boot time use of geom_label is not so lucky in that after booting there is no /dev/label/ or /dev/ufs/ or such. (No geom_label_load line.) Drives plugged into USB after booting do end up in those places. /dev/gpt/ as well. [The boot drive is apm --so, no gpt present to test at boot.] It seems that without /boot/loader.conf having: geom_label_load="YES" even with geom_label in the kernel it is not initialized early enough to be used with the initial devices, such as the boot drive. But it is also the case that with that line listed in /boot/loader.conf when the kernel has geom_label built-in, powerpc64 FreeBSD still crashes, sort of like geom_label_load does not involve the equivalent of -n in "kld -n geom_label". [From this I gather that if boot time label handling is desired, geom_label probably should not be built into the kernel because a second copy would need to be loaded anyway (when such loading is working).] === Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Dec 24 05:42:25 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3B4BE9BD76 for ; Sun, 24 Dec 2017 05:42:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-154.reflexion.net [208.70.210.154]) (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 9628369B0B for ; Sun, 24 Dec 2017 05:42:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9665 invoked from network); 24 Dec 2017 05:42:23 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 24 Dec 2017 05:42:23 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 24 Dec 2017 00:42:23 -0500 (EST) Received: (qmail 15917 invoked from network); 24 Dec 2017 05:42:23 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Dec 2017 05:42:23 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8522DEC7803; Sat, 23 Dec 2017 21:42:22 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: TARGET_ARCH=powerpc64 jump from head -r326192 to -r327075: g_event crashes with "instruction storage interrupt" [kldload -n filemon crashes the system] Date: Sat, 23 Dec 2017 21:42:22 -0800 References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Hackers In-Reply-To: <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> Message-Id: <68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Dec 2017 05:42:25 -0000 [TARGET_ARCH=powerpc (gcc 4.2.1 based) does not have the problem. And my notes about geom_label being builtin were wrong about boot usage of labels when geom_label_load is not used /boot/loader.conf .] On 2017-Dec-23, at 8:00 PM, Mark Millard wrote: > [I note some odd consequences when trying to > build in geom_label to the kernel. filemon > being built-in work fine for my use.] > > On 2017-Dec-22, at 10:33 PM, Mark Millard wrote: > >> [I attempted something that involved kldload -n filemon . >> That gives a similar system crash (by the virtual address >> reported and the type of exception). It seems similar to >> geom_label_load="YES" in /boot/loader.conf getting a >> crash.] >> >> On 2017-Dec-22, at 9:58 PM, Mark Millard wrote: >> >>> [Avoiding referencing partitions via labels >>> avoided the crash.] >>> >>> On 2017-Dec-22, at 9:26 PM, Mark Millard wrote: >>> >>>> [Note: I experiment with using clang as the build and >>>> system compiler for TARGET_ARCH=powerpc64 .] >>>> >>>> I attempted to update a old so-called PowerMac "Quad Core" >>>> from head -r326192 to -r328075, noting special instructions >>>> that have been published. (This was a non-debug kernel >>>> build.) >>>> >>>> Unfortunately around the: >>>> >>>> . . . >>>> cd0: 66.700MB/s transfers (UDMA4, ATPI 12bytes, PIO 65534bytes) >>>> cd0: Attempt >>>> Trying to mount from ufs:/dev/ufs/FBSDG5Lrootfs [rw,noatime]. . . >>>> >>>> There ends up being a repeatable kernel trap: >>>> (transcribed from pictures, but with notes added) >>>> >>>> fatal kernel trap: >>>> (NOTE: The above can be the line before the "Trying to mount" line, >>>> after the "cd0: Attempt" line.) >>>> >>>> exception = 0x400 (instruction storage interrupt) >>>> virtual address = 0x3c4c009438427518 >>>> srr0 = 0x3c4c009438427518 >>>> srr1 = 0x9000000040009032 >>>> lr = 0x14234e8 >>>> curthread = 0x3d52a80 >>>> pid = 13, comm = g_event >>>> >>>> [ thread pid 13 tid 100019 ] >>>> Stopped at 0x3c4c009438427518 >>>> >>>> It reports: >>>> >>>> Tracing command geom pid 13 tid 100019 td 0x3d52a80 (CPU 0) >>>> 0xC0000000032966b0: at g_new_provider_event+0x144 >>>> 0xC0000000032966f0: at g_run_events+0x530 >>>> 0xC000000003296830: at g_event_procbody+0x94 >>>> 0xC000000003296860: at fork_exit+0xd8 >>>> 0xC0000000032968f0: at fork_trampoline+0x18 >>>> 0xC000000003296920: at blocked_loop+0x38 >>>> >>>> These details do not vary between attempts. >>>> >>>> From what I gather the code jumped to 0x3c4c009438427518 >>>> but that is not from an executable page for the context >>>> at the time. >>>> >>>> On the -r326192 powerpc system /dev/ufs/FBSDG5Lrootfs >>>> mounts just fine. >>>> >>> >>> I adjusted: >>> >>> /boot/loader.conf >>> /etc/rc.conf >>> >>> /etc/fstab >>> >>> to avoid use of: >>> >>> geom_label_load="YES" >>> dumpdev="/dev/label/FBSDG5Lswap" >>> >>> /dev/ufs/FBSDG5Lrootfs / ufs rw,noatime 1 1 >>> /dev/label/FBSDG5Lswap none swap sw 0 0 >>> >>> Using instead: >>> >>> dumpdev="/dev/ada0s4" >>> >>> /dev/ada0s3 / ufs rw,noatime 1 1 >>> /dev/ada0s4 none swap sw 0 0 >>> >>> This allowed the boot to work normally. >> >> The use of filemon was tied to buildworld/buildkernel >> related activity. >> >> But it was kldload that was listed in the crash from >> the attempted kldload -n filemon. >> >> This would seem similar to having: >> >> geom_label_load="YES" >> >> in /boot/loader.conf > > I added: > > device filemon > device geom_label > > to the kernel configuration files that > I use. > > After booting, both work fine, including > allowing explicit kldload -n NAME use > (that avoids dynamically loading what is > already present). > > But the boot time use of geom_label is > not so lucky in that after booting > there is no /dev/label/ or /dev/ufs/ > or such. (No geom_label_load line.) I had stupidly forgotten to change the /dev/. . . in the likes of /etc/fstab , /boot/loader.conf , and /etc/rc.conf to use /dev/label/. . . or /dev/ufs/. . . When used with the built-in geom_label (and no geom_label_load in /boot/loader.conf ), it works fine. > . . . (junk removed) . . . > > But it is also the case that with that > line listed in /boot/loader.conf when > the kernel has geom_label built-in, > powerpc64 FreeBSD still crashes, sort of > like geom_label_load does not involve > the equivalent of -n in > "kld -n geom_label". > > . . . (junk removed) . . . I updated from -r326192 to -r327075 for a TARGET_ARCH=powerpc context and it worked fine. But this is a gcc 4.2.1 based kernel build because with system clang 5 and the system binutils the kernel fails to build. (Unlike for devel/powerpc64-binutils , there is no devel/powerpc-binutils to use in cross builds.) === Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Dec 24 06:48:49 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFE67EA0701 for ; Sun, 24 Dec 2017 06:48:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-159.reflexion.net [208.70.210.159]) (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 7F9EB6B78A for ; Sun, 24 Dec 2017 06:48:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30873 invoked from network); 24 Dec 2017 06:48:41 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Dec 2017 06:48:41 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 24 Dec 2017 01:48:41 -0500 (EST) Received: (qmail 14215 invoked from network); 24 Dec 2017 06:48:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Dec 2017 06:48:41 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E5AAEEC88A2; Sat, 23 Dec 2017 22:48:40 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: TARGET_ARCH=powerpc64 jump from head -r326192 to -r327075: g_event crashes with "instruction storage interrupt" [clang-built kernel specific problem] Date: Sat, 23 Dec 2017 22:48:40 -0800 References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> <68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3@dsl-only.net> To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , FreeBSD Hackers In-Reply-To: <68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3@dsl-only.net> Message-Id: <313C2310-ABEF-4BEE-A853-A9965680C3AC@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Dec 2017 06:48:49 -0000 [Using devel/powerpc64-gcc to build the kernel produces a 64-bit kernel that does not crash for kldload use. clang 5.0.1 may be producing code that needs a "new" form of relocation compared to what kldload activity historically needed.] On 2017-Dec-23, at 9:42 PM, Mark Millard wrote: > [TARGET_ARCH=powerpc (gcc 4.2.1 based) does > not have the problem. And my notes about > geom_label being builtin were wrong about > boot usage of labels when geom_label_load > is not used /boot/loader.conf .] > > On 2017-Dec-23, at 8:00 PM, Mark Millard wrote: > >> [I note some odd consequences when trying to >> build in geom_label to the kernel. filemon >> being built-in work fine for my use.] >> >> On 2017-Dec-22, at 10:33 PM, Mark Millard wrote: >> >>> [I attempted something that involved kldload -n filemon . >>> That gives a similar system crash (by the virtual address >>> reported and the type of exception). It seems similar to >>> geom_label_load="YES" in /boot/loader.conf getting a >>> crash.] >>> >>> On 2017-Dec-22, at 9:58 PM, Mark Millard wrote: >>> >>>> [Avoiding referencing partitions via labels >>>> avoided the crash.] >>>> >>>> On 2017-Dec-22, at 9:26 PM, Mark Millard wrote: >>>> >>>>> [Note: I experiment with using clang as the build and >>>>> system compiler for TARGET_ARCH=powerpc64 .] >>>>> >>>>> I attempted to update a old so-called PowerMac "Quad Core" >>>>> from head -r326192 to -r328075, noting special instructions >>>>> that have been published. (This was a non-debug kernel >>>>> build.) >>>>> >>>>> Unfortunately around the: >>>>> >>>>> . . . >>>>> cd0: 66.700MB/s transfers (UDMA4, ATPI 12bytes, PIO 65534bytes) >>>>> cd0: Attempt >>>>> Trying to mount from ufs:/dev/ufs/FBSDG5Lrootfs [rw,noatime]. . . >>>>> >>>>> There ends up being a repeatable kernel trap: >>>>> (transcribed from pictures, but with notes added) >>>>> >>>>> fatal kernel trap: >>>>> (NOTE: The above can be the line before the "Trying to mount" line, >>>>> after the "cd0: Attempt" line.) >>>>> >>>>> exception = 0x400 (instruction storage interrupt) >>>>> virtual address = 0x3c4c009438427518 >>>>> srr0 = 0x3c4c009438427518 >>>>> srr1 = 0x9000000040009032 >>>>> lr = 0x14234e8 >>>>> curthread = 0x3d52a80 >>>>> pid = 13, comm = g_event >>>>> >>>>> [ thread pid 13 tid 100019 ] >>>>> Stopped at 0x3c4c009438427518 >>>>> >>>>> It reports: >>>>> >>>>> Tracing command geom pid 13 tid 100019 td 0x3d52a80 (CPU 0) >>>>> 0xC0000000032966b0: at g_new_provider_event+0x144 >>>>> 0xC0000000032966f0: at g_run_events+0x530 >>>>> 0xC000000003296830: at g_event_procbody+0x94 >>>>> 0xC000000003296860: at fork_exit+0xd8 >>>>> 0xC0000000032968f0: at fork_trampoline+0x18 >>>>> 0xC000000003296920: at blocked_loop+0x38 >>>>> >>>>> These details do not vary between attempts. >>>>> >>>>> From what I gather the code jumped to 0x3c4c009438427518 >>>>> but that is not from an executable page for the context >>>>> at the time. >>>>> >>>>> On the -r326192 powerpc system /dev/ufs/FBSDG5Lrootfs >>>>> mounts just fine. >>>>> >>>> >>>> I adjusted: >>>> >>>> /boot/loader.conf >>>> /etc/rc.conf >>>> >>>> /etc/fstab >>>> >>>> to avoid use of: >>>> >>>> geom_label_load="YES" >>>> dumpdev="/dev/label/FBSDG5Lswap" >>>> >>>> /dev/ufs/FBSDG5Lrootfs / ufs rw,noatime 1 1 >>>> /dev/label/FBSDG5Lswap none swap sw 0 0 >>>> >>>> Using instead: >>>> >>>> dumpdev="/dev/ada0s4" >>>> >>>> /dev/ada0s3 / ufs rw,noatime 1 1 >>>> /dev/ada0s4 none swap sw 0 0 >>>> >>>> This allowed the boot to work normally. >>> >>> The use of filemon was tied to buildworld/buildkernel >>> related activity. >>> >>> But it was kldload that was listed in the crash from >>> the attempted kldload -n filemon. >>> >>> This would seem similar to having: >>> >>> geom_label_load="YES" >>> >>> in /boot/loader.conf >> >> I added: >> >> device filemon >> device geom_label >> >> to the kernel configuration files that >> I use. >> >> After booting, both work fine, including >> allowing explicit kldload -n NAME use >> (that avoids dynamically loading what is >> already present). >> >> But the boot time use of geom_label is >> not so lucky in that after booting >> there is no /dev/label/ or /dev/ufs/ >> or such. (No geom_label_load line.) > > I had stupidly forgotten to change > the /dev/. . . in the likes of > /etc/fstab , /boot/loader.conf , > and /etc/rc.conf to use /dev/label/. . . > or /dev/ufs/. . . > > When used with the built-in geom_label > (and no geom_label_load in > /boot/loader.conf ), it works fine. > >> . . . (junk removed) . . . >> >> But it is also the case that with that >> line listed in /boot/loader.conf when >> the kernel has geom_label built-in, >> powerpc64 FreeBSD still crashes, sort of >> like geom_label_load does not involve >> the equivalent of -n in >> "kld -n geom_label". >> >> . . . (junk removed) . . . > > I updated from -r326192 to -r327075 for > a TARGET_ARCH=powerpc context and it > worked fine. > > But this is a gcc 4.2.1 based kernel build > because with system clang 5 and the system > binutils the kernel fails to build. (Unlike > for devel/powerpc64-binutils , there is no > devel/powerpc-binutils to use in cross > builds.) I built world and kernel based on devel/powerpc64-xtoolchain-gcc and installed the kernel it produced, leaving world as the previously installed clang-5.0.0-based build. kldload does not lead to crashes. Nor does /boot/loader.conf having: geom_label_load="YES" in it. So my guess is that clang is producing some form of relocation need that kldload support does not handle. I'l note that back at -r326192 this was not a problem for clang, so the clang 5.0.1 update may be what changed the status. === Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Dec 24 19:41:28 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F000CEA6B21 for ; Sun, 24 Dec 2017 19:41:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-135.reflexion.net [208.70.210.135]) (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 9904C66FFB for ; Sun, 24 Dec 2017 19:41:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29727 invoked from network); 24 Dec 2017 19:34:41 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 24 Dec 2017 19:34:41 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 24 Dec 2017 14:34:41 -0500 (EST) Received: (qmail 10495 invoked from network); 24 Dec 2017 19:34:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Dec 2017 19:34:41 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 77705EC7B31; Sun, 24 Dec 2017 11:34:40 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: TARGET_ARCH=powerpc64 jump from head -r326192 to -r327075: g_event crashes with "instruction storage interrupt" [R_PPC64_JMP_SLOT problem] Date: Sun, 24 Dec 2017 11:34:39 -0800 References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> <68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3@dsl-only.net> <313C2310-ABEF-4BEE-A853-A9965680C3AC@dsl-only.net> To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML , FreeBSD Hackers In-Reply-To: <313C2310-ABEF-4BEE-A853-A9965680C3AC@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Dec 2017 19:41:29 -0000 [History removed.] I have submitted bugzilla 224561 for the issue. The difference in the likes of filemon.ko produced by system clang 5.0.1 vs. devel/powerpc64-xtoolchain-gcc is. . . clang 5.0.1: Relocation section with addend (.rela.plt): r_offset r_info r_type st_value st_name + = r_addend 000000014480 000300000015 R_PPC64_JMP_SLOT 0000000000000000 copyinstr = + 0 000000014488 000400000015 R_PPC64_JMP_SLOT 0000000000000000 = devfs_set_cdevpriv + 0 . . . vs. devel/powerpc64-xtoolchain-gcc: Relocation section with addend (.rela.dyn): r_offset r_info r_type st_value st_name + = r_addend 0000000145c0 000000000016 R_PPC64_RELATIVE 0000000000000000 + 40d0 0000000145e0 000000000016 R_PPC64_RELATIVE 0000000000000000 + 145b0 . . . 000000014408 000600000026 R_PPC64_ADDR64 0000000000000000 sysent + = 0 000000014410 001100000026 R_PPC64_ADDR64 0000000000000000 = freebsd32_sysent + 0 Apparently R_PPC64_JMP_SLOT is mishandled and does not explicitly lead to rejection of the attempted dynamic load. It might be an issue if .rela.plt and R_PPC64_JMP_SLOT should even be generated instead of .rela.dyn and R_PPC64_RELATIVE and R_PPC64_ADDR64. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Wed Dec 27 01:11:17 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1476E8FF7D for ; Wed, 27 Dec 2017 01:11:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-97.reflexion.net [208.70.210.97]) (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 6E89E7026E for ; Wed, 27 Dec 2017 01:11:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24645 invoked from network); 27 Dec 2017 01:04:30 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 Dec 2017 01:04:30 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 26 Dec 2017 20:04:30 -0500 (EST) Received: (qmail 21508 invoked from network); 27 Dec 2017 01:04:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Dec 2017 01:04:29 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 48818EC83F5; Tue, 26 Dec 2017 17:04:29 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: powerpc64 (head -r326075): www/qt5-webkit gets: CMake Error at CMakeLists.txt:85 (message): Unknown CPU 'powerpc64' Message-Id: <328CF731-D1BF-467B-BFEE-8AF47AC4418F@dsl-only.net> Date: Tue, 26 Dec 2017 17:04:28 -0800 To: FreeBSD PowerPC ML , FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2017 01:11:17 -0000 [I experiment with system clang as the system compiler for powerpc64 (and 32-bit powerpc).] On powerpc64, # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 457194 Last Changed Rev: 457194 gets: ===> Configuring for qt5-webkit-5.212.0.a2_5 ===> Performing out-of-source build /bin/mkdir -p /wrkdirs/usr/ports/www/qt5-webkit/work/.build -- The C compiler identification is Clang 5.0.1 -- The CXX compiler identification is Clang 5.0.1 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Error at CMakeLists.txt:85 (message): Unknown CPU 'powerpc64' www/qt5-webkit was referenced indirectly from attempting to build x11/lumina . === Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sat Dec 30 00:19:03 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D94EE8511F for ; Sat, 30 Dec 2017 00:19:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-112.reflexion.net [208.70.210.112]) (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 055363FD8 for ; Sat, 30 Dec 2017 00:19:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1110 invoked from network); 30 Dec 2017 00:18:56 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 Dec 2017 00:18:56 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 29 Dec 2017 19:18:56 -0500 (EST) Received: (qmail 20260 invoked from network); 30 Dec 2017 00:18:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Dec 2017 00:18:55 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E19BCEC9398; Fri, 29 Dec 2017 16:18:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Is the clang 5.0.1 use of .rela.plt and R_PPC64_JMP_SLOT for kernel modules a llvm issue? Just a FreeBSD one? From: Mark Millard In-Reply-To: Date: Fri, 29 Dec 2017 16:18:54 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <2BD5FD21-95E7-4661-B8B9-2FDCDB986149@dsl-only.net> References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> <68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3@dsl-only.net> <313C2310-ABEF-4BEE-A853-A9965680C3AC@dsl-only.net> To: Ed Maste , Dimitry Andric , Justin Hibbits , Nathan Whitehorn X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 00:19:03 -0000 I've not been able to figure out if I should submit something into llvm's bugzilla for the powerpc64 switching to .rela.plt and R_PPC64_JMP_SLOT for kernel modules from the earlier .rela.dyn and R/PPC64_RELATIVE and R_PPC64_ADDR64 for kernel modules. (I do not know if powerpc would also have the issue since other things have been stopping that build for a long time.) Do one or more of you have a clue? Reminder: I have submitted FreeBSD bugzilla 224561 for the issue. The difference in the likes of filemon.ko produced by system clang 5.0.1 vs. devel/powerpc64-xtoolchain-gcc is. . . clang 5.0.1: Relocation section with addend (.rela.plt): r_offset r_info r_type st_value st_name + = r_addend 000000014480 000300000015 R_PPC64_JMP_SLOT 0000000000000000 copyinstr = + 0 000000014488 000400000015 R_PPC64_JMP_SLOT 0000000000000000 = devfs_set_cdevpriv + 0 . . . vs. devel/powerpc64-xtoolchain-gcc: Relocation section with addend (.rela.dyn): r_offset r_info r_type st_value st_name + = r_addend 0000000145c0 000000000016 R_PPC64_RELATIVE 0000000000000000 + 40d0 0000000145e0 000000000016 R_PPC64_RELATIVE 0000000000000000 + 145b0 . . . 000000014408 000600000026 R_PPC64_ADDR64 0000000000000000 sysent + = 0 000000014410 001100000026 R_PPC64_ADDR64 0000000000000000 = freebsd32_sysent + 0 Apparently R_PPC64_JMP_SLOT is mishandled and does not explicitly lead to rejection of the attempted dynamic load. It might be an issue if .rela.plt and R_PPC64_JMP_SLOT should even be generated instead of .rela.dyn and R_PPC64_RELATIVE and R_PPC64_ADDR64. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sat Dec 30 08:03:30 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4BD7DEB03F8 for ; Sat, 30 Dec 2017 08:03:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-100.reflexion.net [208.70.210.100]) (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 D58BC73886 for ; Sat, 30 Dec 2017 08:03:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26904 invoked from network); 30 Dec 2017 07:36:43 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Dec 2017 07:36:43 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 30 Dec 2017 02:36:43 -0500 (EST) Received: (qmail 18183 invoked from network); 30 Dec 2017 07:36:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Dec 2017 07:36:42 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 334A2EC94FA; Fri, 29 Dec 2017 23:36:42 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: powerpc64: graphics/mesa-dri fails to build because "ImportError: No module named mako.template" Message-Id: <2765A66A-8908-44A1-ACB6-43157202F49C@dsl-only.net> Date: Fri, 29 Dec 2017 23:36:41 -0800 To: FreeBSD PowerPC ML , FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 08:03:30 -0000 gmake[5]: Entering directory = '/wrkdirs/usr/ports/graphics/mesa-dri/work/mesa-17.3.1/src/amd/vulkan' python2.7 ./radv_entrypoints_gen.py \ --xml ../../../src/vulkan/registry/vk.xml --outdir . Traceback (most recent call last): File "./radv_entrypoints_gen.py", line 30, in from mako.template import Template ImportError: No module named mako.template gmake[5]: *** [Makefile:1234: radv_entrypoints.c] Error 1 gmake[5]: Leaving directory = '/wrkdirs/usr/ports/graphics/mesa-dri/work/mesa-17.3.1/src/amd/vulkan' gmake[4]: *** [Makefile:861: all-recursive] Error 1 gmake[4]: Leaving directory = '/wrkdirs/usr/ports/graphics/mesa-dri/work/mesa-17.3.1/src' gmake[3]: *** [Makefile:652: all] Error 2 gmake[3]: Leaving directory = '/wrkdirs/usr/ports/graphics/mesa-dri/work/mesa-17.3.1/src' gmake[2]: *** [Makefile:659: all-recursive] Error 1 gmake[2]: Leaving directory = '/wrkdirs/usr/ports/graphics/mesa-dri/work/mesa-17.3.1' *** Error code 1 (The above is from using MAKE_JOBS_UNSAFE=3Dyes as the second try.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sat Dec 30 08:10:32 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C365BEB0712 for ; Sat, 30 Dec 2017 08:10:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-102.reflexion.net [208.70.210.102]) (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 70E5D739F9 for ; Sat, 30 Dec 2017 08:10:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5669 invoked from network); 30 Dec 2017 08:10:25 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 Dec 2017 08:10:25 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 30 Dec 2017 03:10:25 -0500 (EST) Received: (qmail 27849 invoked from network); 30 Dec 2017 08:10:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Dec 2017 08:10:25 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A9E6CEC94F3; Sat, 30 Dec 2017 00:10:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: powerpc64: graphics/mesa-dri fails to build because "ImportError: No module named mako.template" From: Mark Millard In-Reply-To: <2765A66A-8908-44A1-ACB6-43157202F49C@dsl-only.net> Date: Sat, 30 Dec 2017 00:10:24 -0800 Cc: Jan Beich , se@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <087297E8-4108-442B-8A1A-DB6FDF8A35BA@dsl-only.net> References: <2765A66A-8908-44A1-ACB6-43157202F49C@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Ports , freebsd-x11@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 08:10:32 -0000 [I experiment with system clang based powerpc64 and powerpc builds. For powerpc64, linking pkg requires using a ports binutils instead of the system binutils. This blocks using poudriere. So portmaster is in use here.] On 2017-Dec-29, at 11:36 PM, Mark Millard = wrote: > gmake[5]: Entering directory = '/wrkdirs/usr/ports/graphics/mesa-dri/work/mesa-17.3.1/src/amd/vulkan' > python2.7 ./radv_entrypoints_gen.py \ > --xml ../../../src/vulkan/registry/vk.xml --outdir . > Traceback (most recent call last): > File "./radv_entrypoints_gen.py", line 30, in > from mako.template import Template > ImportError: No module named mako.template > gmake[5]: *** [Makefile:1234: radv_entrypoints.c] Error 1 > gmake[5]: Leaving directory = '/wrkdirs/usr/ports/graphics/mesa-dri/work/mesa-17.3.1/src/amd/vulkan' > gmake[4]: *** [Makefile:861: all-recursive] Error 1 > gmake[4]: Leaving directory = '/wrkdirs/usr/ports/graphics/mesa-dri/work/mesa-17.3.1/src' > gmake[3]: *** [Makefile:652: all] Error 2 > gmake[3]: Leaving directory = '/wrkdirs/usr/ports/graphics/mesa-dri/work/mesa-17.3.1/src' > gmake[2]: *** [Makefile:659: all-recursive] Error 1 > gmake[2]: Leaving directory = '/wrkdirs/usr/ports/graphics/mesa-dri/work/mesa-17.3.1' > *** Error code 1 >=20 > (The above is from using MAKE_JOBS_UNSAFE=3Dyes as the > second try.) freshports indicated: =E2=80=A2 py27-mako>0 : textproc/py-mako@py27 as a build dependency but portmaster did not try to create a textproc/py-mako@py27 on its own. A separate portmaster run for textproc/py-mako@py27 put it in place and then for retrying graphics/mesa-dri the vulkan material was able to get past the above. ( graphics/mesa-dri is still building.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sat Dec 30 09:09:06 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA64DEB2A05; Sat, 30 Dec 2017 09:09:06 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9BF1757AC; Sat, 30 Dec 2017 09:09:06 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id EE5EBBD51; Sat, 30 Dec 2017 09:09:05 +0000 (UTC) From: Jan Beich To: Mark Millard Cc: FreeBSD PowerPC ML , FreeBSD Ports , freebsd-x11@freebsd.org Subject: Re: powerpc64: graphics/mesa-dri fails to build because "ImportError: No module named mako.template" References: <2765A66A-8908-44A1-ACB6-43157202F49C@dsl-only.net> <087297E8-4108-442B-8A1A-DB6FDF8A35BA@dsl-only.net> Date: Sat, 30 Dec 2017 10:09:00 +0100 In-Reply-To: <087297E8-4108-442B-8A1A-DB6FDF8A35BA@dsl-only.net> (Mark Millard's message of "Sat, 30 Dec 2017 00:10:24 -0800") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 09:09:07 -0000 Mark Millard writes: > [I experiment with system clang based powerpc64 and powerpc > builds. For powerpc64, linking pkg requires using a ports > binutils instead of the system binutils. This blocks using > poudriere. So portmaster is in use here.] Would be nice if you cheat by replacing /usr/bin/ld instead. portmaster may miss some issues due to building in a dirty environment. > > On 2017-Dec-29, at 11:36 PM, Mark Millard wrote: > >> gmake[5]: Entering directory '/wrkdirs/usr/ports/graphics/mesa-dri/work/= mesa-17.3.1/src/amd/vulkan' >> python2.7 ./radv_entrypoints_gen.py \ >> --xml ../../../src/vulkan/registry/vk.xml --outdir . >> Traceback (most recent call last): >> File "./radv_entrypoints_gen.py", line 30, in >> from mako.template import Template >> ImportError: No module named mako.template Fixed by https://svnweb.freebsd.org/changeset/ports/457591 Vulkan drivers always need py-mako since Mesa 17.3 but I didn't try building only radv (either anv + radv or none). > freshports indicated: > > =E2=80=A2 py27-mako>0 : textproc/py-mako@py27 > > as a build dependency but portmaster did not > try to create a textproc/py-mako@py27 on > its own. freshports generates dependency list on amd64 but radv was also built on powerpc*. From owner-freebsd-ppc@freebsd.org Sat Dec 30 10:11:31 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34708EB4D77 for ; Sat, 30 Dec 2017 10:11:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-167.reflexion.net [208.70.210.167]) (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 D3D5377633 for ; Sat, 30 Dec 2017 10:11:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20650 invoked from network); 30 Dec 2017 10:04:49 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Dec 2017 10:04:49 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 30 Dec 2017 05:04:49 -0500 (EST) Received: (qmail 8541 invoked from network); 30 Dec 2017 10:04:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Dec 2017 10:04:49 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7F9D0EC9398; Sat, 30 Dec 2017 02:04:48 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: powerpc64: graphics/mesa-dri fails to build because "ImportError: No module named mako.template" From: Mark Millard In-Reply-To: Date: Sat, 30 Dec 2017 02:04:47 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Ports , freebsd-x11@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2765A66A-8908-44A1-ACB6-43157202F49C@dsl-only.net> <087297E8-4108-442B-8A1A-DB6FDF8A35BA@dsl-only.net> To: Jan Beich X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Dec 2017 10:11:31 -0000 On 2017-Dec-30, at 1:09 AM, Jan Beich wrote: > Mark Millard writes: >=20 >> [I experiment with system clang based powerpc64 and powerpc >> builds. For powerpc64, linking pkg requires using a ports >> binutils instead of the system binutils. This blocks using >> poudriere. So portmaster is in use here.] >=20 > Would be nice if you cheat by replacing /usr/bin/ld instead. > portmaster may miss some issues due to building in a dirty = environment. I use poudriere elsewhere, even on a rpi2. I'm familiar with portmaster's issues/limitations. I report problems to FreeBSD and llvm based on what I run into, including reporting the pkg bootstrap problem under poudriere. I try to be fairly normal in how things are used for such experiments. (The system binutils was able to link pkg until fairly recent clang updates.) The purpose of the experiments is to make the bugzilla submittals or list reports for what I run into. >>=20 >> On 2017-Dec-29, at 11:36 PM, Mark Millard = wrote: >>=20 >>> gmake[5]: Entering directory = '/wrkdirs/usr/ports/graphics/mesa-dri/work/mesa-17.3.1/src/amd/vulkan' >>> python2.7 ./radv_entrypoints_gen.py \ >>> --xml ../../../src/vulkan/registry/vk.xml --outdir . >>> Traceback (most recent call last): >>> File "./radv_entrypoints_gen.py", line 30, in >>> from mako.template import Template >>> ImportError: No module named mako.template >=20 > Fixed by https://svnweb.freebsd.org/changeset/ports/457591 > Vulkan drivers always need py-mako since Mesa 17.3 but I didn't > try building only radv (either anv + radv or none). Cool. Thanks. >> freshports indicated: >>=20 >> =E2=80=A2 py27-mako>0 : textproc/py-mako@py27 >>=20 >> as a build dependency but portmaster did not >> try to create a textproc/py-mako@py27 on >> its own. >=20 > freshports generates dependency list on amd64 but radv was also > built on powerpc*. I'm aware that freshports is not based on powerpc64. But it was enough to give me the hint as to where mako.template comes from since I was not familiar with it (or mesa-dri or vulkan). Side note: I used to to use the following to deal with the binutils issue, until clang progressed and system binutils no longer worked for pkg: # more /usr/local/etc/poudriere.d/make.conf=20 . . . # The system clang for TARGET_ARCH=3Dpowerpc64 # and the system binutils (such as ld) do not # (yet?) mix well. So for ports use the # devel/binutils ones. (A problem before # they are already in place!) .if ${.CURDIR:M*/devel/binutils} .elif ${.CURDIR:M*/math/gmp} .elif ${.CURDIR:M*/math/mpfr} .elif ${.CURDIR:M*/devel/bison} .elif ${.CURDIR:M*/devel/gmake} .elif ${.CURDIR:M*/devel/gettext-tools} .elif ${.CURDIR:M*/print/indexinfo} .elif ${.CURDIR:M*/devel/gettext-runtime} .elif ${.CURDIR:M*/ports-mgmt/pkg} .elif ${.CURDIR:M*/devel/m4} .elif ${.CURDIR:M*/lang/perl5.*} .elif ${.CURDIR:M*/print/texinfo} .elif ${.CURDIR:M*/misc/help2man} .elif ${.CURDIR:M*/devel/p5-Locale-gettext} .else USE_BINUTILS=3D # # devel/powerpc64-gcc builds end up using /usr/bin/ld # in places during the build anyway, so try to # separately force the issue to avoid the resulting # error(s). (By contrast lang/gcc7 built fine # without such additions.) CFLAGS+=3D-B${LOCALBASE}/bin/ CXXFLAGS+=3D-B${LOCALBASE}/bin/ CPPFLAGS+=3D-B${LOCALBASE}/bin/ .endif Basically: devel/binutils and the ports that needed to build before it did not use USE_BINUTILS=3D in their builds --but the rest of the built ports did. =3D=3D=3D Mark Millard markmi at dsl-only.net