On Wed, Nov 23, 2016 at 09:17:45PM +0000, Russell King - ARM Linux wrote:

On Wed, Nov 23, 2016 at 08:59:17PM +0000, Jason Cooper wrote:

quoted

As requested on irc:

Thanks.

quoted

     7f0:	ea000002 	b	800 <ath_cmn_process_fft+0xac>
     7f4:	e7970102 	ldr	r0, [r7, r2, lsl #2]
     7f8:	ebfffffe 	bl	0 <relay_buf_full>
     7fc:	e0844000 	add	r4, r4, r0
     800:	e300a000 	movw	sl, #0
     804:	e28b2001 	add	r2, fp, #1
     808:	e340a000 	movt	sl, #0
     80c:	e3a01004 	mov	r1, #4
     810:	e1a0000a 	mov	r0, sl
     814:	ebfffffe 	bl	0 <_find_next_bit_le>
     818:	e5953000 	ldr	r3, [r5]
     81c:	e1500003 	cmp	r0, r3
     820:	e1a0b000 	mov	fp, r0
     824:	e2802008 	add	r2, r0, #8
     828:	bafffff1 	blt	7f4 <ath_cmn_process_fft+0xa0>

Okay, so i was 0, so running UP probably isn't going to help.  r7 is
also spec_priv->rfs_chan_spec_scan.

So, I think the question is... how is this NULL - and has it always
been NULL...

The problem appears to be that ath_cmn_process_fft() isn't called that
often.  When it is, it crashes in ath_cmn_is_fft_buf_full() because
spec_priv->rfs_chan_spec_scan is NULL when ATH9K_DEBUGFS=n. :-(

I'm running with ATH9K_DEBUGFS=y now.  If it goes a couple of days
without crashing, I'll gin up a patch.

thx,

Jason.