[eepro100] Transmitter Timeout -- addednum

[chris]

Thank you very much, Kallol, I appreciate it!

It seems that in the v1.09 driver that the regular->multicast transmit
command issue was resolved:

In set_rx_mode():

		/* Change the command to a NoOp, pointing to the CmdMulti command. */
		sp->tx_skbuff[entry] = 0;
		sp->tx_ring[entry].status = cpu_to_le32(CmdNOp);
		sp->tx_ring[entry].link = virt_to_le32desc(mc_setup_frm);

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