Date: Wed, 8 Sep 1999 10:12:51 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: thorpej@nas.nasa.gov Cc: hackers@freebsd.org Subject: Re: Tulip device driver question Message-ID: <199909081412.KAA07889@skynet.ctr.columbia.edu> In-Reply-To: <199909080316.UAA21624@lestat.nas.nasa.gov> from "Jason Thorpe" at Sep 7, 99 08:16:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Jason Thorpe had to walk into mine and say: > > I'm assuming you actually have a Winbond card. If you do, try this for > > Yah, some Unicom card, I think. > > > me: connect the Winbond to a link partner who's media settings you can > > [ . . . snip . . . ] > > > Winbond that if I changed the link partner's speed settings, it would > > start DMAing all kinds of crap into the host's memory. Furthermore, I > > think it ignores the RX buffer lengths specified in the receive descriptor > > ring and trashes various chunks of memory that it shouldn't, leading to > > a crash. Given that I never observed this behavior with any of the other > > tulip clones using similar code, I was pretty sure this was a chip bug and > > not some horrible coding error that I had made somewhere. > > Yes, I have seen exactly this. I could only get it to happen if I changed > the Winbond's link partner from 10 -> 100 while the Winbond was still in 10. That sounds right. > I see the TDSTAT_Rx_FS and TDSTAT_Rx_LS bits cleared in the descriptor, > as well. When I see this condition occur, I attempt to reset the chip. > This does NOT help this condition on the Winbond. It's thorougly wedged. > > Oh yay, cheap chips. > > > I saw this with at least three separate Winbond cards and I tried my > > best to detect the condition and smack the chip upside the head to make > > it stop, but I'd be interested to see somebody else duplicate the problem > > and give me their take on it. > > Were you ever able to smack it and make it stop? :-) 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. 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. The driver in -current has code that swaps the speed setting and the extra large buffers; originally I just tried to reset the chip and swap the speed as fast as possible, but this proved not to work too well once I started using the miibus sublayer so I had to revisit the whole thing and come up with a better solution. > > Also, just out of curiosity, have you ever observed the PNIC receiver > > bug that gave me so many fits? > > I observed it briefly back when there were still some pretty basic bugs > in the driver, which have since been squashed. I haven't seen it since. > I'm aware of the nature of the problem and your work-around. I'm hoping > I don't need to implement it :-) Unfortunately, I'm still not sure how to trigger it reliably so I can't tell you exactly where or when you might see it. > I have seen some pretty awful problems with the PNIC, tho. The DMA engine > is a piece of crap. On a 500MHz AlphaStation 500, who's PCI bus can surely > keep up with a cheap fast Ethernet board, the PNIC gets constant DMA underruns > unless in Store-and-Forward mode, *including the setup frame*. I have to > initialize the chip into S-F mode just to get the damn filter programmed :-) > > I also noticed that DMA underruns don't abort the transmit pipe on the PNIC. > Every DMA underrun on a real packet corresponded to a junk frame hitting > the wire. A short frame I could understand... but we're talking even the > Ethernet header is toast. > > Another interesting problem I've been seeing; The very first setup frame > fails to complete. All subsequent setup frames succeed. Including setup > frames sent after an ifconfig down/up. Utterly bizarre. > > Oh yay, cheap chips. 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. 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. > ...speaking of the PNIC ... I sent you some mail asking where you got > your PNIC manuals... I have been unable to locate any. I haven't even > been able to find the correct contact at Lite-On. Every Lite-On company > I find seems to not have any networking products... *puzzled* Anyhow, just > wondering if you missed that message... Dammit, I must have. I'm very sorry. Their domain name is not Lite-On; I can't remember what it is off the top of my head but you wouldn't be able to figure it out unless somebody told it to you. Actually, the domain I'm thinking of is in Taiwan; I think they have offices in California too, but most of the e-mail exchanges I've had have been with people in Taiwan. I have to grope through my e-mail at work to find it and send it to you. As for the datasheet, there's a Postscript copy lurking at: http://www.freebsd.org/~wpaul/PNIC/pnic.ps.gz Since I never signed an NDA, I don't feel compelled to keep the thing a secret. :) Originally I just asked somebody at Lite-On for it; it took a couple days and a little arm twisting but I finally got it. Also, I spoke to LinkSys and they provided me with a datasheet too, but it was basically a very cut-down version of the Lite-On one -- all of the register info and very little else. 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. :) > > There's at least one that has a cardbus version... darnit, which is > > is it. Oh: it's the ADMtek. There's an AL982 designed for PCMCIA and > > cardbus use. Unfortunately, the data sheet for it is not on ADMtek's > > server, but it's probably the same core as the AL981. In any case, I > > don't know of any boards that use the AL982. For that matter, I'm not > > even sure which boards use the AL981: the only cards I have are the > > samples that ADMtek sent me, and I haven't seen any board resellers > > claiming to use it. > > I'd like to get more info from you about these contacts... I have one each of: > > * PNIC board (NetGear variety) > * Macronix board ('15 variety, SOHO) > * Winbond board (Unicom thingie) > > ...and am looking to get ahold of more in order to get this merged driver > hammered out. 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 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, ideally you need one each of the 98713, 98713A and 98715A. The 98713 pretends that its NWAY support is handled via the MII bits in the serial I/O register but the 98713A uses the other NWAY registers. Also, if you 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.) 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. 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. 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. 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 a board called the Jaton XpressNet what uses the Davicom DM9102. This is another chip with a pretty cruddy DMA engine. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= 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?199909081412.KAA07889>