*BSD News Article 33205


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!swrinde!news.dell.com!tadpole.com!uunet!zib-berlin.de!irz401!uriah!not-for-mail
From: j@uriah.sax.de (J Wunsch)
Newsgroups: comp.os.386bsd.questions
Subject: Re: [FreeBSD 1.1.5.1] fd0: recal failed
Date: 25 Jul 1994 18:57:01 +0200
Organization: Private U**X site; member IN e.V.
Lines: 52
Message-ID: <310qstINNda3@bonnie.sax.de>
References: <30orjf$k67@homer.cs.mcgill.ca> <30qiom$92c@terrazzo.lm.com> <30ru8c$197@news.cs.tu-berlin.de>
NNTP-Posting-Host: bonnie.sax.de

klier@cs.tu-berlin.de (Jan Klier) writes:

>Maybe the author of the floppy driver can shed a little light on
>this problem.

Sorry, i didn't read the article before since my time doesn't permit
to check Usenet very often.

Folks, if you have any question regarding FreeBSD, especially if it's
urgent for you: remember the file ROSTER.FreeBSD, it has been put
there so you know the ``Who's who'' for FreeBSD. Feel free to contact
the person who's responsible for some part of the system. Though this
is freeware and thus basically unsupported, we'll do our best to
answer questions and help you - just if we knew about the problems...

>>David BREMNER (bremner@cs.mcgill.ca) wrote:

>>: /386bsd:fd0: recal failed ST0 70 <abnrml,seek_complt,equ_chck>

>The real problem lies in the NEC765 chip, which for some unknown reason
>responds with an error if a recal-command isn't completed after 77!
>tracks. Which of course is non-sense on 80-track disks. It might be that
>the handling of this error that actually isn't a real error has been
>changed.

Yes, this is the correct answer. (Note that the 77-step limit has
historical reasons. We still do use a chip that has been assigned
to serve 8-inch standard floppy drives:-)

I've done what i can to make the floppy driver much more stable than
previous versions have been. Several old flaws have been detected and
removed, some error messages are new like the one above.

Unfortunately, with the current conception of the internal floppy
state machine and error recovery strategy, it's impossible to catch
this problem and immediately issue a second recalibration command
(which should always succeed then). Thus, it's flagged as an `error'
(though it's merely a design problem of the FDC chip), and the ususal
`error' recovery is started - which should always lead to success in
this case. That's why this message is rather harmless and doesn't need
more attention as long as it's appearing once per recalibration
attempt.

I'm still planning improvements to the fd driver (especially perform-
ance improvements - my goal for 1.1.5 was to achieve rock-solid
stability first), and so i think this messages will go away with one
of the future releases...
-- 
cheers, J"org                             work:    joerg_wunsch@tcd-dresden.de
                                          private:   joerg_wunsch@uriah.sax.de
Steinbach's Guideline for Systems Programming:
        Never test for an error condition you don't know how to handle.