On 09. okt. 2012 19:36, Jesse Brandeburg wrote:
> I'm not sure what went wrong internally here that this hasn't been
> fixed, and I'm personally embarrassed. I am working on it until I have
> a patch/solution.
>
> currently am trying to reproduce the issue, am in some weird how to
> use BQL limbo, the lack of documentation on user usage of BQL is slowing
> me down.
>
> Hints or clues (I'm trying to follow the repro steps mentioned in
> some related threads) are appreciated.
I found it simplest to reproduce when doing forwarding, and *not*
saturating the interface doing the TX. 100Mbps forwarding on gigabit
link triggered it in seconds. Doing gigabit forwarding speeds (~980Mbps)
did not trigger anything.
Setup looked somewhat like this, GE beeing gigabit link, FE 100Mbps;
reciever PC (iperf -s)
|
GE
|
eth0 <- TX lockups
router with 2*e1000e
eth1
|
GE
|
switch
|
FE
|
source PC (iperf -c recieverPC)
I don't recall all the details anymore, but I'm fairly certain I didnt
use any non-default qdiscs to reproduce - eg just pfifo_fast (usually
doing fq_codel though).
For the bug to manifest itself was somewhat dependent on GRO and TSO in
kernel 3.5, but with 3.6 it didnt matter anymore (at least the rc's).
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
E1000-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
