[Bug 237590] powerpc64 PowerMac11,2 and 7,2 context, -r330614 and later (including -r345758): "ofwdump -ap" crashes the system; probable -r330610 "cause"

[bugzilla-noreply at freebsd.org]

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

Mark Millard <marklmi26-fbsd at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|powerpc64 PowerMac11,2 and  |powerpc64 PowerMac11,2 and
                   |7,2 context, -r330614 and   |7,2 context, -r330614 and
                   |later (including -r345758): |later (including -r345758):
                   |"ofwdump -ap" crashes the   |"ofwdump -ap" crashes the
                   |system, unable to sleep     |system; probable -r330610
                   |cpus; probable -r330610     |"cause"
                   |"cause"                     |

--- Comment #2 from Mark Millard <marklmi26-fbsd at yahoo.com> ---
(In reply to Mark Millard from comment #1)

>From looking at the code the message about timeout
stopping cpus is from kdbtrap and does not of itself
seem to be part of the original problem.

Attempting a bt at the ddb> prompt gets its own
fatal kernel trap but some of the exception information
is possibly of interest. Typed from a screen picture
(this is from -r330614):

exception      = 0x300 (data storage interrupt)
virtual address= 0xffffffffffb7f400
dsisr          = 0x40000000
srr0           = 0x9b2194 (0x9b2194)
srr1           = 0x9000000000001032
lr             = 0x9b254c (0x9b254c)
curthread      = 0xc0000000024fb000
       pid = 12, comm = swi4: clock (0)

The stack backtrace itself listed:

0x0000000f95460: kernel DSI read trap @ 0xffffffffffb7f400
by .db_backtrace+0x40

[Multiple attempts got the same as the above.]

That matches of 0x9b2194 for srr0:

00000000009b2154 <.db_backtrace> mflr    r0
00000000009b2158 <.db_backtrace+0x4> std     r28,-32(r1)
00000000009b215c <.db_backtrace+0x8> std     r29,-24(r1)
00000000009b2160 <.db_backtrace+0xc> std     r30,-16(r1)
00000000009b2164 <.db_backtrace+0x10> std     r31,-8(r1)
00000000009b2168 <.db_backtrace+0x14> std     r0,16(r1)
00000000009b216c <.db_backtrace+0x18> stdu    r1,-144(r1)
00000000009b2170 <.db_backtrace+0x1c> mr      r31,r1
00000000009b2174 <.db_backtrace+0x20> mr      r28,r5
00000000009b2178 <.db_backtrace+0x24> ld      r9,-20736(r2)
00000000009b217c <.db_backtrace+0x28> lwz     r0,0(r9)
00000000009b2180 <.db_backtrace+0x2c> cmpwi   cr7,r0,0
00000000009b2184 <.db_backtrace+0x30> bne     cr7,00000000009b24e0
<.db_backtrace+0x38c>
00000000009b2188 <.db_backtrace+0x34> cmpldi  cr7,r4,4095
00000000009b218c <.db_backtrace+0x38> ble     cr7,00000000009b24e0
<.db_backtrace+0x38c>
00000000009b2190 <.db_backtrace+0x3c> mr      r30,r4
00000000009b2194 <.db_backtrace+0x40> ld      r30,0(r30)
. . .

Which is from:

static int
db_backtrace(struct thread *td, db_addr_t fp, int count)
{
        db_addr_t stackframe, lr, *args;
        boolean_t kernel_only = TRUE;
        boolean_t full = FALSE;

#if 0
. . .
#endif

        stackframe = fp;

        while (!db_pager_quit) {
                if (stackframe < PAGE_SIZE)
                        break;

                /*
                 * Locate the next frame by grabbing the backchain ptr
                 * from frame[0]
                 */
                stackframe = *(db_addr_t *)stackframe;
. . .

That establishes that the 0xffffffffffb7f400 value is
from what the code expects was a stack location holding
a backchain pointer.

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