PID: 0.102 graphic: 0.095 socket: 0.095 other: 0.090 device: 0.078 semantic: 0.076 performance: 0.075 permissions: 0.073 debug: 0.063 network: 0.062 KVM: 0.052 files: 0.050 boot: 0.048 vnc: 0.041 files: 0.225 device: 0.150 PID: 0.109 socket: 0.096 debug: 0.075 boot: 0.059 KVM: 0.058 other: 0.054 semantic: 0.051 vnc: 0.039 network: 0.031 graphic: 0.019 performance: 0.017 permissions: 0.016 virtual fat do not working in qemu 1.5.0 Guest : windows Seven / XP Qemu version : 1.5.0 cmd line : -drive file=fat:floppy:/mnt/vdisk/diskconf/TEST004/,if=none,id=drive-fdc0-0-0,readonly=on generated by libvirt :
works with qemu <= 1.4.1 with qemu 1.5.0 , guest does not see the floppy content. Regards same issue with qemu 1.5.1 floopy content is seen under linux. not under Windows guest On Fri, May 31, 2013 at 03:26:47PM -0000, prochazka nicolas wrote: > Public bug reported: > > Guest : windows Seven / XP > Qemu version : 1.5.0 > cmd line : > -drive file=fat:floppy:/mnt/vdisk/diskconf/TEST004/,if=none,id=drive-fdc0-0-0,readonly=on > generated by libvirt : > > > > > > > >
> > > works with qemu <= 1.4.1 > > with qemu 1.5.0 , guest does not see the floppy content. Thanks for reporting this bug. The vvfat block driver is not actively maintained, but you can help us track down this bug: Since it used to work in QEMU 1.4.1 you could use git-bisect(1) to identify the commit that broke vvfat. http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html http://code-worrier.com/blog/git-bisect-basics/ Something along the lines of: $ git clone git://git.qemu.org/qemu.git $ cd qemu $ git bisect start $ git bisect bad master $ git bisect good v1.4.1 Then build from source and test at each bisect step: $ ./configure --target-list=x86_64-softmmu && make $ qemu -drive file=fat:floppy:... If it fails: $ git bisect bad If it succeeds: $ git bisect good At the end of the process it will tell you which commit broke vvfat. Stefan Triaging old bug tickets... Have you ever bisected the problem? Can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? [Expired for QEMU because there has been no activity for 60 days.]