From owner-freebsd-bugs@FreeBSD.ORG Sat Sep 22 08:50:08 2007 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C834116A41A for ; Sat, 22 Sep 2007 08:50:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AB85913C469 for ; Sat, 22 Sep 2007 08:50:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8M8o6dt082334 for ; Sat, 22 Sep 2007 08:50:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8M8o6Em082333; Sat, 22 Sep 2007 08:50:06 GMT (envelope-from gnats) Date: Sat, 22 Sep 2007 08:50:06 GMT Message-Id: <200709220850.l8M8o6Em082333@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Bruce Evans Cc: Subject: Re: kern/116538: [fdc] [patch] reintroduce FD_NO_CHLINE flag for fdc(4) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2007 08:50:09 -0000 The following reply was made to PR kern/116538; it has been noted by GNATS. From: Bruce Evans To: Eugene Grosbein 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