Date: Sat, 22 Sep 2007 08:50:06 GMT From: Bruce Evans <brde@optusnet.com.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/116538: [fdc] [patch] reintroduce FD_NO_CHLINE flag for fdc(4) Message-ID: <200709220850.l8M8o6Em082333@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/116538; it has been noted by GNATS.
From: Bruce Evans <brde@optusnet.com.au>
To: Eugene Grosbein <eugen@grosbein.pp.ru>
Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: kern/116538: [fdc] [patch] reintroduce FD_NO_CHLINE flag for
fdc(4)
Date: Sat, 22 Sep 2007 18:44:55 +1000 (EST)
On Sat, 22 Sep 2007, Eugene Grosbein wrote:
>> Description:
> Workaround for floppy disk drives missing media change indication
> support (FD_NO_CHLINE flag for fdc(4)) was removed in 2001 after
> media change detection was fixed in fdc(4) and believed to work
> reliably.
>
> This is no longer true these days when new motherboards
> have FDD controlles that miss Configuration Control Register,
> so fdc(4) cannot detect media change. We need FD_NO_CHLINE flag
> again until fdc(4) fixed. See commit log message for
> sys/dev/fdc/fdc.c,v.1.307.2.4 for additional details.
What happens for older FDD controllers that don't support the change
line, and hardware with a broken change line?
> Note that fdc(4) man page still mentions 0x10 flag that
> was ever used as valuse for FD_NO_CHLINE flag it does not exist
> in the code many years. More, the value 0x10 is now used by fdc(4)
> internally for other means and we need to choose another value.
No, the internal flag was always used by fdc(4), and has nothing to do
with the device flag. See my reply to your PR about broken device flags
>> Fix:
>
> --- share/man/man4/fdc.4.orig 2007-09-16 16:23:27.000000000 +0800
> +++ share/man/man4/fdc.4 2007-09-16 16:23:34.000000000 +0800
> @@ -101,7 +101,7 @@
> the driver.
> To indicate a drive that does not have the changeline support,
> this can be overridden using the per-drive device flags value of
> -.Ar 0x10
> +.Ar 0x40
> (causing each call to
> .Xr open 2
> to perform the autodetection).
This shouldn't be changed.
> @@ -98,6 +98,8 @@
> * and fd1 */
> #define FD_NO_PROBE 0x20 /* don't probe drive (seek test), just
> * assume it is there */
> +#define FD_NO_CHLINE 0x40 /* drive does not support changeline
> + * aka. unit attention */
>
> /*
> * Things that could conceiveably considered parameters or tweakables
Add it back where it was, with correct identation.
> @@ -827,7 +829,8 @@
>
> if (bp->bio_cmd & BIO_PROBE) {
>
> - if (!(fdin_rd(fdc) & FDI_DCHG) && !(fd->flags & FD_EMPTY))
> + if (!(fd->flags & FD_NO_CHLINE) &&
> + !(fdin_rd(fdc) & FDI_DCHG) && !(fd->flags & FD_EMPTY))
> return (fdc_biodone(fdc, 0));
>
> /*
>
Use a device_get_flags() call here, not quite where it was. Old code
was obfuscated by using copying the result into a local variable much
earlier, and then using the variable at most once (in the FNONBLOCK
case).
BTW, what happens with no FNONBLOCK/O_NONBLOCK in the whole driver
now? FNONBLOCK used to be used to avoid excessive probing on open.
Some opens must succeed even if the media is unreadable so that the
drive can be controlled (mainly for formatting media that is present
but not readable). cd drivers still handle this poorly, not using
O_NONBLOCK, but fd can be simpler because there is less to control
if there is no media.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200709220850.l8M8o6Em082333>