Bogdan Costescu wrote:
>
> Hi,
Hi, bogdan.
The 3c59x specs can be obtained from
http://support.3com.com/partners/developer/developer_form.html
> I played today with 0.99L on 2.2.15pre16 (SMP) as I was trying to track
> down the Tx timeouts that occur sometimes.
> I noticed that if I set TX_RING_SIZE to 2, I am able to trigger
> the Tx timeout quite often (like 5-6 in 10 minutes) under load; however I
> still don't understand what is going on there.. maybe someone can help?
>
> I put some more printks around and I noticed that the test of tbusy at the
> beginning of boomerang_start_xmit is done at much bigger intervals than
> TX_TIMEOUT (5-600 ticks or more), so the vortex_tx_timeout is called every
> time. Now, if it's called, it always has cur_tx=dirty_tx and tx_full=1,
> which is strange, because cur_tx=dirty_tx means that there are no more
> packets in the tx_ring and tx_full should be 0.
>From a brief reading (forgive me - it's 2:30AM..) I believe it is valid
to have cur_tx == dirty_tx, as long as tx_full is true. However it
would be an interesting experiment to go into boomerang_start_xmit:
vp->cur_tx++;
if (vp->cur_tx - vp->dirty_tx > TX_RING_SIZE - 1)
vp->tx_full = 1;
and make that ">= TX_RING_SIZE - 1". You may have to change the test in
vortex_tx_timeout to reflect these changed semantics though.
> I also found out that at the same time, inl(ioaddr + DownListPtr)=0 which
> means (from what I understand from the driver, I don't have the docs) that
> the card's Tx queue is also empty.
That appears to be true, although it might depend upon the mode in which
the NIC is initialised. Page 93.
> So, vortex_tx_timeout does:
> - outw(TxReset...) and wait
> - tx_errors++
> - Cyclone/Tornado is full bus master, so the condition is TRUE
> - cur_tx - dirty_tx > 0 is FALSE (as they are equal)
> - tx_full is 1 and cur_tx - dirty_tx = 0, so tx_full is set to 0 and
> tbusy is cleared
> - outb(PKT_BUF...)
> - outw(DownUnstall...)
> - outw(TxEnable...)
> - trans_start = jiffies
>
> So, this function does nothing useful in these circumstances (IMO), except
> clearing tx_full and tbusy. To prove this, I removed the out[b,w] calls,
> so the only thing that the function was doing was to clear these 2 flags,
> and it worked.
hmmm... It does write the address of the dirty_tx buffer to
DownListPtr, which should trigger a transmit once the transmitter is
unstalled.
> How is it possible to have tx_full and tbusy set, while cur_tx=dirty_tx?
Well, cur_tx is the _next_ buffer to write to, and dirty_tx is the next
one to send, so there are two pertinent states:
cur_tx = dirty_tx && tx_full = 0: No buffers queued
cur_tx = dirty_tx && tx_full = 1: TX_RING_SIZE buffers queued.
So 'tx_full' changes the interpretation of 'cur_tx = dirty_tx'.
> I was also thinking about putting some test for the above conditions and
> then only reset tx_full and tbusy flags (without doing any HW Tx reset)
> and then continuing as normal with boomerang_start_xmit (not returning 1),
> but I'm not sure that the pointers are correct in all possible situations.
> This checking would allow the queueing of the packet in the current call
> to boomerang_start_xmit (my understanding is that if it returns 1, the
> packet will be retried by the upper level after some delay - which I don't
> know what is: another packet needed to be sent, a timer or whichever
> happens first?)
I'm not sure what triggers a start_xmit retry in kernel 2.2. I believe
the call to netif_wake_queue() in vortex_interrupt will cause a bottom
half handler to be scheduled. On the way back out of the interrupt the
kernel will cause hard_start_xmit to be called if the kernel has more
packets to send. So it'll be a successful Tx interrupt which triggers
another call to start_xmit.
Sounds like you're most of the way there.
--
-akpm-
-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-vortex-bug-request@beowulf.org