Re: sis190

[Francois Romieu]

Pascal CHAPPERON <pascal.chapperon@xxxxxxxxxx> :
[...]
> # i tried to remove NET_IP_ALIGN :

It works but the headers are not aligned any more. It could be interesting
to know what the smallest required alignment is (i.e
dev_alloc_skb(rx_buf_sz + 2^n); skb_reserve(skb, 2^n); increase n and when
the driver starts receiving again, you found it).

> But :
[...]
> Everything failed after 128 packets were received.

Can you give a try at:
http://www.fr.zoreil.com/people/francois/misc/20050616-2.6.12-rc-sis190-test.patch

Please issue a few packets, say 4 to 8, and check your log after an
ethtool -i eth0. Then wait for the Rx process to get stuck and issue
the same ethtool command. You can probably lower NUM_RX_DESC to 16 or
32 to minimize the output.

[...]
> I got a serious headache as i tried to understand how the RX ring works.
> But it is quite too difficult for me now.

The last descriptor of the Rx ring is supposed to be marked with an end
of ring indication (see RingEnd). When it is reached, the asic returns to
the start of the ring. The dirty_rx index locates the first entry in the
ring which is a candidate for refilling (assuming its Rx_skbuff entry is
equal to NULL: when a packet passes rx_copybreak, it does not generate a
hole in the ring). cur_rx locates the currently Rx DMAed buffer.
Both dirty_rx and cur_rx are meaningful % the actual number of entries in
the Rx ring, namely NUM_RX_DESC. Since NUM_RX_DESC usually is a power of
two, it is not uncommon to encounter % NUM_RX_DESC or & (NUM_RX_DESC - 1).

--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/