> >
> >Hi all,
> >
> >I want to find a tool to verify the network card hardware if functional
> >under Linux, does any one know.
> >
> >I have already tried ethtool v3.2 with igb driver 3.4.7. but ethtool -t
> >ethx
> >external_lb is always return :
> >
> >ethtool -t eth14 external_lb
> >The test
On Fri, Jun 01, 2012 at 10:17:08PM +0100, Chris Boot wrote:
> On 23/04/2012 22:29, Chris Boot wrote:
> > ASPM on the 82574 causes trouble. Currently the driver disables L0s for
> > this NIC but only disables L1 if the MTU is >1500. This patch simply
> > causes L1 to be disabled regardless of the MT
> -Original Message-
> From: Jeff Kirsher [mailto:jeffrey.t.kirs...@intel.com]
> Sent: Wednesday, June 06, 2012 5:41 PM
> To: Ethan Zhao
> Cc: e1000-devel@lists.sourceforge.net; Linux NICS; LKML
> Subject: Re: [E1000-devel] [next-net PATCH]
> drivers/net/ethernet/intel/e1000e: fix unregiste
On Wed, 2012-06-06 at 22:57 +0800, Ethan Zhao wrote:
> commit ca3ccc6835943287b6f69e973c126a02bc4de409
> Author: ethan.zhao
> Date: Wed Jun 6 07:32:11 2012 -0700
>
> modified: drivers/net/ethernet/intel/e1000e/param.c
>
> While e1000e_check_options() is called, netdev is not regi
On 06/06/2012 01:44 PM, Andrew J. Schorr wrote:
> Hi Alex,
>
> On Wed, Jun 06, 2012 at 10:53:54AM -0700, Alexander Duyck wrote:
>> Actually the interrupt layout could have a significant impact. Do you
>> happen to know if CPU C states are enabled on your system? You can
>> verify this by checking
Hi Alex,
On Wed, Jun 06, 2012 at 10:53:54AM -0700, Alexander Duyck wrote:
> Actually the interrupt layout could have a significant impact. Do you
> happen to know if CPU C states are enabled on your system? You can
> verify this by checking with a tool called "powertop". If you have C
> states
> -Original Message-
> From: Arthur LENA [mailto:arthur.l...@ftw.at]
> Sent: Tuesday, June 05, 2012 1:25 AM
> To: e1000-devel@lists.sourceforge.net
> Subject: [E1000-devel] Hardware Timestamping in i350-T4
>
> Hello everyone,
>
> I have been working with the i350-T4 ethernet card to test
On Wed, 06 Jun 2012 11:23:32 -0700 (PDT)
David Miller wrote:
> From: Tom Herbert
> Date: Wed, 6 Jun 2012 11:21:40 -0700
>
> > I'm not exactly sure what the exact effect of WTHRESH is here. Does
> > the device coalesce 5 completions regardless of size? Would the
> > problem be avoided if bql l
>-Original Message-
>From: Jack Wang [mailto:jack_w...@usish.com]
>Sent: Sunday, May 27, 2012 11:56 PM
>To: Linux NICS
>Cc: e1000-devel@lists.sourceforge.net
>Subject: [E1000-devel] query for i350 network card test under linux
>
>Hi all,
>
>I want to find a tool to verify the network card h
From: Tom Herbert
Date: Wed, 6 Jun 2012 11:21:40 -0700
> I'm not exactly sure what the exact effect of WTHRESH is here. Does
> the device coalesce 5 completions regardless of size? Would the
> problem be avoided if bql limit_min were MTU, or could same issue be
> hit with larger that 64 byte pa
I'm not exactly sure what the exact effect of WTHRESH is here. Does
the device coalesce 5 completions regardless of size? Would the
problem be avoided if bql limit_min were MTU, or could same issue be
hit with larger that 64 byte packets?
Tom
On Wed, Jun 6, 2012 at 10:19 AM, Hiroaki SHIMODA
wr
On 06/06/2012 09:31 AM, Andrew J. Schorr wrote:
> Hi Alex,
>
> On Wed, Jun 06, 2012 at 08:33:33AM -0700, Alexander Duyck wrote:
>> On 06/06/2012 07:57 AM, Andrew J. Schorr wrote:
>>> queues cpus
>>> A. Fedora 14, builtin driver 2.1.0 8
From: Eric Dumazet
Date: Wed, 06 Jun 2012 19:05:04 +0200
> You cant hold a TX completion indefinitely, this breaks BQL but also
> other stuff.
True.
--
Live Security Virtual Conference
Exclusive live event will cover al
On Wed, 6 Jun 2012 09:26:35 -0700
Jesse Brandeburg wrote:
> On Wed, 6 Jun 2012 Hiroaki SHIMODA wrote:
> > Sorry for long delay. I'll post.
> > (I have no idea how to fix this problem as keeping TXDCTL.WTHRESH to 5)
>
> I don't like changing WTHRESH wholesale because making the global change
> t
On Wed, 2012-06-06 at 09:26 -0700, Jesse Brandeburg wrote:
> On Wed, 6 Jun 2012 Hiroaki SHIMODA wrote:
> > Sorry for long delay. I'll post.
> > (I have no idea how to fix this problem as keeping TXDCTL.WTHRESH to 5)
>
> I don't like changing WTHRESH wholesale because making the global change
> to
Hi Alex,
On Wed, Jun 06, 2012 at 08:33:33AM -0700, Alexander Duyck wrote:
> On 06/06/2012 07:57 AM, Andrew J. Schorr wrote:
> > queues cpus
> > A. Fedora 14, builtin driver 2.1.0 8 1
> > B. Fedora 16, builtin driver 3.2.10
On Wed, 6 Jun 2012 Hiroaki SHIMODA wrote:
> Sorry for long delay. I'll post.
> (I have no idea how to fix this problem as keeping TXDCTL.WTHRESH to 5)
I don't like changing WTHRESH wholesale because making the global change
to WTHRESH on e1000e just to fix this one bug (likely specific to a
parti
On 06/06/2012 07:57 AM, Andrew J. Schorr wrote:
> Hi Alex,
>
> I've done some further testing. I have considered these 4 configurations:
>
> queues cpus
> A. Fedora 14, builtin driver 2.1.08 1
> B. Fedora 16, builtin
Hi Alex,
I've done some further testing. I have considered these 4 configurations:
queues cpus
A. Fedora 14, builtin driver 2.1.0 8 1
B. Fedora 16, builtin driver 3.2.10 8 12
C. Fedora 1
commit ca3ccc6835943287b6f69e973c126a02bc4de409
Author: ethan.zhao
Date: Wed Jun 6 07:32:11 2012 -0700
modified: drivers/net/ethernet/intel/e1000e/param.c
While e1000e_check_options() is called, netdev is not registered, so the
e1000e driver will print out confused ethernet i
Hey guys,
I got a really wired bug that shows skb_over_panic when
ixgbevf_clean_rx_irq calls skb_put(skb, len). In normal case, the
packet length (len) should be less than my mtu (1500), and skb_put
works fine. I have added the memory barrier patch discussed at
"http://www.mail-archive.com/e1000-d
On Wed, 06 Jun 2012 07:10:13 +0200
Eric Dumazet wrote:
> On Tue, 2012-05-29 at 23:25 +0900, Hiroaki SHIMODA wrote:
>
> > If I understand the code and spec correctly, TX interrupts are
> > generated when TXDCTL.WTHRESH descriptors have been accumulated
> > and write backed.
> >
> > I tentatively
22 matches
Mail list logo
