re: kern/50186: sparc memfault panic after 7.99.21 ARP changes

[matthew green <mrg%eterna.com.au@localhost>]

The following reply was made to PR kern/50186; it has been noted by GNATS.

From: matthew green <mrg%eterna.com.au@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
    netbsd-bugs%netbsd.org@localhost
Subject: re: kern/50186: sparc memfault panic after 7.99.21 ARP changes
Date: Tue, 01 Sep 2015 17:32:57 +1000

 > >From GENERIC:
 > =
 
 > cpu0: data fault: pc=3D0xf00a626c addr=3D0x10 sfsr=3D0x326<PERR=3D0x0,LV=
 L=3D0x3,AT=3D0x1,FT=3D0x1,FAV,OW>
 > panic: kernel fault
 > Stopped in pid 0.5 (system) at  netbsd:cpu_Debugger+0x4:        or      =
         %o7, %g0, %g1
 > db> bt
 > cpu_Debugger(0xf03efb58, 0xf9ac7d20, 0xf0482c00, 0xf0483a58, 0xf0483800,=
  0x104) at netbsd:panic+0x20
 > panic(0xf03efb58, 0x0, 0xf00a626c, 0x10, 0xf9ac7d40, 0xf045c800) at netb=
 sd:mem_access_fault4m+0x5b0
 > mem_access_fault4m(0x9, 0x326, 0x10, 0xf9ac7de0, 0xf0459b20, 0xf0a60540)=
  at netbsd:memfault_sun4m+0xe8
 > memfault_sun4m(0xf0b8852c, 0x1, 0x0, 0xf04712a0, 0xf0a60544, 0xf0a60544)=
  at netbsd:arptimer+0x6c
 > arptimer(0xf0b88480, 0xf0a60540, 0xf0b8c808, 0x0, 0xf0b8852c, 0xf0488800=
 ) at netbsd:callout_softclock+0x154
 > callout_softclock(0xf04712a4, 0x1000000, 0x10000, 0xf04712a0, 0xf0b88480=
 , 0xf00a61d8) at netbsd:softint_thread+0x94
 > softint_thread(0xf0a60540, 0x3000, 0x2000, 0x0, 0x0, 0xf9ac0218) at netb=
 sd:lwp_trampoline+0x8
 > db>
 
 OK, so i built my own GENERIC.  i get this:
 
 (gdb) l *(arptimer+0x6c)
 0xf00a6244 is in arptimer (/usr/src4/sys/netinet/if_arp.c:352).
 347             ifp =3D lle->lle_tbl->llt_ifp;
 348     =
 
 349             callout_stop(&lle->la_timer);
 350     =
 
 351             /* XXX: LOR avoidance. We still have ref on lle. */
 352             LLE_WUNLOCK(lle);
 353     =
 
 354             /* We have to call this w/o lock */
 355             arptfree(lle);
 
 disass/m arptimer gives:
 
 351             /* XXX: LOR avoidance. We still have ref on lle. */
 352             LLE_WUNLOCK(lle);
    0xf00a6244 <+108>:   call  0xf0163fd0 <rw_vector_exit>          <--- [a=
 ]
    0xf00a6248 <+112>:   mov  %i4, %o0
 
 but my addresses don't match yours entirely.  [a] is the instruction that
 appears to me faulting... which makes little sense.
 
 John, can you try the above gdb commands for yourself?  thanks.
 
 
 .mrg.