arm64: wily: hanging during reboot

[Ming Lei]

Inside VM wily kernel which is installed via wily d-i installer, reboot hangs, see the following message:

[ 40.294727] reboot: Restarting system

And never return to UEFI UI.

The issue can be observed too in d-i installing too.

[Steve Langasek (vorlon)]

Which version of edk2 did you see this issue with?

[dann frazier (dannf)]

I can reproduce - here are the steps:

I installed an HP m400 (mcdivitt) with wily, and installed qemu-efi (0~20150106.5c2d456b-2) and qemu-kvm (2.3+dfsg-5ubuntu9.1).

$ wget http://cloud-images.ubuntu.com/wily/current/wily-server-cloudimg-arm64-uefi1.img
$ dd if=/dev/zero of=flash0.img bs=1M count=64
$ dd if=/usr/share/qemu-efi/QEMU_EFI.fd of=flash0.img conv=notrunc
$ dd if=/dev/zero of=flash1.img bs=1M count=64

Then created my-seed.iso following instructions at http://ubuntu-smoser.blogspot.com/2013/02/using-ubuntu-cloud-images-without-cloud.html

I then booted with:
$ sudo qemu-system-aarch64 -enable-kvm -m 1024 -cpu host -smp 4 -M virt -nographic -pflash flash0.img -pflash flash1.img -drive if=none,file=wily-server-cloudimg-arm64-uefi1.img,id=hd0 -device virtio-blk-device,drive=hd0 -drive if=none,file=my-seed.img,id=hd1 -device virtio-blk-device,drive=hd1 -netdev type=tap,id=net0 -device virtio-net-device,netdev=net0,mac=ac:67:de:d2:4b:06

After logging in, my console would hang with "irq 37: nobody cared (try booting with the "irqpoll" option)". So I did so, and was able to login and type "sudo reboot". I then observed that it did not, in fact, reboot.

[Steve Langasek (vorlon)]

On Thu, Jan 28, 2016 at 02:03:45AM -0000, dann frazier wrote:
> I can reproduce - here are the steps:

Thanks for confirming, Dann. Do you know if this is reproducible with
0~20160104.c2a892d7 (the version that has just been uploaded to Debian
unstable)?

[dann frazier (dannf)]

On Wed, Jan 27, 2016 at 7:53 PM, Steve Langasek
<email address hidden> wrote:
> On Thu, Jan 28, 2016 at 02:03:45AM -0000, dann frazier wrote:
>> I can reproduce - here are the steps:
>
> Thanks for confirming, Dann. Do you know if this is reproducible with
> 0~20160104.c2a892d7 (the version that has just been uploaded to Debian
> unstable)?

Steve,
  Just tested, and yes it is. I should also note that I'm not sure
that this is necessarily an edk2 issue to fix. Seems to me that this
could also be a problem with QEMU or the guest kernel. I've tested the
latest xenial versions of each (qemu 2.5+dfsg-1ubuntu3, linux
4.4.0-2.16) along with the latest edk2 from Debian, and the problem
persists.

   -dann