[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 1779017] Re: qemu-system-arm: crashes raspian kern

From: Thorsten Otto
Subject: Re: [Qemu-devel] [Bug 1779017] Re: qemu-system-arm: crashes raspian kernels with divide-by-zero
Date: Thu, 28 Jun 2018 10:17:55 -0000

On Donnerstag, 28. Juni 2018 11:32:08 CEST Peter Maydell wrote:

Thanks for your quick answer.

> I'm not sure your bisection has landed on the right thing, as
> d9f8bbd8eb4e95 should be a no-behaviour-change commit.

Yes, i saw that already. But strangely, the commit before worked (tested 
manually after the bisect), and with that commit i get the division by zero.

The problem is that the kernel stops booting at this point (maybe not because 
of the exception, but that is the last message printed)

>Unfortunately the cprman hardware is as far as I can
>determine undocumented

Would there be some way to fake it at least, so that linux does not get a zero 

You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

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

Status in QEMU:

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>] 
  [   10.024726] [<8011d42c>] (warn_slowpath_null) from [<804da378>] 


  [   10.094933] Hardware name: BCM2835
  [   10.101507] [<8010fb3c>] (unwind_backtrace) from [<8010c058>] 
  [   10.105413] [<8010c058>] (show_stack) from [<80455f84>] 
  [   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>] 
  [   10.148017] [<804e5538>] (pl011_set_termios) from [<804da954>] 
  [   10.185887] [<804da954>] (uart_change_speed) from [<804ddedc>] 
  [   10.222187] [<804ddedc>] (uart_startup.part.3) from [<804ddfcc>] 
  [   10.226014] [<804ddfcc>] (uart_port_activate) from [<804c93b8>] 
  [   10.228398] [<804c93b8>] (tty_port_open) from [<804dce64>] 
  [   10.264254] [<804dce64>] (uart_open) from [<804c1d70>] 
  [   10.266697] [<804c1d70>] (tty_open) from [<802753f0>] 
  [   10.269049] [<802753f0>] (chrdev_open) from [<8026d964>] 
  [   10.271620] [<8026d964>] (do_dentry_open) from [<8026ec00>] 
  [   10.275245] [<8026ec00>] (vfs_open) from [<8027f39c>] 
  [   10.312827] [<8027f39c>] (path_openat) from [<80281040>] 
  [   10.317860] [<80281040>] (do_filp_open) from [<8026efd8>] 
  [   10.320370] [<8026efd8>] (do_sys_open) from [<8026f0b4>] 
  [   10.357033] [<8026f0b4>] (SyS_open) from [<801080c0>] 

  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:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]