> Brian, Steve, Dale, John, Barry and other pi-users,
>
> First, my apologies for not responding and thanking each of you sooner.
> I most certainly appreciate your comments and have found each of them of
> value in getting things working, as they are now.  Here is a recap of my
> problem and the solution(s) which, with your help, I have found so far.
>
> The Problem
>
>   My original problem was discovered while trying to get a PI2 rev A
> card to work in a new PII 440BX motherboard ( a Soyo 6BB ).  The problem
> showed up as I began to migrate all of our RF hosts from DOS/JNOS, under
> which they've been running for many years, to Linux.  I was trying to
> first get two Linux boxes up, driving PI cards and 230 kbps radios
> across the bench in the shack.
>   The host santarosa.ampr.org has run full time as 386/JNOS and I was
> trying to use n6gn.ampr.org, the PII, running with PI to develop code
> for Linux.  Santarosa was available to test against, either in DOS or
> Linux.  However I discovered that with either Linux or even JNOS the PI
> card didn't run properly in the new PII and it was then that I posted
> here asking for help and ideas.
>   I had put this whole task off largely because of the time it's taken
> me to get sufficiently up to speed in Linux and because it required
> modifying the PI card driver for Linux to operate with internal clock
> recovery at 230 kbps, as I did years ago for JNOS.  I'm afraid the delay
> caused me to forget some of the things I learned back then.
>
> To help sort this out ( in case anyone else goes through this again)
> there are a number of variables:
>
>
> PI2 card type; rev A or rev B
>
>   We have a number of PI2 cards within the 'system' here, the bulk are
>   PI2 rev A but we do have a couple of Rev B cards.  The B cards have
>   the bus timing jumpers in the lower left corner as well as the
>   BRG/xtal jumper at J14.  The B cards have new PALs as well.
>
> PI Driver Code
>
>   Dave Perry's PI2.C is available for both JNOS and Linux.  In addition
>   to Dave's code, I asked this group several months ago and found that
>   Klaus Kudielka's dmascc code is being used by some of you.  There was
>   a variety of opinions about whether pi2.c was working well under Linux
>   or not.  Klaus's code also supports Gracilis cards and was reported to
>   work well with PI2.
>
>
> Host Computer CPU/Motherboard
>
>   Our arrangement here varies but includes or has included 386, 486,
>   pentium and PII(slot 1) CPUs.  It was the PII 440BX board that
>   precipitated this problem.
>
>
> Host OS
>
>   We've run JNOS 1.11x1GW0.2 for many years on all the machines but I
>   discovered that in the time since the last compile I'd lost the
>   modified pi2.c driver I used to build it.
>     The goal was to get the whole system entirely free of DOS.  Both
>   n6gn and santarosa hosts (as well as k6hsj and a new machine for
>   redwood.ampr.org) have RH 5.0 or 5.1 installed and can dual-boot DOS
>   or Linux.
>
>
> We didn't excercise all permutations of the above variables but perhaps
> those we did hit will save someone some grief.
>
> > From: Brian Mullaney 
> >
> > Just an idea, and one you have probably already tried, at that:
> >
> > There should be DMA/timing parameters in the BIOS, you might try changing
> > them to the slowest/most conservative settings
> >
> > Or try to dig up some older 486 MBs ;-)
>
>
> Brian,
>
> Well, as it turns out I *hadn't* tried it. In fact I'd hardly poked around
> in configuring the new 440BX board. Although I could find little control
> over the DMA or buss, in the processing of looking to see what I could
> do I learned quite a lot about the board. I still don't know much but the
> tip was definitely helpful in getting me started.
>
>   Also, as it turns out, we've ended up migrating two of the old systems
> from 386DX40 to 486 and used the PI2_A cards with no problems.  So while
> I don't have a list of the (several) different 386/486 motherboards that
> we tried or are using, every one of them worked fine with the rev A
> cards.
>
>   The current solution for the 440BX board is one of expedience; make
> sure to use one of the PI2_B cards.
>
> >
> > From: Steve Platt 
> >
> > This appears to be a well known problem with the linux PI2 driver.
> > It seems to xmit corrupt frames on the (DM)A port, but is fine on
> > the B port.
> >
> > There is an alternative driver, called "dmascc" which some people
> > have said avoids the problem.
> >
> > I do not know what efforts are being made to integrate this alternative
> > driver with the linux source tree.
> >
> > So, you could try "dmascc" and if it works perhaps your evidence
> > and good name will persuade someone to consider changing the linux
> > pi2 driver.
> >
>
> Steve,
>   This looks like an excellent idea, though I may have lost a little
>   incentive to pursue it now.  This is because after getting the PII
>   machine happy with a PI2_B card I was able to reconstruct my
>   modifications to Dave Perry's pi2.c and I'm now very happy to report
>   that I have both n6gn and santarosa machines entirely free of DOS and
>   able to drive the 230 kbps radios very well; even better than they
>   were with the JNOS code (a matter of the removal of some hardcoded
>   100ms holdoffs in Dave's old code).
>
>   santarosa.ampr.org is the 7x24 switch/router and seems to be running
>   fine.  I may yet find a problem with the pi2.c code that causes me to
>   want to migrate to dmascc but at the moment performance is very good,
>   no lost packets and very high throughput (at least with pings) via RF
>   across the shack as well as very good performance to the hilltop
>   router, redwood.ampr.org.
>
>   As soon as I've prettied up and "regression-checked" the new code,
>   I'll post the changes in case anyone else wants to be able to do
>   230kbps on PI with Linux.
>
> >
> > From: "Dale Heatherington" <56k@wa4dsy.net>
> >
> >
> > Yep, it sounds like the DMA (or is it DAM(n)) timing problem too me.
> > The only cure I know of is to try one of the PI2 cards which have a higher
> > likelyhood of working.
>
> Dale,
>
>   As you can tell from the above, you were right on with your diagnosis.
> Also, if I remember right, you were one who previously reported good
> results with the Linux pi2.c code at 56K.  It's still a bit early but my
> experience so far seems to verify this.
>
> >
> > From: John Ackermann N8UR 
> >
> >
> > I recently had similar problems trying to get an original PI1 card
> > working on fast(er) 486 motherboards.  In that case, substituting an
> > 85C30 for the original 8530 did the trick.  I tried the old timing hack
> > (add a cap and resistor in the DDIOW line) and, at least when using the
> > 8530, that did no good.
> >
> > I know this isn't directly relevant to your problem, but it may help
> > nail down your suspicion of a timing problem.
>
> John,
>
>   It may be very relevant after all.  I haven't yet tried this since at
> this point we still have enough PI2_B cards to match new motherboards
> but it may be necessary as we upgrade (and I seem to be time-constrained
> (:>) ).
>   I think that in our case that there are already 85C30s in all the
> cards.  Perhaps the 8530 was only in the original PI (not PI2) card.
> It's interesting that you had no help from the RC delay.  Maybe Barry's
> comment (next) is the avenue to follow for anyone trying to solve this.
> It is the one obvious difference between the working and non-working
> cards on my PII.  I'd certainly be interested to know if anyone actually
> looks at bus timing on a BX or other new board.  I don't have sufficient
> tools at home to do this (though I could measure the S Parameters of
> the bus (:>) ) .
>
> > From: bm@lynx.ve3jf.ampr.org
> >
> > This does certainly sound like ye olde DMA timing problem (one of the
> > banes of my existence - sigh).  It wouldn't be too hard to hack in the
> > delay circuit from the B design onto an A card to try it out... ugly,
> > but not too hard.  If you don't have a B schematic, it's available at
> > ftp://hydra.carleton.ca/pub/hamradio/packet/tcpip/pi2/.  Even that fix
> > doesn't cure the most stubborn cases, though.
> >
> > Too bad USB didn't debut a few years sooner... might have been a better
> > way to go.
>
> Barry,
>   Thanks for the confirmation and the pointer to the B schematic.  I was
> just posed ready to hack up an older card when k6hsj arrived with one
> of the two PI2_B's in our system and I was able to avoid the effort.  I
> suspect that change, the addition of the selectable delay, is probably
> the difference between working and not.  However, I have not analysed
> bus timings nor even looked to fully understand them.  I'm interested in
> any further information anyone has.
>
>   You're no doubt right that we would be better off looking to a
> different mechanism for future higher speed data pipes into modern
> computers.  I'm not sure that USB is really fast enough for what we
> might want to do to be attractive.  But whether or not I'll get around
> to trying out my ideas at putting 100Base onto RF and/or laser light is
> another matter!  I think we're all somewhat tired out.
>
>
>
> All,
>
> So, in summary, watch out for PI2_A cards on 440BX motherboards. Try
> to use a PI2_B card or, failing that, if/when it doesn't work try
> adding the selectable delay circuitry from Barry's page above.
>
> Thank you all for your thoughts and help. I appreciate it a lot.
> I'll be posting the revised pi2.c code as soon as I'm confident that
> I haven't broken any thing ( my changes were pretty minor but I'm
> pretty efficient at breaking things  (:>) ).
>
> 73
> Glenn n6gn
>


Additionally,  there is a analysis from someone who tested it in Vancouver who
added a additionally delay one of the DMA lines which should be in this lists
archives.  If necessary, I might be able to get it from backup.