> OSR 5.0.0's /etc/conf/pack.d/fd/space.c has these variables:
> int fd_enable_FIFO = 0;
> int fd_FIFOthresh = 0;
>
> but OSR 5.0.5's does not. Can they be added to space.c under 5.0.5?
>
> The 5.0.5 Driver.o does have the symbols, something defined them:
> [Index] Value Size Type Bind Other Shndx Name
> [125] | 596| 0|NOTY |GLOB |0 |2 |fd_FIFOthresh
> [126] | 592| 0|NOTY |GLOB |0 |2 |fd_enable_FIFO
>
> My problem is with a 5.25" 1.2Mb floppy under 5.0.5 on a dual Pentium III
> 500Mhz box (Tyan S1832DL). 3.5" floppys work fine. The 5.25" floppy
> always has I/O errors as described below and in some TAs.
> (5.25" Drive is used only to convert old media.)
>
> Does anyone know if a 5.25" Teac FD-55GFR has a FIFO?
He was replying to my message from 1997, so we have a nice every-two-
years posting rhythm going on this topic (well, I guess I'm a little
early):
> On Tue, Nov 25, 1997 at 10:13:53PM +0000, Bela Lubkin wrote:
Anyway, I'm sure his problem has long since been fixed, but I'll toss in
a word of explanation anyway. Those FIFO variables in fd/space.c were a
kludge to cover up for the fact that the guy who first put FIFO support
into the floppy driver was too lazy to figure out how to autoconfigure
it. That was later fixed. If Robert was having I/O errors with his
5.25" floppy on OpenServer 5.0.5, it was probably because the drive
hardware was defective.
In particular, the question "Does anyone know if a 5.25" Teac FD-55GFR
has a FIFO?" is off-track. The FIFO is in the floppy _controller_, not
the drive. Thus, the fact that his 3.5" drive worked correctly almost
certainly meant that the FIFO was being auto-recognized correctly and
that the entire control and data path down from the kernel to the
hardware was working fine. The 5.25" target hardware was busted.
So, my response at the time would have been: replace the drive. Plus,
perhaps, a comment on the fact that floppy drives are among the least
reliable types of hardware I have had the displeasure to work with.
Over time, I find that the floppy drive on most machines becomes flaky
and eventually stops working. If the failure rate on hard drives or
even CD-ROM drives was anywhere near as high, I doubt any of us would
still be using computers, we'd have given them up as a bad idea. (Oh,
perhaps I'm wrong -- a similar number of years of experience with the
reliability of MicroSoft operating systems hasn't managed to sour the
general public on computers...)
>Bela<
Wow, nice to hear something on this topic, even now! I always welcome new
information! :-)
> > On Tue, Nov 25, 1997 at 10:13:53PM +0000, Bela Lubkin wrote:
>
> Anyway, I'm sure his problem has long since been fixed, but I'll toss in
No, not really. Over time I've come to the conclusion that there is some
sort of special problem using a 5.25" floppy, as the second floppy, on
that particular motherboard: a Tyan S1832DL. More below.
> a word of explanation anyway. Those FIFO variables in fd/space.c were a
> kludge to cover up for the fact that the guy who first put FIFO support
> into the floppy driver was too lazy to figure out how to autoconfigure
> it. That was later fixed. If Robert was having I/O errors with his
> 5.25" floppy on OpenServer 5.0.5, it was probably because the drive
> hardware was defective.
Or motherboard issue? Keep reading...
> In particular, the question "Does anyone know if a 5.25" Teac FD-55GFR
> has a FIFO?" is off-track. The FIFO is in the floppy _controller_, not
> the drive. Thus, the fact that his 3.5" drive worked correctly almost
> certainly meant that the FIFO was being auto-recognized correctly and
> that the entire control and data path down from the kernel to the
> hardware was working fine.
Interesting...
> The 5.25" target hardware was busted.
Still not the case. The same not-functioning 5.25" drive worked fine on
different machines with different motherboards. The same functioning
5.25" drives from different machines did not function on that particular
Tyan S1832DL board and SCO505. I mixed and matched 2 old and 3 new drives
across various machines. I had success on other non-S1832DL motherboards
with and without SCO505. I had partial success under non-SCO505 operating
systems on the S1832DL. I could never get it going under SCO505 and the
S1832DL.
> So, my response at the time would have been: replace the drive. Plus,
> perhaps, a comment on the fact that floppy drives are among the least
> reliable types of hardware I have had the displeasure to work with.
> Over time, I find that the floppy drive on most machines becomes flaky
> and eventually stops working. If the failure rate on hard drives or
> even CD-ROM drives was anywhere near as high, I doubt any of us would
> still be using computers, we'd have given them up as a bad idea. (Oh,
> perhaps I'm wrong -- a similar number of years of experience with the
> reliability of MicroSoft operating systems hasn't managed to sour the
> general public on computers...)
Over the years I've learned the following:
a) Tyan changed the documentation for the S1832DL. The board by default
ships with the 2nd floppy disabled (and the infrared port enabled). The
jumper settings in older documentation were declared WRONG, meaning that
if you followed the instructions, you did NOT enable the second floppy.
The general rule of thumb to get a 2nd drive working is to change
JP4/JP8/JP9 appropriately and set the correct floppy type for the 2nd
floppy in the bios. I never did get a 5.25" floppy working correctly with
SCO505 and an older S1832DL, but I did get it working with a newer S1832DL
and WinNT. I'm not sure if I ever tried the 5.25" floppy with SCO505 in a
newer S1832DL board.
b) I remember trying various combinations of DOS6 vs SCO505 vs SCO500 vs
WinNT4 and being able to format the 5.25" floppy under DOS6, but not under
SCO505 (same floppy unit, same machine). That's why I suspected something
about SCO505. But I'm not 100% sure (its been a while) if the drive was
ever really "right", even under DOS, on those older motherboards. I do
suspect that even the corrected motherboard documentation was still wrong
for older motherboards and I had reported this to Tyan. Tyan was unable
to reproduce my particular problem (in a multi-processor configuration).
c) I remember that under WinNT4, the 5.25" drive tended to function (at
least from SP5 thru SP6a). The big test was performing a format. Any
time I could format then write then read I knew things were ok. I
remember that under SCO505, I could read, sometimes write, but could NEVER
get a format to complete successfully.
d) As a separate issue, I started wondering about the 5.25" media I had.
Most of it was somewhat aged (3+ yrs) and I had a feeling that the oxide
simply gave up. While going through various old backups and archives
stored on 5.25" floppies (5-10 yrs old), I noticed that many were no
longer readable. I've always wondered if the earth's magnetic field and
radiations from computer equipment could demagnetize old floppies...
assuming they were stored in the same spot for most of those years. I
wanted the 5.25" drive for the purpose of putting all that old data onto a
hard disk or 4mm tape in preparation of the media failing... I think I was
too late. During my tests of floppy drive vs motherboard, I [eventually]
took extra care to use floppies which still accepted a format.
e) Since 5.25" drives are essentially history, I had shelved the issue and
just stopped putting them in SCO505 systems a while back. At the time a
SCO500 system was still available and its 5.25" was still active.
I'm pretty sure I was hit with multiple problems including: erroneous
motherboard documentation, media oxide issues and possibly something that
SCO505 does differently than SCO500/DOS/WinNT4 which compounded the
problem (and you just indicated the auto-configure changed so something
was different). I also have a feeling that there could have been a Pentium
II vs Pentium III issue on the motherboard which did something with the
2nd floppy (no matter how unlikely that would seem). A near duplicate
machine to mine, at a customer, had a working 5.25" drive on a dual
P-II/450 system where I ran the same configuration except for dual
P-III/500s. I built both machines as twins and the only difference was in
the CPUs. This is still an open issue for me and one day I will get
around to doing some more testing on it.
Thanks for your input, its nice to hear from you again!
-Rob
--
Robert Weiner / Programming Plus Hardware & Software Consulting
Email: rob...@progplus.com http://www.progplus.com
> > > OSR 5.0.0's /etc/conf/pack.d/fd/space.c has these variables:
> > > int fd_enable_FIFO = 0;
> > > int fd_FIFOthresh = 0;
> > >
> > > but OSR 5.0.5's does not. Can they be added to space.c under 5.0.5?
> > >
> > > The 5.0.5 Driver.o does have the symbols, something defined them:
> > > [Index] Value Size Type Bind Other Shndx Name
> > > [125] | 596| 0|NOTY |GLOB |0 |2 |fd_FIFOthresh
> > > [126] | 592| 0|NOTY |GLOB |0 |2 |fd_enable_FIFO
> > >
> > > My problem is with a 5.25" 1.2Mb floppy under 5.0.5 on a dual Pentium III
> > > 500Mhz box (Tyan S1832DL). 3.5" floppys work fine. The 5.25" floppy
> > > always has I/O errors as described below and in some TAs.
> > > (5.25" Drive is used only to convert old media.)
> > >
> > > Does anyone know if a 5.25" Teac FD-55GFR has a FIFO?
> >
> > He was replying to my message from 1997, so we have a nice every-two-
> > years posting rhythm going on this topic (well, I guess I'm a little
> > early):
>
> Wow, nice to hear something on this topic, even now! I always welcome new
> information! :-)
Well, I really shouldn't be replying until 2005, but...
> > a word of explanation anyway. Those FIFO variables in fd/space.c were a
> > kludge to cover up for the fact that the guy who first put FIFO support
> > into the floppy driver was too lazy to figure out how to autoconfigure
> > it. That was later fixed. If Robert was having I/O errors with his
> > 5.25" floppy on OpenServer 5.0.5, it was probably because the drive
> > hardware was defective.
>
> Or motherboard issue? Keep reading...
>
> > In particular, the question "Does anyone know if a 5.25" Teac FD-55GFR
> > has a FIFO?" is off-track. The FIFO is in the floppy _controller_, not
> > the drive. Thus, the fact that his 3.5" drive worked correctly almost
> > certainly meant that the FIFO was being auto-recognized correctly and
> > that the entire control and data path down from the kernel to the
> > hardware was working fine.
>
> Interesting...
>
> > The 5.25" target hardware was busted.
>
> Still not the case. The same not-functioning 5.25" drive worked fine on
> different machines with different motherboards. The same functioning
> 5.25" drives from different machines did not function on that particular
> Tyan S1832DL board and SCO505. I mixed and matched 2 old and 3 new drives
> across various machines. I had success on other non-S1832DL motherboards
> with and without SCO505. I had partial success under non-SCO505 operating
> systems on the S1832DL. I could never get it going under SCO505 and the
> S1832DL.
Lotsa more details deleted...
Well, the code now auto-configures the FIFO. From what you've said, I
suppose it's possible that this particular motherboard has a floppy
controller chip that supports the FIFO, but the actual FIFO hardware is
broken. The autoconfig code would not handle that scenario.
> [...] This is still an open issue for me and one day I will get
> around to doing some more testing on it.
If you feel like wasting the time, you could try hot-patching those same
variables. You can no longer control them from space.c, but you can
poke new values into the kernel after booting. Two tools that can do
this are `pat` (available in some TLS or possibly SLS); and /etc/scodb.
I would choose scodb as it's already present on 5.0.5. You may have a
startup issue where it whines about not having "stun" files; if so, a
workaround is to add the kernel scodb driver ("N" -> "Y" in
/etc/conf/sdevice.d/scodb); relink the kernel; then remove it ("Y" ->
"N") and relink again. You don't have to boot the scodb-enabled kernel,
just link it in once to provoke creation of the "stun" files.
In any case, start with `crash`, which you don't need to go to great
trouble to configure. Use it to read the autoconfig'd values of
fd_enable_FIFO and fd_FIFOthresh. Is it in fact being enabled?
To dynamically disable the FIFO, patch fd_enable_FIFO to 0. Then
deliberately cause an I/O error (e.g. try to read from a drive that has
no media in it).
Or if it's been autoconfigured to 0, try patching it to 1. The
autoconfig isn't terribly smart and doesn't necessarily know about "new"
hardware (post-1990 or so ;-). Be warned, however, that trying to turn
the FIFO on might cause an FDC that doesn't support it to fail badly (no
hardware damage, but it could plausibly hang the system -- test
cautiously).
>Bela<
>So, my response at the time would have been: replace the drive. Plus,
>perhaps, a comment on the fact that floppy drives are among the least
>reliable types of hardware I have had the displeasure to work with.
>Over time, I find that the floppy drive on most machines becomes flaky
>and eventually stops working. If the failure rate on hard drives or
>even CD-ROM drives was anywhere near as high, I doubt any of us would
>still be using computers, we'd have given them up as a bad idea. (Oh,
>perhaps I'm wrong -- a similar number of years of experience with the
>reliability of MicroSoft operating systems hasn't managed to sour the
>general public on computers...)
I used to 'use up' floppies in about 9 months to a year. The MTBF
was about 5000 hrs and using them on an online system [when 300BPS
modems were the maximum] did tend to do this.
The 1/2 height drives - which had MTBF's of 20,000 hours [probably
better later on] were a big improvement, as were the prices
at only about $200 each.
I'd not expect much of anthing in today's 3.5" units since anything
in the $10 range has to be considered dispoable in my book.
Not being used along with air being sucked in over the heads
deposting a film on them because of the typical PC power supply
design - doesn't help matters either :-)
--
Bill Vermillion - bv @ wjv . com
>> That was later fixed. If Robert was having I/O errors with his
>> 5.25" floppy on OpenServer 5.0.5, it was probably because the drive
>> hardware was defective.
>Or motherboard issue? Keep reading...
...
>Still not the case. The same not-functioning 5.25" drive worked
>fine on different machines with different motherboards. ...
>Over the years I've learned the following:
>a) Tyan changed the documentation for the S1832DL. The board by
>default ships with the 2nd floppy disabled (and the infrared port
>enabled). The jumper settings in older documentation were declared
>WRONG, meaning that if you followed the instructions, you did NOT
>enable the second floppy. The general rule of thumb to get a 2nd
>drive working is to change JP4/JP8/JP9 appropriately and set the
>correct floppy type for the 2nd floppy in the bios. I never did
>get a 5.25" floppy working correctly with SCO505 and an older
>S1832DL, but I did get it working with a newer S1832DL and WinNT.
>I'm not sure if I ever tried the 5.25" floppy with SCO505 in a
>newer S1832DL board.
Thansk for that research and information.
>c) I remember that under WinNT4, the 5.25" drive tended to function
>(at least from SP5 thru SP6a). The big test was performing a
>format. Any time I could format then write then read I knew things
>were ok. I remember that under SCO505, I could read, sometimes
>write, but could NEVER get a format to complete successfully.
That is not a good test. MS systems will format a disk and will
mark any bad sectors and make them unavailable. You will see this
in the format summary. Unix systems OTOH most often write raw data
to a disk and thus require disks with NO flaws at all. I had one
early Unix system that did not even retry on a write attempt during
format. [8" devices]. On some surplus Xerox disks I bought I had
over 90% failure. Another OS [ LDOS for those who remember it]
was able to get about 50% format. On CP/M [from which MS derived
so much] I had a 95% success rate.
Part of it had to do with the sloppy way formats were done under
CP/M - using the worst case single density format instead of the
worst case double-density format. The SD worst case format is 'e5'.
You could resurect lost files on MS by simply editing the directory
entry and replaceing the 'e5' as the first letter of an 'erased'
file by changing it back to any legal ascii value, not just it's
original value. I haven't looked at an MS product at that low a
level in a few years - but they were still using that format then -
a format which will pass almost anything that will fit in the door.
Do not confuse MS 'take two aspirin and call me in the morning'
approach with the Unix "well run some blood tests and and a
cardiogram' method. The former will do you in at times.
I still routinely format ALL the floppies I use on a Unix system
and then just dd track one [which I've sucked from a known good MS
formatted disk] back on at the end of a format so that I have
a 100% known good formatted disk I can use under Unix or MS.
>d) As a separate issue, I started wondering about the 5.25" media I
>had. Most of it was somewhat aged (3+ yrs) and I had a feeling that
>the oxide simply gave up. While going through various old backups
>and archives stored on 5.25" floppies (5-10 yrs old), I noticed
>that many were no longer readable. I've always wondered if the
>earth's magnetic field and radiations from computer equipment could
>demagnetize old floppies... assuming they were stored in the same
>spot for most of those years.
They really won't demagnetize in proper conditions. Magnetic
materials are quite stable if not changed by an external influence.
Get media hot and the slightest magnetic filed will change them.
[This is technically called the Curie point. At that point the
ease of changing the particle orientation is so easy this was used
to 'contact print' video tapes. Special recorders were made which
angled the video heads in a mirror image of players. The master
tape - with a higher curie point - was sandwiched with a tape of a
lower point and run through rollers and heated up - and you had an
instant high speed duplication. Expensive and duplicator opted to
go with herds of standard VCRs for this] [/topic drift]
However the manufacture of the coatings and the material used
did affect longevity. In the bad old days there were disks that
you could not read 6 months later. Brown made a lot of bad media
as I recall [that's not a retail brand but an OEM]. Bad choice of
binders can make the oxide come off on the heads or just come off
the disks.
Heat is a killer. One hour at 150 degrees will do as much damage
as radiation 500 times higher than a lethal dose. [I had that
reference in some 3M/Scotch literature a long time ago - and I
haven't seen that reference since]. So that means that if you have
a bad fan and leave a floppy in the drive it could get hot enough
to make it easily damaged. I've pulled warm floppies from systems
in the past when I'd gone to look at a problem. Good indicator of
dead/bad fan or dust bunnies galore.
In the early days you could also erase a disk by accidentally
setting a phone on top of a disk and have the phone ring. [this was
when phones had bells in them]. I've always heard that but never
proved it. The HD disks had a much higher coercivity and were
more immune to outside influence. The 3.5" format had media quite
similar to the 5.25" HD format. The latter is remarkable rugged.
In the last year I took archived data from 10 year old 3.5 disks
[written on a Xenix system] and moved it to CD. Out of 200+ disks
I had about 3 or 4 unreadable files. Never had any disk completely
unreadable. The 5.25" HD disks are also almost as rugged.
>hard disk or 4mm tape in preparation of the media failing...
>I think I was too late. During my tests of floppy drive vs
>motherboard, I [eventually] took extra care to use floppies which
>still accepted a format.
Test them ONLY on Unix systems if you want to be sure.
>I'm pretty sure I was hit with multiple problems including:
>erroneous motherboard documentation, media oxide issues
>and possibly something that SCO505 does differently than
>SCO500/DOS/WinNT4 which compounded the problem (and you just
>indicated the auto-configure changed so something was different).
Oxide problems are most likely in the 360/720K formats.
>I also have a feeling that there could have been a Pentium II vs
>Pentium III issue on the motherboard which did something with
>the 2nd floppy (no matter how unlikely that would seem). A near
>duplicate machine to mine, at a customer, had a working 5.25" drive
>on a dual P-II/450 system where I ran the same configuration except
>for dual P-III/500s. I built both machines as twins and the only
>difference was in the CPUs. This is still an open issue for me and
>one day I will get around to doing some more testing on it.
I'd be interested in hearing the results of that testing. We're
the chips of the same family or were they of Celeron or Xeon
variants.
--
Bill Vermillion - bv @ wjv . com
> In article <Pine.SCO.3.96.101052...@pp5.progplus.com>,
> Robert Weiner <rob...@progplus.com> wrote:
> >On Sun, 20 May 2001, Bela Lubkin wrote:
> >> On 1999-12-26, Robert Weiner wrote:
>
> >> That was later fixed. If Robert was having I/O errors with his
> >> 5.25" floppy on OpenServer 5.0.5, it was probably because the drive
> >> hardware was defective.
>
> >Or motherboard issue? Keep reading...
> ...
>
> >Still not the case. The same not-functioning 5.25" drive worked
> >fine on different machines with different motherboards. ...
> <
<lots of MB details deleted>
<a splended explanation of the Curie Point removed>
> I'd be interested in hearing the results of that testing. We're
> the chips of the same family or were they of Celeron or Xeon
> variants.
>
> --
> Bill Vermillion - bv @ wjv . com
When you are done testing the 5.25" floppies, I have a stack of unsorted
punch cards around here somewhere...... 8-)))
Ben Rosenthal