[eepro100] Transmitter Timeout -- addednum

[Kallol Biswas]

Chris,
       I would be happy to share my modifications, rather the design
of my driver if I was allowed to, but the driver is for hp-ux and on
Itanium based system.

You may change the eepro100 to put a cmd NOP after you set the S bit,
probably intel's linux driver already does it.

About developing a new driver, you could use the card 3C905CTXM from 
3COM they have the programming manual publicly available at:
	support.3com.com/partners/developer/license.html

Bye,
Kallol

> 
> I could not see the driver accounting for any other cases . . . would
> you be so kind as to send me a copy of your "modified" driver so that I
> may see what you did?
> 
> 
> The code for the eepro100 driver is confusing me a bit. . . the rx ring
> seems pretty clear and concise:
> 
> 	* ethx is discovered and pci_dev is set up
> 	* pci_dev functions point to speedo functions, and a pointer is made to
> struct speedo_private
> 	* a ring of RX_RING_SIZE sk_buffs is set up, and for each sk_buff a
> RxFD->rx_buf_addr is pointed to sk_buff->tail
> 	* in speedo_private an array of rx_skbuf[] is set up pointing to the
> sk_buffs
> 	* in speedo_private an array rx_ringp[] is set up pointing to the RxFs
> 	* the eepro100 card DMAs the incoming data into the sk_buff->tail
> pointed to by the RxF
> 	* the kernel knows how to deal with the sk_buff and takes the data.
> 	* not too shure on how the RxF are marked dirty and dealt with, but
> that is not the issue.
> 
> As I had said, stright out of the text-book DMA-oriented driver. . . but
> I can't figure out for the life of me how the tx ring is dealt with. . .
> I'm assuming that the data to be sent is held in the same sk_buff
> structure ring as the recieved data, but I can't even find where the
> tx_ring[] is set up, nor can I grep out the structure definition for
> sk_buff. . . .
> 
> In fact the only functions that I could find that are tx-oriented are
> speedo_tx_timeout() which only seems to be dealt with how to reset the
> card on a timeout and is only called by the kernel through the
> pci_dev->tx_timeout() pointer, speedo_start_xmit() which seems to be
> only called after the card changes transmit modes, and
> speedo_tx_buffer_gc() which seems to free dirty tx sk_buffs and
> increment the packet counter. . .why the driver frees sk_buffs, I also
> don't understand, because as I see it the ring of sk_buffs are allocated
> at init time and are marked as "dirty" so that new data is allowed to be
> put in it. . . . .
> 
> I appreciate your patience and help in this matter.  I am fresh out of
> college and have never witten a driver for linux before so thus it is a
> little tricky for me to understand some of the very OS-orinted routines.
> . . I did write a USB driver for a pure-hardware setup on an Ascend 550
> series ATM switch in an internship, but that was very easy seeing that I
> did not have to deal with an OS. . . .
> 
> I think after I figure this all out I'm going to go out an find an
> obscure network card that a linux driver has not been written for and
> give it a shot from scratch :). . . .recommend any good books?
> 
> Thanks,
> Chris
> 
> _______________________________________________
> eepro100 mailing list
> eepro100@scyld.com
> http://www.scyld.com/mailman/listinfo/eepro100
> 


--
Phone: 973-443-7469
Telnet: 1-443-7469
www.kallolbiswas.com
kallol_biswas@hp.com