* [Qemu-devel] [Bug 1191606] [NEW] qemu crashes with iscsi initiator (libiscsi) when using virtio @ 2013-06-16 23:48 Klaus Hochlehnert 2013-06-16 23:54 ` [Qemu-devel] [Bug 1191606] " Klaus Hochlehnert ` (6 more replies) 0 siblings, 7 replies; 19+ messages in thread From: Klaus Hochlehnert @ 2013-06-16 23:48 UTC (permalink / raw) To: qemu-devel Public bug reported: I just tested qemu (with kvm) with an iscsi disk using libiscsi. I tried to install Ubuntu 12.04 as guest and when it comes to the disk configuration during the installation qemu crashes without any notice. No log, no dump. In the log of the iscsi-target I found this: iscsi-scst: ***ERROR***: Connection with initiator iqn.2013-06.de.test:testsrv01 unexpectedly closed! qemu version 1.5.0 libiscsi version 1.9.0 Host OS: Ubuntu 12.04 with 13.04-Kernel (3.8) iSCSI-target: SCST 2.2.x qemu command line: /usr/bin/kvm ... -drive file=iscsi://192.168.x.x/iqn.2006-10.de.test:test/0,if=virtio,bus=0,unit=0,cache=none,media=disk,aio=native -iscsi initiator-name=iqn.2013-06.de.test:testsrv01,header-digest=CRC32C-NONE ... When choosing IDE instead of VIRTIO it doesn't crash when scanning the disks... ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1191606 Title: qemu crashes with iscsi initiator (libiscsi) when using virtio Status in QEMU: New Bug description: I just tested qemu (with kvm) with an iscsi disk using libiscsi. I tried to install Ubuntu 12.04 as guest and when it comes to the disk configuration during the installation qemu crashes without any notice. No log, no dump. In the log of the iscsi-target I found this: iscsi-scst: ***ERROR***: Connection with initiator iqn.2013-06.de.test:testsrv01 unexpectedly closed! qemu version 1.5.0 libiscsi version 1.9.0 Host OS: Ubuntu 12.04 with 13.04-Kernel (3.8) iSCSI-target: SCST 2.2.x qemu command line: /usr/bin/kvm ... -drive file=iscsi://192.168.x.x/iqn.2006-10.de.test:test/0,if=virtio,bus=0,unit=0,cache=none,media=disk,aio=native -iscsi initiator-name=iqn.2013-06.de.test:testsrv01,header-digest=CRC32C-NONE ... When choosing IDE instead of VIRTIO it doesn't crash when scanning the disks... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1191606/+subscriptions ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-16 23:48 [Qemu-devel] [Bug 1191606] [NEW] qemu crashes with iscsi initiator (libiscsi) when using virtio Klaus Hochlehnert @ 2013-06-16 23:54 ` Klaus Hochlehnert 2013-06-17 13:02 ` [Qemu-devel] [Bug 1191606] [NEW] " Stefan Hajnoczi ` (5 subsequent siblings) 6 siblings, 0 replies; 19+ messages in thread From: Klaus Hochlehnert @ 2013-06-16 23:54 UTC (permalink / raw) To: qemu-devel ** Description changed: - Hi, - I just tested qemu (with kvm) with an iscsi disk using libiscsi. I tried to install Ubuntu 12.04 as guest and when it comes to the disk configuration during the installation qemu crashes without any notice. No log, no dump. In the log of the iscsi-target I found this: iscsi-scst: ***ERROR***: Connection with initiator iqn.2013-06.de.test:testsrv01 unexpectedly closed! qemu version 1.5.0 libiscsi version 1.9.0 Host OS: Ubuntu 12.04 with 13.04-Kernel (3.8) iSCSI-target: SCST 2.2.x qemu command line: /usr/bin/kvm ... -drive file=iscsi://192.168.x.x/iqn.2006-10.de.test:test/0,if=virtio,bus=0,unit=0,cache=none,media=disk,aio=native -iscsi initiator-name=iqn.2013-06.de.test:testsrv01,header-digest=CRC32C-NONE ... - - When choosing IDE instead of VIRTIO it doesn't crash when scanning the disks... - - Thanks, Klaus + When choosing IDE instead of VIRTIO it doesn't crash when scanning the + disks... -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1191606 Title: qemu crashes with iscsi initiator (libiscsi) when using virtio Status in QEMU: New Bug description: I just tested qemu (with kvm) with an iscsi disk using libiscsi. I tried to install Ubuntu 12.04 as guest and when it comes to the disk configuration during the installation qemu crashes without any notice. No log, no dump. In the log of the iscsi-target I found this: iscsi-scst: ***ERROR***: Connection with initiator iqn.2013-06.de.test:testsrv01 unexpectedly closed! qemu version 1.5.0 libiscsi version 1.9.0 Host OS: Ubuntu 12.04 with 13.04-Kernel (3.8) iSCSI-target: SCST 2.2.x qemu command line: /usr/bin/kvm ... -drive file=iscsi://192.168.x.x/iqn.2006-10.de.test:test/0,if=virtio,bus=0,unit=0,cache=none,media=disk,aio=native -iscsi initiator-name=iqn.2013-06.de.test:testsrv01,header-digest=CRC32C-NONE ... When choosing IDE instead of VIRTIO it doesn't crash when scanning the disks... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1191606/+subscriptions ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Qemu-devel] [Bug 1191606] [NEW] qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-16 23:48 [Qemu-devel] [Bug 1191606] [NEW] qemu crashes with iscsi initiator (libiscsi) when using virtio Klaus Hochlehnert 2013-06-16 23:54 ` [Qemu-devel] [Bug 1191606] " Klaus Hochlehnert @ 2013-06-17 13:02 ` Stefan Hajnoczi 2013-06-17 17:37 ` [Qemu-devel] [Bug 1191606] " Klaus Hochlehnert ` (4 subsequent siblings) 6 siblings, 0 replies; 19+ messages in thread From: Stefan Hajnoczi @ 2013-06-17 13:02 UTC (permalink / raw) To: Klaus Hochlehnert; +Cc: qemu-devel, ronniesahlberg On Sun, Jun 16, 2013 at 11:48:27PM -0000, Klaus Hochlehnert wrote: > Public bug reported: > > I just tested qemu (with kvm) with an iscsi disk using libiscsi. > > I tried to install Ubuntu 12.04 as guest and when it comes to the disk > configuration during the installation qemu crashes without any notice. > No log, no dump. > > In the log of the iscsi-target I found this: > iscsi-scst: ***ERROR***: Connection with initiator iqn.2013-06.de.test:testsrv01 unexpectedly closed! > > qemu version 1.5.0 > libiscsi version 1.9.0 > Host OS: Ubuntu 12.04 with 13.04-Kernel (3.8) > iSCSI-target: SCST 2.2.x > > qemu command line: > /usr/bin/kvm ... -drive file=iscsi://192.168.x.x/iqn.2006-10.de.test:test/0,if=virtio,bus=0,unit=0,cache=none,media=disk,aio=native -iscsi initiator-name=iqn.2013-06.de.test:testsrv01,header-digest=CRC32C-NONE ... > > When choosing IDE instead of VIRTIO it doesn't crash when scanning the > disks... CCing Ronnie Sahlberg (libiscsi) Can you run /usr/bin/kvm under gdb and post the backtrace? Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-16 23:48 [Qemu-devel] [Bug 1191606] [NEW] qemu crashes with iscsi initiator (libiscsi) when using virtio Klaus Hochlehnert 2013-06-16 23:54 ` [Qemu-devel] [Bug 1191606] " Klaus Hochlehnert 2013-06-17 13:02 ` [Qemu-devel] [Bug 1191606] [NEW] " Stefan Hajnoczi @ 2013-06-17 17:37 ` Klaus Hochlehnert 2013-06-18 9:38 ` Stefan Hajnoczi 2013-06-18 18:01 ` Klaus Hochlehnert ` (3 subsequent siblings) 6 siblings, 1 reply; 19+ messages in thread From: Klaus Hochlehnert @ 2013-06-17 17:37 UTC (permalink / raw) To: qemu-devel Without debug information I just can provide this (on that server I can't recompile qemu with debugging information): warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffe67fe000 0x00007f1bca857313 in poll () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) c Continuing. [New Thread 0x7f1bb9a64700 (LWP 36180)] [Thread 0x7f1bb9a64700 (LWP 36180) exited] [New Thread 0x7f1bb9a64700 (LWP 36181)] [Thread 0x7f1bb9a64700 (LWP 36181) exited] [New Thread 0x7f1bb9a64700 (LWP 36207)] Program received signal SIGABRT, Aborted. 0x00007f1bca7a5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) c Continuing. [Thread 0x7f1bd023b940 (LWP 36119) exited] [Thread 0x7f1bb9a64700 (LWP 36207) exited] [Thread 0x7f1bc1e3c700 (LWP 36132) exited] [Thread 0x7f1bbafff700 (LWP 36135) exited] Program terminated with signal SIGABRT, Aborted. The program no longer exists. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1191606 Title: qemu crashes with iscsi initiator (libiscsi) when using virtio Status in QEMU: New Bug description: I just tested qemu (with kvm) with an iscsi disk using libiscsi. I tried to install Ubuntu 12.04 as guest and when it comes to the disk configuration during the installation qemu crashes without any notice. No log, no dump. In the log of the iscsi-target I found this: iscsi-scst: ***ERROR***: Connection with initiator iqn.2013-06.de.test:testsrv01 unexpectedly closed! qemu version 1.5.0 libiscsi version 1.9.0 Host OS: Ubuntu 12.04 with 13.04-Kernel (3.8) iSCSI-target: SCST 2.2.x qemu command line: /usr/bin/kvm ... -drive file=iscsi://192.168.x.x/iqn.2006-10.de.test:test/0,if=virtio,bus=0,unit=0,cache=none,media=disk,aio=native -iscsi initiator-name=iqn.2013-06.de.test:testsrv01,header-digest=CRC32C-NONE ... When choosing IDE instead of VIRTIO it doesn't crash when scanning the disks... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1191606/+subscriptions ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-17 17:37 ` [Qemu-devel] [Bug 1191606] " Klaus Hochlehnert @ 2013-06-18 9:38 ` Stefan Hajnoczi 2013-06-18 12:26 ` Laszlo Ersek 0 siblings, 1 reply; 19+ messages in thread From: Stefan Hajnoczi @ 2013-06-18 9:38 UTC (permalink / raw) To: Klaus Hochlehnert; +Cc: qemu-devel On Mon, Jun 17, 2013 at 05:37:57PM -0000, Klaus Hochlehnert wrote: > Without debug information I just can provide this (on that server I > can't recompile qemu with debugging information): > > warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffe67fe000 > 0x00007f1bca857313 in poll () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) c > Continuing. > [New Thread 0x7f1bb9a64700 (LWP 36180)] > [Thread 0x7f1bb9a64700 (LWP 36180) exited] > [New Thread 0x7f1bb9a64700 (LWP 36181)] > [Thread 0x7f1bb9a64700 (LWP 36181) exited] > [New Thread 0x7f1bb9a64700 (LWP 36207)] > > Program received signal SIGABRT, Aborted. > 0x00007f1bca7a5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 The program invoked abort(3). This is a deliberate fatal error case. If you're using distro packages, please do the backtrace without symbols ("bt" and "info proc mappings") when gdb stops with SIGABRT and post the package version and distro you are using. Then I'll download the debuginfo packages from the distro and look up the symbols manually. If you're using a QEMU built from source then I would need the symbols from you. Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-18 9:38 ` Stefan Hajnoczi @ 2013-06-18 12:26 ` Laszlo Ersek 2013-06-18 14:37 ` Stefan Hajnoczi 0 siblings, 1 reply; 19+ messages in thread From: Laszlo Ersek @ 2013-06-18 12:26 UTC (permalink / raw) To: Stefan Hajnoczi; +Cc: Klaus Hochlehnert, qemu-devel On 06/18/13 11:38, Stefan Hajnoczi wrote: > On Mon, Jun 17, 2013 at 05:37:57PM -0000, Klaus Hochlehnert wrote: >> Without debug information I just can provide this (on that server I >> can't recompile qemu with debugging information): >> >> warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffe67fe000 >> 0x00007f1bca857313 in poll () from /lib/x86_64-linux-gnu/libc.so.6 >> (gdb) c >> Continuing. >> [New Thread 0x7f1bb9a64700 (LWP 36180)] >> [Thread 0x7f1bb9a64700 (LWP 36180) exited] >> [New Thread 0x7f1bb9a64700 (LWP 36181)] >> [Thread 0x7f1bb9a64700 (LWP 36181) exited] >> [New Thread 0x7f1bb9a64700 (LWP 36207)] >> >> Program received signal SIGABRT, Aborted. >> 0x00007f1bca7a5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > > The program invoked abort(3). This is a deliberate fatal error case. > > If you're using distro packages, please do the backtrace without symbols > ("bt" and "info proc mappings") when gdb stops with SIGABRT and post the > package version and distro you are using. > > Then I'll download the debuginfo packages from the distro and look up > the symbols manually. > > If you're using a QEMU built from source then I would need the symbols > from you. Yes. Yesterday I started responding to this report along the same lines -- SIGABRT + raise() is assert() or abort(), but there was no error message, hence abort(). Also, the reporter said in the opening comment that he used Host OS: Ubuntu 12.04 with 13.04-Kernel (3.8) which does ship a debuginfo package for qemu-kvm ("qemu-kvm-dbgsym"), just some extra repos are needed: https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages Thus I wanted to recommend the reporter to install the debuginfo package and reproduce the crash (as this would not require him to rebuild anything). And that's when I noticed qemu version 1.5.0 (which is not Ubuntu's pristine version in the 12.04 release, ie. it's probably a manual build), *with* on that server I can't recompile qemu with debugging information and decided it was a lost cause and deleted my email. Cheers, Laszlo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-18 12:26 ` Laszlo Ersek @ 2013-06-18 14:37 ` Stefan Hajnoczi 0 siblings, 0 replies; 19+ messages in thread From: Stefan Hajnoczi @ 2013-06-18 14:37 UTC (permalink / raw) To: Laszlo Ersek; +Cc: Klaus Hochlehnert, qemu-devel On Tue, Jun 18, 2013 at 02:26:19PM +0200, Laszlo Ersek wrote: > On 06/18/13 11:38, Stefan Hajnoczi wrote: > > On Mon, Jun 17, 2013 at 05:37:57PM -0000, Klaus Hochlehnert wrote: > >> Without debug information I just can provide this (on that server I > >> can't recompile qemu with debugging information): > >> > >> warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fffe67fe000 > >> 0x00007f1bca857313 in poll () from /lib/x86_64-linux-gnu/libc.so.6 > >> (gdb) c > >> Continuing. > >> [New Thread 0x7f1bb9a64700 (LWP 36180)] > >> [Thread 0x7f1bb9a64700 (LWP 36180) exited] > >> [New Thread 0x7f1bb9a64700 (LWP 36181)] > >> [Thread 0x7f1bb9a64700 (LWP 36181) exited] > >> [New Thread 0x7f1bb9a64700 (LWP 36207)] > >> > >> Program received signal SIGABRT, Aborted. > >> 0x00007f1bca7a5425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > > > > The program invoked abort(3). This is a deliberate fatal error case. > > > > If you're using distro packages, please do the backtrace without symbols > > ("bt" and "info proc mappings") when gdb stops with SIGABRT and post the > > package version and distro you are using. > > > > Then I'll download the debuginfo packages from the distro and look up > > the symbols manually. > > > > If you're using a QEMU built from source then I would need the symbols > > from you. > > Yes. Yesterday I started responding to this report along the same lines > -- SIGABRT + raise() is assert() or abort(), but there was no error > message, hence abort(). > > Also, the reporter said in the opening comment that he used > > Host OS: Ubuntu 12.04 with 13.04-Kernel (3.8) > > which does ship a debuginfo package for qemu-kvm ("qemu-kvm-dbgsym"), > just some extra repos are needed: > > https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages > > Thus I wanted to recommend the reporter to install the debuginfo package > and reproduce the crash (as this would not require him to rebuild anything). > > And that's when I noticed > > qemu version 1.5.0 > > (which is not Ubuntu's pristine version in the 12.04 release, ie. it's > probably a manual build), *with* > > on that server I can't recompile qemu with debugging information > > and decided it was a lost cause and deleted my email. I don't think it's a lost cause, we can figure it out but effort will be required on all sides. Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-16 23:48 [Qemu-devel] [Bug 1191606] [NEW] qemu crashes with iscsi initiator (libiscsi) when using virtio Klaus Hochlehnert ` (2 preceding siblings ...) 2013-06-17 17:37 ` [Qemu-devel] [Bug 1191606] " Klaus Hochlehnert @ 2013-06-18 18:01 ` Klaus Hochlehnert 2013-06-18 19:36 ` Laszlo Ersek 2013-06-24 19:46 ` Laszlo Ersek (Red Hat) ` (2 subsequent siblings) 6 siblings, 1 reply; 19+ messages in thread From: Klaus Hochlehnert @ 2013-06-18 18:01 UTC (permalink / raw) To: qemu-devel I'll see what I can do to recompile qemu with debugging information. Maybe tomorrow. But one other question. I thought this is the "normal" qemu bug reporting or is it Ubuntu only? I tried with the latest release and followed the "Report a bug"-link from the qemu web site. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1191606 Title: qemu crashes with iscsi initiator (libiscsi) when using virtio Status in QEMU: New Bug description: I just tested qemu (with kvm) with an iscsi disk using libiscsi. I tried to install Ubuntu 12.04 as guest and when it comes to the disk configuration during the installation qemu crashes without any notice. No log, no dump. In the log of the iscsi-target I found this: iscsi-scst: ***ERROR***: Connection with initiator iqn.2013-06.de.test:testsrv01 unexpectedly closed! qemu version 1.5.0 libiscsi version 1.9.0 Host OS: Ubuntu 12.04 with 13.04-Kernel (3.8) iSCSI-target: SCST 2.2.x qemu command line: /usr/bin/kvm ... -drive file=iscsi://192.168.x.x/iqn.2006-10.de.test:test/0,if=virtio,bus=0,unit=0,cache=none,media=disk,aio=native -iscsi initiator-name=iqn.2013-06.de.test:testsrv01,header-digest=CRC32C-NONE ... When choosing IDE instead of VIRTIO it doesn't crash when scanning the disks... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1191606/+subscriptions ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-18 18:01 ` Klaus Hochlehnert @ 2013-06-18 19:36 ` Laszlo Ersek 2013-06-19 4:34 ` ronnie sahlberg 0 siblings, 1 reply; 19+ messages in thread From: Laszlo Ersek @ 2013-06-18 19:36 UTC (permalink / raw) To: Bug 1191606; +Cc: qemu-devel On 06/18/13 20:01, Klaus Hochlehnert wrote: > I'll see what I can do to recompile qemu with debugging information. > Maybe tomorrow. > > But one other question. I thought this is the "normal" qemu bug > reporting or is it Ubuntu only? I tried with the latest release and > followed the "Report a bug"-link from the qemu web site. The tracker on launchpad is for upstream bugs, AFAIK. I only referred to Ubuntu because that was your host OS and because for a while I wasn't aware that your qemu version was independent from your host OS. The main thing is the debug symbols. Since for a while I was assuming that you had run into the abort() with your distro's qemu package, I tried to help with your distro's debug symbols for qemu. Thanks Laszlo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-18 19:36 ` Laszlo Ersek @ 2013-06-19 4:34 ` ronnie sahlberg 2013-06-19 8:54 ` Stefan Hajnoczi 2013-06-19 9:17 ` Laszlo Ersek 0 siblings, 2 replies; 19+ messages in thread From: ronnie sahlberg @ 2013-06-19 4:34 UTC (permalink / raw) To: Laszlo Ersek; +Cc: Bug 1191606, qemu-devel I can reproduce with current QEMU. Ubuntu 13 crashes with if=virtio but if=ide is fine. But it seems dependent on the guest/kernel. For example Fedora-18-x86_64-Live-Desktop.iso installs and runs just fine, even with virtio But both ubuntu-12.04-desktop-amd64.iso or ubuntu-13.04-desktop-amd64.iso crash with if=virtio Stack backtrace I got is #0 0x00007f7a9e22d037 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007f7a9e230698 in __GI_abort () at abort.c:90 #2 0x00007f7aa0a93ec8 in qemu_ram_addr_from_host_nofail ( ptr=ptr@entry=0x2020202024008000) at /DATA/SRC/qemu-kvm/qemu/exec.c:1399 #3 0x00007f7aa0a94a50 in address_space_unmap (as=<optimised out>, buffer=0x2020202024008000, len=<optimised out>, is_write=<optimised out>, access_len=1) at /DATA/SRC/qemu-kvm/qemu/exec.c:2155 #4 0x00007f7aa0a94bef in cpu_physical_memory_unmap (buffer=<optimised out>, len=<optimised out>, is_write=<optimised out>, access_len=<optimised out>) at /DATA/SRC/qemu-kvm/qemu/exec.c:2189 #5 0x00007f7aa0ad7867 in virtqueue_fill (vq=vq@entry=0x7f7aa34277f0, elem=elem@entry=0x7f7aa37ca328, len=1, idx=idx@entry=0) at /DATA/SRC/qemu-kvm/qemu/hw/virtio/virtio.c:243 #6 0x00007f7aa0ad79cf in virtqueue_push (vq=0x7f7aa34277f0, elem=elem@entry=0x7f7aa37ca328, len=<optimised out>) at /DATA/SRC/qemu-kvm/qemu/hw/virtio/virtio.c:279 #7 0x00007f7aa0aa9989 in virtio_blk_req_complete ( req=req@entry=0x7f7aa37ca320, status=status@entry=0) at /DATA/SRC/qemu-kvm/qemu/hw/block/virtio-blk.c:49 #8 0x00007f7aa0aa9ffb in virtio_blk_handle_request ( req=req@entry=0x7f7aa37ca320, mrb=mrb@entry=0x7fff7a7b2060) at /DATA/SRC/qemu-kvm/qemu/hw/block/virtio-blk.c:376 ---Type <return> to continue, or q <return> to quit--- #9 0x00007f7aa0aaa625 in virtio_blk_handle_output (vdev=<optimised out>, vq=<optimised out>) at /DATA/SRC/qemu-kvm/qemu/hw/block/virtio-blk.c:412 #10 0x00007f7aa0a17c0e in qemu_iohandler_poll (pollfds=0x7f7aa335f800, ret=ret@entry=1) at iohandler.c:143 #11 0x00007f7aa0a181a6 in main_loop_wait (nonblocking=<optimised out>) at main-loop.c:466 #12 0x00007f7aa08f6fb9 in main_loop () at vl.c:2028 #13 main (argc=<optimised out>, argv=<optimised out>, envp=<optimised out>) at vl.c:4425 On Tue, Jun 18, 2013 at 12:36 PM, Laszlo Ersek <lersek@redhat.com> wrote: > On 06/18/13 20:01, Klaus Hochlehnert wrote: >> I'll see what I can do to recompile qemu with debugging information. >> Maybe tomorrow. >> >> But one other question. I thought this is the "normal" qemu bug >> reporting or is it Ubuntu only? I tried with the latest release and >> followed the "Report a bug"-link from the qemu web site. > > The tracker on launchpad is for upstream bugs, AFAIK. I only referred to > Ubuntu because that was your host OS and because for a while I wasn't > aware that your qemu version was independent from your host OS. > > The main thing is the debug symbols. Since for a while I was assuming > that you had run into the abort() with your distro's qemu package, I > tried to help with your distro's debug symbols for qemu. > > Thanks > Laszlo > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-19 4:34 ` ronnie sahlberg @ 2013-06-19 8:54 ` Stefan Hajnoczi 2013-06-19 9:17 ` Laszlo Ersek 1 sibling, 0 replies; 19+ messages in thread From: Stefan Hajnoczi @ 2013-06-19 8:54 UTC (permalink / raw) To: ronnie sahlberg; +Cc: Bug 1191606, Laszlo Ersek, qemu-devel On Tue, Jun 18, 2013 at 09:34:39PM -0700, ronnie sahlberg wrote: > I can reproduce with current QEMU. > > Ubuntu 13 crashes with if=virtio but if=ide is fine. > > > But it seems dependent on the guest/kernel. > > For example Fedora-18-x86_64-Live-Desktop.iso installs and runs just > fine, even with virtio > But both ubuntu-12.04-desktop-amd64.iso or > ubuntu-13.04-desktop-amd64.iso crash with if=virtio > > > Stack backtrace I got is The issue is not obvious to me yet but here some comments on the stack trace: > #0 0x00007f7a9e22d037 in __GI_raise (sig=sig@entry=6) > at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > #1 0x00007f7a9e230698 in __GI_abort () at abort.c:90 > #2 0x00007f7aa0a93ec8 in qemu_ram_addr_from_host_nofail ( > ptr=ptr@entry=0x2020202024008000) at /DATA/SRC/qemu-kvm/qemu/exec.c:1399 > #3 0x00007f7aa0a94a50 in address_space_unmap (as=<optimised out>, > buffer=0x2020202024008000, len=<optimised out>, is_write=<optimised out>, Junk buffer address. > access_len=1) at /DATA/SRC/qemu-kvm/qemu/exec.c:2155 > #4 0x00007f7aa0a94bef in cpu_physical_memory_unmap (buffer=<optimised out>, > len=<optimised out>, is_write=<optimised out>, access_len=<optimised out>) > at /DATA/SRC/qemu-kvm/qemu/exec.c:2189 > #5 0x00007f7aa0ad7867 in virtqueue_fill (vq=vq@entry=0x7f7aa34277f0, > elem=elem@entry=0x7f7aa37ca328, len=1, idx=idx@entry=0) > at /DATA/SRC/qemu-kvm/qemu/hw/virtio/virtio.c:243 Unmapping req->elem.in_sg[0] (serial number buffer). > #6 0x00007f7aa0ad79cf in virtqueue_push (vq=0x7f7aa34277f0, > elem=elem@entry=0x7f7aa37ca328, len=<optimised out>) > at /DATA/SRC/qemu-kvm/qemu/hw/virtio/virtio.c:279 > #7 0x00007f7aa0aa9989 in virtio_blk_req_complete ( > req=req@entry=0x7f7aa37ca320, status=status@entry=0) > at /DATA/SRC/qemu-kvm/qemu/hw/block/virtio-blk.c:49 > #8 0x00007f7aa0aa9ffb in virtio_blk_handle_request ( > req=req@entry=0x7f7aa37ca320, mrb=mrb@entry=0x7fff7a7b2060) > at /DATA/SRC/qemu-kvm/qemu/hw/block/virtio-blk.c:376 VIRTIO_BLK_T_GET_ID - the guest is querying the device's serial number. Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-19 4:34 ` ronnie sahlberg 2013-06-19 8:54 ` Stefan Hajnoczi @ 2013-06-19 9:17 ` Laszlo Ersek 2013-06-20 13:33 ` ronnie sahlberg 1 sibling, 1 reply; 19+ messages in thread From: Laszlo Ersek @ 2013-06-19 9:17 UTC (permalink / raw) To: ronnie sahlberg; +Cc: Bug 1191606, qemu-devel [-- Attachment #1: Type: text/plain, Size: 1956 bytes --] On 06/19/13 06:34, ronnie sahlberg wrote: > I can reproduce with current QEMU. > > Ubuntu 13 crashes with if=virtio but if=ide is fine. > > > But it seems dependent on the guest/kernel. > > For example Fedora-18-x86_64-Live-Desktop.iso installs and runs just > fine, even with virtio > But both ubuntu-12.04-desktop-amd64.iso or > ubuntu-13.04-desktop-amd64.iso crash with if=virtio > > > Stack backtrace I got is > #0 0x00007f7a9e22d037 in __GI_raise (sig=sig@entry=6) > at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > #1 0x00007f7a9e230698 in __GI_abort () at abort.c:90 > #2 0x00007f7aa0a93ec8 in qemu_ram_addr_from_host_nofail ( > ptr=ptr@entry=0x2020202024008000) at /DATA/SRC/qemu-kvm/qemu/exec.c:1399 > #3 0x00007f7aa0a94a50 in address_space_unmap (as=<optimised out>, > buffer=0x2020202024008000, len=<optimised out>, is_write=<optimised out>, > access_len=1) at /DATA/SRC/qemu-kvm/qemu/exec.c:2155 > #4 0x00007f7aa0a94bef in cpu_physical_memory_unmap (buffer=<optimised out>, > len=<optimised out>, is_write=<optimised out>, access_len=<optimised out>) > at /DATA/SRC/qemu-kvm/qemu/exec.c:2189 > #5 0x00007f7aa0ad7867 in virtqueue_fill (vq=vq@entry=0x7f7aa34277f0, > elem=elem@entry=0x7f7aa37ca328, len=1, idx=idx@entry=0) > at /DATA/SRC/qemu-kvm/qemu/hw/virtio/virtio.c:243 > #6 0x00007f7aa0ad79cf in virtqueue_push (vq=0x7f7aa34277f0, > elem=elem@entry=0x7f7aa37ca328, len=<optimised out>) > at /DATA/SRC/qemu-kvm/qemu/hw/virtio/virtio.c:279 > #7 0x00007f7aa0aa9989 in virtio_blk_req_complete ( > req=req@entry=0x7f7aa37ca320, status=status@entry=0) > at /DATA/SRC/qemu-kvm/qemu/hw/block/virtio-blk.c:49 > #8 0x00007f7aa0aa9ffb in virtio_blk_handle_request ( > req=req@entry=0x7f7aa37ca320, mrb=mrb@entry=0x7fff7a7b2060) > at /DATA/SRC/qemu-kvm/qemu/hw/block/virtio-blk.c:376 Can you try the attached patch? It will produce quite a bit of output on stderr. Thanks Laszlo [-- Attachment #2: 0001-log-map-unmap-in-virtqueue_map_sg-and-virtqueue_fill.patch --] [-- Type: text/plain, Size: 2516 bytes --] >From 18b0c531e9ff1c33cce517c308c8330dd7d33a43 Mon Sep 17 00:00:00 2001 From: Laszlo Ersek <lersek@redhat.com> Date: Wed, 19 Jun 2013 10:37:31 +0200 Subject: [PATCH] log map/unmap in virtqueue_map_sg() and virtqueue_fill(), plus blk req type Signed-off-by: Laszlo Ersek <lersek@redhat.com> --- hw/block/virtio-blk.c | 1 + hw/virtio/virtio.c | 9 +++++++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c index cf12469..14cf898 100644 --- a/hw/block/virtio-blk.c +++ b/hw/block/virtio-blk.c @@ -358,6 +358,7 @@ static void virtio_blk_handle_request(VirtIOBlockReq *req, req->in = (void *)req->elem.in_sg[req->elem.in_num - 1].iov_base; type = ldl_p(&req->out->type); + fprintf(stderr, "%s: type=0x%08" PRIx32 "\n", __FUNCTION__, type); if (type & VIRTIO_BLK_T_FLUSH) { virtio_blk_handle_flush(req, mrb); diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c index 8176c14..0af31c5 100644 --- a/hw/virtio/virtio.c +++ b/hw/virtio/virtio.c @@ -240,6 +240,9 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem, for (i = 0; i < elem->in_num; i++) { size_t size = MIN(len - offset, elem->in_sg[i].iov_len); + fprintf(stderr, "%s: unmapping hva=%p for length=%zu, " + "access_len=%zu, is_write=1\n", __FUNCTION__, + elem->in_sg[i].iov_base, elem->in_sg[i].iov_len, size); cpu_physical_memory_unmap(elem->in_sg[i].iov_base, elem->in_sg[i].iov_len, 1, size); @@ -248,6 +251,9 @@ void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem, } for (i = 0; i < elem->out_num; i++) + fprintf(stderr, "%s: unmapping hva=%p for length=access_len=%zu, " + "is_write=0\n", __FUNCTION__, elem->out_sg[i].iov_base, + elem->out_sg[i].iov_len); cpu_physical_memory_unmap(elem->out_sg[i].iov_base, elem->out_sg[i].iov_len, 0, elem->out_sg[i].iov_len); @@ -430,6 +436,9 @@ void virtqueue_map_sg(struct iovec *sg, hwaddr *addr, error_report("virtio: trying to map MMIO memory"); exit(1); } + fprintf(stderr, "%s: mapped gpa=" TARGET_FMT_plx " at hva=%p " + "for length=%" HWADDR_PRIu ", is_write=%d\n", __FUNCTION__, + addr[i], sg[i].iov_base, len, is_write); } } -- 1.7.1 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-19 9:17 ` Laszlo Ersek @ 2013-06-20 13:33 ` ronnie sahlberg 2013-06-20 14:47 ` Laszlo Ersek 0 siblings, 1 reply; 19+ messages in thread From: ronnie sahlberg @ 2013-06-20 13:33 UTC (permalink / raw) To: Laszlo Ersek; +Cc: Bug 1191606, qemu-devel http://pastebin.com/EuwZPna1 Last few thousand lines from the log with your patch. The crash happens immediately after qemu has called out to iscsi_ioctl with SG_IO to read the serial numbers vpd page. We get the reply back from the target but as soon as ioctl_cb returns we crash. If you comment out SG_IO in iscsi_ioctl then the crash does not happen (but the qemu does nto get serial number either) I will look more into it tonight. On Wed, Jun 19, 2013 at 2:17 AM, Laszlo Ersek <lersek@redhat.com> wrote: > On 06/19/13 06:34, ronnie sahlberg wrote: >> I can reproduce with current QEMU. >> >> Ubuntu 13 crashes with if=virtio but if=ide is fine. >> >> >> But it seems dependent on the guest/kernel. >> >> For example Fedora-18-x86_64-Live-Desktop.iso installs and runs just >> fine, even with virtio >> But both ubuntu-12.04-desktop-amd64.iso or >> ubuntu-13.04-desktop-amd64.iso crash with if=virtio >> >> >> Stack backtrace I got is >> #0 0x00007f7a9e22d037 in __GI_raise (sig=sig@entry=6) >> at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 >> #1 0x00007f7a9e230698 in __GI_abort () at abort.c:90 >> #2 0x00007f7aa0a93ec8 in qemu_ram_addr_from_host_nofail ( >> ptr=ptr@entry=0x2020202024008000) at /DATA/SRC/qemu-kvm/qemu/exec.c:1399 >> #3 0x00007f7aa0a94a50 in address_space_unmap (as=<optimised out>, >> buffer=0x2020202024008000, len=<optimised out>, is_write=<optimised out>, >> access_len=1) at /DATA/SRC/qemu-kvm/qemu/exec.c:2155 >> #4 0x00007f7aa0a94bef in cpu_physical_memory_unmap (buffer=<optimised out>, >> len=<optimised out>, is_write=<optimised out>, access_len=<optimised out>) >> at /DATA/SRC/qemu-kvm/qemu/exec.c:2189 >> #5 0x00007f7aa0ad7867 in virtqueue_fill (vq=vq@entry=0x7f7aa34277f0, >> elem=elem@entry=0x7f7aa37ca328, len=1, idx=idx@entry=0) >> at /DATA/SRC/qemu-kvm/qemu/hw/virtio/virtio.c:243 >> #6 0x00007f7aa0ad79cf in virtqueue_push (vq=0x7f7aa34277f0, >> elem=elem@entry=0x7f7aa37ca328, len=<optimised out>) >> at /DATA/SRC/qemu-kvm/qemu/hw/virtio/virtio.c:279 >> #7 0x00007f7aa0aa9989 in virtio_blk_req_complete ( >> req=req@entry=0x7f7aa37ca320, status=status@entry=0) >> at /DATA/SRC/qemu-kvm/qemu/hw/block/virtio-blk.c:49 >> #8 0x00007f7aa0aa9ffb in virtio_blk_handle_request ( >> req=req@entry=0x7f7aa37ca320, mrb=mrb@entry=0x7fff7a7b2060) >> at /DATA/SRC/qemu-kvm/qemu/hw/block/virtio-blk.c:376 > > Can you try the attached patch? It will produce quite a bit of output on > stderr. > > Thanks > Laszlo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-20 13:33 ` ronnie sahlberg @ 2013-06-20 14:47 ` Laszlo Ersek 2013-06-20 15:31 ` ronnie sahlberg 0 siblings, 1 reply; 19+ messages in thread From: Laszlo Ersek @ 2013-06-20 14:47 UTC (permalink / raw) To: ronnie sahlberg; +Cc: Bug 1191606, qemu-devel On 06/20/13 15:33, ronnie sahlberg wrote: > http://pastebin.com/EuwZPna1 > > Last few thousand lines from the log with your patch. > > > The crash happens immediately after qemu has called out to iscsi_ioctl > with SG_IO to read the serial numbers vpd page. > We get the reply back from the target but as soon as ioctl_cb returns we crash. > If you comment out SG_IO in iscsi_ioctl then the crash does not happen > (but the qemu does nto get serial number either) > > > I will look more into it tonight. virtqueue_map_sg: mapped gpa=00000000790a9000 at hva=0x7f0cb10a9000 for length=4, is_write=1 (out: data) virtqueue_map_sg: mapped gpa=000000007726fc70 at hva=0x7f0caf26fc70 for length=96, is_write=1 (out: sense) virtqueue_map_sg: mapped gpa=00000000764e5aa0 at hva=0x7f0cae4e5aa0 for length=16, is_write=1 (out: errors, data_len, sense_len, residual) virtqueue_map_sg: mapped gpa=00000000764e5adc at hva=0x7f0cae4e5adc for length=1, is_write=1 (out: status) virtqueue_map_sg: mapped gpa=00000000764e5a90 at hva=0x7f0cae4e5a90 for length=16, is_write=0 (in: type, ioprio, sector) virtqueue_map_sg: mapped gpa=000000007ab80578 at hva=0x7f0cb2b80578 for length=6, is_write=0 (in: cmd) virtio_blk_handle_request: type=0x00000002 virtqueue_fill: unmapping hva=0x7f0c24008000 for length=4, access_len=1, is_write=1 Bad ram pointer 0x7f0c24008000 This looks related, in virtio_blk_handle_scsi(): } else if (req->elem.in_num > 3) { /* * If we have more than 3 input segments the guest wants to actually * read data. */ hdr.dxfer_direction = SG_DXFER_FROM_DEV; hdr.iovec_count = req->elem.in_num - 3; for (i = 0; i < hdr.iovec_count; i++) hdr.dxfer_len += req->elem.in_sg[i].iov_len; hdr.dxferp = req->elem.in_sg; } else { This sets - "hdr.iovec_count" to 1, - "hdr.dxfer_len" to 4, - "hdr.dxferp" as shown above, For "struct sg_io_hdr" (which is the type of "hdr"), the typedef & documentation are in <include/scsi/sg.h>: unsigned short iovec_count; /* [i] 0 implies no scatter gather */ void __user *dxferp; /* [i], [*io] points to data transfer memory or scatter gather list */ Now what we're seeing is a corruption of "req->elem.in_sg[0].iov_base", whose address equals that of "req->elem.in_sg" (it's at offset 0 in the struct at subscript #0 in the array). virtqueue_map_sg: mapped gpa=00000000790a9000 at hva=0x7f0cb10a9000 for length=4, is_write=1 [...] virtio_blk_handle_request: type=0x00000002 virtqueue_fill: unmapping hva=0x7f0c24008000 for length=4, access_len=1, is_write=1 Bad ram pointer 0x7f0c24008000 First I don't understand how access_len can only be "1". But, in any case, if the "req->elem.in_sg[0].iov_base" pointer is stored in little-endian order, and the kernel (or iscsi_scsi_command_async()?) for whatever reason misinterprets "hdr.dxferp" to point at an actual receive buffer (instead of an iovec array), that would be consistent with the symptoms: 0x7f0cb10a9000 <--- original value of req->elem.in_sg[0].iov_base 0x7f0c24008000 <--- corrupted value ^^^^^^^^ <--- 4 low bytes overwritten by SCSI data Laszlo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-20 14:47 ` Laszlo Ersek @ 2013-06-20 15:31 ` ronnie sahlberg 2013-06-20 15:47 ` Laszlo Ersek 0 siblings, 1 reply; 19+ messages in thread From: ronnie sahlberg @ 2013-06-20 15:31 UTC (permalink / raw) To: Laszlo Ersek; +Cc: Bug 1191606, qemu-devel On Thu, Jun 20, 2013 at 7:47 AM, Laszlo Ersek <lersek@redhat.com> wrote: > On 06/20/13 15:33, ronnie sahlberg wrote: >> http://pastebin.com/EuwZPna1 >> >> Last few thousand lines from the log with your patch. >> >> >> The crash happens immediately after qemu has called out to iscsi_ioctl >> with SG_IO to read the serial numbers vpd page. >> We get the reply back from the target but as soon as ioctl_cb returns we crash. >> If you comment out SG_IO in iscsi_ioctl then the crash does not happen >> (but the qemu does nto get serial number either) >> >> >> I will look more into it tonight. > > virtqueue_map_sg: mapped gpa=00000000790a9000 at hva=0x7f0cb10a9000 for length=4, is_write=1 (out: data) > virtqueue_map_sg: mapped gpa=000000007726fc70 at hva=0x7f0caf26fc70 for length=96, is_write=1 (out: sense) > virtqueue_map_sg: mapped gpa=00000000764e5aa0 at hva=0x7f0cae4e5aa0 for length=16, is_write=1 (out: errors, data_len, sense_len, residual) > virtqueue_map_sg: mapped gpa=00000000764e5adc at hva=0x7f0cae4e5adc for length=1, is_write=1 (out: status) > virtqueue_map_sg: mapped gpa=00000000764e5a90 at hva=0x7f0cae4e5a90 for length=16, is_write=0 (in: type, ioprio, sector) > virtqueue_map_sg: mapped gpa=000000007ab80578 at hva=0x7f0cb2b80578 for length=6, is_write=0 (in: cmd) > virtio_blk_handle_request: type=0x00000002 > virtqueue_fill: unmapping hva=0x7f0c24008000 for length=4, access_len=1, is_write=1 > Bad ram pointer 0x7f0c24008000 > > This looks related, in virtio_blk_handle_scsi(): > > } else if (req->elem.in_num > 3) { > /* > * If we have more than 3 input segments the guest wants to actually > * read data. > */ > hdr.dxfer_direction = SG_DXFER_FROM_DEV; > hdr.iovec_count = req->elem.in_num - 3; > for (i = 0; i < hdr.iovec_count; i++) > hdr.dxfer_len += req->elem.in_sg[i].iov_len; > > hdr.dxferp = req->elem.in_sg; > } else { > > This sets > - "hdr.iovec_count" to 1, > - "hdr.dxfer_len" to 4, > - "hdr.dxferp" as shown above, > > For "struct sg_io_hdr" (which is the type of "hdr"), the typedef & > documentation are in <include/scsi/sg.h>: > > unsigned short iovec_count; /* [i] 0 implies no scatter gather */ > > void __user *dxferp; /* [i], [*io] points to data transfer memory > or scatter gather list */ > > Now what we're seeing is a corruption of "req->elem.in_sg[0].iov_base", > whose address equals that of "req->elem.in_sg" (it's at offset 0 in the > struct at subscript #0 in the array). > > virtqueue_map_sg: mapped gpa=00000000790a9000 at hva=0x7f0cb10a9000 for length=4, is_write=1 > [...] > virtio_blk_handle_request: type=0x00000002 > virtqueue_fill: unmapping hva=0x7f0c24008000 for length=4, access_len=1, is_write=1 > Bad ram pointer 0x7f0c24008000 > > First I don't understand how access_len can only be "1". But, in any > case, if the "req->elem.in_sg[0].iov_base" pointer is stored in > little-endian order, and the kernel (or iscsi_scsi_command_async()?) for > whatever reason misinterprets "hdr.dxferp" to point at an actual receive > buffer (instead of an iovec array), that would be consistent with the > symptoms: Ah, that makes sense. block.iscsi.c (https://github.com/qemu/qemu/blob/master/block/iscsi.c) does assume that ioh->dxferp is a pointer to the buffer and that there is no scatter gather. See lines 745-749. I did not know that ioctl() could take a scatter/gather list. I cant test now but if I understand right then lines 745-749 should be replaced with something that does * check ioh->iovec_count IF if it zero then there is no scatter gather and ioh->dxferp points to a buffer, so just do what we do today. * IF iovec_count is > 0 then dxferp is NOT a pointer to a buffer but a pointer to an array of iovec then traverse the iovec array and add these as buffers to the task just like we do for readv. For example similar to the loop to add the iovecs in lines 449-453 I will try this tonight. > > 0x7f0cb10a9000 <--- original value of req->elem.in_sg[0].iov_base > 0x7f0c24008000 <--- corrupted value > ^^^^^^^^ <--- 4 low bytes overwritten by SCSI data > > Laszl ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-20 15:31 ` ronnie sahlberg @ 2013-06-20 15:47 ` Laszlo Ersek 0 siblings, 0 replies; 19+ messages in thread From: Laszlo Ersek @ 2013-06-20 15:47 UTC (permalink / raw) To: ronnie sahlberg; +Cc: Bug 1191606, qemu-devel On 06/20/13 17:31, ronnie sahlberg wrote: > On Thu, Jun 20, 2013 at 7:47 AM, Laszlo Ersek <lersek@redhat.com> wrote: >> First I don't understand how access_len can only be "1". But, in any >> case, if the "req->elem.in_sg[0].iov_base" pointer is stored in >> little-endian order, and the kernel (or iscsi_scsi_command_async()?) for >> whatever reason misinterprets "hdr.dxferp" to point at an actual receive >> buffer (instead of an iovec array), that would be consistent with the >> symptoms: > > Ah, that makes sense. > > block.iscsi.c (https://github.com/qemu/qemu/blob/master/block/iscsi.c) > does assume that ioh->dxferp is a pointer to the buffer and that there > is no scatter gather. > See lines 745-749. How could I miss that? :) I stopped looking at the iscsi_scsi_command_async() call on line 734. Sheesh. > I did not know that ioctl() could take a scatter/gather list. > > > I cant test now but if I understand right then > lines 745-749 should be replaced with something that does > > * check ioh->iovec_count IF if it zero then there is no scatter gather > and ioh->dxferp points to a buffer, so just do what we do today. > * IF iovec_count is > 0 then dxferp is NOT a pointer to a buffer but > a pointer to an array of iovec then > traverse the iovec array and add these as buffers to the task just > like we do for readv. For example similar to the loop to add the > iovecs in lines 449-453 Seems correct to me. > > > I will try this tonight. Thanks! Laszlo ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-16 23:48 [Qemu-devel] [Bug 1191606] [NEW] qemu crashes with iscsi initiator (libiscsi) when using virtio Klaus Hochlehnert ` (3 preceding siblings ...) 2013-06-18 18:01 ` Klaus Hochlehnert @ 2013-06-24 19:46 ` Laszlo Ersek (Red Hat) 2013-09-25 6:25 ` Klaus Hochlehnert 2013-09-25 7:30 ` Paolo Bonzini 6 siblings, 0 replies; 19+ messages in thread From: Laszlo Ersek (Red Hat) @ 2013-06-24 19:46 UTC (permalink / raw) To: qemu-devel http://lists.nongnu.org/archive/html/qemu-devel/2013-06/msg03987.html ** Changed in: qemu Status: New => In Progress -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1191606 Title: qemu crashes with iscsi initiator (libiscsi) when using virtio Status in QEMU: In Progress Bug description: I just tested qemu (with kvm) with an iscsi disk using libiscsi. I tried to install Ubuntu 12.04 as guest and when it comes to the disk configuration during the installation qemu crashes without any notice. No log, no dump. In the log of the iscsi-target I found this: iscsi-scst: ***ERROR***: Connection with initiator iqn.2013-06.de.test:testsrv01 unexpectedly closed! qemu version 1.5.0 libiscsi version 1.9.0 Host OS: Ubuntu 12.04 with 13.04-Kernel (3.8) iSCSI-target: SCST 2.2.x qemu command line: /usr/bin/kvm ... -drive file=iscsi://192.168.x.x/iqn.2006-10.de.test:test/0,if=virtio,bus=0,unit=0,cache=none,media=disk,aio=native -iscsi initiator-name=iqn.2013-06.de.test:testsrv01,header-digest=CRC32C-NONE ... When choosing IDE instead of VIRTIO it doesn't crash when scanning the disks... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1191606/+subscriptions ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-16 23:48 [Qemu-devel] [Bug 1191606] [NEW] qemu crashes with iscsi initiator (libiscsi) when using virtio Klaus Hochlehnert ` (4 preceding siblings ...) 2013-06-24 19:46 ` Laszlo Ersek (Red Hat) @ 2013-09-25 6:25 ` Klaus Hochlehnert 2013-09-25 7:30 ` Paolo Bonzini 6 siblings, 0 replies; 19+ messages in thread From: Klaus Hochlehnert @ 2013-09-25 6:25 UTC (permalink / raw) To: qemu-devel I had a chance to test it again. I used qemu 1.6.0 now for this. And the installation works now for virtio and ide. Thanks for fixing this, Klaus -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1191606 Title: qemu crashes with iscsi initiator (libiscsi) when using virtio Status in QEMU: In Progress Bug description: I just tested qemu (with kvm) with an iscsi disk using libiscsi. I tried to install Ubuntu 12.04 as guest and when it comes to the disk configuration during the installation qemu crashes without any notice. No log, no dump. In the log of the iscsi-target I found this: iscsi-scst: ***ERROR***: Connection with initiator iqn.2013-06.de.test:testsrv01 unexpectedly closed! qemu version 1.5.0 libiscsi version 1.9.0 Host OS: Ubuntu 12.04 with 13.04-Kernel (3.8) iSCSI-target: SCST 2.2.x qemu command line: /usr/bin/kvm ... -drive file=iscsi://192.168.x.x/iqn.2006-10.de.test:test/0,if=virtio,bus=0,unit=0,cache=none,media=disk,aio=native -iscsi initiator-name=iqn.2013-06.de.test:testsrv01,header-digest=CRC32C-NONE ... When choosing IDE instead of VIRTIO it doesn't crash when scanning the disks... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1191606/+subscriptions ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Qemu-devel] [Bug 1191606] Re: qemu crashes with iscsi initiator (libiscsi) when using virtio 2013-06-16 23:48 [Qemu-devel] [Bug 1191606] [NEW] qemu crashes with iscsi initiator (libiscsi) when using virtio Klaus Hochlehnert ` (5 preceding siblings ...) 2013-09-25 6:25 ` Klaus Hochlehnert @ 2013-09-25 7:30 ` Paolo Bonzini 6 siblings, 0 replies; 19+ messages in thread From: Paolo Bonzini @ 2013-09-25 7:30 UTC (permalink / raw) To: qemu-devel ** Changed in: qemu Status: In Progress => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1191606 Title: qemu crashes with iscsi initiator (libiscsi) when using virtio Status in QEMU: Fix Released Bug description: I just tested qemu (with kvm) with an iscsi disk using libiscsi. I tried to install Ubuntu 12.04 as guest and when it comes to the disk configuration during the installation qemu crashes without any notice. No log, no dump. In the log of the iscsi-target I found this: iscsi-scst: ***ERROR***: Connection with initiator iqn.2013-06.de.test:testsrv01 unexpectedly closed! qemu version 1.5.0 libiscsi version 1.9.0 Host OS: Ubuntu 12.04 with 13.04-Kernel (3.8) iSCSI-target: SCST 2.2.x qemu command line: /usr/bin/kvm ... -drive file=iscsi://192.168.x.x/iqn.2006-10.de.test:test/0,if=virtio,bus=0,unit=0,cache=none,media=disk,aio=native -iscsi initiator-name=iqn.2013-06.de.test:testsrv01,header-digest=CRC32C-NONE ... When choosing IDE instead of VIRTIO it doesn't crash when scanning the disks... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1191606/+subscriptions ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2013-09-25 7:41 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-06-16 23:48 [Qemu-devel] [Bug 1191606] [NEW] qemu crashes with iscsi initiator (libiscsi) when using virtio Klaus Hochlehnert 2013-06-16 23:54 ` [Qemu-devel] [Bug 1191606] " Klaus Hochlehnert 2013-06-17 13:02 ` [Qemu-devel] [Bug 1191606] [NEW] " Stefan Hajnoczi 2013-06-17 17:37 ` [Qemu-devel] [Bug 1191606] " Klaus Hochlehnert 2013-06-18 9:38 ` Stefan Hajnoczi 2013-06-18 12:26 ` Laszlo Ersek 2013-06-18 14:37 ` Stefan Hajnoczi 2013-06-18 18:01 ` Klaus Hochlehnert 2013-06-18 19:36 ` Laszlo Ersek 2013-06-19 4:34 ` ronnie sahlberg 2013-06-19 8:54 ` Stefan Hajnoczi 2013-06-19 9:17 ` Laszlo Ersek 2013-06-20 13:33 ` ronnie sahlberg 2013-06-20 14:47 ` Laszlo Ersek 2013-06-20 15:31 ` ronnie sahlberg 2013-06-20 15:47 ` Laszlo Ersek 2013-06-24 19:46 ` Laszlo Ersek (Red Hat) 2013-09-25 6:25 ` Klaus Hochlehnert 2013-09-25 7:30 ` Paolo Bonzini
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.