On Wed, 2020-09-02 at 08:36 +0200, Johannes Berg wrote:
> On Tue, 2020-09-01 at 15:03 -0700, James Prestwood wrote:
> > [ 1335.541174] CPU: 0 PID: 982 Comm: hwsim Not tainted 5.8.0 #1
> > [ 1335.553946] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
> > BIOS
> > 1.13.0-2.fc32 04/01/2014
> > [ 1335.588370] RIP: 0010:hwsim_cloned_frame_received_nl+0x141/0x2c0
>
> It'd help if you could run ./scripts/decode_stacktrace.sh or use gdb
> or
> something like that.
I was able to decode the stacktrace, but my kernel isn't built with
debug symbols so its no more useful than what I had before. I guess I
didn't specify exactly before, but I was able to printk debug the
offending line of code (where data2->channel is NULL):
if (rx_status.freq != data2->channel->center_freq &&
(!data2->tmp_chan ||
rx_status.freq != data2->tmp_chan->center_freq)) {
mutex_unlock(&data2->mutex);
goto out;
}
My 'fix' (hack) was to check data2->channel for NULL before this if
statement, and unlock the mutex/goto out if channel was NULL. So
bascially just drop the frame. I really don't think this is the right
way of doing it but I'm not familiar with how/when channel is set and
if its normal for it to be NULL. If this is fine I can send a patch but
it doesnt feel right to me.
Thanks,
James
>
> johannes
>
>
