On 16.12.22. 11:18, Michael Walle wrote: > Hi, > > On 22/12/09 02:14, Ajay.Kathat@xxxxxxxxxxxxx wrote: >> No progress yet. I tried to simulate the condition a few times but was >> unable to see the exact failure in my setup so I need to try more. > Shouldn't it also be possible to see the issue by code reading? I've > provided the call tree in my previous mail and my concerns regarding > the locking. Either I'm missing something there or there is no > locking between these threads which could cause this issue. > >> For the other "FW not responding" continuous logs, I got some clue. >> Probably, will try to send that patch first. > Ok, let me know if you have some patches, I'm happy to test them. > > -michael > > Hello, I faced the same kernel oops issue. After analyzing my logs and brief debugging, I agree with Mikhail: the problem seems to be accessing the scan_result pointer after it has been nulled. Regarding the solution: if there is a race between two threads (as Michael described earlier), then I think that the locking mechanism will be the most reliable solution. We ran into problems during deinitialization, but driver contains two more places (handle_scan_done() and wilc_disconnect() functions in wilc1000/hif.c), where scan_result is set to NULL. I use NetworkManager to manage networks and I have experienced the same failure multiple times when switching from one WiFi network to another. Keep in mind that switching between networks calls wilc_disconnect() and wilc_deinit() functions and it is not yet clear which one is causing a core dump. I think it's worth at least taking a look at these areas of the code. What do you think? Best regards, Kirill Buksha.
