FYI: in the current memory layout my -r317820 variant has been up for 3 days 17+ hours. (Various extra checks for panicking on some observed failures earlier but no HACKISH_EXTRA_CODE.)
I think the wrong code was looked up. . . The code you reported having the failure: > 5a5a18: 38 7c 00 10 addi r3,r28,16 > 5a5a1c: 4b f1 c4 61 bl 4c1e7c <__mtx_unlock_sleep> > 5a5a20: 7f 63 db 78 mr r3,r27 > ->5a5a24: 4b ff f5 9d bl 5a4fc0 <solisten_wakeup> > 5a5a28: 48 00 04 80 b 5a5ea8 <soisconnected+0x6a0> > 5a5a2c: 7c 45 13 78 mr r5,r2 > 5a5a30: 39 20 00 04 li r9,4 The trap you reported in the picture (notes added): > exception = 0x700 (program) > srr0 = 0x6064a90 (the address were execution was attempted) > srr1 = 0x89032 > lr = 0x5a500c (early inside solisten_wakeup) > curthread = 0x6c So: 0x5a4fc0 (solisten_wakeup) 0x5a500c (lr being early inside solisten_wakeup?) What about the code around 0x5a5a24 could possibly jump to 0x6064a90 ? How about around 0x5a500c that is closer to where the processor was executing? I usually have to look at what the backtrace reports and see if a call was made (bl) there and look at what was called. Powerpc backtraces can miss a layer of subroutine that is active. === Mark Millard markmi at dsl-only.net _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "[email protected]"
