TARGET_ARCH=powerpc64 jump from head -r326192 to -r327075: g_event crashes with "instruction storage interrupt" [kldload -n filemon crashes the system]

[Mark Millard]

[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