> 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" <email@example.com> > > > > > > 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: firstname.lastname@example.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.