From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfYfz-0003YX-Aa for qemu-devel@nongnu.org; Tue, 07 Apr 2015 14:56:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfYfx-0008ET-RZ for qemu-devel@nongnu.org; Tue, 07 Apr 2015 14:56:43 -0400 Message-ID: <55242862.9020205@redhat.com> Date: Tue, 07 Apr 2015 14:56:34 -0400 From: John Snow MIME-Version: 1.0 References: <5522D4BD.7080805@kamp.de> <5522D57B.3000203@redhat.com> <5522D85D.20907@kamp.de> <5522DA21.1010702@kamp.de> <20150407084303.GA2298@work-vm> <5523F38A.4090305@kamp.de> <20150407152957.GB2287@work-vm> <55242597.1000700@kamp.de> In-Reply-To: <55242597.1000700@kamp.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-block] Migration sometimes fails with IDE and Qemu 2.2.1 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven , "Dr. David Alan Gilbert" Cc: Paolo Bonzini , "qemu-devel@nongnu.org" , qemu-block@nongnu.org On 04/07/2015 02:44 PM, Peter Lieven wrote: > Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert: >> * Peter Lieven (pl@kamp.de) wrote: >>> Hi David, >>> >>> Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert: >>>>>>> Any particular workload or reproducer? >>>>>> Workload is almost zero. I try to figure out if there is a way to trigger it. >>>>>> >>>>>> Maybe playing a role: Machine type is -M pc1.2 and we set -kvmclock as >>>>>> CPU flag since kvmclock seemed to be quite buggy in 2.6.16... >>>>>> >>>>>> Exact cmdline is: >>>>>> /usr/bin/qemu-2.2.1 -enable-kvm -M pc-1.2 -nodefaults -netdev type=tap,id=guest2,script=no,downscript=no,ifname=tap2 -device e1000,netdev=guest2,mac=52:54:00:ff:00:65 -drive format=raw,file=iscsi://172.21.200.53/iqn.2001-05.com.equallogic:4-52aed6-88a7e99a4-d9e00040fdc509a3-XXX-hd0/0,if=ide,cache=writeback,aio=native -serial null -parallel null -m 1024 -smp 2,sockets=1,cores=2,threads=1 -monitor tcp:0:4003,server,nowait -vnc :3 -qmp tcp:0:3003,server,nowait -name 'XXX' -boot order=c,once=dc,menu=off -drive index=2,media=cdrom,if=ide,cache=unsafe,aio=native,readonly=on -k de -incoming tcp:0:5003 -pidfile /var/run/qemu/vm-146.pid -mem-path /hugepages -mem-prealloc -rtc base=utc -usb -usbdevice tablet -no-hpet -vga cirrus -cpu qemu64,-kvmclock >>>>>> >>>>>> Exact kernel is: >>>>>> 2.6.16.46-0.12-smp (i think this is SLES10 or sth.) >>>>>> >>>>>> The machine does not hang. It seems just I/O is hanging. So you can type at the console or ping the system, but no longer login. >>>>>> >>>>>> Thank you, >>>>>> Peter >>>>> Interesting observation: Migrating the vServer again seems to fix to problem (at least in one case I could test just now). >>>>> >>>>> 2.6.8-24-smp is also affected. >>>> How often does it fail - you say 'sometimes' - is it a 1/10 or a 1/1000 ? >>> Its more often than 1/10 I would say. >> OK, that's not too bad - it's the 1/1000 that are really nasty to find. >> In your setup, how easy would it be for you to try : >> with either 2.1 or current head? >> with a newer machine-type? >> without the cdrom? > > Its all possible. I can clone the system and try everything on my test systems. I hope > it reproduces there. > > Has the cdrom the power of taking down the bus? > > Peter > I don't know if CDROM could stall the entire bus, but I suspect the reason for asking is this: dgilbert and I had tracked down a problem previously where during migration, outstanding requests being handled by the ATAPI code can get lost during migration if, for instance, the user has only prepared the command (via bmdma) but has not yet written to the register to activate the command yet. So if something like this happens: - User writes to the ATA registers to program a command - Migration occurs - User writes to the BMDMA register to initiate the command We can lose some of the state and data of the request. David had checked in a workaround for at least ATAPI that simply coaxes the guest OS into trying the command again to unstick it. I think we determined last time that we couldn't fix this problem without changing the migration format, so we opted not to do it for 2.3. We had also only noticed it with ATAPI drives, not HDDs, so a proper fix got kicked down the road since we thought the workaround was sufficient. IIRC our success rate with reproducing it was something on the order of 1/50, too. If you can reproduce it without a CDROM but using the BMDMA interface, that's a good data point. If you can't reproduce it using the ISA interface, that's a phenomenal data point and implicates BMDMA pretty heavily. --js