Return to BSD News archive
Xref: sserve comp.os.os2.programmer:13332 comp.os.linux:53757 comp.os.mach:3210 comp.os.minix:22589 comp.periphs:4199 comp.unix.bsd:12485 comp.unix.pc-clone.32bit:4175 comp.os.386bsd.development:1132
Newsgroups: comp.os.os2.programmer,comp.os.linux,comp.os.mach,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!darwin.sura.net!europa.eng.gtefsd.com!uunet!pipex!ibmpcug!ibmpcug!jshark!joe
From: joe@jshark.inet-uk.co.uk (Joe Sharkey)
Subject: Re: More annoyance on the DMA problem
Organization: Individual Network (UK)
Date: Mon, 23 Aug 1993 21:00:13 GMT
Message-ID: <CC8D0E.4Ex@jshark.inet-uk.co.uk>
Followup-To: poster
References: <jmonroyCBoq14.Kz0@netcom.com> <jmonroyCBy43E.FLG@netcom.com>
Lines: 67
In article <jmonroyCBy43E.FLG@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes:
> All BIOSes for the PC report errors to the FDC, and even as
> I have not found the code to verify that the BIOS retries,
> MS-DOS does.
Surely you mean: "All BIOS report errors [from] the FDC to MS-DOS, and
MS-DOS then retries...." ??
> Most OSes retry on any error. If you program
> at the IBM BIOS level, most (if not all) references say to
> try at least 3 times before giving up on a transfer.
None of the OS's this is posted to actually *use* the BIOS except during
the initial bootstrap - but you know this.
> What does this say?
>
> That some type of problem exist, what it is - is not certain.
> Maybe a slightly bad disk, who knows.
Just so, I think: floppies can get dirty, maybe slight mis-alignment.
Retrying is as good a way as any to deal with it.
>>> As stated, DMA on post-IBM AT class machines doesnt exist, the
>>> memory controller subsystem does it transperantly. Get a refresh
> Sorry, this does not "jive" with my information.
It is also wrong - phrased very badly as best. Maybe he means
"transparent refresh" ;)
> The timer is hard wired. That is, in-hardware is where
> the refreshes are done, via the 8254 and the DMA controller.
> Also, I reference a book with the page number.
On PC's/AT's and similar.
> TRUE, some motherboards may have a transparent solution,
> but this does not follow my documentation for IBM PC AT.
The integrated chipsets came along later. You are not wrong ;)
>>> Lets face it, the architecture works (except for some CT
>>> chipsets that have buggy 16 bit DMA, which doesnt concern the FDC).
>>>
> INTEL admitted to no DMA problems today when I spoken
> to them. However, I am calling again and will ask
> them if they know anything more.
The release notes for Microsoft Xenix/86 (about 1987!) points out that
some DMA chips can only handle one DMA channel at one time. (Also that
some 8250 UART's don't have working interrupts.)
>>> In general, hardware is the natural scape-goat to blame for
>>> software bugs.
> If it is a software bug then I have yet to find an obvious
> placement.
You may have found a long-known hardware bug ;)
joe.
--
Joe Sharkey joe@jshark.inet-uk.co.uk ...!uunet!ibmpcug!jshark!joe
150 Hatfield Rd, St Albans, Herts AL1 4JA, UK Got a real domain name
(+44) 727 838662 Mail/News Feeds (v32/v32bis): info@inet-uk.co.uk