Mike Pumford wrote: Forgot a couple of things here:
uvm_fault(0xf27e36a0, deadd000, 1) -> e Fatal kernel mode data abort: 'Tranlation Fault (S)' trapframe: 0xf2c4bd58 FSR=18529005,FAR=deaddec5 SPSR=a0000013 r0 =f037e128, r1 =0901a8c0, r2 =deaddead, r3 =0101a8c0 r4 =00003500, r5 =f1179658, r6 =0000faff, r7 =00000000 r8 =8150020a, r9 =c0a80109, r10=f1179658, r11=f2c4bde0 r12=00000000, ssp=f2c4bda4, slr=f02448a0, pc =f00be848
in_pcblookup_connect+??
This was actually pcblookup_connect+0xd4 Which disassembles to: ldr r5, [r2, #24]If I'm reading the pool code correctly this means that the inpcb code was referencing a freed pool entry! I've seen other DIAGNOSTIC traces with the same failure. It also matches behaviour where I've seen an SSH session forced closed when stopping a listening TCP server on the machine from another SSH session.
I've attached the patches I've made to the MD code just in case I've done something stupid in one of those changes. I've also attached a dmesg taken before the system panics to give full details of the hardware in the system.
And a description of the patches might be useful:vidcvideo.patch: Use the RI_NO_AUTO flag when bringing up the console. Stops the system hanging before even starting to boot. Modelled on a similar change in igsfb driver.
iomd_clock.patch: Use the IOMD timer to provide a more accurate delay() implementation. Previous implementation was becoming increasingly optimised away by newer GCC versions to the point that the keyboard driver no longer worked correctly. I'm not sure whether the SPL based locking is better than the disable interrupt approach or if I should be doing something else entirely here.
Feedback on either of these patches is also appreciated. Mike