From owner-freebsd-ppc@freebsd.org Fri Jun 30 09:07:59 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49C53D8C811 for ; Fri, 30 Jun 2017 09:07:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F339C17F6 for ; Fri, 30 Jun 2017 09:07:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1560 invoked from network); 30 Jun 2017 09:12:11 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 Jun 2017 09:12:11 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Fri, 30 Jun 2017 05:07:56 -0400 (EDT) Received: (qmail 26453 invoked from network); 30 Jun 2017 09:07:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Jun 2017 09:07:56 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AD4B1EC7E56; Fri, 30 Jun 2017 02:07:55 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: 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) Message-Id: <1F24D891-4D11-4623-8183-7F95D9637FB2@dsl-only.net> Date: Fri, 30 Jun 2017 02:07:55 -0700 To: FreeBSD PowerPC ML , FreeBSD Current , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 09:07:59 -0000 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=3Dpowerpc64 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 =3D 0x700 (program) (for "illegal instruction") srr0 =3D 0x70bf878 (note: this varies, for example: 0x5e37230) (note: r0 always matches srr0) (note: ctr always matches srr0) srr1 =3D 0x89032 (stays the same) lr =3D 0x5b7b94 (note: solisten_wakeup+0x4c) (stays the same) curthread =3D 0x5ab8ae0 (varies) pid =3D 920 (varies), comm =3D 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=3D0xf032 (stays the same) r1 =3D0xffffd5e0 (stays the same) cr =3D0x24440840 (stays the same) xer =3D0x20000000 (stays the same) ctr =3D0x419db160 (stays the same) 005b7b48 stwu r1,-32(r1) 005b7b4c mflr r0 005b7b50 stw r29,20(r1) 005b7b54 stw r30,24(r1) 005b7b58 stw r31,28(r1) 005b7b5c stw r0,36(r1) 005b7b60 mr r31,r1 005b7b64 bcl- 20,4*cr7+so,005b7b68 = 005b7b68 mflr r30 005b7b6c lwz r0,-36(r30) 005b7b70 add r30,r0,r30 005b7b74 mr r29,r3 005b7b78 lwz r0,232(r3) 005b7b7c cmpwi cr7,r0,0 005b7b80 beq- cr7,005b7b98 = 005b7b84 lwz r4,236(r3) 005b7b88 li r5,1 005b7b8c mtctr r0 005b7b90 bctrl lr: 005b7b94 b 005b7bb4 . . . 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) { =20 if (sol->sol_upcall !=3D 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); } =20 005b8548 li r10,1 005b854c b 005b8558 005b8550 stwcx. r10,0,r9 005b8554 li r10,0 005b8558 cmpwi cr7,r10,0 005b855c bne- cr7,005b8568 = 005b8560 addi r3,r28,16 005b8564 bl 004d4218 <__mtx_unlock_sleep> 005b8568 mr r3,r27 at soisconnected+0x21c: 005b856c bl 005b7b48 005b8570 b 005b89f0 . . . void soisconnected(struct socket *so) { struct socket *head; . . . restart: =20 SOCK_LOCK(so); if ((head =3D so->so_listen) !=3D NULL && __predict_false(SOLISTEN_TRYLOCK(head) =3D=3D 0)) { SOCK_UNLOCK(so); goto restart; } =20 so->so_state &=3D = ~(SS_ISCONNECTING|SS_ISDISCONNECTING|SS_ISCONFIRMING); so->so_state |=3D SS_ISCONNECTED; if (head !=3D NULL && (so->so_qstate =3D=3D SQ_INCOMP)) { again: if ((so->so_options & SO_ACCEPTFILTER) =3D=3D 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 =3D SQ_COMP; SOCK_UNLOCK(so); solisten_wakeup(head); /* unlocks */ . . . =3D=3D=3D Mark Millard markmi at dsl-only.net