[Qemu-devel] [Bug 1779017] Re: qemu-system-arm: crashes raspian kernels with divide-by-zero

[Rob Thomas]

This does not appear to be DIRECTLY a bug in QEMU, but 'something' has
changed in the RPi Kernel to cause this issue.

The actual cause of the panic is (in my situation) because the kernel is
unable to mount root, and this is caused by it being unable to access
the SD interface, as it can't get timing.

This is a random working kernel (using QEMU 3.0) -
https://pastebin.com/wvkneNNF

This is the latest 4.14 kernel (using the identical QEMU) -
https://pastebin.com/QTwgCkV2

The actual error is on line 160:

[    1.706622] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring
probe

This never actually activates the mmc controller, and the root volume is
not available.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1779017

Title:
  qemu-system-arm: crashes raspian kernels with divide-by-zero

Status in QEMU:
  New

Bug description:
  While trying to boot a arm kernel for a raspi2 machine 
(kernel7-4.9.41-stretch.img in my case, but applies to other versions, too) the 
kernel crash with a division by zero. The output on the sreial console is:
  [   10.022377] [<8011d344>] (__warn) from [<8011d42c>] 
(warn_slowpath_null+0x30/0x38)
  [   10.024726] [<8011d42c>] (warn_slowpath_null) from [<804da378>] 
(uart_get_baud_rate+0xf8/0x160)

  ...

  [   10.094933] Hardware name: BCM2835
  [   10.101507] [<8010fb3c>] (unwind_backtrace) from [<8010c058>] 
(show_stack+0x20/0x24)
  [   10.105413] [<8010c058>] (show_stack) from [<80455f84>] 
(dump_stack+0xd4/0x118)
  [   10.140268] [<80455f84>] (dump_stack) from [<8010bed4>] (__div0+0x24/0x28)
  [   10.143065] [<8010bed4>] (__div0) from [<8045498c>] (Ldiv0+0x8/0x14)
  [   10.145553] [<8045498c>] (Ldiv0) from [<804e5538>] 
(pl011_set_termios+0x9c/0x37c)
  [   10.148017] [<804e5538>] (pl011_set_termios) from [<804da954>] 
(uart_change_speed+0x40/0xfc)
  [   10.185887] [<804da954>] (uart_change_speed) from [<804ddedc>] 
(uart_startup.part.3+0xa4/0x13c)
  [   10.222187] [<804ddedc>] (uart_startup.part.3) from [<804ddfcc>] 
(uart_port_activate+0x58/0x64)
  [   10.226014] [<804ddfcc>] (uart_port_activate) from [<804c93b8>] 
(tty_port_open+0xa0/0xe0)
  [   10.228398] [<804c93b8>] (tty_port_open) from [<804dce64>] 
(uart_open+0x40/0x48)
  [   10.264254] [<804dce64>] (uart_open) from [<804c1d70>] 
(tty_open+0xc0/0x678)
  [   10.266697] [<804c1d70>] (tty_open) from [<802753f0>] 
(chrdev_open+0xe0/0x1a0)
  [   10.269049] [<802753f0>] (chrdev_open) from [<8026d964>] 
(do_dentry_open+0x1f4/0x314)
  [   10.271620] [<8026d964>] (do_dentry_open) from [<8026ec00>] 
(vfs_open+0x60/0x8c)
  [   10.275245] [<8026ec00>] (vfs_open) from [<8027f39c>] 
(path_openat+0x2bc/0x1040)
  [   10.312827] [<8027f39c>] (path_openat) from [<80281040>] 
(do_filp_open+0x70/0xd4)
  [   10.317860] [<80281040>] (do_filp_open) from [<8026efd8>] 
(do_sys_open+0x120/0x1d0)
  [   10.320370] [<8026efd8>] (do_sys_open) from [<8026f0b4>] 
(SyS_open+0x2c/0x30)
  [   10.357033] [<8026f0b4>] (SyS_open) from [<801080c0>] 
(ret_fast_syscall+0x0/0x1c)

  Tracking that down in the linux kernel source, it looks like somehow
  uart_get_baud_rate() returns 0.

  The same kernel could be booted without problem with qemu version 2.11.
  Trying to bisecting the issue revealed commit 
@d9f8bbd8eb4e95db97cf02bd03af86a3d606f4f1 as the culprit.

  Commandline to run was:
  qemu-system-arm -M raspi2 \
        -kernel "$KERNEL" \
        -m 1024 \
        -d guest_errors,unimp \
        -dtb bcm2709-rpi-2-b.dtb \
        -drive file="$IMG,if=sd,format=raw"

  Distribution is SuSE tumbleweed (x86_64, kernel 4.17.2), but same
  problem also happens with a freshly compiled qemu from git repository.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1779017/+subscriptions