Date: Fri, 15 Nov 1996 13:54:14 -0600 (CST) From: Mark Tinguely <tinguely@plains.nodak.edu> To: freebsd-atm@freebsd.org Subject: progress report IDT ATM driver Message-ID: <199611151954.NAA14756@plains.nodak.edu>
next in thread | raw e-mail | index | archive | help
Since this mailling list has been too quiet, I will play cheerleader to generate some noise. 1. Driver mostly works, shaking out bugs: After many frustration weeks, I have the IDT NICStAR card working and the driver still has a couple features to be added and I am still shaking out some bugs in my code that come from (what I think are) strange features of the card. for example, today, I found the SAR will deposit timer entries in the transmit status queue, but it does not increment the queue until the transmission has been enabled...my driver advances the queue head when servicing TSQ entries and if I start the card after the first timer wrap, the card thinks the TSQ is full. solution, don't service the TSQ until the card has been initialize for transmission. 2. List of todos: I still have to automate the opening/closing of CBR VC and locating the SCD for a CBR VC on transmission; at least I know how I plan to do this. I also need to pull tons of diagnostic code out of the driver. I also need to be less strict about locking out interrupts. This driver needs to be bundled into the University of Washington's stack code. This stack will evenually be replaced by UNI LANE or MPOA. 3. permanent recieve mbuf: Since the card needs mbufs in the card for potentially a long time I am implementing permanent external (mbuf data) clusters. Right now I am thinking of permamently keeping the mbuf linked to the coorsponding permanent cluster. When we recieve a chunk of a PDU it already has the mbuf and it gets linked to the rest of the PDU mbuf chain immediately. This works great except I will need to add a hash lookup based on the VPI/VCI to more quickly find the partially completed PDU. This permanent mbuf code is running right now. I will require a small change to MFREE and use -current refernce count increment function. I have changed my syntax slightly since I last brought this up with the -hacker mailling list to better handle other stacks using the copy of my data. I still have to figure out how much it cost/saves me in freeing time to reap the savings in time when a packet is recieved. 4. bad SAR, bad: I have a C3 version of the SAR on my NICStAR. This has many thing wrong with it, but the last major hurtle for support of the C3 version is the fact that the size of each memory chunk that makes up a PDU must be a multiple of 48 bytes. obviously each PDU is a multiple of 48 bytes trailers include, but each buffer that makes up the PDU must be a multiple of 48 means if we want to support this version of the SAR, in many cases, we will have to copy data to properly align the data. we need to buy new cards anyway, it almost seems easier to get a version E of the SAR. in case anyone is interested in an E version of the card, I was told to do the following to order an E version SAR: You should be able to order a fiber interface NIC with the Rev E (77211) on it. When you place an order it would be p/n 77904 and state for SCD 77211. You should be able to place it with any of our distributors: Future Electronics, Hamilton/Hallmark, Insight or Wyle. 5. my next step: (the next step for me is to add this copy for transmission code into the trasmit code -- right now I am bouncing fixed cells between the transmit of one card to the recieve from the other and back through code in the recieve code in the driver, since my recieve create perfectly aligned cells, I do not have to compenstate for this bug until now). 6. read this before you buy: there is another bug in all of the versions of the IDT SAR, that it cannot use all of the SRAM for transmission SCDs and TST. This will be fixed in chips that ship in the Spring time frame. I found this problem the hard way. 7. let us hear what is new with you or your group: since I rambled on my woes, let us hear what is going on with the rest of you people out there. --mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611151954.NAA14756>