Bug 729244

What happens when you try to read from the floppy after step 4, say "dir a:" in cmd?

(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.

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.

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

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.

(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

(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

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

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.

(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

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?

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.

(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

Thanks.

Please note that this needs to be fixed upstream first.

Created attachment 600264 [details]
Final patch

*** Bug 821709 has been marked as a duplicate of this bug. ***

(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.

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.

Created attachment 633637 [details]
fail to access drive A

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

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.

np, the important thing is that it works fine.

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