> 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.
Attachment:
dmesg.log
Description: Binary data
