Return to BSD News archive
Xref: sserve comp.os.386bsd.bugs:2750 comp.os.386bsd.questions:15220
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!spool.mu.edu!howland.reston.ans.net!pipex!uunet!zib-berlin.de!irz401!uriah.sax.de!not-for-mail
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.
Lines: 66
Message-ID: <3ckpha$98f@bonnie.tcd-dresden.de>
References: <3bea13$881@shore.shore.net> <JKH.94Nov29145300@whisker.hubbard.ie> <Roy-0212940237530001@adept.cts.com> <3bqhb2$1f1@warlock.win.net>
NNTP-Posting-Host: 192.109.108.139
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
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. ;-)