Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Jan 1995 09:20:05 +0100 (MET)
From:      j@uriah.sax.de (J Wunsch)
To:        babb@sedhps01.mdc.com (Jim Babb)
Cc:        freebsd-hackers@FreeBSD.org (FreeBSD hackers)
Subject:   Re: Colorado 250 Tape Drive
Message-ID:  <199501180820.JAA13643@bonnie.tcd-dresden.de>
In-Reply-To: <199501171411.GAA08047@freefall.cdrom.com> from "Jim Babb" at Jan 17, 95 08:09:29 am

next in thread | previous in thread | raw e-mail | index | archive | help
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. ;-)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199501180820.JAA13643>