On Fri, Oct 28, 2011 at 09:46:33AM -0200, Lucas Meneghel Rodrigues wrote: > On 10/27/2011 11:17 PM, Zhi Yong Wu wrote: > >On Fri, Oct 28, 2011 at 2:57 AM, Lucas Meneghel Rodrigues > ><lmr@xxxxxxxxxx> wrote: > >>On 10/27/2011 05:17 AM, Stefan Hajnoczi wrote: > >>> > >>>On Wed, Oct 26, 2011 at 03:19:17PM -0200, Lucas Meneghel Rodrigues wrote: > >>>> > >>>>On 10/26/2011 01:47 PM, Kevin Wolf wrote: > >>>>> > >>>>>Am 26.10.2011 16:41, schrieb Lucas Meneghel Rodrigues: > >>>>>> > >>>>>>Hi folks: > >>>>>> > >>>>>>We've captured a regression with floppy disk on recent qemu (and > >>>>>>qemu-kvm, after a code merge). We bisected it to be caused by: > >>>>>> > >>>>>>commit 212ec7baa28cc9d819234fed1541fc1423cfe3d8 > >>>>>>Author: Richard Henderson<rth@xxxxxxxxxxx> > >>>>>>Date: Mon Aug 15 15:08:45 2011 -0700 > >>>>>> > >>>>>> fdc: Convert to isa_register_portio_list > >>>>>> > >>>>>> Signed-off-by: Richard Henderson<rth@xxxxxxxxxxx> > >>>>>> Signed-off-by: Avi Kivity<avi@xxxxxxxxxx> > >>>>>> > >>>>>>Since this commit, the guest doesn't see a floppy disk attached to it > >>>>>>anymore, blocking kvm autotest ability to install windows guests > >>>>>>automatically. This is a big deal for kvm autotest (ruins our automated > >>>>>>regression jobs), so please take a look at it. > >>>>> > >>>>>Can you please try again with the latest block branch? I think there is > >>>>>a patch queued that will fix it. > >>>> > >>>>Kevin, I did try with HEAD of your repo: > >>>> > >>>>git://repo.or.cz/qemu/kevin.git > >>>> > >>>>[lmr@freedom qemu-kwolf]$ git branch -r > >>>> origin/HEAD -> origin/master > >>>> origin/blkqueue > >>>> origin/blkqueue-v1 > >>>> origin/block > >>>> origin/coroutine > >>>> origin/coroutine-block > >>>> origin/coroutine-devel > >>>> origin/devel > >>>> origin/ehci > >>>> origin/for-anthony > >>>> origin/for-stable-0.14 > >>>> origin/inplace-conversion > >>>> origin/master > >>>> > >>>>With this repo, master branch, the problem persists. With the block > >>>>branch, the problem persists. > >>>> > >>>>Now, with the blkqueue branch the problem is resolved. Cleber had > >>>>the same results booting a FreeDOS floppy. So the fix is indeed in > >>>>blkqueue. > >>>> > >>>>Oh, you might want to check the blkqueue branch, it does have quite > >>>>a bunch of set but unused variables, which will cause compilation > >>>>errors unless --disable-werror is passed to the configure script. > >>> > >>>I think blkqueue is an older development branch of the "block queue" > >>>feature that Kevin was working on. It is not Kevin's block tree (see > >>>his "block" branch). > >> > >>So no, the block branch does not resolve the floppy access problem. > >> > >>Well, considering the tests of the stable set I'm running against qemu right > >>now, this is not the biggest of our problems... I'm verifying qemu is > >>segfaulting on nearly every prolonged attempt of doing migration... I'm > >>about to write an email about it. > >What is the OS of your guest? fedora16 or RHEL6? I would like recently > >to use floppy device in guest. > > Ok, correcting my answer, it was Windows 7 SP1. For some reason, I > read 'host' instead of guest. I had a long day when I wrote the 1st > reply. > > It's been a while that we've verified that the linux floppy driver > is quite unstable. In general linux + floppy devices on a guest > tends to crash the guest kernel, and that's why in kvm autotest we > moved from floppy devices to cdroms to hold the kickstart file. The > fact you managed to get things working under F14 means you are > lucky, and that particular floppy driver bug does not happen under > F14's kernel. We never had such a kernel crash problem with any of > the Windows's kernels. > > So if I were you, I would *not* use a floppy with a linux guest. > Well, unless you want to debug the floppy driver bug and fix this on > upstream linux once for all, so future versions of linux won't have > this problem. AFAIK the problem exists only on smp guest. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
