svn commit: r319722 - in head: sys/cam/ctl sys/dev/iscsi sys/kern sys/netgraph sys/netgraph/bluetooth/socket sys/netinet sys/ofed/drivers/infiniband/core sys/ofed/drivers/infiniband/ulp/sdp sys/rpc...

[Mark Millard]

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