From owner-freebsd-hackers@freebsd.org Sun Dec 24 04:27: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 A19F2E96433 for ; Sun, 24 Dec 2017 04:27:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-170.reflexion.net [208.70.210.170]) (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 6026467546 for ; Sun, 24 Dec 2017 04:27:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30037 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-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 04:27:28 -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