Bug 729244 - floppy does not show in guest after change floppy from no inserted to new file
floppy does not show in guest after change floppy from no inserted to new file
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.2
Unspecified Unspecified
low Severity medium
: rc
: ---
Assigned To: Pavel Hrdina
Virtualization Bugs
: Triaged
: 821709 (view as bug list)
Depends On:
Blocks: Rhel5KvmTier3 821709
  Show dependency treegraph
 
Reported: 2011-08-09 04:40 EDT by juzhang
Modified: 2013-02-21 02:30 EST (History)
12 users (show)

See Also:
Fixed In Version: qemu-kvm-0.12.1.2-2.302.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 651800
Environment:
Last Closed: 2013-02-21 02:30:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Quick hack to test a hypothesis on root cause (386 bytes, patch)
2012-04-13 04:26 EDT, Markus Armbruster
no flags Details | Diff
Patch commit using modified Markus's hack (1.48 KB, patch)
2012-04-19 07:54 EDT, Pavel Hrdina
no flags Details | Diff
Final patch (12.74 KB, patch)
2012-07-25 06:55 EDT, Pavel Hrdina
no flags Details | Diff
fail to access drive A (77.42 KB, image/png)
2012-10-26 01:12 EDT, Shaolong Hu
no flags Details

  None (edit)
Description juzhang 2011-08-09 04:40:38 EDT
Hit this issue with qemu-kvm-0.12.1.2-2.175.el6.x86_64

Guest:win7
+++ This bug was initially created as a clone of Bug #651800 +++

Description of problem:
Run guest without floppy in cli, and change floppy to new file when guest running, but no floppy shows on guest.

Version-Release number of selected component (if applicable):
kvm-83-207.el5

How reproducible:
100%

Steps to Reproduce:
1.run windows xp guest without floppy option
/usr/libexec/qemu-kvm  -M rhel5.6.0 -m 2G -smp 2 -name winxp -uuid 123465d2-2032-848d-bda0-de7adb149048 -boot cdn -drive file=/mnt/winxp.img,if=virtio,boot=on,bus=0,unit=0,format=qcow2,cache=off -net nic,macaddr=54:52:00:27:12:23,vlan=0,model=virtio -net tap,vlan=0,script=/etc/qemu-ifup -serial pty -parallel none -usb -usbdevice tablet   -monitor stdio   -spice host=0,ic=on,port=5937,disable-ticketing -qxl 1 -drive file=/mnt/data.img,if=virtio,format=qcow2,cache=off

2.check block info
(qemu) info block
virtio0: type=hd removable=0 file=/mnt/winxp.img ro=0 drv=qcow2
virtio1: type=hd removable=0 file=/mnt/data.img ro=0 drv=qcow2
ide1-cd0: type=cdrom removable=1 locked=0 [not inserted]
floppy0: type=floppy removable=1 locked=0 [not inserted]
sd0: type=floppy removable=1 locked=0 [not inserted]

No floppy inserted.

3.change floppy to new file
(qemu) change floppy0 /mnt/virtio-win-1.1.10-0.vfd

4. check block info again
(qemu) info block
virtio0: type=hd removable=0 file=/mnt/winxp.img ro=0 drv=qcow2
virtio1: type=hd removable=0 file=/mnt/data.img ro=0 drv=qcow2
ide1-cd0: type=cdrom removable=1 locked=0 [not inserted]
floppy0: type=floppy removable=1 locked=0 file=/mnt/virtio-win-1.1.10-0.vfd ro=0 drv=raw
sd0: type=floppy removable=1 locked=0 [not inserted]

There is new file inserted.

5. check floppy in guest
  
Actual results:
After step 5, no floppy shows as attached screenshot


Expected results:

There should floppy shows because new file inserted from qemu monitor.

Additional info:

--- Additional comment from armbru@redhat.com on 2011-01-14 10:29:14 EST ---

There is no screenshot attached.

What happens when you try to access the floppy, say "dir a:" in cmd?

If you try the same recipe with a CD-ROM, does it work?

--- Additional comment from szhou@redhat.com on 2011-01-16 22:12:01 EST ---

(In reply to comment #1)
> There is no screenshot attached.
> 
> What happens when you try to access the floppy, say "dir a:" in cmd?
> 
> If you try the same recipe with a CD-ROM, does it work?

Sorry, forget to attach screen shot. Now reproduce this bug as following:

1. start guest without floppy and cdrom
(qemu) info block
ide0-hd0: type=hd removable=0 file=/root/test/winxp.qcow2 ro=0 drv=qcow2
ide1-cd0: type=cdrom removable=1 locked=0 [not inserted]
floppy0: type=floppy removable=1 locked=0 [not inserted]
sd0: type=floppy removable=1 locked=0 [not inserted]

2. insert cdrom and floppy
(qemu) change floppy0 /usr/share/virtio-win/virtio-drivers.vfd
(qemu) change ide1-cd0 /root/WindowsXP-32.iso 
3. check block status
(qemu) info block
ide0-hd0: type=hd removable=0 file=/root/test/winxp.qcow2 ro=0 drv=qcow2
ide1-cd0: type=cdrom removable=1 locked=0 file=/root/WindowsXP-32.iso ro=0 drv=raw
floppy0: type=floppy removable=1 locked=0 file=/usr/share/virtio-win/virtio-drivers.vfd ro=0 drv=raw
sd0: type=floppy removable=1 locked=0 [not inserted]
4. check cdrom and floppy in windows guest

After step 4, we can only see cdrom but no floppy in My computer of windows guest as attached screen shot.

--- Additional comment from szhou@redhat.com on 2011-01-16 22:12:39 EST ---

Created attachment 473753 [details]
screen shot of floppy and cdrom

--- Additional comment from armbru@redhat.com on 2011-01-17 11:37:13 EST ---

We don't yet know what's behind this problem, and further investigation is needed before we can commit to fixing it.

--- Additional comment from armbru@redhat.com on 2011-08-08 11:56:45 EDT ---

Not a customer bug, no progress for 9 months, and not serious enough to justify further investigation at this stage of the RHEL cycle.  Closing WONTFIX.  If you disagree, please reopen.
Comment 2 Markus Armbruster 2011-12-02 10:15:08 EST
What happens when you try to read from the floppy after step 4, say "dir a:" in cmd?
Comment 3 FuXiangChun 2011-12-04 21:52:19 EST
(In reply to comment #2)
> What happens when you try to read from the floppy after step 4, say "dir a:" in
> cmd?

since cann't find floppy from guest, so when reading dri a: in cmd, it show below messages:

c:\Users\Administrator>dir a:
The system cannot find the path specified.

or

c:\Users\Administrator>a:
The system cannot find the path specified.
Comment 4 FuXiangChun 2011-12-04 21:56:07 EST
please ignore this message.
c:\Users\Administrator>a:
The system cannot find the path specified.

it show this message:

c:\Users\Administrator>a:
The system cannot find the drive specified.
Comment 7 Michal Novotny 2012-04-12 14:23:45 EDT
We've been investigating with Pavel (phrdina) today and it seems that issue is that the drive geometry is being guessed on the VM boot time. If there's no image, then there's no way to guess it and it fails on both VMs used for testing (both Windows XP and Fedora 16). In the F-16 dmesg log we've been able to see relevant information in both cases (after modprobe floppy) however just in the case of startup with some FDD image it was working. There was also one more line about the FDD type added to the log in comparison with boot without FDD media. Our guess is that the drive geometry is set to NO GEOMETRY AVAILABLE (meaning no drive available) rather than no media available so calling recalibrate on the drive change is the way to fix it.

Hope it helps.
Michal
Comment 9 Markus Armbruster 2012-04-13 04:26:24 EDT
Created attachment 577268 [details]
Quick hack to test a hypothesis on root cause

Looks like "empty drive" is treated exactly like "no drive" when the initial CMOS contents is computed.  I'm attaching a quick hack to test the hypothesis: it sets the drive type to 1.44MiB for empty drives.  Please test whether the patch changes anything.

Upstream code is quite different, but seems to have the same problem.
Comment 10 Michal Novotny 2012-04-16 04:47:08 EDT
(In reply to comment #9)
> Created attachment 577268 [details]
> Quick hack to test a hypothesis on root cause
> 
> Looks like "empty drive" is treated exactly like "no drive" when the initial
> CMOS contents is computed.  I'm attaching a quick hack to test the hypothesis:
> it sets the drive type to 1.44MiB for empty drives.  Please test whether the
> patch changes anything.
> 
> Upstream code is quite different, but seems to have the same problem.

That's for the hypothesis and I *think* it's valid however there should be "fd_revalidate" call. The call seems to be present there on any change when the guest is booted with the floppy image however never when guest is booted without a floppy. This is the issue for both Linux and Windows guests (tested on Windows XP and Fedora 16 x86_64 VMs).

Pavel is going to do the testing using your hack and he'll let you know however I think the right way to fix this is to make it call "fd_revalidate" on every change no matter whether there was a media present or not.

Michal
Comment 11 Michal Novotny 2012-04-16 16:27:53 EDT
(In reply to comment #10)
> (In reply to comment #9)
> > Created attachment 577268 [details]
> > Quick hack to test a hypothesis on root cause
> > 
> > Looks like "empty drive" is treated exactly like "no drive" when the initial
> > CMOS contents is computed.  I'm attaching a quick hack to test the hypothesis:
> > it sets the drive type to 1.44MiB for empty drives.  Please test whether the
> > patch changes anything.
> > 
> > Upstream code is quite different, but seems to have the same problem.
> 
> That's for the hypothesis and I *think* it's valid however there should be
> "fd_revalidate" call. The call seems to be present there on any change when the
> guest is booted with the floppy image however never when guest is booted
> without a floppy. This is the issue for both Linux and Windows guests (tested
> on Windows XP and Fedora 16 x86_64 VMs).
> 
> Pavel is going to do the testing using your hack and he'll let you know however
> I think the right way to fix this is to make it call "fd_revalidate" on every
> change no matter whether there was a media present or not.
> 
> Michal

We've been able to write a working patch with Pavel however we still need a hack to expose 1.44 MiB drive instead of no drive to the guest.

The behaviour seems to be fixed, tested for both Windows XP and Fedora 16 x86_64 guests booted up with and without the floppy media present.

Pavel will send the patch shortly :-)

Michal
Comment 12 Michal Novotny 2012-04-17 14:05:04 EDT
The issue seems to be that the controller emulation doesn't comply with the specifications.

During the investigation I've found that there are 2 different code paths in the drivers (main difference in Linux floppy driver and Windows floppy driver):

Linux floppy driver
===================

SENSE INTERRUPT STATUS
DUMPREG command
CONFIGURE command
PERPENDICULAR MODE command
LOCK command
PART ID command

[:
PERPENDICULAR MODE command
CONFIGURE command
SPECIFY command
RECALIBRATE command
:]

Windows floppy driver
=====================

SENSE INTERRUPT STATUS
VERSION command
PART ID command
PERPENDICULAR MODE command
PART ID command

[:
SENSE INTERRUPT STATUS command
SPECIFY command
RECALIBRATE command
SEEK command
:]

Both cases have been sniffed using the floppy debugging enabled on in the ISA FDC emulation code of QEMU (hw/fdc.c source file).

Based on the fact just the RECALIBRATE handling change didn't work we most likely need to change handling for both DUMPREGS and SENSE INTERRUPT STATUS as well to satisfy both Linux and Windows drivers. Also, the SEEK command handling should be changed to fulfil driver needs.

Michal
Comment 13 Markus Armbruster 2012-04-19 04:57:57 EDT
Let's not jump to conclusions.

I believe the CMOS floppy byte is initialized incorrectly when we start with an empty drive.  This may or may not be the root cause of this bug.

My hack tests this: if it makes the bug go away, the incorrect CMOS floppy byte is almost certainly the bug's root cause.  Comment#11 seems to say it does make the bug go away, but it's not 100% clear to me.  Please confirm my hack makes the bug go away.

There may be more bugs, but we really need to debug and fix one at a time to get anywhere.
Comment 14 Michal Novotny 2012-04-19 06:45:59 EDT
(In reply to comment #13)
> Let's not jump to conclusions.
> 
> I believe the CMOS floppy byte is initialized incorrectly when we start with an
> empty drive.  This may or may not be the root cause of this bug.
> 
> My hack tests this: if it makes the bug go away, the incorrect CMOS floppy byte
> is almost certainly the bug's root cause.  Comment#11 seems to say it does make
> the bug go away, but it's not 100% clear to me.  Please confirm my hack makes
> the bug go away.
> 
> There may be more bugs, but we really need to debug and fix one at a time to
> get anywhere.

Markus, we think Pavel made a working fix for this since your hack is not enough. However I need to describe the functionality by now: The initialization in fd_init() function makes not just no medium in the drive but also no drive available and then fd_revalidate() populates the drive type and medium type which is preset to FLOPPY_DRV_NONE (no drive available for the system) for case the guest is being booted up without a floppy medium.

fd_revalidate() is checking the drive for medium inserted using the bdrv_is_inserted() function and if there's a media inserted it's trying to match the desired drive type and medium type (as there could be 720 kB drive in the 1.44 MB drive).

For case the block image is not inserted (or not open) it's setting the drive type to FLOPPY_DRV_NONE meaning no disk drive exists on the system.

My recommendation is to set the default to FLOPPY_DRV_144 with the default settings to 1.44 MB medium (last_sect which is basically the key for rest of functionality to work)

We have to keep in mind that qemu-kvm could be started up with -nodefaults (or other name for this functionality to expose no default devices to the guest) so for this case the old handling of FLOPPY_DRV_NONE should be preserted. For this, the image is not being opened at all so we may need to alter the fix with some pseudocode like this:

if (!drv->bs) {
    /* No default devices should be exposed */
    preserve_old_handling();
}
else
if (!bdrv_is_inserted(drv->bs)) {
    /* The drive is present in the system however guest booted up w/o medium */
    set_drive_type(FLOPPY_DRV_144);
    set_last_sect(LAST_SECT_FOR_FLOPPY_DRV_144);
}
else
    preserve_the_rest();

This way we support both scenarios:
1) Guest booted up with -nodefaults
2) Guest booted up without floppy image but the floppy still should be visible to the guest

The rest of the scenarios are preserved as they work currently.

Michal
Comment 15 Markus Armbruster 2012-04-19 07:51:55 EDT
Thanks for the explanation of Pavel's fix.

The CMOS initialization bug needs to be fixed upstream first.  The correct way to fix it is to make the drive type a qdev property.  If we want to preserve the old behavior, the default value needs to be "examine media (if any) and guess".

I'm afraid you still haven't answered my straight question unambiguously.  So I ask it again: does my hack make the bug go away in your testing, yes or no?
Comment 16 Pavel Hrdina 2012-04-19 07:54:35 EDT
Created attachment 578623 [details]
Patch commit using modified Markus's hack

As Michal pointed out that there could be problem when you start guest 
with -nodefaults. I tested this scenario and everything was alright for both guests. Windows and Linux see only FDC but no drive is present.

That hack is needed and I think that it could be defined as default behavior if you use defaults settings for floppy.
Comment 17 Michal Novotny 2012-04-19 07:56:55 EDT
(In reply to comment #15)
> Thanks for the explanation of Pavel's fix.
> 
> The CMOS initialization bug needs to be fixed upstream first.  The correct way
> to fix it is to make the drive type a qdev property.  If we want to preserve
> the old behavior, the default value needs to be "examine media (if any) and
> guess".
> 
> I'm afraid you still haven't answered my straight question unambiguously.  So I
> ask it again: does my hack make the bug go away in your testing, yes or no?

Well, your hack basically helped a lot allowing the guest to see the drive there when guest was booted without a medium however the drive was not working correctly because the drive was present in the system as there was a medium present although it was not present so it was returning many I/O errors in a never-ending loop for the Linux guest with some errors on Windows guests as well (errors, not just the request for floppy drive insertion) so there were some other fixes needed.

That said, your hack was just one part of the patch Pavel did.

Michal
Comment 18 Markus Armbruster 2012-04-19 08:16:01 EDT
Thanks.

Please note that this needs to be fixed upstream first.
Comment 35 Pavel Hrdina 2012-07-25 06:55:55 EDT
Created attachment 600264 [details]
Final patch
Comment 36 Ademar Reis 2012-07-25 11:50:57 EDT
*** Bug 821709 has been marked as a duplicate of this bug. ***
Comment 37 Ademar Reis 2012-07-25 11:52:09 EDT
(In reply to comment #36)
> *** Bug 821709 has been marked as a duplicate of this bug. ***

Please make sure the scenario described there is tested when verifying this one.
Comment 40 Shaolong Hu 2012-10-26 01:12:09 EDT
Failed with qemu-kvm-rhev-0.12.1.2-2.331.el6.x86_64:

1. boot a win7 guest:

2. in qemu monitor:

(qemu) change floppy0 /usr/share/virtio-win/virtio-win.vfd
(qemu) info block
drive-virtio-disk0: removable=0 io-status=ok file=win7-64-virtio.qcow2 ro=0 drv=qcow2 encrypted=0
ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
floppy0: removable=1 locked=0 tray-open=0 file=/usr/share/virtio-win/virtio-win.vfd ro=0 drv=raw encrypted=0
sd0: removable=1 locked=0 tray-open=0 [not inserted]

3. in guest, fail to access drive A, screenshot in attachment.
Comment 41 Shaolong Hu 2012-10-26 01:12:52 EDT
Created attachment 633637 [details]
fail to access drive A
Comment 42 Pavel Hrdina 2012-10-30 12:07:51 EDT
Hi, I couldn't reproduce this bug. I have installed the qemu-kvm-rhev-0.12.1.2-2.331.el6.x86_64 and tested it with two different floppy images.

Could you please provide more information how you manage to produce this bug?

Pavel
Comment 43 Shaolong Hu 2012-11-22 04:46:40 EST
Sorry for late replying, i retry this with:
qemu-kvm-rhev-0.12.1.2-2.334.el6.x86_64

It works fine, i did not try 331 again to find why it fails or just my mistake, what important is it's good now, verified and sorry again for the trouble.
Comment 44 Pavel Hrdina 2012-11-22 04:48:45 EST
np, the important thing is that it works fine.
Comment 45 errata-xmlrpc 2013-02-21 02:30:55 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0527.html

Note You need to log in before you can comment on or make changes to this bug.