Re: Fwd: Re: e1000 1sec latency problem
Ray Lee wrote: > On Feb 9, 2008 1:51 PM, Kok, Auke <[EMAIL PROTECTED]> wrote: >> Martin Rogge wrote: >>> On Saturday 09 February 2008 11:07:26 Martin Rogge wrote: >>>> Hi, >>>> >>>> I am not so familiar with the various mailing lists and missed out on >>>> [EMAIL PROTECTED] the first time. Please cc me on any >>>> replies. >>>> >>>> I am looking for help with either making the e1000e driver work on my >>>> Thinkpad T60 or fixing the 1s latency issue with e1000. >>>> >>>> To be honest, I do not understand why the e1000e driver failed to recognize >>>> the NIC when I tried. At least, I noticed the correct device ID is defined >>>> in drivers/net/e1000e/hw.h: >>>> >>>> #define E1000_DEV_ID_82573L 0x109A >>>> >>>> Any help is appreciated. >>>> >>>> Thanks, >>>> >>>> Martin >>>> >>>> -- Forwarded Message -- >>>> >>>> Subject: Re: e1000 1sec latency problem >>>> Date: Thursday 07 February 2008 >>>> From: Martin Rogge <[EMAIL PROTECTED]> >>>> To: linux-kernel@vger.kernel.org >>>> >>>> Pavel Machek wrote: >>>>> Hi! >>>>> >>>>> I have the famous e1000 latency problems: >>>> Hi, I have the same problem with my Thinkpad T60. >>>> >>>> [EMAIL PROTECTED]:~# ping arnold >>>> PING arnold (192.168.158.6) 56(84) bytes of data. >>>> 64 bytes from arnold (192.168.158.6): icmp_seq=1 ttl=64 time=49.7 ms >>>> 64 bytes from arnold (192.168.158.6): icmp_seq=2 ttl=64 time=0.438 ms >>>> 64 bytes from arnold (192.168.158.6): icmp_seq=3 ttl=64 time=1000 ms >>>> 64 bytes from arnold (192.168.158.6): icmp_seq=4 ttl=64 time=0.970 ms >>>> 64 bytes from arnold (192.168.158.6): icmp_seq=5 ttl=64 time=885 ms >>>> 64 bytes from arnold (192.168.158.6): icmp_seq=6 ttl=64 time=0.484 ms >>>> 64 bytes from arnold (192.168.158.6): icmp_seq=7 ttl=64 time=529 ms >>>> 64 bytes from arnold (192.168.158.6): icmp_seq=8 ttl=64 time=1.02 ms >>>> 64 bytes from arnold (192.168.158.6): icmp_seq=9 ttl=64 time=149 ms >>>> 64 bytes from arnold (192.168.158.6): icmp_seq=10 ttl=64 time=0.549 ms >>>> 64 bytes from arnold (192.168.158.6): icmp_seq=11 ttl=64 time=0.829 ms >>>> >>>> --- arnold ping statistics --- >>>> 11 packets transmitted, 11 received, 0% packet loss, time ms >>>> rtt min/avg/max/mdev = 0.438/238.113/1000.967/365.279 ms, pipe 2 >>>> [EMAIL PROTECTED]:~# uname -a >>>> Linux zorro 2.6.24 #6 SMP PREEMPT Sun Feb 3 18:27:48 CET 2008 i686 Intel(R) >>>> Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux >>>> [EMAIL PROTECTED]:~# lspci -vvv >>> [stuff deleted] >>> >>>> Unfortunately the e1000e driver is not an option as it will not detect the >>>> NIC: >>>> >>>> from dmesg with e1000 compiled in: >>>> Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI >>>> Copyright (c) 1999-2006 Intel Corporation. >>>> ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, low) -> IRQ 16 >>>> PCI: Setting latency timer of device :02:00.0 to 64 >>>> e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) >>>> 00:15:58:c3:3a:71 >>>> e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection >>>> >>>> from dmesg with e1000e compiled in: >>>> e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0 >>>> e1000e: Copyright (c) 1999-2007 Intel Corporation. >>>> >>>> Any pointers? >>>> >>>> Thanks, >>>> >>>> Martin >>>> >>>> >>>> >>>> --- >>> Just for the records, I googled the following solution for the Lenovo T60: >>> >>> (a) use the e1000 driver >>> (b) if compiling as a module, add the following parameter to modprobe.conf: >>> options e1000 RxIntDelay=5 >>> (c) if compiling a static driver, use the following patch (based on 2.6.24): >>> >>> --- e1000_param.c.orig2008-01-24 23:58:37.0 +0100 >>> +++ e1000_param.c 2008-02-09 20:42:23.0 +0100 >>> @@ -158,7 +158,7 @@ >>> * Valid Range: 0-65535 >>> */ >>
Re: Fwd: Re: e1000 1sec latency problem
On Feb 9, 2008 1:51 PM, Kok, Auke <[EMAIL PROTECTED]> wrote: > > Martin Rogge wrote: > > On Saturday 09 February 2008 11:07:26 Martin Rogge wrote: > >> Hi, > >> > >> I am not so familiar with the various mailing lists and missed out on > >> [EMAIL PROTECTED] the first time. Please cc me on any > >> replies. > >> > >> I am looking for help with either making the e1000e driver work on my > >> Thinkpad T60 or fixing the 1s latency issue with e1000. > >> > >> To be honest, I do not understand why the e1000e driver failed to recognize > >> the NIC when I tried. At least, I noticed the correct device ID is defined > >> in drivers/net/e1000e/hw.h: > >> > >> #define E1000_DEV_ID_82573L0x109A > >> > >> Any help is appreciated. > >> > >> Thanks, > >> > >> Martin > >> > >> -- Forwarded Message -- > >> > >> Subject: Re: e1000 1sec latency problem > >> Date: Thursday 07 February 2008 > >> From: Martin Rogge <[EMAIL PROTECTED]> > >> To: linux-kernel@vger.kernel.org > >> > >> Pavel Machek wrote: > >>> Hi! > >>> > >>> I have the famous e1000 latency problems: > >> Hi, I have the same problem with my Thinkpad T60. > >> > >> [EMAIL PROTECTED]:~# ping arnold > >> PING arnold (192.168.158.6) 56(84) bytes of data. > >> 64 bytes from arnold (192.168.158.6): icmp_seq=1 ttl=64 time=49.7 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=2 ttl=64 time=0.438 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=3 ttl=64 time=1000 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=4 ttl=64 time=0.970 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=5 ttl=64 time=885 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=6 ttl=64 time=0.484 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=7 ttl=64 time=529 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=8 ttl=64 time=1.02 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=9 ttl=64 time=149 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=10 ttl=64 time=0.549 ms > >> 64 bytes from arnold (192.168.158.6): icmp_seq=11 ttl=64 time=0.829 ms > >> > >> --- arnold ping statistics --- > >> 11 packets transmitted, 11 received, 0% packet loss, time ms > >> rtt min/avg/max/mdev = 0.438/238.113/1000.967/365.279 ms, pipe 2 > >> [EMAIL PROTECTED]:~# uname -a > >> Linux zorro 2.6.24 #6 SMP PREEMPT Sun Feb 3 18:27:48 CET 2008 i686 Intel(R) > >> Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux > >> [EMAIL PROTECTED]:~# lspci -vvv > > > > [stuff deleted] > > > >> Unfortunately the e1000e driver is not an option as it will not detect the > >> NIC: > >> > >> from dmesg with e1000 compiled in: > >> Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI > >> Copyright (c) 1999-2006 Intel Corporation. > >> ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, low) -> IRQ 16 > >> PCI: Setting latency timer of device :02:00.0 to 64 > >> e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) > >> 00:15:58:c3:3a:71 > >> e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > >> > >> from dmesg with e1000e compiled in: > >> e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0 > >> e1000e: Copyright (c) 1999-2007 Intel Corporation. > >> > >> Any pointers? > >> > >> Thanks, > >> > >> Martin > >> > >> > >> > >> --- > > > > Just for the records, I googled the following solution for the Lenovo T60: > > > > (a) use the e1000 driver > > (b) if compiling as a module, add the following parameter to modprobe.conf: > > options e1000 RxIntDelay=5 > > (c) if compiling a static driver, use the following patch (based on 2.6.24): > > > > --- e1000_param.c.orig2008-01-24 23:58:37.0 +0100 > > +++ e1000_param.c 2008-02-09 20:42:23.0 +0100 > > @@ -158,7 +158,7 @@ > > * Valid Range: 0-65535 > > */ > > E1000_PARAM(RxIntDelay, "Receive Interrupt Delay"); > > -#define DEFAULT_RDTR 0 > > +#define DEFAULT_RDTR 5 > > #define MAX_RXDELAY 0x > > #define MIN_RXDELAY0 > > > > After reboot, the average ping time is still factor 10 worse than it should > > be, but it stays below 2 ms (which is a remarkable improvement compared to > > 1000 ms). > > correct, this was a workaround which improved things for most people, but did > not > *fix* it. > > the real fix is to disable L1 ASPM alltogether at the cost of more power > consumption, which is what is in e1000e in 2.6.25-git. e1000e doesn't recognize his NIC. Will you be adding this to the e1000 driver as well? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: e1000 1sec latency problem
Martin Rogge wrote: > On Saturday 09 February 2008 11:07:26 Martin Rogge wrote: >> Hi, >> >> I am not so familiar with the various mailing lists and missed out on >> [EMAIL PROTECTED] the first time. Please cc me on any >> replies. >> >> I am looking for help with either making the e1000e driver work on my >> Thinkpad T60 or fixing the 1s latency issue with e1000. >> >> To be honest, I do not understand why the e1000e driver failed to recognize >> the NIC when I tried. At least, I noticed the correct device ID is defined >> in drivers/net/e1000e/hw.h: >> >> #define E1000_DEV_ID_82573L0x109A >> >> Any help is appreciated. >> >> Thanks, >> >> Martin >> >> -- Forwarded Message -- >> >> Subject: Re: e1000 1sec latency problem >> Date: Thursday 07 February 2008 >> From: Martin Rogge <[EMAIL PROTECTED]> >> To: linux-kernel@vger.kernel.org >> >> Pavel Machek wrote: >>> Hi! >>> >>> I have the famous e1000 latency problems: >> Hi, I have the same problem with my Thinkpad T60. >> >> [EMAIL PROTECTED]:~# ping arnold >> PING arnold (192.168.158.6) 56(84) bytes of data. >> 64 bytes from arnold (192.168.158.6): icmp_seq=1 ttl=64 time=49.7 ms >> 64 bytes from arnold (192.168.158.6): icmp_seq=2 ttl=64 time=0.438 ms >> 64 bytes from arnold (192.168.158.6): icmp_seq=3 ttl=64 time=1000 ms >> 64 bytes from arnold (192.168.158.6): icmp_seq=4 ttl=64 time=0.970 ms >> 64 bytes from arnold (192.168.158.6): icmp_seq=5 ttl=64 time=885 ms >> 64 bytes from arnold (192.168.158.6): icmp_seq=6 ttl=64 time=0.484 ms >> 64 bytes from arnold (192.168.158.6): icmp_seq=7 ttl=64 time=529 ms >> 64 bytes from arnold (192.168.158.6): icmp_seq=8 ttl=64 time=1.02 ms >> 64 bytes from arnold (192.168.158.6): icmp_seq=9 ttl=64 time=149 ms >> 64 bytes from arnold (192.168.158.6): icmp_seq=10 ttl=64 time=0.549 ms >> 64 bytes from arnold (192.168.158.6): icmp_seq=11 ttl=64 time=0.829 ms >> >> --- arnold ping statistics --- >> 11 packets transmitted, 11 received, 0% packet loss, time ms >> rtt min/avg/max/mdev = 0.438/238.113/1000.967/365.279 ms, pipe 2 >> [EMAIL PROTECTED]:~# uname -a >> Linux zorro 2.6.24 #6 SMP PREEMPT Sun Feb 3 18:27:48 CET 2008 i686 Intel(R) >> Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux >> [EMAIL PROTECTED]:~# lspci -vvv > > [stuff deleted] > >> Unfortunately the e1000e driver is not an option as it will not detect the >> NIC: >> >> from dmesg with e1000 compiled in: >> Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI >> Copyright (c) 1999-2006 Intel Corporation. >> ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, low) -> IRQ 16 >> PCI: Setting latency timer of device :02:00.0 to 64 >> e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) >> 00:15:58:c3:3a:71 >> e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection >> >> from dmesg with e1000e compiled in: >> e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0 >> e1000e: Copyright (c) 1999-2007 Intel Corporation. >> >> Any pointers? >> >> Thanks, >> >> Martin >> >> >> >> --- > > Just for the records, I googled the following solution for the Lenovo T60: > > (a) use the e1000 driver > (b) if compiling as a module, add the following parameter to modprobe.conf: > options e1000 RxIntDelay=5 > (c) if compiling a static driver, use the following patch (based on 2.6.24): > > --- e1000_param.c.orig2008-01-24 23:58:37.0 +0100 > +++ e1000_param.c 2008-02-09 20:42:23.0 +0100 > @@ -158,7 +158,7 @@ > * Valid Range: 0-65535 > */ > E1000_PARAM(RxIntDelay, "Receive Interrupt Delay"); > -#define DEFAULT_RDTR 0 > +#define DEFAULT_RDTR 5 > #define MAX_RXDELAY 0x > #define MIN_RXDELAY0 > > After reboot, the average ping time is still factor 10 worse than it should > be, but it stays below 2 ms (which is a remarkable improvement compared to > 1000 ms). correct, this was a workaround which improved things for most people, but did not *fix* it. the real fix is to disable L1 ASPM alltogether at the cost of more power consumption, which is what is in e1000e in 2.6.25-git. Cheers, Auke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: e1000 1sec latency problem
On Saturday 09 February 2008 11:07:26 Martin Rogge wrote: > Hi, > > I am not so familiar with the various mailing lists and missed out on > [EMAIL PROTECTED] the first time. Please cc me on any > replies. > > I am looking for help with either making the e1000e driver work on my > Thinkpad T60 or fixing the 1s latency issue with e1000. > > To be honest, I do not understand why the e1000e driver failed to recognize > the NIC when I tried. At least, I noticed the correct device ID is defined > in drivers/net/e1000e/hw.h: > > #define E1000_DEV_ID_82573L0x109A > > Any help is appreciated. > > Thanks, > > Martin > > ------ Forwarded Message -- > > Subject: Re: e1000 1sec latency problem > Date: Thursday 07 February 2008 > From: Martin Rogge <[EMAIL PROTECTED]> > To: linux-kernel@vger.kernel.org > > Pavel Machek wrote: > > Hi! > > > > I have the famous e1000 latency problems: > > Hi, I have the same problem with my Thinkpad T60. > > [EMAIL PROTECTED]:~# ping arnold > PING arnold (192.168.158.6) 56(84) bytes of data. > 64 bytes from arnold (192.168.158.6): icmp_seq=1 ttl=64 time=49.7 ms > 64 bytes from arnold (192.168.158.6): icmp_seq=2 ttl=64 time=0.438 ms > 64 bytes from arnold (192.168.158.6): icmp_seq=3 ttl=64 time=1000 ms > 64 bytes from arnold (192.168.158.6): icmp_seq=4 ttl=64 time=0.970 ms > 64 bytes from arnold (192.168.158.6): icmp_seq=5 ttl=64 time=885 ms > 64 bytes from arnold (192.168.158.6): icmp_seq=6 ttl=64 time=0.484 ms > 64 bytes from arnold (192.168.158.6): icmp_seq=7 ttl=64 time=529 ms > 64 bytes from arnold (192.168.158.6): icmp_seq=8 ttl=64 time=1.02 ms > 64 bytes from arnold (192.168.158.6): icmp_seq=9 ttl=64 time=149 ms > 64 bytes from arnold (192.168.158.6): icmp_seq=10 ttl=64 time=0.549 ms > 64 bytes from arnold (192.168.158.6): icmp_seq=11 ttl=64 time=0.829 ms > > --- arnold ping statistics --- > 11 packets transmitted, 11 received, 0% packet loss, time ms > rtt min/avg/max/mdev = 0.438/238.113/1000.967/365.279 ms, pipe 2 > [EMAIL PROTECTED]:~# uname -a > Linux zorro 2.6.24 #6 SMP PREEMPT Sun Feb 3 18:27:48 CET 2008 i686 Intel(R) > Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux > [EMAIL PROTECTED]:~# lspci -vvv [stuff deleted] > Unfortunately the e1000e driver is not an option as it will not detect the > NIC: > > from dmesg with e1000 compiled in: > Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI > Copyright (c) 1999-2006 Intel Corporation. > ACPI: PCI Interrupt :02:00.0[A] -> GSI 16 (level, low) -> IRQ 16 > PCI: Setting latency timer of device :02:00.0 to 64 > e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) > 00:15:58:c3:3a:71 > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > > from dmesg with e1000e compiled in: > e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0 > e1000e: Copyright (c) 1999-2007 Intel Corporation. > > Any pointers? > > Thanks, > > Martin > > > > --- Just for the records, I googled the following solution for the Lenovo T60: (a) use the e1000 driver (b) if compiling as a module, add the following parameter to modprobe.conf: options e1000 RxIntDelay=5 (c) if compiling a static driver, use the following patch (based on 2.6.24): --- e1000_param.c.orig 2008-01-24 23:58:37.0 +0100 +++ e1000_param.c 2008-02-09 20:42:23.0 +0100 @@ -158,7 +158,7 @@ * Valid Range: 0-65535 */ E1000_PARAM(RxIntDelay, "Receive Interrupt Delay"); -#define DEFAULT_RDTR 0 +#define DEFAULT_RDTR 5 #define MAX_RXDELAY 0x #define MIN_RXDELAY0 After reboot, the average ping time is still factor 10 worse than it should be, but it stays below 2 ms (which is a remarkable improvement compared to 1000 ms). Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: e1000 1sec latency problem
On Saturday 09 February 2008 11:07:26 Martin Rogge wrote: Hi, I am not so familiar with the various mailing lists and missed out on [EMAIL PROTECTED] the first time. Please cc me on any replies. I am looking for help with either making the e1000e driver work on my Thinkpad T60 or fixing the 1s latency issue with e1000. To be honest, I do not understand why the e1000e driver failed to recognize the NIC when I tried. At least, I noticed the correct device ID is defined in drivers/net/e1000e/hw.h: #define E1000_DEV_ID_82573L0x109A Any help is appreciated. Thanks, Martin -- Forwarded Message -- Subject: Re: e1000 1sec latency problem Date: Thursday 07 February 2008 From: Martin Rogge [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org Pavel Machek wrote: Hi! I have the famous e1000 latency problems: Hi, I have the same problem with my Thinkpad T60. [EMAIL PROTECTED]:~# ping arnold PING arnold (192.168.158.6) 56(84) bytes of data. 64 bytes from arnold (192.168.158.6): icmp_seq=1 ttl=64 time=49.7 ms 64 bytes from arnold (192.168.158.6): icmp_seq=2 ttl=64 time=0.438 ms 64 bytes from arnold (192.168.158.6): icmp_seq=3 ttl=64 time=1000 ms 64 bytes from arnold (192.168.158.6): icmp_seq=4 ttl=64 time=0.970 ms 64 bytes from arnold (192.168.158.6): icmp_seq=5 ttl=64 time=885 ms 64 bytes from arnold (192.168.158.6): icmp_seq=6 ttl=64 time=0.484 ms 64 bytes from arnold (192.168.158.6): icmp_seq=7 ttl=64 time=529 ms 64 bytes from arnold (192.168.158.6): icmp_seq=8 ttl=64 time=1.02 ms 64 bytes from arnold (192.168.158.6): icmp_seq=9 ttl=64 time=149 ms 64 bytes from arnold (192.168.158.6): icmp_seq=10 ttl=64 time=0.549 ms 64 bytes from arnold (192.168.158.6): icmp_seq=11 ttl=64 time=0.829 ms --- arnold ping statistics --- 11 packets transmitted, 11 received, 0% packet loss, time ms rtt min/avg/max/mdev = 0.438/238.113/1000.967/365.279 ms, pipe 2 [EMAIL PROTECTED]:~# uname -a Linux zorro 2.6.24 #6 SMP PREEMPT Sun Feb 3 18:27:48 CET 2008 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux [EMAIL PROTECTED]:~# lspci -vvv [stuff deleted] Unfortunately the e1000e driver is not an option as it will not detect the NIC: from dmesg with e1000 compiled in: Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, low) - IRQ 16 PCI: Setting latency timer of device :02:00.0 to 64 e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:15:58:c3:3a:71 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection from dmesg with e1000e compiled in: e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0 e1000e: Copyright (c) 1999-2007 Intel Corporation. Any pointers? Thanks, Martin --- Just for the records, I googled the following solution for the Lenovo T60: (a) use the e1000 driver (b) if compiling as a module, add the following parameter to modprobe.conf: options e1000 RxIntDelay=5 (c) if compiling a static driver, use the following patch (based on 2.6.24): --- e1000_param.c.orig 2008-01-24 23:58:37.0 +0100 +++ e1000_param.c 2008-02-09 20:42:23.0 +0100 @@ -158,7 +158,7 @@ * Valid Range: 0-65535 */ E1000_PARAM(RxIntDelay, Receive Interrupt Delay); -#define DEFAULT_RDTR 0 +#define DEFAULT_RDTR 5 #define MAX_RXDELAY 0x #define MIN_RXDELAY0 After reboot, the average ping time is still factor 10 worse than it should be, but it stays below 2 ms (which is a remarkable improvement compared to 1000 ms). Martin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: e1000 1sec latency problem
Martin Rogge wrote: On Saturday 09 February 2008 11:07:26 Martin Rogge wrote: Hi, I am not so familiar with the various mailing lists and missed out on [EMAIL PROTECTED] the first time. Please cc me on any replies. I am looking for help with either making the e1000e driver work on my Thinkpad T60 or fixing the 1s latency issue with e1000. To be honest, I do not understand why the e1000e driver failed to recognize the NIC when I tried. At least, I noticed the correct device ID is defined in drivers/net/e1000e/hw.h: #define E1000_DEV_ID_82573L0x109A Any help is appreciated. Thanks, Martin -- Forwarded Message -- Subject: Re: e1000 1sec latency problem Date: Thursday 07 February 2008 From: Martin Rogge [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org Pavel Machek wrote: Hi! I have the famous e1000 latency problems: Hi, I have the same problem with my Thinkpad T60. [EMAIL PROTECTED]:~# ping arnold PING arnold (192.168.158.6) 56(84) bytes of data. 64 bytes from arnold (192.168.158.6): icmp_seq=1 ttl=64 time=49.7 ms 64 bytes from arnold (192.168.158.6): icmp_seq=2 ttl=64 time=0.438 ms 64 bytes from arnold (192.168.158.6): icmp_seq=3 ttl=64 time=1000 ms 64 bytes from arnold (192.168.158.6): icmp_seq=4 ttl=64 time=0.970 ms 64 bytes from arnold (192.168.158.6): icmp_seq=5 ttl=64 time=885 ms 64 bytes from arnold (192.168.158.6): icmp_seq=6 ttl=64 time=0.484 ms 64 bytes from arnold (192.168.158.6): icmp_seq=7 ttl=64 time=529 ms 64 bytes from arnold (192.168.158.6): icmp_seq=8 ttl=64 time=1.02 ms 64 bytes from arnold (192.168.158.6): icmp_seq=9 ttl=64 time=149 ms 64 bytes from arnold (192.168.158.6): icmp_seq=10 ttl=64 time=0.549 ms 64 bytes from arnold (192.168.158.6): icmp_seq=11 ttl=64 time=0.829 ms --- arnold ping statistics --- 11 packets transmitted, 11 received, 0% packet loss, time ms rtt min/avg/max/mdev = 0.438/238.113/1000.967/365.279 ms, pipe 2 [EMAIL PROTECTED]:~# uname -a Linux zorro 2.6.24 #6 SMP PREEMPT Sun Feb 3 18:27:48 CET 2008 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux [EMAIL PROTECTED]:~# lspci -vvv [stuff deleted] Unfortunately the e1000e driver is not an option as it will not detect the NIC: from dmesg with e1000 compiled in: Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, low) - IRQ 16 PCI: Setting latency timer of device :02:00.0 to 64 e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:15:58:c3:3a:71 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection from dmesg with e1000e compiled in: e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0 e1000e: Copyright (c) 1999-2007 Intel Corporation. Any pointers? Thanks, Martin --- Just for the records, I googled the following solution for the Lenovo T60: (a) use the e1000 driver (b) if compiling as a module, add the following parameter to modprobe.conf: options e1000 RxIntDelay=5 (c) if compiling a static driver, use the following patch (based on 2.6.24): --- e1000_param.c.orig2008-01-24 23:58:37.0 +0100 +++ e1000_param.c 2008-02-09 20:42:23.0 +0100 @@ -158,7 +158,7 @@ * Valid Range: 0-65535 */ E1000_PARAM(RxIntDelay, Receive Interrupt Delay); -#define DEFAULT_RDTR 0 +#define DEFAULT_RDTR 5 #define MAX_RXDELAY 0x #define MIN_RXDELAY0 After reboot, the average ping time is still factor 10 worse than it should be, but it stays below 2 ms (which is a remarkable improvement compared to 1000 ms). correct, this was a workaround which improved things for most people, but did not *fix* it. the real fix is to disable L1 ASPM alltogether at the cost of more power consumption, which is what is in e1000e in 2.6.25-git. Cheers, Auke -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: e1000 1sec latency problem
On Feb 9, 2008 1:51 PM, Kok, Auke [EMAIL PROTECTED] wrote: Martin Rogge wrote: On Saturday 09 February 2008 11:07:26 Martin Rogge wrote: Hi, I am not so familiar with the various mailing lists and missed out on [EMAIL PROTECTED] the first time. Please cc me on any replies. I am looking for help with either making the e1000e driver work on my Thinkpad T60 or fixing the 1s latency issue with e1000. To be honest, I do not understand why the e1000e driver failed to recognize the NIC when I tried. At least, I noticed the correct device ID is defined in drivers/net/e1000e/hw.h: #define E1000_DEV_ID_82573L0x109A Any help is appreciated. Thanks, Martin -- Forwarded Message -- Subject: Re: e1000 1sec latency problem Date: Thursday 07 February 2008 From: Martin Rogge [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org Pavel Machek wrote: Hi! I have the famous e1000 latency problems: Hi, I have the same problem with my Thinkpad T60. [EMAIL PROTECTED]:~# ping arnold PING arnold (192.168.158.6) 56(84) bytes of data. 64 bytes from arnold (192.168.158.6): icmp_seq=1 ttl=64 time=49.7 ms 64 bytes from arnold (192.168.158.6): icmp_seq=2 ttl=64 time=0.438 ms 64 bytes from arnold (192.168.158.6): icmp_seq=3 ttl=64 time=1000 ms 64 bytes from arnold (192.168.158.6): icmp_seq=4 ttl=64 time=0.970 ms 64 bytes from arnold (192.168.158.6): icmp_seq=5 ttl=64 time=885 ms 64 bytes from arnold (192.168.158.6): icmp_seq=6 ttl=64 time=0.484 ms 64 bytes from arnold (192.168.158.6): icmp_seq=7 ttl=64 time=529 ms 64 bytes from arnold (192.168.158.6): icmp_seq=8 ttl=64 time=1.02 ms 64 bytes from arnold (192.168.158.6): icmp_seq=9 ttl=64 time=149 ms 64 bytes from arnold (192.168.158.6): icmp_seq=10 ttl=64 time=0.549 ms 64 bytes from arnold (192.168.158.6): icmp_seq=11 ttl=64 time=0.829 ms --- arnold ping statistics --- 11 packets transmitted, 11 received, 0% packet loss, time ms rtt min/avg/max/mdev = 0.438/238.113/1000.967/365.279 ms, pipe 2 [EMAIL PROTECTED]:~# uname -a Linux zorro 2.6.24 #6 SMP PREEMPT Sun Feb 3 18:27:48 CET 2008 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux [EMAIL PROTECTED]:~# lspci -vvv [stuff deleted] Unfortunately the e1000e driver is not an option as it will not detect the NIC: from dmesg with e1000 compiled in: Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, low) - IRQ 16 PCI: Setting latency timer of device :02:00.0 to 64 e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:15:58:c3:3a:71 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection from dmesg with e1000e compiled in: e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0 e1000e: Copyright (c) 1999-2007 Intel Corporation. Any pointers? Thanks, Martin --- Just for the records, I googled the following solution for the Lenovo T60: (a) use the e1000 driver (b) if compiling as a module, add the following parameter to modprobe.conf: options e1000 RxIntDelay=5 (c) if compiling a static driver, use the following patch (based on 2.6.24): --- e1000_param.c.orig2008-01-24 23:58:37.0 +0100 +++ e1000_param.c 2008-02-09 20:42:23.0 +0100 @@ -158,7 +158,7 @@ * Valid Range: 0-65535 */ E1000_PARAM(RxIntDelay, Receive Interrupt Delay); -#define DEFAULT_RDTR 0 +#define DEFAULT_RDTR 5 #define MAX_RXDELAY 0x #define MIN_RXDELAY0 After reboot, the average ping time is still factor 10 worse than it should be, but it stays below 2 ms (which is a remarkable improvement compared to 1000 ms). correct, this was a workaround which improved things for most people, but did not *fix* it. the real fix is to disable L1 ASPM alltogether at the cost of more power consumption, which is what is in e1000e in 2.6.25-git. e1000e doesn't recognize his NIC. Will you be adding this to the e1000 driver as well? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Re: e1000 1sec latency problem
Ray Lee wrote: On Feb 9, 2008 1:51 PM, Kok, Auke [EMAIL PROTECTED] wrote: Martin Rogge wrote: On Saturday 09 February 2008 11:07:26 Martin Rogge wrote: Hi, I am not so familiar with the various mailing lists and missed out on [EMAIL PROTECTED] the first time. Please cc me on any replies. I am looking for help with either making the e1000e driver work on my Thinkpad T60 or fixing the 1s latency issue with e1000. To be honest, I do not understand why the e1000e driver failed to recognize the NIC when I tried. At least, I noticed the correct device ID is defined in drivers/net/e1000e/hw.h: #define E1000_DEV_ID_82573L0x109A Any help is appreciated. Thanks, Martin -- Forwarded Message -- Subject: Re: e1000 1sec latency problem Date: Thursday 07 February 2008 From: Martin Rogge [EMAIL PROTECTED] To: linux-kernel@vger.kernel.org Pavel Machek wrote: Hi! I have the famous e1000 latency problems: Hi, I have the same problem with my Thinkpad T60. [EMAIL PROTECTED]:~# ping arnold PING arnold (192.168.158.6) 56(84) bytes of data. 64 bytes from arnold (192.168.158.6): icmp_seq=1 ttl=64 time=49.7 ms 64 bytes from arnold (192.168.158.6): icmp_seq=2 ttl=64 time=0.438 ms 64 bytes from arnold (192.168.158.6): icmp_seq=3 ttl=64 time=1000 ms 64 bytes from arnold (192.168.158.6): icmp_seq=4 ttl=64 time=0.970 ms 64 bytes from arnold (192.168.158.6): icmp_seq=5 ttl=64 time=885 ms 64 bytes from arnold (192.168.158.6): icmp_seq=6 ttl=64 time=0.484 ms 64 bytes from arnold (192.168.158.6): icmp_seq=7 ttl=64 time=529 ms 64 bytes from arnold (192.168.158.6): icmp_seq=8 ttl=64 time=1.02 ms 64 bytes from arnold (192.168.158.6): icmp_seq=9 ttl=64 time=149 ms 64 bytes from arnold (192.168.158.6): icmp_seq=10 ttl=64 time=0.549 ms 64 bytes from arnold (192.168.158.6): icmp_seq=11 ttl=64 time=0.829 ms --- arnold ping statistics --- 11 packets transmitted, 11 received, 0% packet loss, time ms rtt min/avg/max/mdev = 0.438/238.113/1000.967/365.279 ms, pipe 2 [EMAIL PROTECTED]:~# uname -a Linux zorro 2.6.24 #6 SMP PREEMPT Sun Feb 3 18:27:48 CET 2008 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux [EMAIL PROTECTED]:~# lspci -vvv [stuff deleted] Unfortunately the e1000e driver is not an option as it will not detect the NIC: from dmesg with e1000 compiled in: Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, low) - IRQ 16 PCI: Setting latency timer of device :02:00.0 to 64 e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:15:58:c3:3a:71 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection from dmesg with e1000e compiled in: e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0 e1000e: Copyright (c) 1999-2007 Intel Corporation. Any pointers? Thanks, Martin --- Just for the records, I googled the following solution for the Lenovo T60: (a) use the e1000 driver (b) if compiling as a module, add the following parameter to modprobe.conf: options e1000 RxIntDelay=5 (c) if compiling a static driver, use the following patch (based on 2.6.24): --- e1000_param.c.orig2008-01-24 23:58:37.0 +0100 +++ e1000_param.c 2008-02-09 20:42:23.0 +0100 @@ -158,7 +158,7 @@ * Valid Range: 0-65535 */ E1000_PARAM(RxIntDelay, Receive Interrupt Delay); -#define DEFAULT_RDTR 0 +#define DEFAULT_RDTR 5 #define MAX_RXDELAY 0x #define MIN_RXDELAY0 After reboot, the average ping time is still factor 10 worse than it should be, but it stays below 2 ms (which is a remarkable improvement compared to 1000 ms). correct, this was a workaround which improved things for most people, but did not *fix* it. the real fix is to disable L1 ASPM alltogether at the cost of more power consumption, which is what is in e1000e in 2.6.25-git. e1000e doesn't recognize his NIC. Will you be adding this to the e1000 driver as well? no, from 2.6.25 onwards e1000e will support 82573 nics, so you'll have to migrate drivers, and you will get the fix automatically that way. after 2.6.25 releases, support for all pci-e nics will be removed from the e1000 driver. Cheers Auke -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Pavel Machek wrote: > On Thu 2008-02-07 14:32:16, Kok, Auke wrote: >> Pavel Machek wrote: >>> Hi! >>> > I have the famous e1000 latency problems: > > 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms > 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms > 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms > 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms > 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms > 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms > 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms > > ...and they are still there in 2.6.25-git0. I had ethernet EEPROM > checksum problems, which I fixed by the update, but problems are not > gone. pavel, start using "e1000e" instead - this driver replaces e1000 for all the pci-express devices and has the infamous L1 ASPM disable patch to fix this issue. >>> Ok, e1000e seems to work for me. >>> >>> In another email, you asked for lspci - of failing e1000 >>> case. Should I still provide it? >> well, if you do it you should see that L1 ASPM is now disabled (with e1000e) >> whereas with e1000 it is still enabled. That's the fix that you need... > > Is there easy way to push that fix to e1000, too? Or print "use e1000e > instead" and refuse to load? well we're going to delete all pci-e related code from this driver soon anyway, but I am indeed writing a patch right now that prints out this warning... Auke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
On Thu 2008-02-07 14:32:16, Kok, Auke wrote: > Pavel Machek wrote: > > Hi! > > > >>> I have the famous e1000 latency problems: > >>> > >>> 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms > >>> 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms > >>> 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms > >>> 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms > >>> 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms > >>> 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms > >>> 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms > >>> > >>> ...and they are still there in 2.6.25-git0. I had ethernet EEPROM > >>> checksum problems, which I fixed by the update, but problems are not > >>> gone. > >> pavel, start using "e1000e" instead - this driver replaces e1000 for all > >> the > >> pci-express devices and has the infamous L1 ASPM disable patch to > >> fix this issue. > > > > Ok, e1000e seems to work for me. > > > > In another email, you asked for lspci - of failing e1000 > > case. Should I still provide it? > > well, if you do it you should see that L1 ASPM is now disabled (with e1000e) > whereas with e1000 it is still enabled. That's the fix that you need... Is there easy way to push that fix to e1000, too? Or print "use e1000e instead" and refuse to load? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Pavel Machek wrote: > Hi! > >>> I have the famous e1000 latency problems: >>> >>> 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms >>> 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms >>> 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms >>> 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms >>> 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms >>> 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms >>> 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms >>> >>> ...and they are still there in 2.6.25-git0. I had ethernet EEPROM >>> checksum problems, which I fixed by the update, but problems are not >>> gone. >> pavel, start using "e1000e" instead - this driver replaces e1000 for all the >> pci-express devices and has the infamous L1 ASPM disable patch to >> fix this issue. > > Ok, e1000e seems to work for me. > > In another email, you asked for lspci - of failing e1000 > case. Should I still provide it? well, if you do it you should see that L1 ASPM is now disabled (with e1000e) whereas with e1000 it is still enabled. That's the fix that you need... Auke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: e1000 1sec latency problem
Pavel Machek wrote: > Hi! > > I have the famous e1000 latency problems: Hi, I have the same problem with my Thinkpad T60. [EMAIL PROTECTED]:~# ping arnold PING arnold (192.168.158.6) 56(84) bytes of data. 64 bytes from arnold (192.168.158.6): icmp_seq=1 ttl=64 time=49.7 ms 64 bytes from arnold (192.168.158.6): icmp_seq=2 ttl=64 time=0.438 ms 64 bytes from arnold (192.168.158.6): icmp_seq=3 ttl=64 time=1000 ms 64 bytes from arnold (192.168.158.6): icmp_seq=4 ttl=64 time=0.970 ms 64 bytes from arnold (192.168.158.6): icmp_seq=5 ttl=64 time=885 ms 64 bytes from arnold (192.168.158.6): icmp_seq=6 ttl=64 time=0.484 ms 64 bytes from arnold (192.168.158.6): icmp_seq=7 ttl=64 time=529 ms 64 bytes from arnold (192.168.158.6): icmp_seq=8 ttl=64 time=1.02 ms 64 bytes from arnold (192.168.158.6): icmp_seq=9 ttl=64 time=149 ms 64 bytes from arnold (192.168.158.6): icmp_seq=10 ttl=64 time=0.549 ms 64 bytes from arnold (192.168.158.6): icmp_seq=11 ttl=64 time=0.829 ms --- arnold ping statistics --- 11 packets transmitted, 11 received, 0% packet loss, time ms rtt min/avg/max/mdev = 0.438/238.113/1000.967/365.279 ms, pipe 2 [EMAIL PROTECTED]:~# uname -a Linux zorro 2.6.24 #6 SMP PREEMPT Sun Feb 3 18:27:48 CET 2008 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux [EMAIL PROTECTED]:~# lspci -vvv 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Lenovo Unknown device 2015 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- GSI 16 (level, low) -> IRQ 16 PCI: Setting latency timer of device :02:00.0 to 64 e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:15:58:c3:3a:71 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection from dmesg with e1000e compiled in: e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0 e1000e: Copyright (c) 1999-2007 Intel Corporation. Any pointers? Thanks, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Hi! > > I have the famous e1000 latency problems: > > > > 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms > > 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms > > 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms > > 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms > > 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms > > 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms > > 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms > > > > ...and they are still there in 2.6.25-git0. I had ethernet EEPROM > > checksum problems, which I fixed by the update, but problems are not > > gone. > > pavel, start using "e1000e" instead - this driver replaces e1000 for all the > pci-express devices and has the infamous L1 ASPM disable patch to > fix this issue. Ok, e1000e seems to work for me. In another email, you asked for lspci - of failing e1000 case. Should I still provide it? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Kok, Auke wrote: > Max Krasnyansky wrote: >> Kok, Auke wrote: >>> Max Krasnyansky wrote: Kok, Auke wrote: > Max Krasnyansky wrote: >> So you don't think it's related to the interrupt coalescing by any >> chance ? >> I'd suggest to try and disable the coalescing and see if it makes any >> difference. >> We've had lots of issues with coalescing misbehavior. Not this bad (ie 1 >> second) though. >> >> Add this to modprobe.conf and reload e1000 module >> >> options e1000 RxIntDelay=0,0 RxAbsIntDelay=0,0 InterruptThrottleRate=0,0 >> TxIntDelay=0,0 TxAbsIntDelay=0,0 > that can't be the problem. irq moderation would only account for 2-3ms > variance > maximum. Oh, I've definitely seen worse than that. Not as bad as a 1second though. Plus you're talking about the case when coalescing logic is working as designed ;-). What if there is some kind of bug where timer did not expire or something. >>> we don't use a software timer in e1000 irq coalescing/moderation, it's all >>> in >>> hardware, so we don't have that problem at all. And I certainly have never >>> seen >>> anything you are referring to with e1000 hardware, and I do not know of any >>> bug >>> related to this. >>> >>> are you maybe confused with other hardware ? >>> >>> feel free to demonstrate an example... >> Just to give you a background. I wrote and maintain http://libe1000.sf.net >> So I know E1000 HW and SW in and out. > > wow, even I do not dare to say that! Ok maybe that was a bit of an overstatement :). >> And no I'm not confused with other HW and I know that we're >> not using SW timers for the coalescing. HW can be buggy as well. Note that >> I'm not saying that I >> know for sure that the problem is coalescing, I'm just suggesting to take it >> out of the equation >> while Pavel is investigating. >> >> Unfortunately I cannot demonstrate an example but I've seen unexplained >> packet delays in the range >> of 1-20 milliseconds on E1000 HW (and boy ... I do have a lot of it in my >> labs). Once coalescing >> was disabled those problems have gone away. > > this sounds like you have some sort of PCI POST-ing problem and those can > indeed > be worse if you use any form of interrupt coalescing. In any case that is > largely > irrelevant to the in-kernel drivers, and as I said we definately have no open > issues on that right now, and I really do not recollect any as well either > (other > than the issue of interference when both ends are irq coalescing) I was actually talking about in kernel drivers. ie We were seeing delays with TIPC running over in kernel E1000 driver. And no it was not a TIPC issue, everything worked fine with over TG3 and issues went away when coalescing was disabled. Anyway, I think we can drop this subject. Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Max Krasnyansky wrote: > > Kok, Auke wrote: >> Max Krasnyansky wrote: >>> Kok, Auke wrote: Max Krasnyansky wrote: > So you don't think it's related to the interrupt coalescing by any chance > ? > I'd suggest to try and disable the coalescing and see if it makes any > difference. > We've had lots of issues with coalescing misbehavior. Not this bad (ie 1 > second) though. > > Add this to modprobe.conf and reload e1000 module > > options e1000 RxIntDelay=0,0 RxAbsIntDelay=0,0 InterruptThrottleRate=0,0 > TxIntDelay=0,0 TxAbsIntDelay=0,0 that can't be the problem. irq moderation would only account for 2-3ms variance maximum. >>> Oh, I've definitely seen worse than that. Not as bad as a 1second though. >>> Plus you're talking >>> about the case when coalescing logic is working as designed ;-). What if >>> there is some kind of >>> bug where timer did not expire or something. >> we don't use a software timer in e1000 irq coalescing/moderation, it's all in >> hardware, so we don't have that problem at all. And I certainly have never >> seen >> anything you are referring to with e1000 hardware, and I do not know of any >> bug >> related to this. >> >> are you maybe confused with other hardware ? >> >> feel free to demonstrate an example... > > Just to give you a background. I wrote and maintain http://libe1000.sf.net > So I know E1000 HW and SW in and out. wow, even I do not dare to say that! > And no I'm not confused with other HW and I know that we're > not using SW timers for the coalescing. HW can be buggy as well. Note that > I'm not saying that I > know for sure that the problem is coalescing, I'm just suggesting to take it > out of the equation > while Pavel is investigating. > > Unfortunately I cannot demonstrate an example but I've seen unexplained > packet delays in the range > of 1-20 milliseconds on E1000 HW (and boy ... I do have a lot of it in my > labs). Once coalescing > was disabled those problems have gone away. this sounds like you have some sort of PCI POST-ing problem and those can indeed be worse if you use any form of interrupt coalescing. In any case that is largely irrelevant to the in-kernel drivers, and as I said we definately have no open issues on that right now, and I really do not recollect any as well either (other than the issue of interference when both ends are irq coalescing) Cheers, Auke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Kok, Auke wrote: > Max Krasnyansky wrote: >> Kok, Auke wrote: >>> Max Krasnyansky wrote: So you don't think it's related to the interrupt coalescing by any chance ? I'd suggest to try and disable the coalescing and see if it makes any difference. We've had lots of issues with coalescing misbehavior. Not this bad (ie 1 second) though. Add this to modprobe.conf and reload e1000 module options e1000 RxIntDelay=0,0 RxAbsIntDelay=0,0 InterruptThrottleRate=0,0 TxIntDelay=0,0 TxAbsIntDelay=0,0 >>> that can't be the problem. irq moderation would only account for 2-3ms >>> variance >>> maximum. >> Oh, I've definitely seen worse than that. Not as bad as a 1second though. >> Plus you're talking >> about the case when coalescing logic is working as designed ;-). What if >> there is some kind of >> bug where timer did not expire or something. > > we don't use a software timer in e1000 irq coalescing/moderation, it's all in > hardware, so we don't have that problem at all. And I certainly have never > seen > anything you are referring to with e1000 hardware, and I do not know of any > bug > related to this. > > are you maybe confused with other hardware ? > > feel free to demonstrate an example... Just to give you a background. I wrote and maintain http://libe1000.sf.net So I know E1000 HW and SW in and out. And no I'm not confused with other HW and I know that we're not using SW timers for the coalescing. HW can be buggy as well. Note that I'm not saying that I know for sure that the problem is coalescing, I'm just suggesting to take it out of the equation while Pavel is investigating. Unfortunately I cannot demonstrate an example but I've seen unexplained packet delays in the range of 1-20 milliseconds on E1000 HW (and boy ... I do have a lot of it in my labs). Once coalescing was disabled those problems have gone away. Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Pavel Machek wrote: > Hi! > > I have the famous e1000 latency problems: > > 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms > 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms > 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms > 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms > 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms > 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms > 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms > > ...and they are still there in 2.6.25-git0. I had ethernet EEPROM > checksum problems, which I fixed by the update, but problems are not > gone. pavel, start using "e1000e" instead - this driver replaces e1000 for all the pci-express devices and has the infamous L1 ASPM disable patch to fix this issue. make sure you have CONFIG_E1000E=m/y in your .config, otherwise the old e1000 code will drive your card, and that driver does not have the fix. BAH, this is a good example how Linus' patch can wreak havoc - a lot of people will now not see fixes since they only go into e1000e, but people can unnoticed now go and use e1000 for too long... Auke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Max Krasnyansky wrote: > Kok, Auke wrote: >> Max Krasnyansky wrote: >>> So you don't think it's related to the interrupt coalescing by any chance ? >>> I'd suggest to try and disable the coalescing and see if it makes any >>> difference. >>> We've had lots of issues with coalescing misbehavior. Not this bad (ie 1 >>> second) though. >>> >>> Add this to modprobe.conf and reload e1000 module >>> >>> options e1000 RxIntDelay=0,0 RxAbsIntDelay=0,0 InterruptThrottleRate=0,0 >>> TxIntDelay=0,0 TxAbsIntDelay=0,0 >> that can't be the problem. irq moderation would only account for 2-3ms >> variance >> maximum. > Oh, I've definitely seen worse than that. Not as bad as a 1second though. > Plus you're talking > about the case when coalescing logic is working as designed ;-). What if > there is some kind of > bug where timer did not expire or something. we don't use a software timer in e1000 irq coalescing/moderation, it's all in hardware, so we don't have that problem at all. And I certainly have never seen anything you are referring to with e1000 hardware, and I do not know of any bug related to this. are you maybe confused with other hardware? feel free to demonstrate an example... Cheers, Auke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Kok, Auke wrote: > Max Krasnyansky wrote: >> So you don't think it's related to the interrupt coalescing by any chance ? >> I'd suggest to try and disable the coalescing and see if it makes any >> difference. >> We've had lots of issues with coalescing misbehavior. Not this bad (ie 1 >> second) though. >> >> Add this to modprobe.conf and reload e1000 module >> >> options e1000 RxIntDelay=0,0 RxAbsIntDelay=0,0 InterruptThrottleRate=0,0 >> TxIntDelay=0,0 TxAbsIntDelay=0,0 > > that can't be the problem. irq moderation would only account for 2-3ms > variance > maximum. Oh, I've definitely seen worse than that. Not as bad as a 1second though. Plus you're talking about the case when coalescing logic is working as designed ;-). What if there is some kind of bug where timer did not expire or something. Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Max Krasnyansky wrote: > Pavel Machek wrote: >> Hi! >> >> I have the famous e1000 latency problems: >> >> 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms >> 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms >> 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms >> 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms >> 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms >> 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms >> 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms >> >> ...and they are still there in 2.6.25-git0. I had ethernet EEPROM >> checksum problems, which I fixed by the update, but problems are not >> gone. >> >> irqpoll helps. >> >> nosmp (which implies XT-PIC is being used) does not help. >> >> 16: 1925 0 IO-APIC-fasteoi ahci, yenta, uhci_hcd:usb2, >> eth0 >> >> Booting kernel with nosmp/ no yenta, no usb does not help. >> >> Hmm, as expected, interrupt load on ahci (find /) makes latencies go >> away. >> >> It should be easily reproducible on x60 with latest bios, it is 100% >> reproducible for me... > > So you don't think it's related to the interrupt coalescing by any chance ? > I'd suggest to try and disable the coalescing and see if it makes any > difference. > We've had lots of issues with coalescing misbehavior. Not this bad (ie 1 > second) though. > > Add this to modprobe.conf and reload e1000 module > > options e1000 RxIntDelay=0,0 RxAbsIntDelay=0,0 InterruptThrottleRate=0,0 > TxIntDelay=0,0 TxAbsIntDelay=0,0 that can't be the problem. irq moderation would only account for 2-3ms variance maximum. Pavel, can you send me the `lspci -vvv` of your machine with the very latest git tree and after it's showing the poor ping performance? Auke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: e1000 1sec latency problem
Pavel Machek wrote: > Hi! > > I have the famous e1000 latency problems: > > 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms > 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms > 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms > 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms > 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms > 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms > 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms > > ...and they are still there in 2.6.25-git0. I had ethernet EEPROM > checksum problems, which I fixed by the update, but problems are not > gone. > > irqpoll helps. > > nosmp (which implies XT-PIC is being used) does not help. > > 16: 1925 0 IO-APIC-fasteoi ahci, yenta, uhci_hcd:usb2, > eth0 > > Booting kernel with nosmp/ no yenta, no usb does not help. > > Hmm, as expected, interrupt load on ahci (find /) makes latencies go > away. > > It should be easily reproducible on x60 with latest bios, it is 100% > reproducible for me... So you don't think it's related to the interrupt coalescing by any chance ? I'd suggest to try and disable the coalescing and see if it makes any difference. We've had lots of issues with coalescing misbehavior. Not this bad (ie 1 second) though. Add this to modprobe.conf and reload e1000 module options e1000 RxIntDelay=0,0 RxAbsIntDelay=0,0 InterruptThrottleRate=0,0 TxIntDelay=0,0 TxAbsIntDelay=0,0 Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
e1000 1sec latency problem
Hi! I have the famous e1000 latency problems: 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms ...and they are still there in 2.6.25-git0. I had ethernet EEPROM checksum problems, which I fixed by the update, but problems are not gone. irqpoll helps. nosmp (which implies XT-PIC is being used) does not help. 16: 1925 0 IO-APIC-fasteoi ahci, yenta, uhci_hcd:usb2, eth0 Booting kernel with nosmp/ no yenta, no usb does not help. Hmm, as expected, interrupt load on ahci (find /) makes latencies go away. It should be easily reproducible on x60 with latest bios, it is 100% reproducible for me... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Kok, Auke wrote: Max Krasnyansky wrote: Kok, Auke wrote: Max Krasnyansky wrote: Kok, Auke wrote: Max Krasnyansky wrote: So you don't think it's related to the interrupt coalescing by any chance ? I'd suggest to try and disable the coalescing and see if it makes any difference. We've had lots of issues with coalescing misbehavior. Not this bad (ie 1 second) though. Add this to modprobe.conf and reload e1000 module options e1000 RxIntDelay=0,0 RxAbsIntDelay=0,0 InterruptThrottleRate=0,0 TxIntDelay=0,0 TxAbsIntDelay=0,0 that can't be the problem. irq moderation would only account for 2-3ms variance maximum. Oh, I've definitely seen worse than that. Not as bad as a 1second though. Plus you're talking about the case when coalescing logic is working as designed ;-). What if there is some kind of bug where timer did not expire or something. we don't use a software timer in e1000 irq coalescing/moderation, it's all in hardware, so we don't have that problem at all. And I certainly have never seen anything you are referring to with e1000 hardware, and I do not know of any bug related to this. are you maybe confused with other hardware ? feel free to demonstrate an example... Just to give you a background. I wrote and maintain http://libe1000.sf.net So I know E1000 HW and SW in and out. wow, even I do not dare to say that! Ok maybe that was a bit of an overstatement :). And no I'm not confused with other HW and I know that we're not using SW timers for the coalescing. HW can be buggy as well. Note that I'm not saying that I know for sure that the problem is coalescing, I'm just suggesting to take it out of the equation while Pavel is investigating. Unfortunately I cannot demonstrate an example but I've seen unexplained packet delays in the range of 1-20 milliseconds on E1000 HW (and boy ... I do have a lot of it in my labs). Once coalescing was disabled those problems have gone away. this sounds like you have some sort of PCI POST-ing problem and those can indeed be worse if you use any form of interrupt coalescing. In any case that is largely irrelevant to the in-kernel drivers, and as I said we definately have no open issues on that right now, and I really do not recollect any as well either (other than the issue of interference when both ends are irq coalescing) I was actually talking about in kernel drivers. ie We were seeing delays with TIPC running over in kernel E1000 driver. And no it was not a TIPC issue, everything worked fine with over TG3 and issues went away when coalescing was disabled. Anyway, I think we can drop this subject. Max -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Pavel Machek wrote: Hi! I have the famous e1000 latency problems: 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms ...and they are still there in 2.6.25-git0. I had ethernet EEPROM checksum problems, which I fixed by the update, but problems are not gone. pavel, start using e1000e instead - this driver replaces e1000 for all the pci-express devices and has the infamous L1 ASPM disable patch to fix this issue. make sure you have CONFIG_E1000E=m/y in your .config, otherwise the old e1000 code will drive your card, and that driver does not have the fix. BAH, this is a good example how Linus' patch can wreak havoc - a lot of people will now not see fixes since they only go into e1000e, but people can unnoticed now go and use e1000 for too long... Auke -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Kok, Auke wrote: Max Krasnyansky wrote: Kok, Auke wrote: Max Krasnyansky wrote: So you don't think it's related to the interrupt coalescing by any chance ? I'd suggest to try and disable the coalescing and see if it makes any difference. We've had lots of issues with coalescing misbehavior. Not this bad (ie 1 second) though. Add this to modprobe.conf and reload e1000 module options e1000 RxIntDelay=0,0 RxAbsIntDelay=0,0 InterruptThrottleRate=0,0 TxIntDelay=0,0 TxAbsIntDelay=0,0 that can't be the problem. irq moderation would only account for 2-3ms variance maximum. Oh, I've definitely seen worse than that. Not as bad as a 1second though. Plus you're talking about the case when coalescing logic is working as designed ;-). What if there is some kind of bug where timer did not expire or something. we don't use a software timer in e1000 irq coalescing/moderation, it's all in hardware, so we don't have that problem at all. And I certainly have never seen anything you are referring to with e1000 hardware, and I do not know of any bug related to this. are you maybe confused with other hardware ? feel free to demonstrate an example... Just to give you a background. I wrote and maintain http://libe1000.sf.net So I know E1000 HW and SW in and out. And no I'm not confused with other HW and I know that we're not using SW timers for the coalescing. HW can be buggy as well. Note that I'm not saying that I know for sure that the problem is coalescing, I'm just suggesting to take it out of the equation while Pavel is investigating. Unfortunately I cannot demonstrate an example but I've seen unexplained packet delays in the range of 1-20 milliseconds on E1000 HW (and boy ... I do have a lot of it in my labs). Once coalescing was disabled those problems have gone away. Max -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
e1000 1sec latency problem
Hi! I have the famous e1000 latency problems: 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms ...and they are still there in 2.6.25-git0. I had ethernet EEPROM checksum problems, which I fixed by the update, but problems are not gone. irqpoll helps. nosmp (which implies XT-PIC is being used) does not help. 16: 1925 0 IO-APIC-fasteoi ahci, yenta, uhci_hcd:usb2, eth0 Booting kernel with nosmp/ no yenta, no usb does not help. Hmm, as expected, interrupt load on ahci (find /) makes latencies go away. It should be easily reproducible on x60 with latest bios, it is 100% reproducible for me... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Max Krasnyansky wrote: Kok, Auke wrote: Max Krasnyansky wrote: Kok, Auke wrote: Max Krasnyansky wrote: So you don't think it's related to the interrupt coalescing by any chance ? I'd suggest to try and disable the coalescing and see if it makes any difference. We've had lots of issues with coalescing misbehavior. Not this bad (ie 1 second) though. Add this to modprobe.conf and reload e1000 module options e1000 RxIntDelay=0,0 RxAbsIntDelay=0,0 InterruptThrottleRate=0,0 TxIntDelay=0,0 TxAbsIntDelay=0,0 that can't be the problem. irq moderation would only account for 2-3ms variance maximum. Oh, I've definitely seen worse than that. Not as bad as a 1second though. Plus you're talking about the case when coalescing logic is working as designed ;-). What if there is some kind of bug where timer did not expire or something. we don't use a software timer in e1000 irq coalescing/moderation, it's all in hardware, so we don't have that problem at all. And I certainly have never seen anything you are referring to with e1000 hardware, and I do not know of any bug related to this. are you maybe confused with other hardware ? feel free to demonstrate an example... Just to give you a background. I wrote and maintain http://libe1000.sf.net So I know E1000 HW and SW in and out. wow, even I do not dare to say that! And no I'm not confused with other HW and I know that we're not using SW timers for the coalescing. HW can be buggy as well. Note that I'm not saying that I know for sure that the problem is coalescing, I'm just suggesting to take it out of the equation while Pavel is investigating. Unfortunately I cannot demonstrate an example but I've seen unexplained packet delays in the range of 1-20 milliseconds on E1000 HW (and boy ... I do have a lot of it in my labs). Once coalescing was disabled those problems have gone away. this sounds like you have some sort of PCI POST-ing problem and those can indeed be worse if you use any form of interrupt coalescing. In any case that is largely irrelevant to the in-kernel drivers, and as I said we definately have no open issues on that right now, and I really do not recollect any as well either (other than the issue of interference when both ends are irq coalescing) Cheers, Auke -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Max Krasnyansky wrote: Kok, Auke wrote: Max Krasnyansky wrote: So you don't think it's related to the interrupt coalescing by any chance ? I'd suggest to try and disable the coalescing and see if it makes any difference. We've had lots of issues with coalescing misbehavior. Not this bad (ie 1 second) though. Add this to modprobe.conf and reload e1000 module options e1000 RxIntDelay=0,0 RxAbsIntDelay=0,0 InterruptThrottleRate=0,0 TxIntDelay=0,0 TxAbsIntDelay=0,0 that can't be the problem. irq moderation would only account for 2-3ms variance maximum. Oh, I've definitely seen worse than that. Not as bad as a 1second though. Plus you're talking about the case when coalescing logic is working as designed ;-). What if there is some kind of bug where timer did not expire or something. we don't use a software timer in e1000 irq coalescing/moderation, it's all in hardware, so we don't have that problem at all. And I certainly have never seen anything you are referring to with e1000 hardware, and I do not know of any bug related to this. are you maybe confused with other hardware? feel free to demonstrate an example... Cheers, Auke -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
On Thu 2008-02-07 14:32:16, Kok, Auke wrote: Pavel Machek wrote: Hi! I have the famous e1000 latency problems: 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms ...and they are still there in 2.6.25-git0. I had ethernet EEPROM checksum problems, which I fixed by the update, but problems are not gone. pavel, start using e1000e instead - this driver replaces e1000 for all the pci-express devices and has the infamous L1 ASPM disable patch to fix this issue. Ok, e1000e seems to work for me. In another email, you asked for lspci - of failing e1000 case. Should I still provide it? well, if you do it you should see that L1 ASPM is now disabled (with e1000e) whereas with e1000 it is still enabled. That's the fix that you need... Is there easy way to push that fix to e1000, too? Or print use e1000e instead and refuse to load? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Pavel Machek wrote: Hi! I have the famous e1000 latency problems: 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms ...and they are still there in 2.6.25-git0. I had ethernet EEPROM checksum problems, which I fixed by the update, but problems are not gone. pavel, start using e1000e instead - this driver replaces e1000 for all the pci-express devices and has the infamous L1 ASPM disable patch to fix this issue. Ok, e1000e seems to work for me. In another email, you asked for lspci - of failing e1000 case. Should I still provide it? well, if you do it you should see that L1 ASPM is now disabled (with e1000e) whereas with e1000 it is still enabled. That's the fix that you need... Auke -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Hi! I have the famous e1000 latency problems: 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms ...and they are still there in 2.6.25-git0. I had ethernet EEPROM checksum problems, which I fixed by the update, but problems are not gone. pavel, start using e1000e instead - this driver replaces e1000 for all the pci-express devices and has the infamous L1 ASPM disable patch to fix this issue. Ok, e1000e seems to work for me. In another email, you asked for lspci - of failing e1000 case. Should I still provide it? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [E1000-devel] e1000 1sec latency problem
Pavel Machek wrote: On Thu 2008-02-07 14:32:16, Kok, Auke wrote: Pavel Machek wrote: Hi! I have the famous e1000 latency problems: 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms 64 bytes from 195.113.31.123: icmp_seq=71 ttl=56 time=308.9 ms 64 bytes from 195.113.31.123: icmp_seq=72 ttl=56 time=305.4 ms 64 bytes from 195.113.31.123: icmp_seq=73 ttl=56 time=9.8 ms 64 bytes from 195.113.31.123: icmp_seq=74 ttl=56 time=3.7 ms ...and they are still there in 2.6.25-git0. I had ethernet EEPROM checksum problems, which I fixed by the update, but problems are not gone. pavel, start using e1000e instead - this driver replaces e1000 for all the pci-express devices and has the infamous L1 ASPM disable patch to fix this issue. Ok, e1000e seems to work for me. In another email, you asked for lspci - of failing e1000 case. Should I still provide it? well, if you do it you should see that L1 ASPM is now disabled (with e1000e) whereas with e1000 it is still enabled. That's the fix that you need... Is there easy way to push that fix to e1000, too? Or print use e1000e instead and refuse to load? well we're going to delete all pci-e related code from this driver soon anyway, but I am indeed writing a patch right now that prints out this warning... Auke -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: e1000 1sec latency problem
Pavel Machek wrote: Hi! I have the famous e1000 latency problems: Hi, I have the same problem with my Thinkpad T60. [EMAIL PROTECTED]:~# ping arnold PING arnold (192.168.158.6) 56(84) bytes of data. 64 bytes from arnold (192.168.158.6): icmp_seq=1 ttl=64 time=49.7 ms 64 bytes from arnold (192.168.158.6): icmp_seq=2 ttl=64 time=0.438 ms 64 bytes from arnold (192.168.158.6): icmp_seq=3 ttl=64 time=1000 ms 64 bytes from arnold (192.168.158.6): icmp_seq=4 ttl=64 time=0.970 ms 64 bytes from arnold (192.168.158.6): icmp_seq=5 ttl=64 time=885 ms 64 bytes from arnold (192.168.158.6): icmp_seq=6 ttl=64 time=0.484 ms 64 bytes from arnold (192.168.158.6): icmp_seq=7 ttl=64 time=529 ms 64 bytes from arnold (192.168.158.6): icmp_seq=8 ttl=64 time=1.02 ms 64 bytes from arnold (192.168.158.6): icmp_seq=9 ttl=64 time=149 ms 64 bytes from arnold (192.168.158.6): icmp_seq=10 ttl=64 time=0.549 ms 64 bytes from arnold (192.168.158.6): icmp_seq=11 ttl=64 time=0.829 ms --- arnold ping statistics --- 11 packets transmitted, 11 received, 0% packet loss, time ms rtt min/avg/max/mdev = 0.438/238.113/1000.967/365.279 ms, pipe 2 [EMAIL PROTECTED]:~# uname -a Linux zorro 2.6.24 #6 SMP PREEMPT Sun Feb 3 18:27:48 CET 2008 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux [EMAIL PROTECTED]:~# lspci -vvv 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Lenovo Unknown device 2015 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Capabilities: [e0] Vendor Specific Information [stuff deleted] 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller Subsystem: Lenovo ThinkPad T60 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at ee00 (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at 3000 [size=32] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: Data: Capabilities: [e0] Express Endpoint IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s 512ns, L1 64us Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0 Link: Latency L0s 128ns, L1 64us Link: ASPM L1 Enabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 71-3a-c3-ff-ff-58-15-00 Unfortunately the e1000e driver is not an option as it will not detect the NIC: from dmesg with e1000 compiled in: Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, low) - IRQ 16 PCI: Setting latency timer of device :02:00.0 to 64 e1000: :02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:15:58:c3:3a:71 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection from dmesg with e1000e compiled in: e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0 e1000e: Copyright (c) 1999-2007 Intel Corporation. Any pointers? Thanks, Martin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
