-
Notifications
You must be signed in to change notification settings - Fork 5.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
raspberrypi 3b wifi 802.1x benchmark, kernel Internal error: Oops: 17 [#1] SMP ARM for BCM2835 #2794
Comments
We like reproducible errors, and we like ones that can be reproduced in minutes (not hours) even more. Here's what I suggest you do:
|
@pelwell I used nodejs to send command to wpa_supplicant ctrl_interface to send wifi test command. The test logic:
The test logic is repeated every two minutes. Sometimes after hundreds of tests , the kernel gave many error messages, such as And in some cases , kernel will failed. The test script and wpa_supplicant config file attached here. Many thanks. |
Does it fail quicker with a shorter interval? |
I will try to do the test with a shorter interval, and tell the result. But in syslog , there was an noteable line, "Unable to handle kernel NULL pointer deference at virtual address 000000". Maybe some bug in wifi driver or other modules cause the problem? |
Yes, there is almost certainly a bug in the driver - it shouldn't crash. There are never no outstanding issues, so you are competing with other users for our support. The time-to-failure is important because the shorter it is, the more chance an engineer will take the time to look at it. |
@pelwell ok, thank u for reply. The kernel message file , some kernel log message like this |
@pelwell The wifi kernel crash could be easily using my test script in one minute interval. I reproduced the crash in two respberry pi 3B board. One kernel version is 4.14.79-v7+ #1159, and the other one is 4.14.90-v7+ #1183. The crash backstrace is almost same. 4.14.79-v7+ #1159 crash log: Is there any way to avoid this problem in wifi 802.1x mode? Thanks |
I've been running a modified version of your script for about an hour now, reconnecting every 20 seconds. In that time the kernel log has accumulated 4 "scan error (-16)"s, and no crashes. However, the script modification was to switch to WPA-PSK authentation rather than WPA-EAP, which I am unable to test. Are you able to try with WPA-PSK to see if it is more or less reliable? |
@pelwell In my wifi 802.1x test, sometimes the raspberry pi system was stable for serveral days, sometimes kernel crash in hours. General speaking, the chance of kernel crash was high in my enviroment. Now I am doing some PSK authentation test. I will report the result later. Thanks. |
@pelwell I found when the wifi kernel crash problem happened, the raspberry pi system worked in abnormal way. The system didn't response to reboot command. The ssh service didn't work. The cpu usage became very high , sometimes load avg reached 100 or higher. I think it is a critical problem. |
@pelwell Since we have no idea the reason of the kernel crash , could some action to be taken to detect the kernel crash. When kernel crash is detected, the system will be rebooted automatically to avoid the bad situaction. Any way to achieve that goal? Thanks. The newest kernel crash log with official kernel version 4.14.79-v7+ #1159.
|
You could try with a script like this - I called it
Run with Any appearance of the string wpa_supplicant in the kernel log will trigger a reboot. You can test it with:
I did try to use a simple shell script, but the line buffering wasn't co-operating, hence the Perl - sorry (not sorry). |
@pelwell Thank you for your perl watchdog script. It works. I will add the watch dog daemon to restart the system when wpa_supplicant and kernel bug occured. But anyway, any idea about the kernel bug? I think the best way is to fix the kernel bug directly. |
We can't fix the kernel bug until we can reproduce it, and so far that hasn't been possible. Your kernel is not a standard kernel, your environment is different, and your use case (repeatedly connecting and disconnecting) is very niche. |
@cxueqin Have you tried this with the latest kernel? Does that make any difference? This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested. |
@JamesH65 I haven't test in the lastest kernel. Can you tell me which kernel version I should use for testing? Thanks |
Just the latest release one, from apt. sudo apt update |
I am also having this issue. |
I have been able to reproduce this today. As with the OP, this effectively causes the RPi to stop responding to reboots (well, it shuts down but then hangs and a hard reset is required).
This is on I am attempting to use the RPi as a Passpoint/Hotspot 2.0 access point, which requires some configuration. It appears to have this moment whilst going through the ANQP phase of the association. Configuration file can be provided (it contains RADIUS secrets to a third-party server that are sensitive). |
As an addendum: When the line |
Hi friend:
I use raspberrypi 3B board as a wifi station mode to connect to an AP. The wifi connection was made by wpa_supplicant with 802.1X authtication params. The 802.1x params list below:
The wifi connection was fine at first. I used wpa_cli to reassociate the AP with the same params every two minutes. In other words, the rp 3b board test 802.1x access authentication every two minutes. After hundreds of successful reassociations, the kernel went wrong. The syslog shown
The syslog told kernel Internal error: Oops: 17 [#1] SMP ARM for BCM2835. After that the wpa_supplicant didn't work, the system cpu usage increased gradually which would reach 100 or higher(measured by uptime). And then the linux system didn't work . SSH service couldn't be reach, but icmp ping was still alive.
I tried the above test several times on the same and different raspberry pi 3B boards. The kernel error problem could be reproduced. The kernel firmware was upgraded to lastest 4.14.90-v7+.
Any suggestion is welcome. Thank you !
The text was updated successfully, but these errors were encountered: