Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!sgiblab!spool.mu.edu!olivea!decwrl!decwrl!netcomsv!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: [continued] [FreeBSD 1.0R] DMA Problems?
Message-ID: <jmonroyCIyA7x.JBx@netcom.com>
Keywords: DMA problems 386 8237
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
Date: Sat, 1 Jan 1994 12:19:08 GMT
Lines: 100
Thread moved because it was going to die on my news feeder.
=======================================================================
>> From: terry@cs.weber.edu (A Wizard of Earth C)
>> Newsgroups: comp.os.386bsd.development
>> Subject: Re: [FreeBSD 1.0R] DMA Problems?
>> Date: 1 Jan 1994 09:53:34 GMT
>>
>> In article <jmonroyCIvwpv.8F3@netcom.com> jmonroy@netcom.com
>> (Jesus Monroy Jr<yes it's me again>) writes :
>>
>> > This is possible, but the timing inconsitency might crash the
>> > system. To make it work correctly it would require a rewrite
>> > of the RTC (Real Time Control) System. I beleive you
>> > have a copy of my report on this, so further details are
>> > available there.
>>
>> I agree that the clock code needs rewritten -- but mostly for TQE style
>> event processing and for select-in-kernel-without-buzzloop and finally
>> to allow future use as a realtime box (with more changes).
>>
I sort of agree.
>> The sum of
>> the QIC-40/80 requirements are there to avoid buzz-looping in the driver
>> ad taking the system to its knees. Admirable goals, but not strictly
>> a requirement for a driver -- as has been proven by a Linux Driver, a
>> BSD driver, and Vadim Atinov's code for BSDi (and the SCO code and...).
>>
I disagree that the drivers for the other systems are "proven".
However, I don't want to stray from the subject so I am forced
to say, "They did prove something!". (Except for Vadim Atinov's
code, to which I will say - "bepe3kn".)
^^^^^^^
This is Russian.
Sorry for the Mispelling!
>> I don't think a driver could be reasonably used to back up a drive
>> over the network, and it is somewhat questionable on slow (ie: not as
>> fast as mine) machines with most (again, not mine) fixed disk controllers.
>> Spending 60% of the machine buzzing or doing seeks to keep the tape in
>> a usable place but not streaming, are simply not commercial quality
>> in my opinion (Vadim's driver is the best one of the lot, and it could
>> still benefit in some small places -- he was real tricky).
>>
I will agree with your comments to an extent. Mainly, 60% is
too high a number. I expect an overhead of not more than 20-30%
with my driver. Designing it right the first time helps; borrowing
other peoples code is another issue.
>> > It is possible, via software, to reprogram the refresh cycle.
>> > My example program does this. The results are had when the
>> > system crashes. That is, to make this a software *probe*
>> > the program would (if it existed for *BSD) slowly turn down
>> > the timer till the system crashed. At this point, some
>> > test could readily determine the *consistency* of ths system.
>> >
>> > I hope this is clear.
>>
>> It is, but I still don't agree with it. The problem that I see is that
>> the DRAM contents need to be kept above fail level -- where the 1 may
>> be seen to have flipped over to a 0. But any kind of probe can't
>> determine that, because you may get something that *seems* to work,
>> but of a period of time will converge to the fail level. This is
>> because the write will result in a high capacitive charge, and adding
>> charge incrementally must still exceed the drain rate -- if it does not,
>> and only does not barely, then over a long time, the memory will seem
>> to fail -- unless you propose to wait 5 days for the probe to complete.
>>
>>
I propose a good job done completely, if nothing at all.
I believe you are aware of the fact that all BSD releases
have been labeled "experimental". If this is true, then
please take it at face value, as I do.
In short, computer science is more of an art form than a
science. I may have not stated this before, "Computer
programing needs to be done more by programmers NOT EE's.
If you want reliable good computer systems, then let the
computer programmer design it, and let the EE's build it."
Data General had good experiences with this, but a lack of
technology may have been their down fall. I expect my work
to be as bullet-proof as possible and to last more than 5 years.
As for the probe, if you are serious I will write the d*mm thing
and you may, at your leisure, set a sieres(sp?) of tests to it.
(I will even write the test, if you like.) But please, let's
clear the air and go on to the next subject -or- make plans
for this one. I don't want to beat the DMA horse (:-) to death.
--
Jesus Monroy Jr jmonroy@netcom.com
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________