From: j@uriah.sax.de (J Wunsch)
Newsgroups: comp.os.386bsd.bugs,comp.os.386bsd.questions
Subject: Re: FreeBSD2.0R install glitches -- patched floppies coming shortly!!
Date: 13 Dec 1994 19:35:22 +0100
Organization: Private U**x site, Dresden.
Message-ID: <3ckpha$98f@bonnie.tcd-dresden.de>

Mark Hittinger <bugs@warlock.win.net> wrote:

[fd0: hard error reading fsbn ...]
>>Does on-board floppy controller have anything to do with it?

Nope, it does not.
...

>Had the floppy problem here too.  It seemed to be sporadic and intermittent.
>I made several floppies and finally was able to get  the installation to fly
>but I think it was because of luck that the errors did not occur in a critical
>file.

There have been three types of floppy failure reports so far.

1     Floppy totally stuck after device configuration phase.  Sometimes
      even requires a power-cycle to come up again, or banging against
      the case.

2     Sporadic ``hard error reading... <no_am>'' problems (like above).

3     A rock solid ``hard error reading fsbn 16 ... <no_am>'', right after
      the ``changing root device to fd0'' message.


1:    This has apparently been caused by problems in the floppy tape
      driver.  To get a better feeling of what's happening: floppy
      tapes receive their commands via magic step pulse sequences.
      The ft probe code sometimes caused confusion on the attached
      floppy disk drives, making them seeking beyond cylinder zero and
      jamming there.  Until the ft driver has been cleaned up, the
      floppy tape probe has been disabled from the default kernel.
      [This should replace the ``business card'' solution someone
      suggested. :-)]

2:    This happens on a few machines, even with drives and diskettes
      that are known to work.  I've attempted to work around this by
      increasing the head settlement times after a seek or recalibrate,
      but a few drives still show this behaviour.  I've noticed on one
      of my test machines that disabling all the nonexistent devices
      from probing (after booting with the ``-c'' flag) decreases
      the likelihood of this failure - but i don't get any good
      correlation that helps me finding the real problem.  Any sugges-
      tions welcome!

3:    This happens on even fewer machines and now that i've found one
      box that also experiences this behaviour i found that it's also
      occuring with a FreeBSD 1.1.5.1 kernel.  The floppy controller
      absolutely fails to find any address mark on the diskette, even
      though the transfer rate initialization has been done properly.
      This is even more mysterious than point 2, even though i can
      fully reproduce it here on an older Data General PC.  -- And
      for all those guessing it might be a problem of supermodern
      QD controllers: nope.  By now all reports so far are related
      to rather old controllers.  (Maybe i should start collecting
      the exact chip revisions and vendors?  Perhaps they are all
      the same? ;-)


Any suggestions on how i can reproduce and find the errors are welcome,
you can also send me failing drive/controller combinations. 8^)
-- 
cheers, J"org                             work:    joerg_wunsch@tcd-dresden.de
                                          private:   joerg_wunsch@uriah.sax.de

Never trust an operating system you don't have sources for. ;-)

