[lkml]   [2002]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:25    [W:0.025 / U:7.892 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site