berryboot
berryboot copied to clipboard
maxnet
Reboot don't work on RPI2
Hello. I've been test berryboot for the first.
Maybe i have do more than excpected, but when i try to do sudo reboot, my rpi crash on boot.
And when i click on exit in edit menu, it's do the same.
Last message on crash boot is:
SMP: failed to stop secondary CPUs
---[end Kernel panix - not syncing: Attempted to kill the idle task.
I must do an electric shot to reboot. Did you know, what i've been breaking ?
Maybe I know it's because I do a mistake on rpi2 on the place of 3. I think I use Berryboot for 4 core. But maybe rpi2 don't have quad core.
Rpi 2 and 3 has 4 cores there is no version for 1 core,were exactly you do a reboot you press the exit in the berryboot menu?
Ok thanks. So i change for nothing lol. If i'm on one of my OS and if i do sudo reboot, sometime it's work, sometimes not... Like if i push this button:
I'm on vnc. I just have on disk with 2 usb for power. And 1 rflink on usb too.
Your photo shows this kernel bug: https://github.com/raspberrypi/linux/issues/2450 Do not have a solution for that.
Interesting if same bug: so far was only discussed in context of Pi3b+, not RPI2. Would be a severe regression then: maybe such info should be passed-on on that ticket.
@landaisbenj can you check dmesg messages when it boots, and check if there are any under-voltage warning (dmesg | grep oltage)?
You seem to have many peripherals on USB, and maybe your PSU does not supply enough power for a stable setup...
seeing some of the recent changes (4.14.34 & 4.14.37, including hdmi/video related firmware tweaks), any chance an up-to-date build fixes this?
Don't think it has to do with HDMI, but rather the problem described here: https://www.spinics.net/lists/arm-kernel/msg325250.html Can occur if the FIQ interrupted a kernel thread that does not have up-to-date L1 page table pointers yet. Table is updated upon accessing an address that is not in it, causing a page fault. This mechanism to update table lazily in fault handler works fine for normal kernel code, but not when using FIQs as they are not allowed to cause faults.
Not sure why this never seemed a problem before 4.14 though.
Hello. dmesg | grep voltage don't do anything. uname -a:
Linux raspberrypi2 4.14.32v7-aufs #1 SMP Thu Apr 5 21:48:06 CEST 2018 armv7l GNU/Linux
I have a rflink on usb. And it's an old hard drive 2.5 with an Y cable with 2 usb. I can try to unplug rflink and test if it's pertinent?
@maxnet just thought about hdmi as folks in raspberry/linux thread seemed to correlate issue occurrence to hdmi screen use (and initramfs).
@landaisbenj I omitted the "v" on purpose in my command, as some messages use capital "V" :)
Test with both then, or carefully read dmesg output.
By chance, would you have a well-powered USB hub to connect your stuff and safeguard PI's PSU?
For info i use vnc on boot. I'm do both with and without v and i read all dmesg. Juste 3 red line:
[ 10.164353] sd 0:0:0:0: [sda] No Caching mode page found
[ 10.164582] sd 0:0:0:0: [sda] Assuming drive cache: write through
and
[ 34.685132] CIFS VFS: cifs_mount failed w/return code = -112
For one lan drive who wouldn't mounted, i don't know why.
I don't have usb hub. But i may test without my rflink. Can you explain what is "PSU" because i'm french noob's and it's really difficult lol
PSU is Power Supply Unit ;)
Did not find any under-voltage warning in supplied dmesg, so I guess we can eliminate that cause indeed.
Some warnings about dwc_otg driver & FIQ though.
There have been lots of changes between 4.14.32 current berryboot ships with, and latest 4.14.37: I have not looked at all the diffs in details on kernel.org, but would be nice to give it a go & check if problem still occurs with latest. In any cases, it also addresses many other issues.
Thanks :) I try yesterday to disconnect my rflink et my hdmi, and after 4 or 5 reboot i think i can't replicate issue. However, 1 time berryboot tell me my disk need verification, but i don't remember utility. I try tonight to test.
For this:
but would be nice to give it a go & check if problem still occurs with latest. In any cases, it also addresses many other issues.
Do you mean i can try upgrad kernel ? but, if i had to, it would be "sudo rpi-upgrade" ?
Do you mean i can try upgrad kernel ?
No, this would need a new berryboot build.
@maxnet following through the maillist thread you mentioned, and factoring-in some folks mentioned this issue mostly shows-up in custom initramfs setup, couldn't that point to potential initialization issue in initramfs generation process, like cpio bug or some recent lib version dependency mismatch, creating now some awkward memory management/alignment issue of some sort?
Hi, i had exactly same issue and same message on my RPi2 yesterday.Unable to reboot i had to pull off at almost every reboot since last automatic berryboot update, i made just before.I have no rflink connected on my machine.
@maxnet following through the maillist thread you mentioned, and factoring-in some folks mentioned this issue mostly shows-up in custom initramfs setup, couldn't that point to potential initialization issue in initramfs generation process, like cpio bug or some recent lib version dependency mismatch, creating now some awkward memory management/alignment issue of some sort?
Don't know.
Could also just be that without initramfs the memory before or after the ioremapped address the FIQ wants to access is actively read from by other kernel code, causing the L1 page table pointer to be updated before the FIQ accesses it.
If there is initramfs data before and after the address, that isn't read from early in the boot process, this does not occur. So the FIQ is first to access that 1 MB region, and causes the page fault.
As they share some design principles, I guess we should see similar issues in NOOBS & PINN, right?
As they share some design principles, I guess we should see similar issues in NOOBS & PINN, right?
May or may not be the case.
NOOBS uses a legacy initrd file system image. One big 32 MB memory chunk is allocated on boot, and that has a compressed squashfs file system, that stays compressed to save memory. (did it that way because it used to run out of memory when you used the bundled webbrowser under the "help" button, and visited raspberrypi.org)
Berryboot uses initramfs. It is uncompressed on boot, and I think (but have not checked) that individual files may be individual small memory allocations, rather than one big chunk. Chances are higher those memory allocations end up near other dynamically allocated kernel memory.
Can confirm this problem is still happening today after reboot. Able to download and attempt to install image and then failure after all subsequent reboots.
I have had the same issue on my Raspberry Pi 2 B. I think the SD card was corrupted because of low voltage from my power supply. I have seen a flash icon when connected a monitor and a message with something about "undervoltage". So I flashed SD card with a OS once again, connected the Official Raspberry Pi power supply which provides 5.1V and everything started to work normally.
