Thanks, Please get us the other information we have asked for.
Cheers,
John
From: Michał Mirosław [mailto:michal.miros...@atendesoftware.pl]
Sent: Thursday, April 21, 2016 8:04 AM
To: Ronciak, John
Cc: e1000-devel@lists.sourceforge.net; intel-wired-...@lists.osuosl.org; Pawel
Malachowski
> -Original Message-
> From: Michał Mirosław [mailto:michal.miros...@atendesoftware.pl]
> Sent: Thursday, April 21, 2016 5:45 AM
> To: e1000-devel@lists.sourceforge.net; intel-wired-...@lists.osuosl.org
> Cc: Paweł Małachowski ; mirq-
> li...@rere.qmqm.pl
> Subject: [E1000-devel] i40e: Dead
; From: Fujinaka, Todd
> Sent: Wednesday, March 16, 2016 10:16 AM
> To: Ronciak, John ; Skidmore, Donald C
> ; Leonardo Amaral - Listas
>
> Cc: e1000-devel@lists.sourceforge.net
> Subject: RE: [E1000-devel] ixgbe 4.3.13 x Linux 4.5.0 = Compilation Faillure
>
> No, this is an
No this is a CentOS kernel so I don't know why a kcompat change is needed but I
guess it is.
Cheers,
John
> -Original Message-
> From: Skidmore, Donald C [mailto:donald.c.skidm...@intel.com]
> Sent: Wednesday, March 16, 2016 9:45 AM
> To: Leonardo Amaral - Listas ; Fujinaka,
> Todd
> C
bject: Re: [E1000-devel] Poor IPsec performance and high ksoftirqd load
>
>
>
> Am 29.02.2016 um 16:15 schrieb Anna Fischer:
> >
> >
> > Am 26.02.2016 um 17:31 schrieb Ronciak, John:
> >> Hi Anna,
> >>
> >>> I have tried with multipl
gree. If the stack is being overrun then that is what is happening.
Cheers,
John
> -Original Message-
> From: Anna Fischer [mailto:a.fisc...@sirrix.com]
> Sent: Monday, February 29, 2016 7:16 AM
> To: Ronciak, John ; e1000-
> de...@lists.sourceforge.net
> Subject: Re:
you running out of CPU cycles or are packets being dropped causing
retransmitted packets? Use netstat and ethtool to look for dropped packets.
Cheers,
John
> -Original Message-
> From: Anna Fischer [mailto:a.fisc...@sirrix.com]
> Sent: Friday, February 26, 2016 12:10 AM
> T
As Todd points out we aren't the CPU folks but until you run the CPU out of
cycles in the test you probably can't tell what's going on regarding
throughput.
Thanks.
Cheers,
John
> -Original Message-
> From: Anna Fischer [mailto:a.fisc...@sirrix.com]
> Se
To be clear here, compile issues were not fixed until Canonical put in the
version number in to the Ubuntu releases which was either 15.04 or 15.10.
Before that we were not able to programmatically determine what kernel the
driver was being compiled for and so we were not able to fix the compil
> -Original Message-
> From: Anna Fischer [mailto:a.fisc...@sirrix.com]
> Sent: Thursday, February 25, 2016 10:53 AM
> To: e1000-devel@lists.sourceforge.net
> Subject: [E1000-devel] Poor IPsec performance and high ksoftirqd load
>
> Hi,
>
> I'm running Linux 4.3.3 (Gentoo) and standard ig
Hi Mattias,
First of all there is no real firmware that runs on these e1000 support
devices. So I want to make that clear that there isn't something running
behind the scenes. If you really turned off the interrupt delay and NAPI is
off the issue is most likely because of the write-back thres
Thanks Todd.
Cheers,
John
> -Original Message-
> From: Fujinaka, Todd
> Sent: Tuesday, January 26, 2016 10:57 AM
> To: Kirsher, Jeffrey T; Szymon Tokarski
> Cc: e1000-devel; Ronciak, John; Templeman, Chaim
> Subject: RE: [E1000-devel] [Intel-wired-lan] e1000e driv
> -Original Message-
> From: Tom Walsh [mailto:expressweb...@gmail.com]
> Sent: Tuesday, January 5, 2016 1:24 PM
> To: e1000-devel@lists.sourceforge.net
> Subject: [E1000-devel] X557-AT2 Problems
>
> Okay, I am at my wits end here with these NICs.
>
> We have a total of six X10SDV-TNL4F m
oba...@prosoftsystems.ru]
> Sent: Tuesday, September 15, 2015 10:20 PM
> To: Ronciak, John; Fujinaka, Todd; e1000-devel@lists.sourceforge.net
> Subject: RE: Intel 82551IL chips
>
> I want to give a small addition: even the chip is EOL, but we have a big
> number of embedded d
The first upstream kernel was 3.19. Is that what you are asking?
Cheers,
John
> -Original Message-
> From: Gooch, Stephen (Wind River) [mailto:stephenx.go...@intel.com]
> Sent: Wednesday, September 16, 2015 1:21 PM
> To: e1000-devel@lists.sourceforge.net
> Subject: [E1000-devel] Driver V
As long as there is no copy and pasting from the Linux driver to the QNX driver
it should not be a problem. I'm not a lawyer but that's generally the case.
That said, since the driver works after another a second reboot it's probably
not related to the driver. This is probably something that
> So, assuming the setting was picked up, there is no improvement.
>
> Currently, the system is faster up than the network device tries to configure
> the link. Do you have any other suggestions?
>
> Aren’t there really any other options to easily debug/instrument the Linux
> kernel module to be
There was no patch attached. Please post the patch inline in the email in case
the patch gets stripped from the email again.
Thanks.
Cheers,
John
> -Original Message-
> From: zhuyj [mailto:zyjzyj2...@gmail.com]
> Sent: Thursday, June 25, 2015 2:06 AM
> To: e1000-devel@lists.sourceforge
There was no patch attached. Can you please post the patch also inline of the
email in case the patch gets stripped again?
Cheers,
John
> -Original Message-
> From: shouta.ueh...@jp.yokogawa.com
> [mailto:shouta.ueh...@jp.yokogawa.com]
> Sent: Wednesday, June 24, 2015 10:06 PM
> To: Rus
ilto:pavel.odint...@gmail.com]
> Sent: Friday, June 19, 2015 9:04 AM
> To: Ronciak, John
> Cc: Skidmore, Donald C; e1000-devel@lists.sourceforge.net
> Subject: Re: [E1000-devel] VF inside VM with bypassed PCI-E ixgbe
>
> Hello, folks!
>
> Thanks for answer! Really important informa
In addition Pavel you should go back to the Intel Field person you got the
NIC's from to get the enabling code. Most people who buy these NIC's are
building their own kernels which have the modified driver which includes this
code. That code can't be pushed upstream as there is no generic kern
We think that maybe you are having link issues since the problem is
intermittent and moving from machine to machine. If it more repeatable on a
since system we could do more. Please check the link at the switch port to see
if it think it has link on that failing system.
Thanks.
Cheers,
John
ing the laundry-list of cc's because I think I'm the only
> >> one on
> 82574L support on Linux at this time.
> >>
> >> Todd Fujinaka
> >> Software Application Engineer
> >> Networking Division (ND)
> >> Intel Corporation
>
Can you try KVM to see if it's also happening there?
Cheers,
John
> -Original Message-
> From: Zoltán Halassy [mailto:cf0...@gmail.com]
> Sent: Wednesday, March 25, 2015 1:55 AM
> To: Ronciak, John
> Cc: e1000-devel@lists.sourceforge.net
> Subject: Re: [E1000-devel]
Hi Zoltan,
Sorry to hear that you are having problems. Does this happen on the same
system when _not_ using Xen? This device has been in out for a very long time
and we have not had reports come in like this. So please let us know if
running without Xen changes it's behavior.
Thanks.
Cheer
2015 6:00 PM
> To: Ronciak, John
> Cc: Kirsher, Jeffrey T; e1000-devel; Tantilov, Emil S
> Subject: Re: [E1000-devel] ixgbe: kernel BUG at include/linux/mm.h
>
> On Tue, Mar 10, 2015 at 11:13 PM, Ronciak, John
> wrote:
> > Hi Bob,
> >
> >> I think that's the n
ks.
Cheers,
John
> -Original Message-
> From: Bob Liu [mailto:lliu...@gmail.com]
> Sent: Tuesday, March 10, 2015 7:26 AM
> To: Ronciak, John
> Cc: Kirsher, Jeffrey T; e1000-devel; Tantilov, Emil S
> Subject: Re: [E1000-devel] ixgbe: kernel BUG at include/linux/mm.h
>
&
> -Original Message-
> From: Jeff Kirsher [mailto:jeffrey.t.kirs...@intel.com]
> Sent: Tuesday, March 10, 2015 6:38 AM
> To: Bob Liu
> Cc: e1000-devel; Tantilov, Emil S
> Subject: Re: [E1000-devel] ixgbe: kernel BUG at include/linux/mm.h
>
> On Tue, 2015-03-10 at 21:29 +0800, Bob Liu wrote
They are not available publically yet. Certain select OEM's and other
customers have the adapters in hard and are testing the upstream driver. You
wil have to wait for them to be shipping (post release) before you will be able
to buy them.
Cheers,
John
> -Original Message-
> From: Fa
gt; -Original Message-
> From: Jeremiah Brock [mailto:jbr...@everettcc.edu]
> Sent: Wednesday, March 4, 2015 11:35 AM
> To: Ronciak, John
> Cc: e1000-devel@lists.sourceforge.net
> Subject: Re: [E1000-devel] i350 - NVM Checksum Is Not Valid
>
> Hello John,
>
>
Where did the NIC come from? Is it a new NIC? Is this only happening with
this Security Onion 1204 (probably very old driver)? Can you boot a live image
of Ubuntu 14.10 or even 14.04 to see if that works?
Cheers,
John
> -Original Message-
> From: Jeremiah Brock [mailto:jbr...@everett
Adding Vasu and Neerav
Cheers,
John
> -Original Message-
> From: Ethan Zhao [mailto:ethan.z...@oracle.com]
> Sent: Friday, January 9, 2015 8:38 AM
> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Wyborny, Carolyn;
> Skidmore, Donald C; Rose, Gregory V; Vick, M
No you need the ne020 driver. It's in any recent Linux kernel.
You could always search for the PCI device ID in the Linux source to tell you
which driver supports your particular device.
Cheers,
John
> -Original Message-
> From: John Donnelly [mailto:b24warb...@gmail.com]
> Sent: Monda
HI Brandon,
You haven't given us much to go on here. Is this on x86 (Intel) architecture
or something else? Is the system cache coherent? Is it set up of big or
little end-in? If the DD bit is never getting set it could be a cache
coherency problem of some kind. Have you done a PCI bus tra
Please do not include attachments. Include the error messages in-line of the
email.
We are going to need much more detail of what you are trying to do and what the
actual error case is. Include what version of everything you are using in the
email.
Cheers,
John
> -Original Message-
o see that pause frame works with our HW and
drivers? Like for some sort of validation that they actually work?
Cheers,
John
> -Original Message-
> From: Julia Niewiejska [mailto:julia.niewiej...@fkie.fraunhofer.de]
> Sent: Thursday, November 6, 2014 5:31 AM
> To: Ronciak,
Julia,
First we can't help you with your Realtec issue. Not our driver.
The only time when you'll notice actual pauses in traffic due to XON/XOFF will
be when the link is saturated to the point where packets would be dropped with
the HW (on the end that is XON/XOFF enabled). So in using ping
David,
> How best would we go about getting this functionality into the standard
> driver? I suspect my initial experiments would need some work to watch out
> for corner cases and interactions with other adapter features.
I would suggest working on submitting changes to ethtool to enable the feat
The kernel headers get installed when the kernel-devel package is installed.
Sorry for the confusion.
Thanks Todd.
Cheers,
John
-Original Message-
From: Hisashi T Fujinaka [mailto:ht...@twofifty.com]
Sent: Wednesday, October 29, 2014 3:26 PM
To: Ronciak, John
Cc: Freelance48; e1000
You most likely did not install the kernel headers package.
Cheers,
John
-Original Message-
From: Freelance48 [mailto:freelance...@gmail.com]
Sent: Monday, October 27, 2014 2:55 PM
To: e1000-de...@lists.sf.net
Subject: [E1000-devel] issus with Kernel header files not in any of the
expec
What do you mean by "outside the network"? Outside of what network? Like
anther address on the same subnet or something that has to go through a router
or bridge? If you don't bond the interfaces does it work?
Also, what kind of system is this one? What Linux version? Version of the
ixgbe d
So it looks like you are losing link between the NIC and the switch. It can
take up to 4 seconds to regain link in auto-neg configurations. So have you
tried different cables? Any set of cables show the issues more than others?
Do you see the problem on all port of the switch or only some o
> -Original Message-
> From: xuyongjia...@gmail.com [mailto:xuyongjia...@gmail.com]
> Sent: Monday, May 12, 2014 10:07 PM
> To: eric.duma...@gmail.com
> Cc: e1000-devel@lists.sourceforge.net; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Yongjian Xu
> Subject: [E1000-devel] [PATC
> -Original Message-
> From: CHEN Cliff [mailto:cliff.c...@alcatel-lucent.com]
> Sent: Thursday, April 17, 2014 1:58 AM
> To: e1000-devel@lists.sourceforge.net
> Subject: [E1000-devel] e1000 driver
>
> Is there any High-level design doc for e1000 driver?
>
> Regards
> Cliff
Are you lookin
> Hi,
>
> using the IGB driver v5.2.5 together with several i211 NICs I see that
> all of them are not correctly set up because of NVM checksum errors
> reported.
>
> Adding a few debug messages I get:
>
> [2.605249] e1000_validate_nvm_checksum_generic
> [2.605483] e1000_validate_nvm_che
Boris,
What kind of system (platform) is this happening on? It's a LOM correct? Can
you run 'lspci -vvv' and output the results?
Thanks.
Cheers,
John
> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Thursday, April 10, 2014 5:00 AM
> To: e1000-devel@lists
, 2014 11:21 AM
> To: Rustad, Mark D
> Cc: Ronciak, John; e1000-devel@lists.sourceforge.net
> Subject: Re: [E1000-devel] Bringing down igb interface causes 200ms
> latency in unrelated processes
>
> Yes, I think that's the issue. With our 20ms timeslots it was taking
>
> -Original Message-
> From: Aaron Brice [mailto:aaron.br...@gmail.com]
> Sent: Tuesday, March 25, 2014 5:54 PM
> To: e1000-devel@lists.sourceforge.net
> Subject: [E1000-devel] Bringing down igb interface causes 200ms latency
> in unrelated processes
>
> I have a 12 CPU server with 3 4-por
> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Friday, March 21, 2014 7:52 AM
> To: Ertman, DavidX M
> Cc: e1000-devel@lists.sourceforge.net; net...@vger.kernel.org
> Subject: Re: [E1000-devel] i217-LM boot wreckage
>
> On Fri, 21 Mar 2014, Thomas Gleixner
If you are looking for the serial number use ethtool to read it.
Cheers,
John
> -Original Message-
> From: Nomad Esst [mailto:noname.e...@yahoo.com]
> Sent: Monday, March 10, 2014 11:37 PM
> To: e1000-devel@lists.sourceforge.net
> Subject: [E1000-devel] igb serial number register
>
> Hi
> This is very odd. I booted into Windows to verify what settings it
> uses for this NIC relating to WOL. What I found:
> [x] Wake on Magic Packet
> [x] Wake on Pattern Match
> [x] Wake of Magic Packet from power off state
>
> I shutdown from Windows and again, it went down and did not wake up.
m: John [mailto:da_audioph...@yahoo.com]
> Sent: Wednesday, February 26, 2014 3:23 PM
> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Wyborny,
> Carolyn; Skidmore, Donald C; Rose, Gregory V; Duyck, Alexander H;
> Ronciak, John; Williams, Mitch A
> Cc: da_audioph...@yah
s.
Cheers,
John
> -Original Message-
> From: Dr. David Alan Gilbert [mailto:d...@treblig.org]
> Sent: Saturday, February 15, 2014 12:13 PM
> To: Ronciak, John
> Cc: e1000-devel@lists.sourceforge.net
> Subject: Re: [E1000-devel] dual e100 'exec cuc_dump_reset
Do you have the kernel configured to have PTP support? I'm guessing not which
is causing this problem. Please check your kernel configuration.
Thanks.
Cheers,
John
> -Original Message-
> From: Fred Klassen [mailto:fklas...@appneta.com]
> Sent: Thursday, February 13, 2014 11:33 AM
> T
r that supports DCA.
Cheers,
John
From: Scott Silverman [mailto:ssilver...@simplexinvestments.com]
Sent: Thursday, February 13, 2014 8:28 AM
To: Ronciak, John
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] DCA on Sandy Bridge?
John,
Thanks for the prompt response, but I
e-
> From: Dr. David Alan Gilbert [mailto:d...@treblig.org]
> Sent: Saturday, February 08, 2014 12:16 PM
> To: Ronciak, John
> Cc: e1000-devel@lists.sourceforge.net
> Subject: Re: [E1000-devel] dual e100 'exec cuc_dump_reset' vs PCI
> latency (possibly vs Tulip)
>
The driver is just telling you what's possible not that DCA is enabled. The
newer chipsets do not included it as it's all DDIO. So even though the NIC's
is capable of support DCA the chipset does not have it so it won't be used.
That's all this is saying. It's not an issue at all.
Cheers,
J
Hi Dave,
Please see my comments in-line below.
Cheers,
John
> -Original Message-
> From: Dr. David Alan Gilbert [mailto:d...@treblig.org]
> Sent: Monday, February 03, 2014 12:11 PM
> To: Ronciak, John
> Cc: e1000-devel@lists.sourceforge.net
> Subject: Re: [E1000-deve
Some list removed for now
What do the HW stats for the failing port say? Is it receiving what it thinks
are packets that a problem in some way? Is there a way to change the MTU being
used on the camera that is causing the problem? Does moving the problem camera
link to the other e100 port wo
Maybe but does it compile correctly if you don't specify -pae? I don't think
we test for that config option anymore and I'm pretty sure a generic 3.2 kernel
will compile the driver correctly it's probably something like this.
Cheers,
John
> -Original Message-
> From: Lauper Alexander
Hi Alexander,
You need to get the tools and the NVM image from your field person from Intel
that sold you the i210 parts. You should be under NDA and your field person
will be able to get you the tools and the initial NVM image for you to put into
the NVM of the parts.
Let me know if your Int
Where did you buy the parts (the i210 parts) from? They are only sold from
suppliers that have the Intel contacts for supplying the tools and images
needed for HW development.
Cheers,
John
> -Original Message-
> From: Lauper Alexander [mailto:alexander.lau...@comlab.ch]
> Sent: Thursd
rently cannot change anything on that machine. As soon as I can, I
> will try the driver. Is it enough to test some up-to-date -next tree?
>
> >> -Original Message-
> >> From: Jiri Slaby [mailto:jirisl...@gmail.com] On Behalf Of Jiri
> Slaby
> >> Sent: Sunday, Ja
Hi Jean-Francois,
You will need to use another utility called "eeupdate" to program the flash.
The field person you got bootutil from should have also given you eeupdate.
The tool is under NDA as the only people that need it are the actual HW
developers implementing designs using the device.
This could be a BIOS issue. Do you have the latest one for your system? It
looks like the Ethernet device wasn't suspended correctly which seems to be
happening here.
So this doesn't happen if you have a cable with link plugged in to the port?
Are you also saying that it's only happening on
Where is the output from the calls I asked you for? Please attach the output.
Thanks.
Cheers,
John
> -Original Message-
> From: Evan.Wang(王维) [mailto:evan.w...@advantech.com.cn]
> Sent: Monday, November 11, 2013 8:32 PM
> To: Ronciak, John; e1000-de...@lists.sf.net
> Cc
Please supply the output from 'lspci -vvv' as well as 'ifconfig -a'. That will
tell us which of our devices are in the system.
When you use the term "MACs" below do you mean the 4 Ethernet ports on the
motherboard?
Cheers,
John
> -Original Message-
> From: Evan.Wang(王维) [mailto:evan.
I think you are pinging yourself (the same machine that you just configured,
10.0.77.1). So the packets aren't really going out to the system and back into
the system. Ping a remote machine that is on the same subnet and see what it
does.
Cheers,
John
> -Original Message-
> From: ve
This has been fixed and there will be an update KMP from SuSE that will have it
fixed. Our stand-alone drivers don't do this so it's not an issue with those.
Cheers,
John
> -Original Message-
> From: Bill Snapko [mailto:bsna...@sgi.com]
> Sent: Monday, October 28, 2013 12:36 PM
> To: e
> -Original Message-
> From: Kristian Kielhofner [mailto:k...@kriskinc.com]
> Sent: Friday, October 25, 2013 12:01 PM
> To: e1000-devel@lists.sourceforge.net
> Subject: [E1000-devel] Intel I350, igb and
> overruns/rx_fifo_errors/queue drops
>
> Hello,
>
> I have a brand new Dell R620 wi
Hello,
Why would you have an unprogrammed i210 device/NIC? Did something happen to
the system the device or NIC was in? What type of system is the i210 in?
Since you are asking for an eepromARMtool I'm assuming that the i210 is in some
sort of ARM system. Is that correct? Where did the sys
Does it work OK with a newer kernel? Like 3.10? What are the device ID's of
the NIC's? Use 'lspci -vvv' to print out the ID's.
Did you check for a BIOS update for the platform? Please see if you have the
latest BIOS on the system. If not, please update it.
Please let us know.
Thanks.
C
> -Original Message-
> From: Dâniel Fraga [mailto:frag...@gmail.com]
> Sent: Sunday, September 08, 2013 11:47 PM
> To: Ronciak, John
> Cc: 'e1000-devel@lists.sourceforge.net'
> Subject: Re: [linux-nics] e1000e: link up and down issue with TP-Link
> WDR4300 router
Just to you and e1000-devel
Hi Daniel,
These types of link partner problems do come up. Most times there is nothing
that the end-point system can do about it as the actual problem is on the
router/switch side of things. The way end-points get around things like this
is start the whole link
Hi Steve,
Thanks for the tip. Maybe we should add this to the readme or something like
that. I'll see what we can do.
Thanks again.
Cheers,
John
> -Original Message-
> From: Steve O'Brien [mailto:obr...@velocent.com]
> Sent: Sunday, September 08, 2013 6:58 PM
> To: 'e1000-devel@list
You don't know what the problem is however even though you made a code change
where you don't see the issue any more. Before a patch can be applied there
needs to root cause of the issue and there isn't enough information to
understand what the issue really is. The e1000 driver has been in use
Is the PF interface up and working before you bring up the VF?
Cheers,
John
From: William Tu [mailto:u9012...@gmail.com]
Sent: Wednesday, August 07, 2013 2:30 PM
To: Ronciak, John
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] PF still in reset state and vpd r/w failed
Hi John
ugust 07, 2013 1:39 PM
To: Ronciak, John
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] PF still in reset state and vpd r/w failed
Hi John,
No... after loading the ixgbe with no VF, I did not see any interface brought
up by ixgbe. However, the message did not should any err
Try a stable kernel and not an RC. Also something newer, like 3.10 or Fedora
19.
Cheers,
John
From: William Tu [mailto:u9012...@gmail.com]
Sent: Wednesday, August 07, 2013 2:06 PM
To: Ronciak, John
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] PF still in reset state and vpd
Does the ixgbe driver work with any virtualization? Like bare metal 10 gig
interface in the host system?
Cheers,
John
> -Original Message-
> From: William Tu [mailto:u9012...@gmail.com]
> Sent: Wednesday, August 07, 2013 1:17 PM
> To: e1000-devel@lists.sourceforge.net
> Subject: [E1000
I think you are going to have some issue because you are trying to have the HW
do some filtering which a driver (or existing user-space tool) would need to be
in communications with your application to do this. That's why the PF_RING is
processing all the packets. In your case you are trying t
Have you seen an actual problem where this has really happened? It's unclear
to me that this can happen with how the locks are implemented.
Cheers,
John
> -Original Message-
> From: Eugene Shatokhin [mailto:eugene.shatok...@rosalab.ru]
> Sent: Friday, August 02, 2013 8:27 AM
> To: e100
The request for stats should be happening only once every 2 seconds. Do you
have a script pounding on getting stats repeatedly? Are you sure that it's the
request for stats that is causing the issue you are seeing or are you guessing
that this is the case? Can you make this happen without bon
BTW, this is in reference to using ping with larger sized frames.
Cheers,
John
> -Original Message-
> From: Ronciak, John [mailto:john.ronc...@intel.com]
> Sent: Friday, July 12, 2013 9:40 AM
> To: Jagdish Motwani; e1000-devel@lists.sourceforge.net
> Subject: Re: [E
Yes the patch is still needed. Setting the MTU smaller than a normal packet
will cause the frame to be IP fragmented. So you should be seeing at least 2
packets on the wire being IP fragments. Use wireshark (or something similar)
to make sure those packets make it to on to the wire.
Cheers,
; From: Pavel Machek [mailto:pa...@ucw.cz]
> Sent: Tuesday, July 09, 2013 1:49 PM
> To: Waskiewicz Jr, Peter P
> Cc: Ronciak, John; Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce
> W; Wyborny, Carolyn; Skidmore, Donald C; Rose, Gregory V; Duyck,
> Alexander H; Dave, Tush
Jesse; Allan, Bruce W; Wyborny,
> Carolyn; Skidmore, Donald C; Rose, Gregory V; Waskiewicz Jr, Peter P;
> Duyck, Alexander H; Ronciak, John; Dave, Tushar N; e1000-
> de...@lists.sourceforge.net; net...@vger.kernel.org
> Subject: e1000e on thinkpad x60: interrupt problem
>
> H
So are you using DPDK as Don asked previously?
Cheers,
John
From: Kaushal Bhandankar [mailto:kaushal...@gmail.com]
Sent: Thursday, July 04, 2013 9:39 AM
To: Skidmore, Donald C; Ronciak, John
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] Intel 82599 Driver dropping packets
There can be but it depends on timing of releases and the kernel merge windows.
One may be ahead of the other for a short period of time. We do everything we
can to keep them as close as possible. This is true for all our current
drivers.
Cheers,
John
> -Original Message-
> From: D
Are the packets being dropped by the HW or by the SW somewhere? Read the
actual HW stats using ethtool to see if the HW is seeing all the packets.
Thanks.
Cheers,
John
> -Original Message-
> From: Kaushal Bhandankar [mailto:kaushal...@gmail.com]
> Sent: Monday, June 17, 2013 7:32 PM
>
V; Skidmore, Donald C
> Cc: Ronciak, John; Kirsher, Jeffrey T; e1000-
> de...@lists.sourceforge.net; Brandeburg, Jesse
> Subject: RE: [E1000-devel] Regarding 82599 SR-IOV support in MSI
>
> Hi Greg,
>
> By the way, I have Intel Centerton (S1200) board also. As far as I know
e interrupt for everything so there is no way to
differentiate. That is the problem and why MSI-X is required.
Cheers,
John
> -Original Message-
> From: mhban [mailto:mh...@samsung.com]
> Sent: Thursday, June 13, 2013 7:50 PM
> To: Ronciak, John; Skidmore, Donald C; Kirsher,
Hello,
No it's not possible. MSI-X is needed so that interrupts can be routed to each
guest. With MSI there is only a single interrupt so there is no way to route
it to multiple VF's. MSI-X is a requirement for SR-IOV support. So don's
comments below are correct. Sorry.
Does this system
site)?
Cheers,
John
> -Original Message-
> From: pla...@gmail.com [mailto:pla...@gmail.com] On Behalf Of Peter
> LaDow
> Sent: Thursday, June 06, 2013 1:22 PM
> To: Ronciak, John
> Cc: Brandeburg, Jesse; Waskiewicz Jr, Peter P; e1000-
> de...@lists.sourceforge.net
> Subj
> Sent: Thursday, June 06, 2013 12:40 PM
> To: Ronciak, John
> Cc: Brandeburg, Jesse; Waskiewicz Jr, Peter P; e1000-
> de...@lists.sourceforge.net
> Subject: Re: [E1000-devel] Memory Corruption with e1000
>
> On Thu, Jun 6, 2013 at 11:23 AM, Ronciak, John
> wrote:
> >
.
Cheers,
John
> -Original Message-
> From: Brandeburg, Jesse
> Sent: Thursday, June 06, 2013 10:34 AM
> To: Peter LaDow
> Cc: Waskiewicz Jr, Peter P; e1000-devel@lists.sourceforge.net; Ronciak,
> John; Brandeburg, Jesse
> Subject: Re: [E1000-devel] Memory Corruption with
Hi Peter,
So I have a couple of questions. Does this happen with a non-preemptive
kernel? I understand that you probably need to use a preemptive kernel but for
testing purposes it would be good to know. We don't always test with
preemptive kernels.
When doing the up/down transitions is t
I think you want to look at using raw sockets from your user-space application.
The raw socket will allow you to send and receive data directly without the
network stack touching the packets.
Cheers,
John
> -Original Message-
> From: Yupeng Zhu [mailto:ypzhu1...@gmail.com]
> Sent: Tue
Hi,
If you have to "up" the interface to get link (actual link reported by both
sides of the connection) then this is correct. If the switch side (assuming
switch) is reporting link but the NIC side is not then there may be something
else going on.
Do you have the interface configured to co
Hi Alan,
You found the right people for looking into this. Indeed this looks to be an
issue for one of the two calls. Since we are going to have to recode the area
around the call a bit please give a bit to get a test version ready. Once we
versify that it works we'll push upstream and give
1 - 100 of 329 matches
Mail list logo
