Hi Graeme, Mainline kernel, 4.3.0-rc2 boots fine with acpi=force. Thanks!
Itaru
On 10/18/15 7:27 PM, G Gregory wrote:
Hi Itaru,
Sorry I just realised the issue, the virtio-blk ACPI support didn't enter the kernel until 4.3-rc series.
Graeme
On Sun, Oct 18, 2015 at 05:56:06PM +0900, Itaru Kitayama wrote:
Hi Graeme,
Thank you for sharing your script. I changed my script so it almost looks like yours using the image Linaro provides (also used -kernel and -append options as well - KVM is not enabled this time).
http://releases.linaro.org/14.08/openembedded/aarch64/vexpress64-openembedde...
System boots just fine with acpi=off, but not with acpi=force saying:
[ 40.468285] VFS: Cannot open root device "vda2" or unknown-block(0,0): error -6 [ 40.469606] Please append a correct "root=" boot option; here are the available partitions: [ 40.471926] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
On 10/16/15 4:14 PM, G Gregory wrote:
Hi Itaru,
My script has basically the same arguments for block device as yours.
../qemu/aarch64-softmmu/qemu-system-aarch64 \ -smp 1 -m 1024 -M virt \ -cpu cortex-a57 \ -nographic \ -device e1000,netdev=net1,mac="52:54:00:12:34:56" \ -netdev type=tap,ifname=tap0,id=net1,script=no,downscript=no \ -device virtio-net-pci,netdev=net2,mac="52:54:00:12:34:57" \ -netdev type=tap,ifname=tap1,id=net2,script=no,downscript=no \ -device virtio-net-device,netdev=net3,mac="52:54:00:12:34:58" \ -netdev type=tap,ifname=tap2,id=net3,script=no,downscript=no \ -monitor telnet::4444,server,nowait \ -drive file=../filesystems/Fedora_22.qcow2,id=root,if=none,format=qcow2 \ -device virtio-blk-device,drive=root \ -device virtio-serial,id=vser0 \ -chardev socket,host=127.0.0.1,port=5500,server,id=foo \ -device virtconsole,chardev=foo,bus=vser0.0,name=console.foo \ -bios QEMU_EFI.fd \ -kernel Image \ -append "console=ttyAMA0 earlycon=pl011,0x9000000 console=hvc0 rw acpi=force root=/dev/vda4"
You can ignore the virtconsole/networking stuff thats just me experimenting.
For rootfs I have fedora but it was done using virt-install and doesn't make use of a initramfs
I am not using KVM!
Graeme
On 16 October 2015 at 07:44, Itaru Kitayama itaru.kitayama@riken.jp wrote:
Graeme, Do you have your own QEMU setup suitable for ACPI layer testing?
On 10/15/15 12:58 AM, G Gregory wrote:
On 14 October 2015 at 16:47, Itaru Kitayama itaru.kitayama@riken.jp wrote:
Hanjun, Graeme,
I rebuild virtio-blk as built-in, but still hangs at the same place, followed by the dracut message:
[ OK ] Reached target Paths. [ OK ] Reached target Basic System. [ 202.860821] dracut-initqueue[192]: Warning: Could not boot. [ 202.880347] dracut-initqueue[192]: Warning: /dev/disk/by-uuid/b5cc0232-adb7-4b2c-8ca8-98ca14a80286 does not exist Starting Dracut Emergency Shell... [ 203.051583] audit: type=1131 audit(1444837393.670:10): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=plymouth-start comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Warning: /dev/disk/by-uuid/b5cc0232-adb7-4b2c-8ca8-98ca14a80286 does not exist
Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exit the shell to continue. Type "journalctl" to view system logs. You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot after mounting them and attach it to a bug report.
dracut:/#
I'm using Leif's QEMU script; in it, options are:
-driver if=none,file=hda.img,id=hd0 -device virtio-blk-device,driver=hd0
There are numerous reasons this may not work, you will have to use that shell to debug them, start with checking virtio-blk devices got created, check whether partitions with your expected UUIDs turn up etc.
Graeme
On 10/14/15 10:06 PM, Hanjun Guo wrote: > On 10/14/2015 04:23 PM, G Gregory wrote: >> On 14 October 2015 at 09:21, G Gregory graeme.gregory@linaro.org >> wrote: >>> On 14 October 2015 at 06:55, Itaru Kitayama itaru.kitayama@riken.jp >>> wrote: >>>> Hi, >>>> I have been trying to boot the acpi-topic-bad-madt branch kernel on >>>> QEMU >>>> virt machine >>>> (KVM enabled on Mustang) this couples of days, however it can not get >>>> to the >>>> prompt. >>>> Can someone take a look at the boot log below and spot what the >>>> problem >>>> is? >>>> >>> No SATA driver enabled? >>> >> Or virtio-blk or wherever your rootfs is? > Or virtio-blk was built as module? > > Thanks > Hanjun