Messages in this thread | | | Date | Wed, 10 Apr 2002 18:51:30 +0200 (CEST) | From | Urban Widmark <> | Subject | Re: Via-Rhine stalls - transmit errors |
| |
On Sat, 6 Apr 2002, Ivan G. wrote:
> frame number is evidence that my frame-1 fix is working.
Which frame-1 fix?
> this log seems normal, except > 1) are the addresses supposed to be initialized ? rx addresses are ...
They are written in start_tx when used. The buffer with data comes from the higher levels so it can't be initialised here.
> 2) what exactly do addr and next_desc point to? how can i check those > addresses.
The addr points to the data to transmit. The next_desc simply makes the entries form a ring. I think you can assume that they are ok. But otherwise check what is written in via_rhine_start_tx.
> Look at txstatus - notice one 0002 interrupt (tx done) removes 2 ownership > bits, after which another interrupt removes 0, transmit stops soon, and the > queue keeps going on until timeout. In another log, I recorded many > exit_status interrupts between the ownership lock > and the NETDEV timeout. After the timeout, addr fields are marked bad.
It is intentional that one interrupt can remove more than one used buffer. via_rhine_tx has a loop that tries to clean up all "dirty" tx descriptors. I think that one is ok.
I wonder about the one that removes zero. Why that interrupt happened. Maybe it just happened while the previous interrupt was being handled.
> Notice the cur->tx and dirty->tx reported after timeout.
You don't print cur_tx and dirty_tx, but the slots they point to are strange. You should check what they point to after the tx_timeout routine has completed, they should both be 0 by then.
/Urban
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |