[Bug 226974] kernel DSI read trap at boot

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226974

            Bug ID: 226974
           Summary: kernel DSI read trap at boot
           Product: Base System
           Version: CURRENT
          Hardware: powerpc
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: leandro.lupori at gmail.com

Latest kernel and bootloader are not able to boot in powerpc64 anymore:

Stopped at      .trap+0x40:     stdu    r1, r1, 0xfe40
db> bt
Tracing pid 0 tid 0 td 0x14c45e0
0xc000000000001190: kernel DSI read trap @ 0xdeadc0dedeadc0de by
.pmap_decode_kernel_ptr+0x38: srr1=0x8000000000001032
            r1=0xc000000000001440 cr=0x20001032 xer=0x20000000 ctr=0
r2=0x137bc08 sr=0x40000000
saved LR(0x7f83e3784bfffccd) is invalid.


Using git bisect, I was able to find the commit that introduced the issue:

commit 47a0fb0f642831283509dab8b3ca1c63f3d7cda6
Author: nwhitehorn <nwhitehorn at FreeBSD.org>
Date: Sun Mar 4 04:49:09 2018 +0000

Where we can, pass the kernel an FDT facsimile of the OF device tree rather
    than a pointer to Open Firmware by default. This eliminates a number of
    potentially unsafe calls to firmware from the kernel and provides better
    performance.


But this commit only sets usefdt to 1 in the bootloader. Older kernels didn't
break with this option. So after another round of git bisect I found when the
kernel stopped working with the new bootloader:

commit e3be9f8fb6d01fd2604b306b6f8ab52afb2d1173
Author: jeff <jeff at FreeBSD.org>
Date: Tue Feb 20 00:06:07 2018 +0000

Further parallelize the buffer cache.


Tracking down the issue, this is what I was able to find out so far:
- during one of the calls to keg_fetch_slab(), reached from malloc_init(), when
in mi_startup(), mmu_obj is overwritten with 0xdeadc0dedeadc0de.
- then, the next time pmap_decode_kernel_ptr is called the trap happens when it
tries to use the now invalid mmu_obj

-- 
You are receiving this mail because:
You are the assignee for the bug.