From owner-freebsd-hackers@freebsd.org Sun Dec 24 06:55:28 2017 Return-Path: Delivered-To: freebsd-hackers@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 BC310EA0D01 for ; Sun, 24 Dec 2017 06:55:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-106.reflexion.net [208.70.210.106]) (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 7882B6BAED for ; Sun, 24 Dec 2017 06:55:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32408 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-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Dec 2017 06:55:28 -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