Date: Wed, 08 Sep 1999 11:45:17 -0700 From: Jason Thorpe <thorpej@nas.nasa.gov> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: hackers@freebsd.org Subject: Re: Tulip device driver question Message-ID: <199909081845.LAA01909@lestat.nas.nasa.gov>
next in thread | raw e-mail | index | archive | help
On Wed, 8 Sep 1999 10:12:51 -0400 (EDT) Bill Paul <wpaul@skynet.ctr.columbia.edu> wrote: > Well, yes, but I made some assumptions in order to do it. The assumption > is that whatever the current speed setting is now, the link partner's > speed setting is exactly opposite. So if I detect the condition, I first > toggle the speed setting (if it's IFM_10_T, make it IFM_100_TX and vice- > versa), then do a reset, then re-init the chip. ...hm... okay, I'll investigate this option. > However, the main problem is keeping the chip from zapping memory that it > doesn't own. Normally I use mbuf cluster buffers in the receive ring, but > I would only tell the chip that the buffer was 1536 bytes long instead of > 2048. But again, it seemed like the chip was DMAing much more data than > it should have been and overruning the whole cluster. Since I needed to > copy received packets in order to fix up the alignment anyway, I stopped > using mbuf clusters and instead allocated my own 4K receive buffers and > told the chip to DMA into those, on the theory that it may have been > barfing up the entire contents of its FIFO memory which was more than > 2048 bytes. Sure, most of the time you waste a lot of those 4K blocks, > but at least when the chip freaks out it doesn't trash any memory that > you don't know about. Um. Ew. Okay. Sigh. In NetBSD, we only copy if the system doesn't have __NO_STRICT_ALIGNMENT (e.g. i386, m68k [we support some PCI m68k boxes], VAX [all those PCI vaxes, you know!)... I'll have to see what I can do about all of this. > Bleh. My experience with the PNIC shows that it does not handle > multi-fragment transmits very well (i.e. a packet split across multiple > buffers instead of just a single configuous buffer). Lite-On claims > that they get pretty good transmit speed with the PNIC, however I'm > certain they do their measurements using only single buffer transmits. > I typically don't see more than about 80-85Mbps, though others using > the Linux driver (which doesn't use multi-fragment transmits) have > claimed better performance (90-95Mbps). On a whim, I decided one day > to disable the code in pn_encap() that splits the outbound packet up > amount multiple descriptors and just let it copy all packer fragments > into a single buffer -- transmit performance actually got a little > faster. That's ... scary. Y'know, since real 21143s are *still available* (Intel is still manufacturing them!) you'd think the companies that used to put Tulips on their boards would still use them ... oh well. > My biggest problem with this stupid thing now is trying to get to work > on the 486/66 that I'm currently using for testing. It has an old Integrated > Micro Systems PCI bridge and the PNIC seems to have decided not to be > friends with it: the machine tends to freeze up solid whenever the chip > does any DMA, including just loading the setup frame. It it trying to use Memory-Read-Multiple or Memory-Read-Line? Old (esp. 486) PCI bridges were known to have problems with those PCI commands. > http://www.freebsd.org/~wpaul/PNIC/pnic.ps.gz Excellent! Thank you very much! > I've also got a Winbond datasheet at: > > http://www.freebsd.org/~wpaul/Winbond/winbond.ps.gz > > The originals of both these documents were in M$ Turd format. :) Already have this one; the Winbond datasheet is available at www.winbond.com.tw in PDF form... > All of the Winbond cards are essentially the same so the one you have > should be enough -- mine is from a company called Trendware. The PNIC > is a bit tougher to deal with because there are a couple of revisions: > the original LinkSys PNIC cards use the 82c168 and the internal busted > NWAY support (i.e. no MII transceiver). For these you have to fiddle > with the GPIO bits to flip the relay on the card (yes, a relay) in order Heh... I have a Kingston 21140 board that uses the PCS function to do 100baseTX, and you hear a relay flip on that board too :-) On these PNIC boards which use the external ENDEC / PCS ... I guess you'd be able to detect which flavor you have (for flipping the GPIO pins) using the subsystem IDs in PCI configuration space... The PNIC doesn't use the DEC-format SROM, unfortunately, so just getting CSR6 and CSR12 from the SROM isn't an option... > to select the right media. The trouble is LinkSys doesn't sell them > anymore: the later cards use the 82c169, and now they've gone to the > PNIC II. I had some 82c168 cards donated by FreeBSD users. I can part > with one of them if you can't find one anywhere. As for the Macronix, I would appreciate this... I haven't been able to find '168 boards at all. > ideally you need one each of the 98713, 98713A and 98715A. The 98713 I have a '15A board... I know of a NetBSD user who has a '13 board (he sent in patches to make it work with the `de' driver initially). > look at the application notes from Macronix, they mention the "magic > numbers" you need to program into CSR15 (I think). The original 98713 > needs one setting while the others require another setting. Macronix > doesn't say what the magic values really do, so I just program them in > and cross my fingers. (I'm considering adding some code to provide a fake > MII interface to the 98713A and friends so that I can use the miibus code > to control the media selection so that I can convert the whole driver > to use the miibus layer.) Yah, I have the Macronix data sheets... Doing the NWAY register stuff as a simulated PHY is a good idea... should sort-of work for the PNIC, too, and would save duplicating all that logic that MII code already implements. > Also, the PNIC II (LC82c115) is actually a Macronix chip with wake > on lan and only a 128-bit multicast hash table. The LinkSys LNE100TX v2.0 > card that I have and the sample 98715A card look almost identical. ...I'll have to hunt down one of these cards. > If you have a 98715A datasheet handy, you can use that as a reference > when programming this chip; just remember about the smaller hash table. > I'll stick a copy of my PNIC II datasheet at www.freebsd.org for you > a little later -- I originally got my copy from LinkSys. That's be great... > As for ADMtek, I originally went looking at www.admtek.com.tw and just > e-mailed one of the contacts that they list asking where I could buy a > board in the U.S., since I already had the datasheet (the AL981 sheet is > on their server). They turned out to be really eager to help me and sent > me two cards directly. Again, I have to grope through my back e-mail to > find the name of the guy I spoke too, but you can easily get in touch > with them using the contact info on their site. Ok, good to know, thanks. > Cnet makes a couple of cards using clone tulip chips: the Pro110 and 120 > series. One of them uses the ASIX chip and the others use Macronix. I've > been told you can sometimes find these at Fry's. Jaton Corporation makes Okay... good to know... > a board called the Jaton XpressNet what uses the Davicom DM9102. This > is another chip with a pretty cruddy DMA engine. Davicom ... Winbond-like? Thanks a LOT for this info! -- Jason R. Thorpe <thorpej@nas.nasa.gov> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909081845.LAA01909>