Open ghost opened 8 years ago
You need to switch to the logging console before you initiate the action that causes the lockup, and then take and post a photo of the screen. You could also setup network logging, but that is much more complicated and requires a second network device.
ok, I managed to get a lockup from the console:
On 2/2/16, lwfinger notifications@github.com wrote:
You need to switch to the logging console before you initiate the action that causes the lockup, and then take and post a photo of the screen. You could also setup network logging, but that is much more complicated and requires a second network device.
Reply to this email directly or view it on GitHub: https://github.com/lwfinger/rtl8723bu/issues/21#issuecomment-178647567
seems like the attachments didn't get here via the mail... uploading them via the web interface
Thanks for the picture. I think I found the place where it fails and changed the code to log a message. Please pull these changes and tell me (a) if it still crashes, and (b) if you see a message with "****" logged if it doesn't.
still looks the same after the upgrade... where should the "*****" be logged?
I "fixed" the wrong place. Do a new pull and try again. The printout of the stars has been removed as it was not useful.
it's stil crashing, but in a different place it seems...
[ 273.406289] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
[ 273.407792] IP: [
I guess we are gaining; however, the make file was stripping the object files and I could not use gdb to find the bad code location. In addition, I could not figure it out without that info.
Please pull and try again. Do a "make clean" before the make. It will crash again, but I should be able to interpret the traceback.
as far as I can see you did not push anything...
is this any help? I added a "-g" and removed the "--strip-debug" but I'm not sure if that was what you wanted...
[ 112.919964] RTL871X: module init start
[ 112.919967] RTL871X: rtl8723bu v4.3.6.11_12942.20141204_BTCOEX20140507-4E40
[ 112.919968] RTL871X: rtl8723bu BT-Coex version = BTCOEX20140507-4E40
[ 112.973705] RTL871X: rtw_ndev_init(wlan0)
[ 112.973975] usbcore: registered new interface driver rtl8723bu
[ 112.973977] RTL871X: module init ret=0
[ 130.314419] RTL871X: RTW_ADAPTIVITY_EN_AUTO, chplan:0x21, Regulation:0,0
[ 130.314421] RTL871X: RTW_ADAPTIVITY_MODE_NORMAL
[ 130.834745] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 132.843118] RTL871X: nolinked power save enter
[ 144.975880] RTL871X: RTW_ADAPTIVITY_EN_AUTO, chplan:0x21, Regulation:0,0
[ 144.975882] RTL871X: RTW_ADAPTIVITY_MODE_NORMAL
[ 145.586925] RTL871X: nolinked power save leave
[ 145.789942] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 145.791186] IP: [
2120 #ifdef CONFIG_P2P 2121 if( pwdinfo->driver_interface == DRIVER_CFG80211 ) 0x000000000004930f <+161>: cmpb $0x2,0x4594(%rbx) 0x0000000000049316 <+168>: jne 0x493f5 <cfg80211_rtw_scan+391>
2122 { 2123 if (_rtw_memcmp(ssids->ssid, "DIRECT-", 7) && 0x000000000004931c <+174>: mov $0x7,%edx 0x0000000000049321 <+179>: mov $0x0,%rsi 0x0000000000049328 <+186>: mov -0x388(%rbp),%rdi 0x000000000004932f <+193>: callq 0x49334 <cfg80211_rtw_scan+198> 0x000000000004933e <+208>: test %eax,%eax 0x0000000000049340 <+210>: je 0x493f5 <cfg80211_rtw_scan+391> 0x000000000004935f <+241>: test %rax,%rax 0x0000000000049362 <+244>: je 0x493eb <cfg80211_rtw_scan+381>
It seems that "ssids" in line 2123 of os_dep/ioctl_cfg80211.c is NULL. The new version protects against that.
yep, that fixed the OOPS. but the machine still locks up when using "wicd" from X. I'll need to try some more things to get info on that lock up
this is all I can get, no scrollback unfortunately since it's all locked up.
Not seeing the location that actually crashed is a problem. The location in rtw_free_network_nolock() calls rtw_cfg80211_unlink_bss(), which is as far back as I can trace. I added some checking to the latter routine. Perhaps for once I got lucky.
I just sent another trial.
that's more of the previous oops
sorry, but I don't see the code you submitted 20 min ago
I added some more printfs and ifs of my own, and it looks like the "pnetwork" is null when rtl_cfg80211_unlink_bss is called
I just protected the unlink bss routine from arg 2 being NULL.
When I set up an ad-hoc access point using wicd on slackware64-current (x64, kernel linux-4.4.0) the machine locks up completely. what info can I provide to debug this issue?