From owner-freebsd-hackers Wed Jan 18 01:00:40 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id BAA11128 for hackers-outgoing; Wed, 18 Jan 1995 01:00:40 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id AAA11084 for ; Wed, 18 Jan 1995 00:57:09 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA05796; Wed, 18 Jan 1995 09:55:46 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id JAA04956 for freebsd-hackers@freebsd.org; Wed, 18 Jan 1995 09:55:46 +0100 Received: by bonnie.tcd-dresden.de (8.6.8/8.6.6) id JAA13643; Wed, 18 Jan 1995 09:20:05 +0100 From: j@uriah.sax.de (J Wunsch) Message-Id: <199501180820.JAA13643@bonnie.tcd-dresden.de> Subject: Re: Colorado 250 Tape Drive To: babb@sedhps01.mdc.com (Jim Babb) Date: Wed, 18 Jan 1995 09:20:05 +0100 (MET) Cc: freebsd-hackers@FreeBSD.org (FreeBSD hackers) In-Reply-To: <199501171411.GAA08047@freefall.cdrom.com> from "Jim Babb" at Jan 17, 95 08:09:29 am X-Phone: +49-351-8141 137 Reply-To: joerg_wunsch@uriah.sax.de X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2332 Sender: hackers-owner@FreeBSD.org Precedence: bulk As Jim Babb wrote: | | I think some of the problems that were blamed on the ft driver were actually | the spurious interrupts from certain controller chips (which has now been | fixed). I doubt. | The only way for the ft probe to screw up a floppy drive | (by stepping it too far) is for that drive to be broken and ignore the | drive select signal. I would like to work with anyone that has a machine | that the ft probe breaks to try and fix the driver (if possible). My drives don't jam due to the step pulses, but they still emit strange noises, indicating they're really being *activated* where they shouldn't. | I think the number of people with working tape drives far outnumber the | number of people with broken floppy drives, so the logic of the flag | should be inverted, such that you set the flag to *disable* the probe. Not yet. The ft driver really needs someone responsible who is willing to maintain it on a regular basis. I cannot do this (for lack of time, material, documentation and experience with floppy tapes). Floppy tape probe still causes my driver to complain with lots of ``Ready for output in input'' error messages, until they finally reach there (currently static) limit of 100 per controller. This is a good indicator that the driver actually still *is* broken: someone attempts to read from the FDC where it doesn't want to emit any byte. The error became obvious after Peter's latest rewritten fdc_{in,out} functions which complain if something is going wrong (the old functions didn't and therefore did hide the problem). There are more points where the ft driver needs maintenance, e.g. it should record any IO activities performed on the DOR in the mirror variable within the fdc_data structure, just to note one here. I doubt that any of the recent changes made to the floppy driver will have ``self-cured'' anything in ft. E.g. the spurious interrupt problem didn't even affect the bad ft probe -- since interrupts are disabled at probe time. If we start enabling ft again as a default i'm afraid we'll have to ship business cards along with the CD's... -- cheers, J"org work: --- no longer --- private: joerg_wunsch@uriah.sax.de Never trust an operating system you don't have sources for. ;-)