-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Kernel panic on Pi 1 B(+) when using an initramfs with DeviceTree enabled #914
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
Can you test if it does it with the latest "rpi-update" firmware/kernel? |
I've managed to also produce this kernel panic starting from the
Log:
|
Will do that now.
This is the 2nd time I got this result (no kernel panic). I'll re-generate the initramfs a couple of more time to see whether I can get a kernel panic again. |
I have now regenerated the initramfs 5 times and I haven't got a kernel panic (yet?). |
I'm quite sure the issue is fixed with the 3.18.10+ kernel. |
I cheered too soon, I have just gotten a kernel crash with with the latest kernel from I have done the installation with the raspbian-ua-netinst with some custom configuration (release=jessie) and a script which is run near the end of the installation which installs and runs I can provide the configuration files for the installer if you like with which I have gotten the kernel panic. |
And it happened on a Pi 1 B too, this time with release=wheezy |
Shiftplusone/@XECDesign asked for an image which would have the crashing kernel and I have just uploaded one: http://cknow.org/rpi/raspbian-wheezy-rpi1b-kernel-panic.img.tar.gz I have shrunk the image so it should fit on any 8GB card. You can log into the image with user [pi1]
#kernel=vmlinuz-3.18.0-trunk-rpi
#initramfs initrd.img-3.18.0-trunk-rpi followkernel
kernel=vmlinuz-3.18.10+
initramfs initrd.img-3.18.10+ followkernel
#initramfs initrd.img-3.18.10+-crash followkernel The 3.18.10+ kernel is installed from If you have any further questions, just let me know and I'll answer them as best as I can. |
It took a while and many tries, but there is now also an image from a kernel panic on a RPi 1B+ with Raspbian Jessie as OS version: http://cknow.org/rpi/raspbian-jessie-rpi1b+-kernel-panic.img.tar.gz Apart from now also having a documented kernel crash on a RPi 1B+ (next to a 1B) another (potential) relevant difference is a newer version (from Jessie) of |
Sadly that image is too large for the 8GB cards I have at my disposal: NOOBS - 15415296 (eb3800) sectors = 7,892,631,552 bytes So the image is at least 61MB too large. I'll bring in a larger card tomorrow and see if that works. |
I've made them smaller, so they now they should (really) fit on a 8GB card: |
I've downloaded both images, and both produce crashes on a B and a B+. Interestingly, they crash in different locations on the two models, but between runs and the two images, all crashes are remarkably consistent. On the B+, the abridged callstack looks like this:
while on a B you get:
Getting different failures like this suggests that both code paths stumble across memory corruption of some kind, but that's just a hunch. By correlating multiple runs it appears that the B+ code is failing after accessing [r0], while the B code is reading [r4 + 0xc]. The next step would be to extract the kernel and see if the source of the two addresses can be determined by disassembly. |
[ The comments above refer to the larger images, after extracting them onto a 32GB card. ] |
That's what I noticed too. In this comment there are a number of logs from boot till the kernel crash and they all look very much alike.
The new images are exactly the same as the old ones. The only thing I did was further shrink the root partition with gparted. |
Interesting development. While preparing a new release for 'my' installer, I did some testing and now I can reproduce the crash ALWAYS on a Pi 1B, but not on a Pi 1B+. So now I have uploaded installer files which contain all 3 kernels with various (commented out) lines for those kernels in http://cknow.org/rpi/raspbian-ua-netinst-20150414-git6afb9a1.img They are all the same, just different compression formats. |
Here are the dumps of the crashes from all 3 kernels: |
Based on shiftplusone's comment on IRC, I also tested it with the kernel from |
Maybe it isn't the initramfs after all. |
After some more testing, I just got a case in which it did crash :-/ |
I'm now rather convinced the problem is related to DeviceTree. When using the installer image from #914 (comment) but adding |
guys, I have a very similar issue. I'm using multi image(kernel+ramdisk+dtb) to bootup my system, which is armv7 based on 3.14.43 kernel, and it shows up the crash log as below(the crash happened randomly)
|
@diederikdehaas has your issue been resolved? If yes, then please close this issue. |
No. |
I'm the maintainer of raspbian-ua-netinst and we've had several reports about kernel panics on the Pi 1 B/B+ (see debian-pi/raspbian-ua-netinst#199 and debian-pi/raspbian-ua-netinst#201).
By default it's using the raspbian.org kernel and an initramfs and I have multiple times 'fixed' the issue by disabling the initramfs (which is generated/used by default with the raspbian.org kernel).
But that kernel is not (exactly) the same as the kernel build from this repo.
Plugwash told me on IRC that he was able to get a kernel panic by using an initramfs with a rpf kernel (this repo), so I tried whether I could accomplish the same ... and I have.
Procedure:
root
and passwordraspbian
(the default)raspberrypi-bootloader
package to get the rpf kernel (it will uninstall some other packages)/etc/kernel/postinst.d/initramfs-tools $(uname -r)
/boot/config.txt
so it contains the lineinitramfs initrd.img-3.18.7+ followkernel
(I have it under a [pi1] header)If it doesn't give a kernel panic, re-generating the initramfs with the earlier mentioned command often/sometimes gives a kernel panic on reboot. The 'problem' is that it doesn't consistently fail.
Log from start to kernel panic (which is also stored here, more dumps in debian-pi/raspbian-ua-netinst#199):
The text was updated successfully, but these errors were encountered: