[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121124213348.GA8313@electric-eye.fr.zoreil.com>
Date: Sat, 24 Nov 2012 22:33:48 +0100
From: Francois Romieu <romieu@...zoreil.com>
To: David Woodhouse <dwmw2@...radead.org>
Cc: netdev@...r.kernel.org, jasowang@...hat.com, gilboad@...il.com,
jgarzik@...hat.com
Subject: Re: 8139cp TX stall, timeout, failed recovery
David Woodhouse <dwmw2@...radead.org> :
[...]
> To reproduce this, I send a *large* flood of packets (ping -l 1000) from
> inside my network to the ADSL router. Its internal-facing interface is
> an 8139cp. It seems to work best if the packets are destined for the
> outside world over the ADSL lines, rather than the router itself. But
> it's hard to tell. I need between 10 and 30 runs of 'ping -l 1000
> $outside' before it happens. Or sometimes more...
Did you try pktgen as well ?
[...]
> Looking at it now... do we wrap around the Rx ring buffer at 28498.055
> and process some of the packets more than once? Or is the hardware
> genuinely keeping up with us as we suck out, descriptors 51-63, 0-63,
> and 0-39 again all off the same interrupt? Perhaps there lies the root
> of the problem?
Rx slots are always spaced by ~50 us, i.e. more than needed to get a 98 bytes
packets. I do not like the lack of barrier wrt opts2 and opts1 writes for rx
descriptors but it does nprobably not matter for your problem.
If the r8169 experience is any guide, cp_tx_timeout is too light. It should
imho match the init sequence more closely, especially wrt descriptor rings
addresses and CpCmd.
--
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists