From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Alex <coderain@sdf.org>,
Nikolay Nikolov <nickysn@users.sourceforge.net>,
seabios@seabios.org, John Snow <jsnow@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [SeaBIOS] Re: Regression with floppy drive controller
Date: Tue, 20 Aug 2019 15:36:14 +0100 [thread overview]
Message-ID: <20190820143614.GJ2867@work-vm> (raw)
In-Reply-To: <1a45cee8-66e1-448d-78bc-4f0b9695cab4@redhat.com>
* Philippe Mathieu-Daudé (philmd@redhat.com) wrote:
> On 8/20/19 3:38 PM, Philippe Mathieu-Daudé wrote:
> > On 8/20/19 3:12 PM, John Snow wrote:
> >> On 8/20/19 6:25 AM, Philippe Mathieu-Daudé wrote:
> >>> [cross posting QEMU & SeaBIOS]
> >>>
> >>> Hello,
> >>>
> >>> I'v been looking at a QEMU bug report [1] which bisection resulted in a
> >>> SeaBIOS commit:
> >>>
> >>> 4a6dbcea3e412fe12effa2f812f50dd7eae90955 is the first bad commit
> >>> commit 4a6dbcea3e412fe12effa2f812f50dd7eae90955
> >>> Author: Nikolay Nikolov <nickysn@users.sourceforge.net>
> >>> Date: Sun Feb 4 17:27:01 2018 +0200
> >>>
> >>> floppy: Use timer_check() in floppy_wait_irq()
> >>>
> >>> Use timer_check() instead of using floppy_motor_counter in BDA for the
> >>> timeout check in floppy_wait_irq().
> >>>
> >>> The problem with using floppy_motor_counter was that, after it reaches
> >>> 0, it immediately stops the floppy motors, which is not what is
> >>> supposed to happen on real hardware. Instead, after a timeout (like in
> >>> the end of every floppy operation, regardless of the result - success,
> >>> timeout or error), the floppy motors must be kept spinning for
> >>> additional 2 seconds (the FLOPPY_MOTOR_TICKS). So, now the
> >>> floppy_motor_counter is initialized to 255 (the max value) in the
> >>> beginning of the floppy operation. For IRQ timeouts, a different
> >>> timeout is used, specified by the new FLOPPY_IRQ_TIMEOUT constant
> >>> (currently set to 5 seconds - a fairly conservative value, but should
> >>> work reliably on most floppies).
> >>>
> >>> After the floppy operation, floppy_drive_pio() resets the
> >>> floppy_motor_counter to 2 seconds (FLOPPY_MOTOR_TICKS).
> >>>
> >>> This is also consistent with what other PC BIOSes do.
> >>>
> >>>
> >>> This commit improve behavior with real hardware, so maybe QEMU is not
> >>> modelling something or modelling it incorrectly?
> > [...]
> >>
> >> Well, that's unfortunate.
> >>
> >> What version of QEMU shipped the SeaBIOS that caused the regression?
> >
> > See https://bugs.launchpad.net/qemu/+bug/1840719/comments/3
> >
> > QEMU commit 0b8f74488e, slighly before QEMU v3.1.0
> > (previous tag is v3.0.0).
> >
> > But you can use v4.1.0 too, simply change the SeaBIOS bios.bin, i.e.:
> >
> > qemu$ git checkout v4.1.0
> >
> > qemu$ (cd roms/seabios && git checkout 4a6dbcea3e4~) && \
> > make -C roms bios
> >
> > Now pc-bios/bios.bin is built using the last commit working,
> >
> > qemu$ (cd roms/seabios && git checkout 4a6dbcea3e4) && \
> > make -C roms bios
> >
> > And you can reproduce the error.
>
> Looking at the fdc timer I noticed it use a static '50 ns' magic value.
That's not 50ns
> Increasing this value allows the floppy image to boot again, using this
> snippet:
>
> -- >8 --
> diff --git a/hw/block/fdc.c b/hw/block/fdc.c
> index 9b24cb9b85..5fc54073fd 100644
> --- a/hw/block/fdc.c
> +++ b/hw/block/fdc.c
> @@ -2134,7 +2134,7 @@ static void fdctrl_handle_readid(FDCtrl *fdctrl,
> int direction)
>
> cur_drv->head = (fdctrl->fifo[1] >> 2) & 1;
> timer_mod(fdctrl->result_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
> - (NANOSECONDS_PER_SECOND / 50));
That's 1/50th of a second in ns.
> + (NANOSECONDS_PER_SECOND / 5000));
I'm not too sure about readid; but assuming we're rotating at 360rpm,
that's 6 revolutions/second, and 18 sectors/track = 108 sectors/second
(half of that for a double density disk).
So, the wait for a sector to spin around and read feels like it should
be in the region of 1/108 of a second + some latency - so 1/50th of a
second would seem to be in the ballpark or being right, where as 1/5000
of a second is way too fast for a poor old floppy.
Dave
> }
>
> static void fdctrl_handle_format_track(FDCtrl *fdctrl, int direction)
> ---
>
> Any idea what is the correct value to use here?
>
> Regards,
>
> Phil.
> _______________________________________________
> SeaBIOS mailing list -- seabios@seabios.org
> To unsubscribe send an email to seabios-leave@seabios.org
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2019-08-20 14:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-20 10:25 [Qemu-devel] Regression with floppy drive controller Philippe Mathieu-Daudé
2019-08-20 13:12 ` John Snow
2019-08-20 13:38 ` Philippe Mathieu-Daudé
2019-08-20 14:00 ` Philippe Mathieu-Daudé
2019-08-20 14:36 ` Dr. David Alan Gilbert [this message]
2019-08-20 14:54 ` [Qemu-devel] [SeaBIOS] " Philippe Mathieu-Daudé
2019-08-20 15:02 ` Philippe Mathieu-Daudé
2019-08-20 15:04 ` Dr. David Alan Gilbert
2019-08-20 16:21 ` [Qemu-devel] " Philippe Mathieu-Daudé
2019-08-20 20:37 ` Eduardo Habkost
2019-08-21 6:42 ` Gerd Hoffmann
2019-08-21 7:45 ` Paolo Bonzini
2019-08-21 13:31 ` [Qemu-devel] [SeaBIOS] " Kevin O'Connor
2019-08-22 8:32 ` Gerd Hoffmann
2019-08-22 8:42 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190820143614.GJ2867@work-vm \
--to=dgilbert@redhat.com \
--cc=coderain@sdf.org \
--cc=jsnow@redhat.com \
--cc=nickysn@users.sourceforge.net \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=seabios@seabios.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.