fatal kernel trap

[Mark Millard]

On 2018-Mar-18, at 8:16 PM, Steve Wills <swills at FreeBSD.org> wrote:

> Sure. The system has 8GB of RAM and 2 CPUs. The root fs is on UFS and it also has a disk with ZFS. The panic doesn't happen until very late in boot, when it's mounting disks. I updated the whole system to r328835 back in Feb. Then I switched the compiler over gcc 6.3.0 and rebuilt kernel/world again. Not sure what other info might be helpful, let me know if there's some particular that might help.
> 
> Steve
> 
> On 03/17/2018 19:57, Nathan Whitehorn wrote:
>> Could you provide any other detail on your system? Amount of RAM, etc.?
>> -Nathan
>> On 03/17/18 08:39, Steve Wills wrote:
>>> Finished bisecting, r329611 boots fine, r329612 does not.
>>> 
>>> Steve
>>> 
>>> On 03/16/2018 10:43, Justin Hibbits wrote:
>>>> 
>>>> On Mar 16, 2018 09:29, "Steve Wills" <swills at freebsd.org <mailto:swills at freebsd.org>> wrote:
>>>> 
>>>>     My PowerMac G5 runs r328835 fine, but upgrading to r330240 results in:
>>>> 
>>>>     fatal kernel trap:
>>>> 
>>>>        exception           = 0x300 (data storage interrupt)
>>>>        virtual address     = 0xc186bff8
>>>>        dsisr               = 0x40000000
>>>>        srr0                = 0x8ef510 (0x8ef510)
>>>>        srr1                = 0x9000000000009032
>>>>        lr                  = 0x7be3e4 (0x7be3e4)
>>>>        curthread           = 0x11b26560
>>>>               pid = 38, comm = kldload

Given that it reports "kldload": Do you have a way to do a simple
boot that would avoid loading any .ko files?

In my clang-based experiments I ran into .ko files getting a
different type of linkage (R_PPC64_JMP_SLOT) for the kldload to
resolve (that it did not handle, leading to panics). I ended up
adding:

device 	filemon
device 	geom_label

to the kernel so that my normal activity could happen without
kldload's of .ko files.

[This goes back to 2017-Dec-24 or so. I've not been very active
on FreeBSD most of the time after that.]

I'm not claiming you have R_PPC64_JMP_SLOT use. I'm just
illustrating avoiding kldload activity as a possible test.

>>>>     [ thread pid 38 tid 100087 ]
>>>>     Stopped at      strchr+0x70:    lbzu   r10, 0x1(r4)
>>>>     db>
>>>> 
>>>>     Note this was transcribed by hand and may have typos. Also note my
>>>>     kernel was compiled with gcc 6.3.0, although the previous kernel was
>>>>     as well and it works fine.
>>>> 
>>>>     Any suggestions would be appreciated.
>>>> 
>>>>     Thanks,
>>>>     Steve
>>>> 
>>>> 
>>>> Hi Steve,
>>>> 
>>>> I see the same thing with any attempt to upgrade the kernel on my G5 (PowerMac11,2) from a November 6 build to more recent. I've seen it since the January timeframe, and haven't yet figured it out.
>>>> 
>>>> - Justin



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)