From owner-freebsd-hackers Sat Sep 13 15:07:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA02593 for hackers-outgoing; Sat, 13 Sep 1997 15:07:27 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA02588 for ; Sat, 13 Sep 1997 15:07:23 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id PAA29890; Sat, 13 Sep 1997 15:07:11 -0700 (MST) From: Terry Lambert Message-Id: <199709132207.PAA29890@usr03.primenet.com> Subject: Re: Do *you* have problems with floppies? To: grog@lemis.com (Greg Lehey) Date: Sat, 13 Sep 1997 22:07:10 +0000 (GMT) Cc: joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG In-Reply-To: <19970913165635.17336@lemis.com> from "Greg Lehey" at Sep 13, 97 04:56:35 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > An FDC-reported ``CRC error in data field'' is just what the FDC is > > telling me. I don't see why you're blaming the driver for being > > blind-eyed if it just believes what the FDC is telling. > > It looks like it, doesn't it? But how does that explain why people > can read some things on one machine when it's running Linux, and not > on the same machine when it's running FreeBSD? Remember that floppies > contain a lot of analogue electronics (well, a large proportion of the > electronics are analogue :-). And we all know that floppy drives are > a piece of shit. I think that any driver that believes the drive is > being blind-eyed. JOOI, how many times do you retry? It is not an issue of retrying forever; typical BIOS implementations will seek and retry. I think the problem lies in the use of sector instead of track based reads and writes, actually. Doing a sector at a time can add a lot of slop-error. To keep multitrack writes streaming would require two track buffers, BTW. The track buffer would act as a cache. Inter-track seeking would be a bit slowed by this, but the MSDOSFS should probably see a good performance improvement, especially since locality dictates that most of the interesting pieces of the FAT will be in one buffer or the other. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.