head -r320482 vs. TARGET_ARCH=powerpc production style kernel: jumps to non-code and traps (but the debug kernel build works for the same world)

From: Mark Millard <markmi_at_dsl-only.net>
Date: Fri, 30 Jun 2017 02:07:55 -0700
The -r320482 kernel build is via gcc 4.2.1.
Both gcc 4.2.1 and clang based worlds show
the same problems. TARGET_ARCH=powerpc64
is not showing the problems.

The production kernel build fails
but the debug works --each built
from the same /usr/src/ tree.

I'll note what a normal boot does
before getting to the login prompt but
after "Starting nfsd." ("Updating motd:"
can be mixed in the trap text: not shown
below.)

I use an example and note a lot about what
varies and what stays the same from example
boot to example boot of the production
kernel.

[Manually entered from camera pictures
of the screen.]

fatal kernel trap
exception = 0x700 (program) (for "illegal instruction")
srr0      = 0x70bf878 (note: this varies, for example: 0x5e37230)
            (note:  r0 always matches srr0)
            (note: ctr always matches srr0)
srr1      = 0x89032   (stays the same)
lr        = 0x5b7b94  (note: solisten_wakeup+0x4c) (stays the same)
curthread = 0x5ab8ae0 (varies)
pid = 920 (varies), comm = mountd (stays the same)

Tracing command mountd pid 920 tid 100119 (varies) td 0x5ab8ae0 (varies)(CPU 1)
(stack addr
range varies)
0xd250a500: at soisconnected+0x21c     (at stays the same)
0xd250a540: at unp_connect2+0xf0       (at stays the same)
0xd250a560: at unp_connectat+0x658     (at stays the same)
0xd250a770: at unp_connect+0x2c        (at stays the same)
0xd250a790: at uipc_connect+0xc0       (at stays the same)
0xd250a7d0: at soconnectat+0xa0        (at stays the same)
0xd250a800: at soconnect+0x2c          (at stays the same)
0xd250a820: at kern_connect+0134       (at stays the same)
0xd250a870: at sys_connect+0x64        (at stays the same)
0xd250a8b0: at trap+0x638              (at stays the same)
0xd250aa50: at powerpc_interrupt+0x1a0 (at stays the same)
0xd250aa80: at user SC trap (at stays the same)
            by 0x419db168   (stays the same)
            srr1=0xf032     (stays the same)
            r1  =0xffffd5e0 (stays the same)
            cr  =0x24440840 (stays the same)
            xer =0x20000000 (stays the same)
            ctr =0x419db160 (stays the same)

005b7b48 <solisten_wakeup> stwu    r1,-32(r1)
005b7b4c <solisten_wakeup+0x4> mflr    r0
005b7b50 <solisten_wakeup+0x8> stw     r29,20(r1)
005b7b54 <solisten_wakeup+0xc> stw     r30,24(r1)
005b7b58 <solisten_wakeup+0x10> stw     r31,28(r1)
005b7b5c <solisten_wakeup+0x14> stw     r0,36(r1)
005b7b60 <solisten_wakeup+0x18> mr      r31,r1
005b7b64 <solisten_wakeup+0x1c> bcl-    20,4*cr7+so,005b7b68 <solisten_wakeup+0x20>
005b7b68 <solisten_wakeup+0x20> mflr    r30
005b7b6c <solisten_wakeup+0x24> lwz     r0,-36(r30)
005b7b70 <solisten_wakeup+0x28> add     r30,r0,r30
005b7b74 <solisten_wakeup+0x2c> mr      r29,r3
005b7b78 <solisten_wakeup+0x30> lwz     r0,232(r3)
005b7b7c <solisten_wakeup+0x34> cmpwi   cr7,r0,0
005b7b80 <solisten_wakeup+0x38> beq-    cr7,005b7b98 <solisten_wakeup+0x50>
005b7b84 <solisten_wakeup+0x3c> lwz     r4,236(r3)
005b7b88 <solisten_wakeup+0x40> li      r5,1
005b7b8c <solisten_wakeup+0x44> mtctr   r0
005b7b90 <solisten_wakeup+0x48> bctrl
lr:
005b7b94 <solisten_wakeup+0x4c> b       005b7bb4 <solisten_wakeup+0x6c>
. . .

Apparently this means that sol->sol_upcall is not
pointing to code at all yet is not null. Given the
variability observed, it might be uninitialized
--or sol itself is junk. . .

void
solisten_wakeup(struct socket *sol)
{
                
        if (sol->sol_upcall != NULL)
                (void )sol->sol_upcall(sol, sol->sol_upcallarg, M_NOWAIT);
        else {
                selwakeuppri(&sol->so_rdsel, PSOCK);
                KNOTE_LOCKED(&sol->so_rdsel.si_note, 0);
        }
        SOLISTEN_UNLOCK(sol);
        wakeup_one(&sol->sol_comp);
}                               


005b8548 <soisconnected+0x1f8> li      r10,1
005b854c <soisconnected+0x1fc> b       005b8558 <soisconnected+0x208>
005b8550 <soisconnected+0x200> stwcx.  r10,0,r9
005b8554 <soisconnected+0x204> li      r10,0
005b8558 <soisconnected+0x208> cmpwi   cr7,r10,0
005b855c <soisconnected+0x20c> bne-    cr7,005b8568 <soisconnected+0x218>
005b8560 <soisconnected+0x210> addi    r3,r28,16
005b8564 <soisconnected+0x214> bl      004d4218 <__mtx_unlock_sleep>
005b8568 <soisconnected+0x218> mr      r3,r27
at soisconnected+0x21c:
005b856c <soisconnected+0x21c> bl      005b7b48 <solisten_wakeup>
005b8570 <soisconnected+0x220> b       005b89f0 <soisconnected+0x6a0>
. . .

void
soisconnected(struct socket *so)
{
        struct socket *head;
. . .
restart:                
        SOCK_LOCK(so);
        if ((head = so->so_listen) != NULL &&
            __predict_false(SOLISTEN_TRYLOCK(head) == 0)) {
                SOCK_UNLOCK(so);
                goto restart;
        }        
        so->so_state &= ~(SS_ISCONNECTING|SS_ISDISCONNECTING|SS_ISCONFIRMING);
        so->so_state |= SS_ISCONNECTED;
        if (head != NULL && (so->so_qstate == SQ_INCOMP)) {
again:
                if ((so->so_options & SO_ACCEPTFILTER) == 0) {
                        TAILQ_REMOVE(&head->sol_incomp, so, so_list);
                        head->sol_incqlen--;
                        TAILQ_INSERT_TAIL(&head->sol_comp, so, so_list);
                        head->sol_qlen++;
                        so->so_qstate = SQ_COMP;
                        SOCK_UNLOCK(so);
                        solisten_wakeup(head);  /* unlocks */
. . .




===
Mark Millard
markmi at dsl-only.net
Received on Fri Jun 30 2017 - 07:07:59 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:12 UTC