-
Notifications
You must be signed in to change notification settings - Fork 5.2k
RPI0w Kernel Panic Related to ipv6_rcv #4466
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
Comments
That's not a great distribution - more reproducible would be better.
|
I've been searching for a better repro case but haven't found one yet. I've seen the problem on 3 different pi zero w units so I am pretty sure it isn't hardware.
I'm using the wlan0 interface on the pi using a Linksys WRT54GS 2.4 gHz wifi router/access point. The access point isn't capable of ipv6. I've tried this with another access point for which I can't get the model number right now and had the same problem.
I was not intentionally using IPv6 however in thoroughly answering your question, I noticed that pigpiod creates IPV6 sockets by default and communicates with my code. I've reset pigpiod to use ipv4 sockets in my test setup and will see if the oops and panic continue.
I'm running my own application that logs a2d converter values connected to i2c and occasionally toggles gpio pins with pigpiod. |
I agree that it doesn't have the feel of a hardware fault. I'm curious to see if the pigpiod change has made a difference - if nothing else it might give a route to recreating the issue. Your application doesn't sound particularly intensive, which is also encouraging in terms of reproducibility. |
I changed pigpiod not to use ipv6 and ran the RPI0w for a while and getting a different panic related to swapper. Whatever's going on looks to me like it's not going to be easily debuggable. I also tried updating the kernel to 5.10.52 with rpi-update. The system has run for about a day without panicking where it usually crashed before that.
|
I have similar problem(same address bf8447b8) on RPI0w during over the air system update using mender .
|
I am seeing the same problem: I have a Zero W and all it is running is raspivid and cvlc, and I randomly get a hard hang, and once I connected a serial cable discovered the same ipv6_rcv stack trace as above, in a random process, anywhere between 5 and 30 minutes after power on. I have a NOIR camera and a HC-SR501 PIR sensor and with it connected to a 2.4A USB power supply anda USB current monitor it never draws more than about 0.7A so I don't think it is power related.
Ironically it panicked when I ran raspinfo to get the above information! |
I am going to disable ipv6 (for example https://www.howtoraspberry.com/2020/04/disable-ipv6-on-raspberry-pi/ ) because I don't need it, and see if the problem goes away |
@pastcompute it would be great to know if it worked |
@bao-eng well, this time it stayed up overnight. But instead I was seeing non-panic crashes in dmesg instead, so the problem has "moved". On one occasion the ssh connection hung but I still had the serial console and could reboot from there. Now I have gone a rabbit hole, I tried increasing the amount of RAM by reducing the GPU size, and then by upgrading the kernel which it turned out broke raspivid and I have to use libcamera instead, and now I'm seeing this flooding domes instead: |
On the occasion I lost ssh but still had a serial console, there was this in dmesg:
|
Is this the right place for my bug report?
We're seeing a kernel panic.
Describe the bug
The kernel panics on RPI0w.
To reproduce
Run the RPI0w for between 5 minutes and a few days.
Expected behaviour
The RPI0w should run without crashing.
Actual behaviour
The system crashes and halts at the panic.
System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:
cat /etc/rpi-issue
)?vcgencmd version
)?uname -a
)?Additional context
Add any other relevant context for the problem.
The text was updated successfully, but these errors were encountered: