Created attachment 175831 [details] dmesg for linux 4.1rc2 with r8712u problem. result of bisecting: 6501c8e7d86cca5fab74f873810cbc573273d1b4 is the first bad commit commit 6501c8e7d86cca5fab74f873810cbc573273d1b4 Author: Vaishali Thakkar <vthakkar1994@gmail.com> Date: Fri Mar 6 16:23:35 2015 +0530 Staging: rtl8712: Eliminate use of _cancel_timer_ex Use timer API function del_timer_sync instead of driver specific function _cancel_timer_ex as besides deactivating a timer, it ensures that the timer is stopped on all CPUs before the driver exists. Also, definition of function _cancel_timer_ex is removed as it is no longer needed after this change. This is done using Coccinelle and semantic patch used for this is as follows: @@ expression x; @@ - _cancel_timer_ex (&x); + del_timer_sync (&x); Signed-off-by: Vaishali Thakkar <vthakkar1994@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> :040000 040000 eaab34b0be7461ea124eb924a374babf19bb05f9 32fe24820b768fdebf160e003e57a4d2b9cf3505 M drivers Everything works really good as before, no wifi networking problem etc.
Created attachment 175841 [details] dmesg for 4.1rc2 + reverted stuff kernel log after reverting commits: 382d020f4459cd77237c5463098935fd64afdab3 "Staging: rtl8712: Eliminate use of _cancel_timer" and 6501c8e7d86cca5fab74f873810cbc573273d1b4 "Staging: rtl8712: Eliminate use of _cancel_timer_ex"
Created attachment 175851 [details] kernel log for the good one kernel v4.0 nice and clean kernel log, without strange calling CRDA again and again.
Hi, Can you please check if you have the same problem with 4.1-rc3 also. If you have please attach your config file also.
Created attachment 176851 [details] patch to test Please test the attached patch. It will apply to 4.1-rc2 and 4.1-rc3 both. Not a formal patch for submission, just for testing.
Thx for reply. In rc3 and next-20150512 problem is still here. I'm building the kernel with patch from above, so i try and call you back asap.
Created attachment 176891 [details] config for rc3 i'm pretty sure it's the same config as for rc2 & rc1.
Created attachment 176921 [details] dmesg for rc3+patch This patch didn't work for me, but now i have no spam at logs. [cut here] staff appears only one time for over 1h.
Created attachment 176931 [details] dmesg for rc3 without patch "clean" Uptime about 25 min.
Created attachment 176961 [details] patch to test Hi, Thanks for your time, can you please test this one as well. This should solve all the problems. As before this will apply to 4.1-rc2 , 4.1-rc3 and also linux-next.
Yes, problems are gone. Tested for rc3 only. Thanks again.
Great. Please modify the status of this bug to VERIFIED. I will submit the patch with Reported-by and Tested-by both your name. After that one is accepted then you can mark this as CLOSED. Thanks for your time.
I can't do this, the olny choice for status is RESOLVED (or NEW) but no CLOSED, VERIFIED ...strange.
The FAQ page is saying about many different statuses including VERIFIED and CLOSED. maybe we need to raise a bug about bugzilla :) Then leave it for now. I will post the patch today, later we will see how to close it.
I need set status to [RESOLVED] and wait for QA guy to verify it. But i really don't know who is that guy (probably someone from Quatar? ;). see this: https://bugzilla.kernel.org/page.cgi?id=fields.html#bug_status
patch has been posted. https://lkml.org/lkml/2015/5/15/226 If it is applied then the correct status should be FIXED.
And you are right... it should be and it is :) Now i can set VERIFIED or CLOSED (maybe I am QA in this case). When patch will land into mainline (probably rc4) i will close this. Thanks again for help & patience :)
Nope, rc4 not possible. rc4 will be released tomorrow. may be in rc6. First it will be applied to staging-testing then staging-next, from there it will go to linux-next.
Hi, You can close the bug now. The fix is in 4.1-rc7 now.
Thanks again best regards