:44 +0800, Ethan Zhao wrote:
Hi guys,
We got network I/O performance degradation with latest stable
kernel and the be2net driver as compared to old kernel 3.0.6. later
we found even compared to
the same latest stable kernel but the INTEL_IOMMU set to 'n', still
got very noticeable
for last HTML mail, resend txt )
Ethan
On Tue, Nov 12, 2013 at 9:34 AM, Eric Dumazet eric.duma...@gmail.com wrote:
On Tue, 2013-11-12 at 09:03 +0800, Ethan Zhao wrote:
Eric,
We have tested the performance with the TSO and TSQ patches
merged, the result not good, even worse than kernel
Eric,
Thanks, hope it could kill the most pain of the regression. I will
try them and report the result.
Ethan
> You might hit a known problem for some 10Gb links.
>
> 3.12-rc6 has the fixes already, and stable has some pending backports :
>
> commit 95bd09eb27507691520d39ee1044d6ad831c1168
Eric,
Thanks, hope it could kill the most pain of the regression. I will
try them and report the result.
Ethan
You might hit a known problem for some 10Gb links.
3.12-rc6 has the fixes already, and stable has some pending backports :
commit 95bd09eb27507691520d39ee1044d6ad831c1168
tcp:
Hi guys,
We got network I/O performance degradation with latest stable
kernel and the be2net driver as compared to old kernel 3.0.6. later
we found even compared to
the same latest stable kernel but the INTEL_IOMMU set to 'n', still
got very noticeable performance regression:
Kernel :
Hi guys,
We got network I/O performance degradation with latest stable
kernel and the be2net driver as compared to old kernel 3.0.6. later
we found even compared to
the same latest stable kernel but the INTEL_IOMMU set to 'n', still
got very noticeable performance regression:
Kernel :
On Sun, Oct 13, 2013 at 1:50 AM, Greg KH wrote:
> On Sat, Oct 12, 2013 at 02:52:51PM +0800, Ethan Zhao wrote:
>> >> --- a/drivers/base/core.c
>> >> +++ b/drivers/base/core.c
>> >> @@ -1904,8 +1904,7 @@ int device_rename(struct device *dev, const char
On Sat, Oct 12, 2013 at 12:08 AM, Bjorn Helgaas wrote:
> [+cc Don, e1000-devel]
>
> On Fri, Oct 11, 2013 at 9:35 AM, Greg KH wrote:
>> On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote:
>>> From: "ethan.zhao"
>>>
>>> While loading ixgbevf driver,every vf detected will be output as the
On Sat, Oct 12, 2013 at 1:26 AM, Skidmore, Donald C
wrote:
>> -Original Message-
>> From: Greg KH [mailto:gre...@linuxfoundation.org]
>> Sent: Friday, October 11, 2013 9:12 AM
>> To: Bjorn Helgaas
>> Cc: ethan.zhao; linux-kernel@vger.kernel.org; Skidmore, Donald C; e1000-
>>
On Fri, Oct 11, 2013 at 11:35 PM, Greg KH wrote:
> On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote:
>> From: "ethan.zhao"
>>
>> While loading ixgbevf driver,every vf detected will be output as the
>> same name 'eth4':
>>
>> ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual Function
On Fri, Oct 11, 2013 at 11:35 PM, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote:
From: ethan.zhao ethan.ker...@gmail.com
While loading ixgbevf driver,every vf detected will be output as the
same name 'eth4':
ixgbevf: Intel(R) 10
On Sat, Oct 12, 2013 at 1:26 AM, Skidmore, Donald C
donald.c.skidm...@intel.com wrote:
-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org]
Sent: Friday, October 11, 2013 9:12 AM
To: Bjorn Helgaas
Cc: ethan.zhao; linux-kernel@vger.kernel.org; Skidmore, Donald C; e1000-
On Sat, Oct 12, 2013 at 12:08 AM, Bjorn Helgaas bhelg...@google.com wrote:
[+cc Don, e1000-devel]
On Fri, Oct 11, 2013 at 9:35 AM, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Oct 11, 2013 at 10:58:18AM +0800, ethan.zhao wrote:
From: ethan.zhao ethan.ker...@gmail.com
While loading
On Sun, Oct 13, 2013 at 1:50 AM, Greg KH gre...@linuxfoundation.org wrote:
On Sat, Oct 12, 2013 at 02:52:51PM +0800, Ethan Zhao wrote:
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1904,8 +1904,7 @@ int device_rename(struct device *dev, const char
*new_name)
if (!dev
Got it.
On Mon, Oct 7, 2013 at 12:41 PM, Mike Galbraith wrote:
> On Fri, 2013-10-04 at 20:06 +0800, Ethan Zhao wrote:
>> Mike, Peter,
>>Seems lots of work has been done these days, studious guys. those
>> patches merged in last stable/dev branch (fix performance regressi
Got it.
On Mon, Oct 7, 2013 at 12:41 PM, Mike Galbraith bitbuc...@online.de wrote:
On Fri, 2013-10-04 at 20:06 +0800, Ethan Zhao wrote:
Mike, Peter,
Seems lots of work has been done these days, studious guys. those
patches merged in last stable/dev branch (fix performance regression
On Sat, Oct 5, 2013 at 7:55 AM, Yinghai Lu wrote:
> On Fri, Oct 4, 2013 at 3:11 PM, Bjorn Helgaas wrote:
>> On Thu, Oct 3, 2013 at 7:18 PM, Hedi Berriche wrote:
>
>> It's regrettable that the code is so subtle. The obvious thing to do
>> would be to check for _CBA, and if it doesn't exist,
On Sat, Oct 5, 2013 at 7:55 AM, Yinghai Lu ying...@kernel.org wrote:
On Fri, Oct 4, 2013 at 3:11 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Thu, Oct 3, 2013 at 7:18 PM, Hedi Berriche h...@sgi.com wrote:
It's regrettable that the code is so subtle. The obvious thing to do
would be to
Mike, Peter,
Seems lots of work has been done these days, studious guys. those
patches merged in last stable/dev branch (fix performance regression
caused by extra rtimer programming and rescheduling IPI,confusing
idle... etc) ? So I could just do a lazy pull for test with my
environment. I
Mike, Peter,
Seems lots of work has been done these days, studious guys. those
patches merged in last stable/dev branch (fix performance regression
caused by extra rtimer programming and rescheduling IPI,confusing
idle... etc) ? So I could just do a lazy pull for test with my
environment. I
On Tue, Jul 30, 2013 at 5:35 PM, Peter Zijlstra wrote:
>
> On Tue, Jul 30, 2013 at 05:12:49PM +0800, Ethan Zhao wrote:
> > On Mon, Jul 29, 2013 at 6:18 PM, Thomas Gleixner wrote:
> > > The test case does not involve anything hrtimer related. Do you have
> > &g
On Tue, Jul 30, 2013 at 5:35 PM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Jul 30, 2013 at 05:12:49PM +0800, Ethan Zhao wrote:
On Mon, Jul 29, 2013 at 6:18 PM, Thomas Gleixner t...@linutronix.de wrote:
The test case does not involve anything hrtimer related. Do you have
Seems there are code style issues etc after I pasted it in my mail client.
I will correct it and resend v2.
Thanks.
On Sun, Jul 28, 2013 at 12:09 AM, Bjorn Helgaas wrote:
> On Sat, Jul 27, 2013 at 8:27 AM, Yinghai Lu wrote:
>> On Fri, Jul 26, 2013 at 10:39 AM, Bjorn Helgaas wrote:
>
>>>
On Sat, Jul 27, 2013 at 1:39 AM, Bjorn Helgaas wrote:
> [+cc Jiang, linux-pci, -cc bjorn.helg...@hp.com (dead address)]
>
> On Fri, Jul 26, 2013 at 05:10:39PM +0800, ethan zhao wrote:
>> Cleanup the -EINVAL return value handling and add warning message
>> for invalid
>>
On Sat, Jul 27, 2013 at 1:39 AM, Bjorn Helgaas bhelg...@google.com wrote:
[+cc Jiang, linux-pci, -cc bjorn.helg...@hp.com (dead address)]
On Fri, Jul 26, 2013 at 05:10:39PM +0800, ethan zhao wrote:
Cleanup the -EINVAL return value handling and add warning message
for invalid
start,end,addr
Seems there are code style issues etc after I pasted it in my mail client.
I will correct it and resend v2.
Thanks.
On Sun, Jul 28, 2013 at 12:09 AM, Bjorn Helgaas bhelg...@google.com wrote:
On Sat, Jul 27, 2013 at 8:27 AM, Yinghai Lu ying...@kernel.org wrote:
On Fri, Jul 26, 2013 at 10:39 AM,
Cleanup the -EINVAL return value handling and add warning message for
invalid
start,end,addr parameters.
Signed-off-by: ethan.zhao
---
arch/x86/pci/mmconfig-shared.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/pci/mmconfig-shared.c
Cleanup the -EINVAL return value handling and add warning message for
invalid
start,end,addr parameters.
Signed-off-by: ethan.zhao ethan.z...@oracle.com
---
arch/x86/pci/mmconfig-shared.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git
commit 968320b hrtimer: Fix extra wakeups from __remove_hrtimer()
introduced a significant scheduling
performance regression, following is the test:
a. Test environment:
SUN FIRE X4170 M2 SERVER
CPU model name: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz
2 socket X 6 core X 2 thread
b. To eliminate
commit 968320b hrtimer: Fix extra wakeups from __remove_hrtimer()
introduced a significant scheduling
performance regression, following is the test:
a. Test environment:
SUN FIRE X4170 M2 SERVER
CPU model name: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz
2 socket X 6 core X 2 thread
b. To eliminate
Konrad,
This patch fix a typo in comments of arch/x86/pci/xen.c
Thanks,
ethan.z...@oracle.com
---
commit 333a48b76d5311ae370d65dfac293ca0d839c455
Author: ethan.zhao
Date: Thu Dec 20 20:23:31 2012 -0800
Fix a typo in comments
diff --git
Konrad,
This patch fix a typo in comments of arch/x86/pci/xen.c
Thanks,
ethan.z...@oracle.com
---
commit 333a48b76d5311ae370d65dfac293ca0d839c455
Author: ethan.zhao ethan.ker...@gmail.com
Date: Thu Dec 20 20:23:31 2012 -0800
Fix a typo in comments
Joe,
Possibly your customer is running a kernel without source code on
a platform whose vendor wouldn't like to fix BIOS issue( Is that a
HP/Dell server ?).
Anyway, to see if is a payload issue or, you could change the
payload size with setpci tool to those devices and set the link
Joe,
Possibly your customer is running a kernel without source code on
a platform whose vendor wouldn't like to fix BIOS issue( Is that a
HP/Dell server ?).
Anyway, to see if is a payload issue or, you could change the
payload size with setpci tool to those devices and set the link
Hi, Len
Please help to review and apply the patch if it is OK.
I didn't go through all the related code, simply add the model 3e to
the id list, I have tested it with stable branch kernel 3.6.7 on my
Server with Intel ES0 installed.
Thanks,
Ethan
commit
Hi, Len
Please help to review and apply the patch if it is OK.
I didn't go through all the related code, simply add the model 3e to
the id list, I have tested it with stable branch kernel 3.6.7 on my
Server with Intel ES0 installed.
Thanks,
Ethan
commit
T64(acpi_gbl_FADT.Xdsdt)));
-
- acpi_gbl_FADT.Xdsdt = (u64)acpi_gbl_FADT.dsdt;
- }
-
/* If Hardware Reduced flag is set, we are all done */
if (acpi_gbl_reduced_hardware) {
--
1.7.1
Thanks,
Ethan
On Fri, Nov 16, 2012 at 11:49 AM, Moore, Robert wrote:
> No decision(s) yet, we are stil
Bob,
Thanks for your detailed reviewing about the whole possible conditions.
I.C. So that is impossible zero value for Xfacs /Xdsdt if
facs/dsdt >0, for they are assigned in acpi_tb_convert_fadt(), I need
to move my eyes one line code higher to see why it yelled twice
but not using
Hi, Lsi guys,
On our servers (Sun fire X3-2/2L/2B, Sun fire X4-2/2L/2B ),
while loading mpt2sas driver, the _diag_reset action always triggers
correct AER,
So mask CRER bit before the reset action and restore it after
successful resetting.
Please help to check the attached patch, I
Hi, Lsi guys,
On our servers (Sun fire X3-2/2L/2B, Sun fire X4-2/2L/2B ),
while loading mpt2sas driver, the _diag_reset action always triggers
correct AER,
So mask CRER bit before the reset action and restore it after
successful resetting.
Please help to check the attached patch, I
Bob,
Thanks for your detailed reviewing about the whole possible conditions.
I.C. So that is impossible zero value for Xfacs /Xdsdt if
facs/dsdt 0, for they are assigned in acpi_tb_convert_fadt(), I need
to move my eyes one line code higher to see why it yelled twice
but not using
*/
if (acpi_gbl_reduced_hardware) {
--
1.7.1
Thanks,
Ethan
On Fri, Nov 16, 2012 at 11:49 AM, Moore, Robert robert.mo...@intel.com wrote:
No decision(s) yet, we are still investigating
-Original Message-
From: Ethan Zhao [mailto:ethan.ker...@gmail.com]
Sent: Thursday, November 15, 2012 7:47 PM
s number %d\n",
+ d , pxd);
+ return 0;
+ }
+
for (i = 0; i < d; i++) {
for (j = 0; j < d; j++) {
u8 val = slit->entry[d*i + j];
--
1.7.1
Thanks,
Ethan
On Thu, May 24, 2012 at 12:59
proximity domains number %d\n,
+ d , pxd);
+ return 0;
+ }
+
for (i = 0; i d; i++) {
for (j = 0; j d; j++) {
u8 val = slit-entry[d*i + j];
--
1.7.1
Thanks,
Ethan
On Thu, May 24, 2012 at 12:59 PM, ethan zhao
Hi, Len, Robert,
Please help to check the following patch, add more conditions
when validate the 64bit 32bit FACS/DSDT address in FADT to follow ACPI
spec, In the meantime, keep the compatibility and latitude.
Thanks,
Ethan
>From c1116211a7b329c26b0370565c36b084ceb08f71 Mon Sep 17
Hi, Len, Robert,
Please help to check the following patch, add more conditions
when validate the 64bit 32bit FACS/DSDT address in FADT to follow ACPI
spec, In the meantime, keep the compatibility and latitude.
Thanks,
Ethan
From c1116211a7b329c26b0370565c36b084ceb08f71 Mon Sep 17
601 - 646 of 646 matches
Mail list logo
