qemu-system-sparc64 crash when initializing disk

[wbx]

Hi,

I try to boot up Linux for SPARC64 in qemu-system-sparc64 (qemu 1.7.0). A self compiled kernel with initramfs as piggyback boots up fine.
(http://www.openadk.org/qemu-sparc64-initramfs-piggyback-kernel)
When trying to use a disk image I get following trace:
qemu-system-sparc64 -nographic -kernel /home/wbx/openadk/bin/qemu_sparc64_eglibc/qemu-sparc64-archive-kernel qemu-sparc64.img -append "root=/dev/sda1"
[ 43.520705] ata1.00: ATA-7: QEMU HARDDISK, 1.7.0, max UDMA/100
[ 43.792734] ata1.00: 1048576 sectors, multi 16: LBA48
[ 44.100768] ata1.00: configured for UDMA/33
[ 44.316791] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 1.7. PQ: 0 ANSI: 5
[ 44.724835] sd 0:0:0:0: [sda] 1048576 512-byte logical blocks: (536 MB/512 MiB)
[ 45.172883] ata2.00: ATAPI: QEMU DVD-ROM, 1.7.0, max UDMA/100
[ 45.508920] ata2.00: configured for UDMA/33
[ 45.752946] scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 1.7. PQ: 0 ANSI: 5
[ 46.309006] sd 0:0:0:0: [sda] Write Protect is off
[ 46.737053] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
qemu: fatal: Trap 0x0032 while trap level (5) >= MAXTL (5), Error state
pc: 00000000004055dc npc: 00000000004055e0
%g0-3: 0000000000000000 0000000000000200 fffff80006a3f170 0000000000000200
%g4-7: f500046400000000 0000000000000000 fffff80006a3c000 f500000000000000
%o0-3: fffff80006a10140 fffff80006a10160 fffff80006900010 0000000006a6c000
%o4-7: 0000000000000002 00000000000003e7 fffff80006a3e1c1 0000000000593988
%l0-3: 000000000000ffff 0000000000ff0000 0000000000002000 0000000000000001
%l4-7: 0000000000000000 fffff80006a0d980 0000000000000001 00000000c0004000
%i0-3: 0000000000000000 000000000000ff00 0000000000010000 0000000000000001
%i4-7: fffff80006a11d50 fffff80006a10000 fffff80006a3e271 0000000000582444
%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f16: 076e072707740720 0773077507700770 076f077207740720 07440750074f0720
%f24: 076f077207200746 0755074107200720 0720072007200720 0720072007200720
%f32: 0720072007200720 0720072007200720 0720072007200720 0720072007200720
%f40: 0720072007200720 0720072007200720 0720072007200720 0720072007200720
%f48: 0720072007200720 0755074107200720 0720072007200720 0720072007200720
%f56: 0720072007200720 0720072007200720 0720072007200720 0720072007200720
pstate: 00000015 ccr: 00 (icc: ---- xcc: ----) asi: 80 tl: 5 pil: e
cansave: 4 canrestore: 2 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 4
fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000

Aborted

Same happens when starting up Debian/wheezy 7.4 for sparc64:
qemu-system-sparc64 -nographic -kernel vmlinuz -initrd initrd.gz qemu.img
[ 102.943129] eth0: RealTek RTL-8029 found at 0x1fe02000400, IRQ 6, 52:54:00:12:34:56.
[ 105.143367] scsi0 : pata_cmd64x
[ 105.667424] scsi1 : pata_cmd64x
[ 106.003460] ata1: PATA max UDMA/33 cmd 0x1fe02000500 ctl 0x1fe02000580 bmdma 0x1fe02000700 irq 7
[ 106.871554] ata2: PATA max UDMA/33 cmd 0x1fe02000600 ctl 0x1fe02000680 bmdma 0x1fe02000708 irq 7
[ 108.247703] ata1.00: ATA-7: QEMU HARDDISK, 1.7.0, max UDMA/100
[ 108.775760] ata1.00: 1048576 sectors, multi 16: LBA48
[ 109.399827] ata1.00: configured for UDMA/33
[ 109.815872] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 1.7. PQ: 0 ANSI: 5
[ 111.004001] ata2.00: ATAPI: QEMU DVD-ROM, 1.7.0, max UDMA/100
[ 111.608066] ata2.00: configured for UDMA/33
[ 112.040113] scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 1.7. PQ: 0 ANSI: 5
[ 114.344362] sd 0:0:0:0: [sda] 1048576 512-byte logical blocks: (536 MB/512 MiB)
qemu: fatal: Trap 0x0032 while trap level (5) >= MAXTL (5), Error state
pc: 00000000004055bc npc: 00000000004055c0
%g0-3: 0000000000000000 0000000000000200 fffff80007e6bd10 0000000000000200
%g4-7: f500046400000000 0000000000000000 fffff80005d34000 f500000000000000
%o0-3: fffff80005f68148 fffff80005f68180 000000000000000c 0000000000000001
%o4-7: fffff80005d4b889 000001fe02000600 fffff8000705b391 0000000010064474
%l0-3: 0000000000000000 00000000007f6330 0000000000200200 fffff80007e6be60
%l4-7: 0000000000000000 0000000000945bd8 0000000000945fd8 00000000009463d8
%i0-3: fffff80005f68000 fffff80005f68148 0000000000000058 0000000000000001
%i4-7: fffff80005f69ce8 0000000000000000 fffff8000705b451 0000000010064ab8
%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
pstate: 00000015 ccr: 00 (icc: ---- xcc: ----) asi: 80 tl: 5 pil: e
cansave: 3 canrestore: 3 otherwin: 0 wstate: 0 cleanwin: 7 cwp: 7
fsr: 0000000000000000 y: 000000000003e810 fprs: 0000000000000000

Aborted

Anything I can do to get it boot from disk?

thanks in advance.
 Waldemar

[Mark Cave-Ayland (mark-cave-ayland)]

Hi Waldemar,

The bug you are seeing is related to the Linux cmd646 driver which happens to cause an illegal access in the kernel under qemu-system-sparc64. It is most likely due to the lack of IOMMU emulation, however I haven't had a chance to dig into it in much detail yet.

The good news is that if you do want to boot directly from a disk image then you can do it using the virtio drivers with a little work. Take a look at Artyom's blog entry here for more information: http://tyom.blogspot.co.uk/2013/03/debiansparc64-wheezy-under-qemu-how-to.html.

Kind regards,

Mark.

[wbx (k-mail-n)]

Hi Mark,

thanks for the tip. It works fine with virtio drivers. Is there any specific reason, why Qemu sparc64 virtualization have to use the cmd646 driver? For example mips emulator is using PIIX3/4 IDE driver.

thanks so far,
 Waldemar

[wbx (k-mail-n)]

Hi,

my linux system boots up fine in the emulator, but when I try to extract perl source code it just hangs after a while:
..
perl-5.18.1/cpan/Pod-Simple/t/basic.t
perl-5.18.1/cpan/Pod-Simple/t/begin.t
perl-5.18.1/cpan/Pod-Simple/t/cbacks.t
perl-5.18.1/cpan/Pod-Simple/t/chunking.t

no further console output. When I restart qemu-system-sparc64 it hangs again, but on other files.
The process of qemu-system-sparc64 is still running. Strace shows something like this in endless manner:
150 tgkill(20150, 20705, SIGUSR1) = 0
20150 futex(0x7feca6f87400, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
20705 --- SIGUSR1 (User defined signal 1) @ 0 (0) ---
20705 rt_sigreturn(0x7feca78d9150) = 16777216
20705 futex(0x7feca6f87400, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
20150 <... futex resumed> ) = 0
20150 futex(0x7feca6f873c0, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
20705 <... futex resumed> ) = 1
20705 futex(0x7feca6f873c0, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
20150 <... futex resumed> ) = 0
20150 futex(0x7feca6f873c0, FUTEX_WAKE_PRIVATE, 1) = 0
20150 futex(0x7feca6f873c4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7feca6f87400, 129702) = 0
20150 clock_gettime(CLOCK_MONOTONIC, {24909511, 655710718}) = 0
20150 clock_gettime(CLOCK_MONOTONIC, {24909511, 655710718}) = 0
20150 clock_gettime(CLOCK_MONOTONIC, {24909511, 655710718}) = 0
20150 clock_gettime(CLOCK_MONOTONIC, {24909511, 655710718}) = 0
20150 gettimeofday({1392836771, 784958}, NULL) = 0
20150 futex(0x7feca6f87400, FUTEX_WAKE_PRIVATE, 1) = 0
20150 ppoll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=5, events=POLLIN}, {fd=0, events=POLLIN}, {fd=7, events=POLLIN}, {fd=4, events=POLLIN}], 5, {1, 0}, NULL, 8 <unfinished ...>
20705 <... futex resumed> ) = 1
20705 futex(0x7feca6f873c4, FUTEX_WAIT_PRIVATE, 129701, NULL) = -1 EAGAIN (Resource temporarily unavailable)
20705 clock_gettime(CLOCK_MONOTONIC, {24909511, 655710718}) = 0
20705 clock_gettime(CLOCK_MONOTONIC, {24909511, 655710718}) = 0
20705 clock_gettime(CLOCK_MONOTONIC, {24909511, 655710718}) = 0
20705 clock_gettime(CLOCK_MONOTONIC, {24909511, 655710718}) = 0
20705 clock_gettime(CLOCK_MONOTONIC, {24909511, 655710718}) = 0
20705 clock_gettime(CLOCK_MONOTONIC, {24909511, 655710718}) = 0
20705 write(4, "\1\0\0\0\0\0\0\0", 8 <unfinished ...>
20150 <... ppoll resumed> ) = 1 ([{fd=4, revents=POLLIN}], left {1, 0})
20150 tgkill(20150, 20705, SIGUSR1) = 0
20150 futex(0x7feca6f87400, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
20705 <... write resumed> ) = 8
20705 --- SIGUSR1 (User defined signal 1) @ 0 (0) ---

Looks like some kind of deadlock between two qemu-system-sparc64 threads.
Anything I doing wrong?

Best regards
 Waldemar

[Mark Cave-Ayland (mark-cave-ayland)]

Hi Waldemar,

I can't say that I've seen anything like that here, although I don't tend to push my images too much. It does sound like some kind of deadlock though.

Are these the straces from the qemu-system-sparc64 host process or the qemu-system-sparc64 guest process? If it's the former, can you try the latter and see if that provides any information?

ATB,

Mark.

[wbx (k-mail-n)]

Hi Mark,

the strace is from qemu-system-sparc64 host process. Inside the running system (Linux 3.13.3, glib 2.19, busybox) I get:
 [pid 273] umask(0) = 022
[pid 273] umask(022) = 0
[pid 273] mkdir("perl-5.18.1/", 0777) = -1 EEXIST (File exists)
[pid 273] stat64("perl-5.18.1/", {st_mode=0, st_size=0, ...}) = 0
[pid 273] mkdir("perl-5.18.1/cpan/", 0777) = -1 EEXIST (File exists)
[pid 273] stat64("perl-5.18.1/cpan/", {st_mode=0, st_size=0, ...}) = 0
[pid 273] mkdir("perl-5.18.1/cpan/Unicode-Collate/", 0777) = -1 EEXIST (File exists)
[pid 273] stat64("perl-5.18.1/cpan/Unicode-Collate/", {st_mode=0, st_size=0, ...}) = 0
[pid 273] mkdir("perl-5.18.1/cpan/Unicode-Collate/Collate/", 0777) = -1 EEXIST (File exists)
[pid 273] stat64("perl-5.18.1/cpan/Unicode-Collate/Collate/", {st_mode=0, st_size=0, ...}) = 0
[pid 273] mkdir("perl-5.18.1/cpan/Unicode-Collate/Collate/Locale", 0777) = -1 EEXIST (File exists)
[pid 273] stat64("perl-5.18.1/cpan/Unicode-Collate/Collate/Locale", {st_mode=0, st_size=0, ...}) = 0
[pid 273] unlink("perl-5.18.1/cpan/Unicode-Collate/Collate/Locale/wo.pl") = -1 ENOENT (No such file or directory)
[pid 273] open("perl-5.18.1/cpan/Unicode-Collate/Collate/Locale/wo.pl", O_WRONLY|O_CREAT|O_EXCL, 0100444) = 4
[pid 273] read(3, "+{\n locale_version => 0.93,\n# "..., 1949) = 1949
[pid 273] write(4, "+{\n locale_version => 0.93,\n# "..., 1949) = 1949
[pid 273] close(4) = 0
[pid 273] open("/etc/passwd", O_RDONLY) = 4
[pid 273] fstat64(4, {st_mode=0, st_size=0, ...}) = 0
[pid 273] mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffc0100026000
[pid 273] read(4, "root:x:0:0:root:/root:/bin/ash\nn"..., 8192) = 75
[pid 273] read(4, "", 8192) = 0
[pid 273] close(4) = 0
[pid 273] munmap(0xfffffc0100026000, 8192) = 0
[pid 273] open("/etc/group", O_RDONLY) = 4
[pid 273] fstat64(4, {st_mode=0, st_size=0, ...}) = 0
[pid 273] mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffc0100026000
[pid 273] read(4, "root:x:0:\nvideo:x:1:\naudio:x:2:\n"..., 8192) = 49
[pid 273] read(4, "", 8192) = 0
[pid 273] close(4) = 0
[pid 273] munmap(0xfffffc0100026000, 8192) = 0
[pid 273] chown("perl-5.18.1/cpan/Unicode-Collate/Collate/Locale/wo.pl", 502, 502) = 0
[pid 273] chmod("perl-5.18.1/cpan/Unicode-Collate/Collate/Locale/wo.pl", 0100444) = 0
[pid 273] utimes("perl-5.18.1/cpan/Unicode-Collate/Collate/Locale/wo.pl", {{1376275488, 0}, {1376275488, 0}}) = 0
[pid 273] lseek(3, 99, SEEK_CUR) = -1 ESPIPE (Illegal seek)
[pid 273] read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 99) = 99
[pid 273] read(3, "perl-5.18.1/cpan/Unicode-Collate"..., 512) = 512
[pid 273] umask(0) = 022
[pid 273] umask(022) = 0
[pid 273] mkdir("perl-5.18.1/", 0777) = -1 EEXIST (File exists)
[pid 273] stat64("perl-5.18.1/", {st_mode=0, st_size=0, ...}) = 0
[pid 273] mkdir("perl-5.18.1/cpan/", 0777) = -1 EEXIST (File exists)

Here it stops and does not react on any input li...

[Mark Cave-Ayland (mark-cave-ayland)]

Hi Waldemar,

Apologies for the delay in the reply! A few more questions for you:

- Do you still see the same issue with qemu git master? (soon to be 2.0)
- Can you use gdb or similar to get a backtrace from one of the deadlocked processes?
- Does the extraction always freeze at the same place, or does it vary at all?

Many thanks,

Mark.

[wbx (k-mail-n)]

Hi Mark,

I have done some more testing on this and giving up. It is very fuzzy. Seems to work on MacOSX and Linux hosts with Qemu 1.7 and
Qemu 2.0rc0 when the load of the system is under 2-3. If it is higher sometimes the deadlock occur.
So I think we can close the bug and hope nobody is cross-compiling in the background a lot of stuff, while using qemu-system-sparc64 with virtio ;)

Just tried 2.0rc0 on Maverick with a load of 8 and deadlock happens.

I can provide an kernel and filesystem if you are interested to debug this ;)

have fun
 Waldemar

[Artyom Tarasenko (atar4qemu)]

Hi Waldemar,

can you try launching QEMU with -monitor telnet::4442,server,nowait
(or any other port), and check if the monitor is available when the
suspected deadlock occurs? If connecting works, try info block and
blockstats, this may give some further clues, whether the hang happens
in host or in guest.

Of course everything is possible, but I think it is quite unlikely
that it hangs in the host virtio code: it's used a lot in emulation of
systems where we have much more users (x86-64 and ppc).

Artyom

On Mon, Mar 31, 2014 at 9:27 AM, wbx <email address hidden> wrote:
> Hi Mark,
>
> I have done some more testing on this and giving up. It is very fuzzy. Seems to work on MacOSX and Linux hosts with Qemu 1.7 and
> Qemu 2.0rc0 when the load of the system is under 2-3. If it is higher sometimes the deadlock occur.
> So I think we can close the bug and hope nobody is cross-compiling in the background a lot of stuff, while using qemu-system-sparc64 with virtio ;)
>
> Just tried 2.0rc0 on Maverick with a load of 8 and deadlock happens.
>
> I can provide an kernel and filesystem if you are interested to debug
> this ;)
>
> have fun
> Waldemar
>
> --
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/1278977
>
> Title:
> qemu-system-sparc64 crash when initializing disk
>
> Status in QEMU:
> New
>
> Bug description:
> Hi,
>
> I try to boot up Linux for SPARC64 in qemu-system-sparc64 (qemu 1.7.0). A self compiled kernel with initramfs as piggyback boots up fine.
> (http://www.openadk.org/qemu-sparc64-initramfs-piggyback-kernel)
> When trying to use a disk image I get following trace:
> qemu-system-sparc64 -nographic -kernel /home/wbx/openadk/bin/qemu_sparc64_eglibc/qemu-sparc64-archive-kernel qemu-sparc64.img -append "root=/dev/sda1"
> [ 43.520705] ata1.00: ATA-7: QEMU HARDDISK, 1.7.0, max UDMA/100
> [ 43.792734] ata1.00: 1048576 sectors, multi 16: LBA48
> [ 44.100768] ata1.00: configured for UDMA/33
> [ 44.316791] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 1.7. PQ: 0 ANSI: 5
> [ 44.724835] sd 0:0:0:0: [sda] 1048576 512-byte logical blocks: (536 MB/512 MiB)
> [ 45.172883] ata2.00: ATAPI: QEMU DVD-ROM, 1.7.0, max UDMA/100
> [ 45.508920] ata2.00: configured for UDMA/33
> [ 45.752946] scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 1.7. PQ: 0 ANSI: 5
> [ 46.309006] sd 0:0:0:0: [sda] Write Protect is off
> [ 46.737053] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> qemu: fatal: Trap 0x0032 while trap level (5) >= MAXTL (5), Error state
> pc: 00000000004055dc npc: 00000000004055e0
> %g0-3: 0000000000000000 0000000000000200 fffff80006a3f170 0000000000000200
> %g4-7: f500046400000000 0000000000000000 fffff80006a3c000 f500000000000000
> %o0-3: fffff80006a10140 fffff80006a10160 fffff80006900010 0000000006a6c000
> %o4-7: 0000000000000002 00000000000003e7 fffff80006a3e1c1 0000000000593988
> %l0-3: 000000000000ffff 0000000000ff0000 0000000000002000 0000000000000001
> %l4-7: 0000000000000000 fffff80006a0d980 0000000000000001 0...

[wbx (k-mail-n)]

Hi Artyom,

okay, with 1.7.0 on Maverick I get:
(qemu) info block
virtio0: qemu-sparc64.img (raw)

ide0-hd0: qemu-sparc64.img (raw)

ide1-cd0: [not inserted]
    Removable device: not locked, tray closed

floppy0: [not inserted]
    Removable device: not locked, tray closed

sd0: [not inserted]
    Removable device: not locked, tray closed
(qemu) info blockstats
virtio0: rd_bytes=42984448 wr_bytes=148874240 rd_operations=6310 wr_operations=16470 flush_operations=0 wr_total_time_ns=450789456000 rd_total_time_ns=23944239000 flush_total_time_ns=0
ide0-hd0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 flush_operations=0 wr_total_time_ns=0 rd_total_time_ns=0 flush_total_time_ns=0
ide1-cd0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 flush_operations=0 wr_total_time_ns=0 rd_total_time_ns=0 flush_total_time_ns=0
floppy0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 flush_operations=0 wr_total_time_ns=0 rd_total_time_ns=0 flush_total_time_ns=0
sd0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 flush_operations=0 wr_total_time_ns=0 rd_total_time_ns=0 flush_total_time_ns=0

The guest is hanging.

best regards
 Waldemar

[Artyom Tarasenko (atar4qemu)]

Hi Waldemar,

It can be a Linux kernel bug or a QEMU bug. To get the further info,
try -serial telnet::4444,server,wait
and use the telnet as a serial console. When the guest hangs use the
telnet menu to send break, and then type 'T'.
This would produce the same result as magic SysRq+T: the kernel will
list the active threads (the magic SysRq has to be enabled to use this
feature though). Then please post the listing here and on the
sparclinux@ mailing list.

Artyom

On Tue, Apr 1, 2014 at 11:37 AM, wbx <email address hidden> wrote:
> Hi Artyom,
>
> okay, with 1.7.0 on Maverick I get:
> (qemu) info block
> virtio0: qemu-sparc64.img (raw)
>
> ide0-hd0: qemu-sparc64.img (raw)
>
> ide1-cd0: [not inserted]
> Removable device: not locked, tray closed
>
> floppy0: [not inserted]
> Removable device: not locked, tray closed
>
> sd0: [not inserted]
> Removable device: not locked, tray closed
> (qemu) info blockstats
> virtio0: rd_bytes=42984448 wr_bytes=148874240 rd_operations=6310 wr_operations=16470 flush_operations=0 wr_total_time_ns=450789456000 rd_total_time_ns=23944239000 flush_total_time_ns=0
> ide0-hd0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 flush_operations=0 wr_total_time_ns=0 rd_total_time_ns=0 flush_total_time_ns=0
> ide1-cd0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 flush_operations=0 wr_total_time_ns=0 rd_total_time_ns=0 flush_total_time_ns=0
> floppy0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 flush_operations=0 wr_total_time_ns=0 rd_total_time_ns=0 flush_total_time_ns=0
> sd0: rd_bytes=0 wr_bytes=0 rd_operations=0 wr_operations=0 flush_operations=0 wr_total_time_ns=0 rd_total_time_ns=0 flush_total_time_ns=0
>
> The guest is hanging.
>
> best regards
> Waldemar
>
> --
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/1278977
>
> Title:
> qemu-system-sparc64 crash when initializing disk
>
> Status in QEMU:
> New
>
> Bug description:
> Hi,
>
> I try to boot up Linux for SPARC64 in qemu-system-sparc64 (qemu 1.7.0). A self compiled kernel with initramfs as piggyback boots up fine.
> (http://www.openadk.org/qemu-sparc64-initramfs-piggyback-kernel)
> When trying to use a disk image I get following trace:
> qemu-system-sparc64 -nographic -kernel /home/wbx/openadk/bin/qemu_sparc64_eglibc/qemu-sparc64-archive-kernel qemu-sparc64.img -append "root=/dev/sda1"
> [ 43.520705] ata1.00: ATA-7: QEMU HARDDISK, 1.7.0, max UDMA/100
> [ 43.792734] ata1.00: 1048576 sectors, multi 16: LBA48
> [ 44.100768] ata1.00: configured for UDMA/33
> [ 44.316791] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 1.7. PQ: 0 ANSI: 5
> [ 44.724835] sd 0:0:0:0: [sda] 1048576 512-byte logical blocks: (536 MB/512 MiB)
> [ 45.172883] ata2.00: ATAPI: QEMU DVD-ROM, 1.7.0, max UDMA/100
> [ 45.508920] ata2.00: configured for UDMA/33
> [ 45.752946] scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 1.7. PQ: 0 ANSI: 5
> [ 46.309006] sd 0:0:0:0: [sda] Write Protect is off
> [ 46.737053] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DP...

[wbx (k-mail-n)]

Hi Artyom,

unfortunately there is no output, when the system gets the deadlock:
perl-5.18.1/pod/perlvms.pod
perl-5.18.1/pod/rofftoc
telnet> send brk

When the system is running, I get
ENTER
and can then push the t key to get the running threads/tasks.

Any other idea?

best regards
 Waldemar

[wbx (k-mail-n)]

Hi,

here is the kernel and image:
http://www.openadk.org/sparc64/

Inside the system do:
rw
tar xvf perl-5.18.1.tar.gz

The kernel contains full debug info. Be sure that your system has a high load.

[Richard Henderson (rth)]

We don't implement the sparc64 iommu, and the kernel expects to be able to use it.

The kernel sets up an iommu translation table, but qemu does not adjust its internal mappings,
and thus the first time the kernel touches the PCI bus we get an oops.

If you build a kernel with virtio built in, you can use a virtio disk, as that does not require the iommu.

[Mark Cave-Ayland (mark-cave-ayland)]

Hi Waldemar,

An update on this bug: it seems there is a problem with QEMU's block AIO code which seems to be easily triggerable with virtio. I think it's be identified within recent discussions on the mailing list, but I don't believe a patch has been committed to resolve the issue.

Note that as of QEMU 2.1, the sun4u IOMMU is now implemented in QEMU and so you should be able to boot Linux with the standard cmd646 driver as per your original attempt above. Please can you try this and see if you still experience the deadlock?

Many thanks,

Mark.

[wbx (k-mail-n)]

Hi Mark,

I tried the cmd646 driver again and it works fine now. I can even extract the perl code without problems.
No deadlock, even with a high load of the host system.

When switching back to virtio using following command:
qemu-system-sparc64 -M sun4u -nographic -net nic,model=virtio -net user -drive file=qemu-sparc64.img,if=virtio,index=0 -kernel /home/wbx/sparc64/firmware/qemu-sparc64_glibc/qemu-sparc64-archive-kernel qemu-sparc64.img
The deadlock can be reproduced again using Qemu 2.1.
Interesting is that I can not reproduce the deadlock using qemu-system--aarch64, which uses virtio, too.
But for qemu-system-aarch64 I need following command:
qemu-system-aarch64 -nographic -M virt -cpu cortex-a57 -smp 1 -netdev user,id=eth0 -device virtio-net-device,netdev=eth0 -device virtio-blk-device,drive=vda -drive file=qemu-aarch64.img,if=none,id=vda -kernel /home/wbx/aarch64/firmware/qemu-aarch64_glibc/qemu-aarch64-archive-kernel qemu-aarch64.img

The sparc64 system emulator does not work with this syntax and I get following warning with the other one:
qemu-system-sparc64: unable to init msix vectors to 3
qemu-system-sparc64: -drive file=qemu-sparc64.img,if=virtio,index=0: unable to init msix vectors to 2

Hmm, I think I haven't seen this messages with older Qemu versions. Both are using virtio, why the deadlock only occurs with sparc64?

[Mark Cave-Ayland (mark-cave-ayland)]

HI Waldemar,

Glad that you now have something that works for you.

I've tried to reproduce your virtio hang this morning with multiple 100% CPU and "find / -name 'foo'" processes running but I can't seem to get virtio to hang on my system here.

Since this is the second report I've had of this problem, I'd be interested to try and get a backtrace from a debug-enabled qemu build if possible. Would you be willing to contact me directly with a temporary account on your system so I can try and get a backtrace from a hung qemu?

Many thanks,

Mark.