[rpi 2] Kernel panic with new kernel 4.9.11-1

[jskier]

I have had 2 Pi's go out because of this update (both with cameras, different brand SD cards). Connecting over serial, and like others, get kdb but can't do anything with it.

Removing the camera solved nothing. Replaced the config.txt with pacnew, still won't boot - same error. Will try backup and replace from image as suggested. EDIT, boot partition restored from img works fine.

This is a very serious bug, where should this be reported?
EDIT Bug report here:
https://archlinuxarm.org/forum/viewtopic.php?f=15&t=11354

Output:
$this->bbcode_second_pass_code('', '[ 9.685772] Linux video capture interface: v2.00
[ 9.742438] systemd-journald[213]: Received request to flush runtime journal from PID 1
PANIC: stack-protector: Kernel stack is corrupted in: 7f13b2a0


Entering kdb (current=0x9b51c880, pid 223) on processor 2 due to Keyboard Entry
[2]kdb>
')

[dipogon]

I tested also by copying partitions to Samsung EVO+ SD card. Same panic, so perhaps not a SD issue after all.

[pschmitt]

Same deal here with all generations of the Raspberry Pi Model B (1, 2 and 3).
Has anyone managed to roll back?

EDIT: Okay here's how

You'll need a separate PC and set up QEMU chrooting:https://wiki.archlinux.org/index.php/Raspberry_Pi#QEMU_chroot
Then it goes somewhat like this (do not copy/paste...):

$this->bbcode_second_pass_code('', '
mkdir -p mnt/boot
mount /dev/mmcblk0p2 mnt
mount /dev/mmcblk0p1 mnt/boot
cp /usr/bin/qemu-arm-static mnt/usr/bin
arch-chroot mnt /usr/bin/qemu-arm-static /bin/bash
# INSIDE THE CHROOT
pacman -U /var/cache/pacman/pkg/linux-raspberrypi-4.4.49-1-arm*.pkg.tar.xz
exit
# Done! unmount and pop it back inside
sync; umount -R mnt
')

[jskier]

$this->bbcode_second_pass_quote('', 'H')as anyone managed to roll back?

[pschmitt]

Yeah that's ugly.
QEMU-chrooting may be more elegant (cf. my previous post) and it works.

[alonzo99]

I also got the kernel panic on a Pi A and a Pi B. And, I also got the following warning when the mkinitcpio was building:
$this->bbcode_second_pass_code('', '
(1/4) Updating linux-raspberrypi initcpios
==> Building image from preset: /etc/mkinitcpio.d/linux-raspberrypi.preset: 'default'
-> -k 4.9.11-1-ARCH -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 4.9.11-1-ARCH
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
-> Running build hook: [fsck]
==> WARNING: No modules were added to the image. This is probably not what you want.
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
==> Image generation successful')

I recovered both Pi's by downgrading linux-raspberry pi.

[android]

The warning during mkinitcpio is almost certainly not part of the kernel oops issue.

The archlinuxarm stock boot for ARMv7h does not use an initramfs image, and the stock kernel contains most drivers built-in, not as modules.

So when the standard kernel install causes mkinitcpio to run, there are no modules to be included in the initramfs, and it gives this warning.

I do build a custom initramfs for RPi3, to install aufs root filesystem. Even the drivers (and patches) for aufs are built into the stock ALARM ARMv7h kernel, and so I get the same "WARNING: No modules were added to the image. This is probably not what you want." message when building my custom initramfs. And yet the initramfs still functions and installs the aufs rootfs on boot.

Short story: You probably don't even have an initramfs, therefore no modules are added to it. That's the cause for this warning, so I don't think it's related to the kernel oops.

[alonzo99]

>> The warning during mkinitcpio is almost certainly not part of the kernel oops issue.

I did wonder about that. I'm thinking that 4.9.x is the first time I've even seen mkinitcpio being run.
In fact, I just deleted /boot/initramfs-linux.img and rebooted with no problems.
Thanks for the info.
-- alonzo

[dipogon]

It seems that by not loading of kernel module bcm2835_v4l2 prevents the kernel panic.

[WarheadsSE]

See viewtopic.php?f=15&t=11354 (duplication of efforts here)

And https://github.com/raspberrypi/linux/issues/1447