Date: Fri, 22 Dec 2017 22:33:54 -0800 From: Mark Millard <markmi@dsl-only.net> To: Justin Hibbits <chmeeedalf@gmail.com>, Nathan Whitehorn <nwhitehorn@freebsd.org>, 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: <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> In-Reply-To: <A9FD92FD-7877-4457-9A2B-A21FF0A4F0DD@dsl-only.net> References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <A9FD92FD-7877-4457-9A2B-A21FF0A4F0DD@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[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 === Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?244D5C85-E1E7-4349-A46A-1D275D54833F>