1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
qemu-system-arm hangs with -icount and -nodefaults
I tested with the latest git repo, (commit: dbe2b65566e76d3c3a0c3358285c0336ac61e757).
My configure options when building QEMU:
'../configure' '--prefix=$HOME/local/qemu.git' '--target-list=aarch64-softmmu,arm-softmmu' '--cpu=x86_64' '--cc=gcc' '--disable-user' '--disable-sdl' '--disable-stack-protector' '--disable-attr' '--disable-pie' '--disable-linux-aio' '--disable-tpm' '--without-system-pixman' '--disable-docs' '--disable-guest-agent' '--disable-guest-agent-msi' '--disable-modules' '--disable-sparse' '--disable-gnutls' '--disable-nettle' '--disable-gcrypt' '--disable-gtk' '--disable-vte' '--disable-curses' '--disable-vnc' '--disable-cocoa' '--disable-virtfs' '--disable-xen' '--disable-brlapi' '--disable-curl' '--disable-bluez' '--disable-rdma' '--disable-uuid' '--disable-vde' '--disable-netmap' '--disable-cap-ng' '--disable-attr' '--disable-vhost-net' '--disable-spice' '--disable-rbd' '--disable-libiscsi' '--disable-libnfs' '--disable-smartcard' '--disable-libusb' '--disable-usb-redir' '--disable-lzo' '--disable-snappy' '--disable-bzip2' '--disable-seccomp' '--disable-glusterfs' '--disable-archipelago' '--disable-libssh2' '--disable-vhdx' '--disable-numa' '--disable-werror' '--disable-blobs' '--disable-vhost-scsi' '--enable-debug' '--disable-strip' '--enable-debug-tcg' '--enable-debug-info' '--extra-cflags=-fPIC'
My host OS is Redhat RHEL-6.5. uname command gives:
Linux rslpc1 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
The test image is downloaded from http://wiki.qemu.org/download/arm-test-0.2.tar.gz
The command to re-produce the problem:
qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -icount 1 -nodefaults -chardev stdio,mux=on,id=char0 -serial chardev:char0 --append "console=ttyAMA0"
After console prints the message below:
"Uncompressing Linux.......................................................................... done, booting the kernel."
there's no further action noticed.
If "-icount" is not set, namely run as:
qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -nodefaults -chardev stdio,mux=on,id=char0 -serial chardev:char0 --append "console=ttyAMA0"
or if "-nodefaults" is not set, namely run as:
qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -icount 1 --append "console=ttyAMA0"
The Linux boot procedure can finish successfully.
Thanks.
Hansni
On Thu, Dec 29, 2016 at 5:04 AM, Andrew Jones <email address hidden> wrote:
> On Thu, Dec 29, 2016 at 08:02:16AM -0000, Hansni Bu wrote:
>> Public bug reported:
> ...
>> https://bugs.launchpad.net/bugs/1653063
> ...
>> After console prints the message below:
>> "Uncompressing Linux.......................................................................... done, booting the kernel."
>> there's no further action noticed.
>>
>> If "-icount" is not set, namely run as:
>> qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -nodefaults -chardev stdio,mux=on,id=char0 -serial chardev:char0 --append "console=ttyAMA0"
>>
>> or if "-nodefaults" is not set, namely run as:
>> qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -icount 1 --append "console=ttyAMA0"
>>
>> The Linux boot procedure can finish successfully.
>
> Hi Hansni,
>
> The fact things work when you remove -nodefaults is a sign that with it
> your single cpu may just not be getting scheduled again. Does the patch
> from Alex Bennée here[*] help?
>
> [*] https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg01743.html
>
This bug is still reproducible with the latest git.
--
Pranith
--
Pranith
I think we fixed this bug in commit 013aabdc665e4256b38d which would have been in the 3.1.0 release (this is why we closed #1774677, which is the same issue).
|