qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: gaowanlong@cn.fujitsu.com
Cc: Hu Tao <hutao@cn.fujitsu.com>,
	"seabios@seabios.org" <seabios@seabios.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [BUG] qemu crash when using "lsilogic"
Date: Tue, 20 Nov 2012 12:45:57 +0200	[thread overview]
Message-ID: <50AB5F65.4040208@redhat.com> (raw)
In-Reply-To: <50AB4700.5020801@cn.fujitsu.com>

On 11/20/2012 11:01 AM, Wanlong Gao wrote:

>> $ git bisect good
>> d22b096ef6e0b20810193b68a1d472f3fb8a4f9e is the first bad commit
>> commit d22b096ef6e0b20810193b68a1d472f3fb8a4f9e
>> Author: Avi Kivity <avi@redhat.com>
>> Date:   Sun Sep 30 22:21:11 2012 +0200
>> 
>>     kvm: use separate MemoryListeners for memory and I/O
>>     
>>     The construct
>>     
>>        if (address_space == get_system_memory()) {
>>            // memory thing
>>        } else {
>>            // io thing
>>        }
>>     
>>     fails if we have more than two address spaces.  Use a separate listener
>>     for memory and I/O, and utilize MemoryListener's address space filtering to
>>     fix this.
>>     
>>     Signed-off-by: Avi Kivity <avi@redhat.com>
>> 
>> :100644 100644 92a71374ed1e040cef5ad70a6cb00adabf671dd4 c69e01200461c7a87440f7a915bd171a9fc8f318 M	kvm-all.c
>> 
>> 
>> Ooooops, I didn't find any error in above patch, can you guys help to investigate this bug?
> 
> I confirmed again and found that "lsi" can't work on the upstream qemu.
> Any thoughts?
> 

I appears to be a bug in Seabios:

(gdb) thread 3
[Switching to thread 3 (Thread 0x7fffebfff700 (LWP 19032))]
#0  0x000055555586df2c in access_with_adjusted_size (addr=29563620,
value=0x7fffebffe5f0, size=4, access_size_min=0, access_size_max=0, access=
    0x55555586ddbb <memory_region_read_accessor>, opaque=0x55555655dd00)
at /home/tlv/akivity/qemu/memory.c:349
349	{
(gdb) bt
#0  0x000055555586df2c in access_with_adjusted_size (addr=29563620,
value=0x7fffebffe5f0, size=4, access_size_min=0, access_size_max=0, access=
    0x55555586ddbb <memory_region_read_accessor>, opaque=0x55555655dd00)
at /home/tlv/akivity/qemu/memory.c:349
#1  0x0000555555870a4e in memory_region_dispatch_read1
(mr=0x55555655dd00, addr=29563620, size=4) at
/home/tlv/akivity/qemu/memory.c:862
#2  0x0000555555870b3e in memory_region_dispatch_read
(mr=0x55555655dd00, addr=29563620, size=4) at
/home/tlv/akivity/qemu/memory.c:894
#3  0x0000555555873c2d in io_mem_read (mr=0x55555655dd00, addr=29563620,
size=4) at /home/tlv/akivity/qemu/memory.c:1575
#4  0x00005555558054ed in address_space_rw (as=0x555556629d78,
addr=29563620, buf=0x7fffebffe874 "", len=4, is_write=false) at
/home/tlv/akivity/qemu/exec.c:3428
#5  0x00005555556bf4c3 in dma_memory_rw_relaxed (dma=0x555556603cf0,
addr=29563620, buf=0x7fffebffe874, len=4, dir=DMA_DIRECTION_TO_DEVICE)
at /home/tlv/akivity/qemu/dma.h:130
#6  0x00005555556bf558 in dma_memory_rw (dma=0x555556603cf0,
addr=29563620, buf=0x7fffebffe874, len=4, dir=DMA_DIRECTION_TO_DEVICE)
at /home/tlv/akivity/qemu/dma.h:156
#7  0x00005555556bf5fb in pci_dma_rw (dev=0x555556629b60, addr=29563620,
buf=0x7fffebffe874, len=4, dir=DMA_DIRECTION_TO_DEVICE) at
/home/tlv/akivity/qemu/hw/pci.h:607
#8  0x00005555556bf65b in pci_dma_read (dev=0x555556629b60,
addr=29563620, buf=0x7fffebffe874, len=4) at
/home/tlv/akivity/qemu/hw/pci.h:614
#9  0x00005555556bfc08 in read_dword (s=0x555556629b60, addr=29563620)
at /home/tlv/akivity/qemu/hw/lsi53c895a.c:385
#10 0x00005555556c1937 in lsi_execute_script (s=0x555556629b60) at
/home/tlv/akivity/qemu/hw/lsi53c895a.c:1040
#11 0x00005555556c3c82 in lsi_reg_writeb (s=0x555556629b60, offset=47,
val=0 '\000') at /home/tlv/akivity/qemu/hw/lsi53c895a.c:1781
#12 0x00005555556c513c in lsi_io_write (opaque=0x555556629b60, addr=47,
val=0, size=1) at /home/tlv/akivity/qemu/hw/lsi53c895a.c:1953
#13 0x000055555586def2 in memory_region_write_accessor
(opaque=0x55555662a340, addr=47, value=0x7fffebffeab0, size=1, shift=0,
mask=255) at /home/tlv/akivity/qemu/memory.c:334
#14 0x000055555586dfd4 in access_with_adjusted_size (addr=47,
value=0x7fffebffeab0, size=1, access_size_min=1, access_size_max=1,
access=0x55555586de6d <memory_region_write_accessor>,
    opaque=0x55555662a340) at /home/tlv/akivity/qemu/memory.c:364
#15 0x000055555586e43c in memory_region_iorange_write
(iorange=0x7fffe4000ed0, offset=47, width=1, data=0) at
/home/tlv/akivity/qemu/memory.c:439
#16 0x0000555555866acc in ioport_writeb_thunk (opaque=0x7fffe4000ed0,
addr=49199, data=0) at /home/tlv/akivity/qemu/ioport.c:212
#17 0x00005555558664a6 in ioport_write (index=0, address=49199, data=0)
at /home/tlv/akivity/qemu/ioport.c:83
#18 0x0000555555867046 in cpu_outb (addr=49199, val=0 '\000') at
/home/tlv/akivity/qemu/ioport.c:289
#19 0x000055555586a958 in kvm_handle_io (port=49199,
data=0x7ffff7ff3000, direction=1, size=1, count=1) at
/home/tlv/akivity/qemu/kvm-all.c:1423
#20 0x000055555586af5e in kvm_cpu_exec (env=0x55555659b0b0) at
/home/tlv/akivity/qemu/kvm-all.c:1571
#21 0x00005555557f74e4 in qemu_kvm_cpu_thread_fn (arg=0x55555659b0b0) at
/home/tlv/akivity/qemu/cpus.c:757
#22 0x00007ffff6727d14 in start_thread () from /lib64/libpthread.so.0
#23 0x00007ffff533667d in clone () from /lib64/libc.so.6
(gdb) fr 4
#4  0x00005555558054ed in address_space_rw (as=0x555556629d78,
addr=29563620, buf=0x7fffebffe874 "", len=4, is_write=false) at
/home/tlv/akivity/qemu/exec.c:3428
3428	                    val = io_mem_read(section->mr, addr1, 4);
(gdb) p as.root.name
$1 = 0x55555662cc80 "bus master"
(gdb) p as.root.enabled
$2 = false

We're executing a scsi script without enabling the lsi bus master bit.

There is also a bug in the lsi code:


1038	again:
1039	    insn_processed++;
1040	    insn = read_dword(s, s->dsp);
1041	    if (!insn) {
1042	        /* If we receive an empty opcode increment the DSP by 4 bytes
1043	           instead of 8 and execute the next opcode at that location */
1044	        s->dsp += 4;
1045	        goto again;

Which causes the script interpreter to go into an infinite loop.  This
should be moved to a bottom half or thread.


-- 
error compiling committee.c: too many arguments to function

      reply	other threads:[~2012-11-20 10:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-19  9:43 [Qemu-devel] [BUG] qemu crash when using "lsilogic" Wanlong Gao
2012-11-20  9:01 ` Wanlong Gao
2012-11-20 10:45   ` Avi Kivity [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50AB5F65.4040208@redhat.com \
    --to=avi@redhat.com \
    --cc=gaowanlong@cn.fujitsu.com \
    --cc=hutao@cn.fujitsu.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).