On 4/4/23 10:07, Tim K wrote:
As rx_status is local to the routine, the error has to be in the right-hand side
of the statement. As hw->conf.....->center_freq is apparently OK most of the
time, I think you are getting a spurious RX interrupt. I have pushed a patch
that will show if hw is NULL, and quit the routine. Do a 'git pull', make... and
let me know what you see in the log.
Updated the drivers to e6d63e1 on your github repo, and ran for about
16 hours happily. Came back this morning to an error. I've attached
the stack trace, and the line of code that caused the error.
l *rtw_rx_fill_rx_status+0x48
0x8cd8 is in rtw_rx_fill_rx_status (/home/tkuester/code/rtw88/rx.c:163).
163 rx_status->freq = hw->conf.chandef.chan->center_freq;
Much to my chagrin, it seems I have an intermittent USB cable causing
spurious disconnects. However, while this does appear to be associated
with the issue, I also discovered this issue 20-some odd seconds into
boot on one boot cycle with no mention of USB disconnects.
Tim,
I suspect that your intermittent USB cable could also produce spurious
interrupts, which I thought might be the cause of the problem.
I had done some updates against wireless-next yesterday. To them, I added an
additional check in this routine. The driver should survive things like bad
cables without crashing the kernel. Do a pull, and let me know what you learn. I
would appreciate learning what happens with the faulty cable.
Larry
