Date: Sat, 23 Dec 2017 21:42:22 -0800 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: TARGET_ARCH=powerpc64 jump from head -r326192 to -r327075: g_event crashes with "instruction storage interrupt" [kldload -n filemon crashes the system] Message-ID: <68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3@dsl-only.net> In-Reply-To: <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <A9FD92FD-7877-4457-9A2B-A21FF0A4F0DD@dsl-only.net> <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[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 <markmi at dsl-only.net> 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 <markmi at dsl-only.net> 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 <markmi at dsl-only.net> wrote: >> >>> [Avoiding referencing partitions via labels >>> avoided the crash.] >>> >>> On 2017-Dec-22, at 9:26 PM, Mark Millard <markmi at dsl-only.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3>