Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Mar 2018 13:16:52 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 226974] kernel DSI read trap at boot
Message-ID:  <bug-226974-8@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226974

            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@FreeBSD.org
          Reporter: leandro.lupori@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=3D0x8000000000001032
            r1=3D0xc000000000001440 cr=3D0x20001032 xer=3D0x20000000 ctr=3D0
r2=3D0x137bc08 sr=3D0x40000000
saved LR(0x7f83e3784bfffccd) is invalid.


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

commit 47a0fb0f642831283509dab8b3ca1c63f3d7cda6
Author: nwhitehorn <nwhitehorn@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 t=
he
kernel stopped working with the new bootloader:

commit e3be9f8fb6d01fd2604b306b6f8ab52afb2d1173
Author: jeff <jeff@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 whe=
n it
tries to use the now invalid mmu_obj

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-226974-8>