Date: Fri, 30 Jun 2017 02:07:55 -0700 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, freebsd-hackers@freebsd.org 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>
next in thread | raw e-mail | index | archive | help
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 <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)
{
=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 <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: =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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1F24D891-4D11-4623-8183-7F95D9637FB2>