On Thu, Nov 24, 2016 at 02:06:57PM +0800, miaoqing@xxxxxxxxxxxxxx wrote: > > >>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. > > > > A similar patch was applied to ath-next branch: > https://patchwork.kernel.org/patch/9431163/. Hmm. Ok, I'm giving it a spin on my board with SMP=y, ATH9K_DEBUGFS=n (so the only change from known crashing is the patch) and we'll see how it goes. Honestly, though, I think the real problem is when kernels are built without ATH9K_DEBUGFS. Did the reporter of the crash say if that was enabled on his system or not? I'm concerned that there may be other code lurking that secretly depends on ATH9K_DEBUGFS being enabled. thx, Jason.
