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: > > As requested on irc: > > Thanks. > > > 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.
