TARGET_ARCH=powerpc64 jump from head -r326192 to -r327075: g_event crashes with "instruction storage interrupt"

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

TARGET_ARCH=powerpc64 jump from head -r326192 to -r327075: g_event crashes with "instruction storage interrupt"

Mark Millard-2
[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.


===
Mark Millard
markmi at dsl-only.net

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: TARGET_ARCH=powerpc64 jump from head -r326192 to -r327075: g_event crashes with "instruction storage interrupt" [sidestepped by avoiding use of drive labels]

Mark Millard-2
[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.

===
Mark Millard
markmi at dsl-only.net


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Is the clang 5.0.1 use of .rela.plt and R_PPC64_JMP_SLOT for kernel modules a llvm issue? Just a FreeBSD one? (Still true of clang 6.)

freebsd-hackers mailing list
[Notes on clang 6 properties for this. Also note: newer Email
address than the original.]

On 2017-Dec-29, at 4:18 PM, Mark Millard <markmi at dsl-only.net> wrote:

> I've not been able to figure out if I should submit something
> into llvm's bugzilla for the powerpc64 switching to .rela.plt
> and R_PPC64_JMP_SLOT for kernel modules from the earlier
> .rela.dyn and R/PPC64_RELATIVE and R_PPC64_ADDR64 for kernel
> modules. (I do not know if powerpc would also have the issue
> since other things have been stopping that build for a long
> time.)
>
> Do one or more of you have a clue?
>
> Reminder:
>
>
> I have submitted FreeBSD bugzilla 224561 for the issue.
>
> The difference in the likes of filemon.ko
> produced by system clang 5.0.1 vs.
> devel/powerpc64-xtoolchain-gcc is. . .
>
> clang 5.0.1:
>
> Relocation section with addend (.rela.plt):
> r_offset     r_info       r_type              st_value         st_name + r_addend
> 000000014480 000300000015 R_PPC64_JMP_SLOT    0000000000000000 copyinstr + 0
> 000000014488 000400000015 R_PPC64_JMP_SLOT    0000000000000000 devfs_set_cdevpriv + 0
> . . .

I finally did some updating of part of my
FreeBSD environment, jumping something like
2000 revision numbers . . .

Under head -r329542 and its clang 6 there is still a
"Relocation section with addend (.rela.plt)" that
uses R_PPC64_JMP_SLOT r_types.

(This is using devel/powerpc64-binutils .)

(There was and is some .rela.dyn and
R_PPC64_RELATIVE/R_PPC64_ADDR64 use
as well.)

So: 6 is like 5.0.1 for this issue.

> vs.
>
> devel/powerpc64-xtoolchain-gcc:
>
> Relocation section with addend (.rela.dyn):
> r_offset     r_info       r_type              st_value         st_name + r_addend
> 0000000145c0 000000000016 R_PPC64_RELATIVE    0000000000000000  + 40d0
> 0000000145e0 000000000016 R_PPC64_RELATIVE    0000000000000000  + 145b0
> . . .
> 000000014408 000600000026 R_PPC64_ADDR64      0000000000000000 sysent + 0
> 000000014410 001100000026 R_PPC64_ADDR64      0000000000000000 freebsd32_sysent + 0

Under head -r329542 devel/powerpc64-gcc there is
no use of .rela.plt or R_PPC64_JMP_SLOT: Just
.rela.dyn and R_PPC64_RELATIVE/R_PPC64_ADDR64
use.

(This is using devel/powerpc64-binutils .)

> Apparently R_PPC64_JMP_SLOT is mishandled
> and does not explicitly lead to rejection
> of the attempted dynamic load.
>
> It might be an issue if .rela.plt and
> R_PPC64_JMP_SLOT should even be generated
> instead of .rela.dyn and R_PPC64_RELATIVE
> and R_PPC64_ADDR64.

I have not actually tried the modern builds
on a old PowerMac G5 yet: other things took
up time. Also the USB devmatch issues are a
worry since I have no alternatives to
directly connected USB keyboards, mice (and
possibly more) if I end up unable to connect
over the local network for some reason.

But I've not noticed anything go by that
indicated adding support for R_PPC64_JMP_SLOT
or .rela.plt in filemon.ko or other such .ko's.
So I only expect dynamic module loading to work
for the devel/powerpc64-gcc based kernel.

(I still build-in two(?) extra .ko's to avoid the
loading issue for them if I play with the clang
based kernel. One of them is filemon.ko .)

===
Mark Millard
marklmi at yahoo.com
( markmi at dsl-only.net is
going away in 2018-Feb, late)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"