[E1000-devel] Ofertas de Outubro na REFRIMUR!!!
nbsp; Problemas para visualizar a mensagem? Acesse aqui nbsp; Clique para natilde;o receber nossos emails nbsp; nbsp; -- 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 E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net] e1000e: Change wthresh to 1 to avoid possible Tx stalls.
Jesse did not share any performance numbers with me, I am sure he can give some background tomorrow when he is back online. I am working on an alternative patch now and should have something to share tomorrow. Please allow me to ask if there's any progess here? I've tried 3.5.4 a couple of days ago on a SuperMicro X8SIE-LN4 (82574L) and could still observe severe latency (up to 3000ms) spikes. Applying Hiroakis suggested patch did fix this for me as well. [please note as well that I didn't had this issue in any 3.4.x kernel before - so +1 for fixing the regression] 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. -- 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 E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] Problem of using ethtool to change the content of NVM for Intel X540 Controller (8086:1528)
Hi Emil, What version is your ethtool? I wonder if using older version (2.6.33-pre1) of ethtool is the problem I am having. Thanks, --Steven -Original Message- From: Steven La Sent: Monday, October 08, 2012 5:00 PM To: 'Tantilov, Emil S'; e1000-devel@lists.sourceforge.net Subject: RE: [E1000-devel] Problem of using ethtool to change the content of NVM for Intel X540 Controller (8086:1528) Hi Emil, Ethtool actually does not complain anything at all. # /sbin/ethtool -E eth4 magic 0x15288086 offset 1220 value 0 # /sbin/ethtool -E eth4 magic 0x15288086 offset 1221 value 0x0e # /sbin/ethtool -E eth4 magic 0x15288086 offset 1222 value 0xb6 # /sbin/ethtool -E eth4 magic 0x15288086 offset 1223 value 0x04 # /sbin/ethtool -E eth4 magic 0x15288086 offset 1224 value 0x65 # /sbin/ethtool -E eth4 magic 0x15288086 offset 1225 value 0x91 # /sbin/ethtool -e eth4 offset 1220 length 6 Offset Values -- -- 0x04c4 00 0e b6 04 65 91 Howver, after doing the above change on eth4, I found dmesg has these two lines below. --- Extracted from dmesg ixgbe :44:00.1: eth5: NIC Link is Up 100 Mbps, Flow Control: None IPv6: ADDRCONF(NETDEV_CHANGE): eth5: link becomes ready Note that eth5 is just another device of the same type. # ethtool -i eth4 driver: ixgbe version: 3.9.15-k firmware-version: 0x8314 bus-info: :44:00.0 # ethtool -i eth5 driver: ixgbe version: 3.9.15-k firmware-version: 0x8314 bus-info: :44:00.1 # uname -a Linux (none) 3.5.5 #2 SMP Wed Oct 3 11:00:33 PDT 2012 x86_64 GNU/Linux lspci -n | grep 1528 44:00.0 0200: 8086:1528 (rev 01) 44:00.1 0200: 8086:1528 (rev 01) Thanks for looking into this. --Steven -Original Message- From: Tantilov, Emil S [mailto:emil.s.tanti...@intel.com] Sent: Monday, October 08, 2012 4:08 PM To: Steven La; e1000-devel@lists.sourceforge.net Subject: RE: [E1000-devel] Problem of using ethtool to change the content of NVM for Intel X540 Controller (8086:1528) -Original Message- From: Steven La [mailto:steven...@riverbed.com] Sent: Monday, October 08, 2012 4:01 PM To: Tantilov, Emil S; e1000-devel@lists.sourceforge.net Subject: RE: [E1000-devel] Problem of using ethtool to change the content of NVM for Intel X540 Controller (8086:1528) No, CONFIG_STRICT_DEVMEM was not set. Thanks, anyway. --Steven Well I can't think of anything else. We are not able to reproduce the case you're describing in our lab. Could you provide the output of ethtool -e? Thanks, Emil -Original Message- From: Tantilov, Emil S [mailto:emil.s.tanti...@intel.com] Sent: Monday, October 08, 2012 3:40 PM To: Steven La; e1000-devel@lists.sourceforge.net Subject: RE: [E1000-devel] Problem of using ethtool to change the content of NVM for Intel X540 Controller (8086:1528) -Original Message- From: Steven La [mailto:steven...@riverbed.com] Sent: Friday, October 05, 2012 6:24 PM To: e1000-devel@lists.sourceforge.net Subject: [E1000-devel] Problem of using ethtool to change the content of NVM for Intel X540 Controller (8086:1528) Hi all, I am trying to flash a new MAC address into the NVM of the X540 controller using the Linux 3.5 kernel with option CONFIG_IXGBE set to yes. # uname -a Linux (none) 3.5.5 #2 SMP Wed Oct 3 11:00:33 PDT 2012 x86_64 GNU/Linux # ethtool -i eth0 driver: ixgbe version: 3.9.15-k firmware-version: 0x8314 bus-info: :44:00.0 After reading the X540 Controller datasheet, I have figured out the offset of the MAC address start at location 1220 in the NVM (this is for the one of the two functions of the PCI device). I verify the correctness of the offset by doing the following. # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:11:22:33:44:55 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) # /sbin/ethtool -e eth0 offset 1220 length 6 Offset Values -- -- 0x04c4 00 11 22 33 44 55 Then, I program the MAC address by doing the following: # /sbin/ethtool -e eth0 offset 1220 length 6 Offset Values -- -- 0x04c4 00 11 22 33 44 55 # /sbin/ethtool -E eth0 magic 0x15288086 offset 1220 value 0 # /sbin/ethtool -E eth0 magic 0x15288086 offset 1221 value 0x0e # /sbin/ethtool -E eth0 magic 0x15288086 offset 1222 value 0xb1 # /sbin/ethtool -E eth0 magic 0x15288086 offset 1223 value 0xdf # /sbin/ethtool -E eth0 magic 0x15288086 offset 1224 value 0xd5 # /sbin/ethtool -E eth0 magic 0x15288086 offset 1225 value 0xa8 I verify that the content of the NVM has been changed to the new MAC address. # /sbin/ethtool -e eth0 offset 1220
Re: [E1000-devel] [PATCH net] e1000e: Change wthresh to 1 to avoid possible Tx stalls.
On Tue, 2012-10-09 at 10:36 -0700, Jesse Brandeburg wrote: Jesse did not share any performance numbers with me, I am sure he can give some background tomorrow when he is back online. I am working on an alternative patch now and should have something to share tomorrow. Please allow me to ask if there's any progess here? I've tried 3.5.4 a couple of days ago on a SuperMicro X8SIE-LN4 (82574L) and could still observe severe latency (up to 3000ms) spikes. Applying Hiroakis suggested patch did fix this for me as well. [please note as well that I didn't had this issue in any 3.4.x kernel before - so +1 for fixing the regression] 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. BQL is blocking qdisc from delivering additional packet to TX as long as previous packets were not completed. Not sure what you want to know about BQL. Hints or clues (I'm trying to follow the repro steps mentioned in some related threads) are appreciated. Problem is BQL depends on TX completion being done in a reasonable time. It seems e1000e can hold an skb in TX ring for up to 3000ms (not reasonable it seems) Aggregation / coalescing is fine, as long as we dont hold a packet too long, in case no other packet follows. -- 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 E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] [PATCH net] e1000e: Change wthresh to 1 to avoid possible Tx stalls.
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 E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
[E1000-devel] X9SCM-F/82574L/e1000e lag / high latency (e1000e/Intel bug)
Hi, Good news: Supermicro 2.0b fixes an unrelated problem where only 16GB is addressed in the BIOS when you have 32GB on the system, with 2.0b that is resolved. Bad news: This bug still remains (E1000): When you transfer a file/files over Samba, the latency shoots up really high (this also affects other applications!) This bug has been bothering me for months (random lag) during high network I/O on my X9SCM-F motherboard. There is a lot of discussion about this problem here: http://sourceforge.net/p/e1000/bugs/27/?page=4 I tried the EEPROM fix but it did not work: http://sourceforge.net/projects/e1000/files/e1000e%20stable/eeprom_fix_82574 _or_82583/ The value at offset 0x001e (58) has bit 1 unset. This enables the problematic power saving feature. In this case, the EEPROM needs to read 5a at offset 0x001e. # ethtool -e eth4 |grep 0x0010 0x0010: ff ff ff ff 6b 02 00 00 d9 15 d3 10 ff ff 5a a5 Yes I did reboot. Here is what the problem looks like, during a SAMBA copy from A-B where B=X9SCM running Linux: (ONBOARD Intel eth0 / 82574L ) $ ping windowspc PING windowspc (192.168.0.1) 56(84) bytes of data. 64 bytes from windowspc (192.168.0.1): icmp_req=1 ttl=128 time=0.544 ms 64 bytes from windowspc (192.168.0.1): icmp_req=2 ttl=128 time=0.193 ms 64 bytes from windowspc (192.168.0.1): icmp_req=3 ttl=128 time=0.619 ms 64 bytes from windowspc (192.168.0.1): icmp_req=4 ttl=128 time=0.642 ms 64 bytes from windowspc (192.168.0.1): icmp_req=5 ttl=128 time=0.426 ms 64 bytes from windowspc (192.168.0.1): icmp_req=6 ttl=128 time=0.464 ms 64 bytes from windowspc (192.168.0.1): icmp_req=7 ttl=128 time=0.696 ms 64 bytes from windowspc (192.168.0.1): icmp_req=8 ttl=128 time=1353 ms 64 bytes from windowspc (192.168.0.1): icmp_req=9 ttl=128 time=353 ms 64 bytes from windowspc (192.168.0.1): icmp_req=10 ttl=128 time=0.492 ms 64 bytes from windowspc (192.168.0.1): icmp_req=11 ttl=128 time=0.618 ms 64 bytes from windowspc (192.168.0.1): icmp_req=12 ttl=128 time=0.474 ms 64 bytes from windowspc (192.168.0.1): icmp_req=13 ttl=128 time=0.542 ms 64 bytes from windowspc (192.168.0.1): icmp_req=14 ttl=128 time=0.471 ms 64 bytes from windowspc (192.168.0.1): icmp_req=15 ttl=128 time=0.645 ms 64 bytes from windowspc (192.168.0.1): icmp_req=16 ttl=128 time=0.394 ms 64 bytes from windowspc (192.168.0.1): icmp_req=17 ttl=128 time=0.537 ms 64 bytes from windowspc (192.168.0.1): icmp_req=18 ttl=128 time=0.706 ms 64 bytes from windowspc (192.168.0.1): icmp_req=19 ttl=128 time=0.465 ms 64 bytes from windowspc (192.168.0.1): icmp_req=20 ttl=128 time=0.707 ms 64 bytes from windowspc (192.168.0.1): icmp_req=21 ttl=128 time=348 ms 64 bytes from windowspc (192.168.0.1): icmp_req=22 ttl=128 time=0.703 ms 64 bytes from windowspc (192.168.0.1): icmp_req=23 ttl=128 time=0.560 ms 64 bytes from windowspc (192.168.0.1): icmp_req=24 ttl=128 time=0.554 ms 64 bytes from windowspc (192.168.0.1): icmp_req=25 ttl=128 time=0.585 ms 64 bytes from windowspc (192.168.0.1): icmp_req=26 ttl=128 time=0.508 ms 64 bytes from windowspc (192.168.0.1): icmp_req=27 ttl=128 time=345 ms 64 bytes from windowspc (192.168.0.1): icmp_req=28 ttl=128 time=0.374 ms 64 bytes from windowspc (192.168.0.1): icmp_req=29 ttl=128 time=0.728 ms 64 bytes from windowspc (192.168.0.1): icmp_req=30 ttl=128 time=0.537 ms 64 bytes from windowspc (192.168.0.1): icmp_req=31 ttl=128 time=0.190 ms 64 bytes from windowspc (192.168.0.1): icmp_req=32 ttl=128 time=0.204 ms 64 bytes from windowspc (192.168.0.1): icmp_req=33 ttl=128 time=0.239 ms Same test (copy test) with samba as above but now with an Intel 4-port NIC: $ ping windowspc 64 bytes from windowspc (192.168.0.1): icmp_req=1 ttl=128 time=0.175 ms 64 bytes from windowspc (192.168.0.1): icmp_req=2 ttl=128 time=0.332 ms 64 bytes from windowspc (192.168.0.1): icmp_req=3 ttl=128 time=0.276 ms 64 bytes from windowspc (192.168.0.1): icmp_req=4 ttl=128 time=0.221 ms 64 bytes from windowspc (192.168.0.1): icmp_req=5 ttl=128 time=0.518 ms 64 bytes from windowspc (192.168.0.1): icmp_req=6 ttl=128 time=0.157 ms 64 bytes from windowspc (192.168.0.1): icmp_req=7 ttl=128 time=0.222 ms 64 bytes from windowspc (192.168.0.1): icmp_req=8 ttl=128 time=0.605 ms 64 bytes from windowspc (192.168.0.1): icmp_req=9 ttl=128 time=0.335 ms 64 bytes from windowspc (192.168.0.1): icmp_req=10 ttl=128 time=0.679 ms 64 bytes from windowspc (192.168.0.1): icmp_req=11 ttl=128 time=0.223 ms 64 bytes from windowspc (192.168.0.1): icmp_req=12 ttl=128 time=0.189 ms 64 bytes from windowspc (192.168.0.1): icmp_req=13 ttl=128 time=0.432 ms 64 bytes from windowspc (192.168.0.1): icmp_req=14 ttl=128 time=0.235 ms 64 bytes from windowspc (192.168.0.1): icmp_req=15 ttl=128 time=0.386 ms 64 bytes from windowspc (192.168.0.1): icmp_req=16 ttl=128 time=0.658 ms 64 bytes from windowspc (192.168.0.1): icmp_req=17 ttl=128 time=0.430 ms 64 bytes from windowspc (192.168.0.1): icmp_req=18 ttl=128 time=0.494 ms 64 bytes from windowspc (192.168.0.1): icmp_req=19 ttl=128 time=0.411
Re: [E1000-devel] [PATCH net] e1000e: Change wthresh to 1 to avoid possible Tx stalls.
On 10.10.2012 00:48, Andre Tomt wrote: On 09. okt. 2012 19:36, Jesse Brandeburg wrote: [...] Hints or clues (I'm trying to follow the repro steps mentioned in some related threads) are appreciated. In our scenario - the SuperMicro X8SIE-LN4 acts as a router. eth0 - uplink eth1 - core servers network 192.168.a.b/24 eth2 - developer employees network 192.168.c.d/24 eth1 and eth2 are hooked into (two different) HP2510-24G switches (they both show no errors at all). The switch connected to eth2 connects a bunch of developers doing day-2-day stuff (commits/checkouts/documentation/ listening to stream music/surfing/email) and the such. Continously running a ping from ie. 192.168.c.d/24 to 192.168.a.b/24 visualizes those spikes (mostly triplets, where the first echo reply is quite high and the two following replies are each around 50 percent faster - but mostly still 500ms) - whenever these spikes happen, it feels like the whole net 'stalls'. Just like Denys Fedoryshchenko stated in http://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg05517.html HTH, Frank Reppin -- 43rd Law of Computing: Anything that can go wr fortune: Segmentation violation -- Core dumped -- 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 E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
