Date: Sat, 23 Dec 2017 20:00:44 -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: <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> In-Reply-To: <244D5C85-E1E7-4349-A46A-1D275D54833F@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>
next in thread | previous in thread | raw e-mail | index | archive | help
[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@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.) 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55A9388E-2C04-4388-A4E9-F25574FAF129>