firmware from Cisco.
So, I’d be asking, why is the switch cycling or dropping the link? Hope this
helps!
Jesse
From: Buchholz, Donald
Sent: Thursday, December 7, 2023 11:05 AM
To: Assaf Albo
Cc: Brandeburg, Jesse ;
e1000-devel@lists.sourceforge.net; Matan Levy ; Itamar Maron
Subject: RE: [e1000
Related to reducing the likelihood of a backlog of transmits at 1G, try
Disable TSO - ethtool -K eth0 tso off
Reduce TX descriptors - ethtool -G eth0 tx 64
I would try the first by itself, then try the two combined.
--
Jesse Brandeburg
> On Feb 4, 2021, at 7:55 AM, Fujinaka, Todd wrote:
>
>
> Subject: [E1000-devel] Possible bug in the i40e driver 2.4.3
Thanks for your report, someone here will have a look. We may not be able to
get back to you until after the holidays.
--
Check out the vibrant tech commun
You've seem to have found a major regression, if you wouldn't mind would you
post the bug to debian Bugzilla and let us know the number so we can watch/join
in?
Breaking stateless offloads like this will knock everyone down to sub 10Gb
performance, and increase CPU dramatically for no reason.
Thanks for the report, probably not much we can do, but it might be interesting
to have lspci output and dmidecode output. Can't attach on this list so you
would have to put inline or in a bug on Sourceforge or on pastebin
--
Jesse Brandeburg
> On Dec 2, 2016, at 7:31 PM, Michał Mirosław w
This is not my program or an endorsement, but you can try building this
http://free-electrons.com/pub/mirror/devmem2.c
I ran it like this:
Wget above...
gcc -O2 -o devmem2 devmem2.c
ethtool -i ethx
find bus:dev.fn address from ethx via command above
lspci -s -v
get first "Memory at HWMEM" addre
016 at 8:04 PM, Brandeburg, Jesse
mailto:jesse.brandeb...@intel.com>> wrote:
Hi Mattias,
Please see the pktgen.c module for how to correctly call driver ops directly
(well, almost, as you should pretty much never call driver ops directly, and
certainly not ignore the return code or the
Hi Mattias,
Please see the pktgen.c module for how to correctly call driver ops directly
(well, almost, as you should pretty much never call driver ops directly, and
certainly not ignore the return code or the state changes)
http://lxr.free-electrons.com/source/net/core/pktgen.c#L3366
What you
The elrepo kernels *ARE* stable kernel.org kernels, pre-built for RHEL/Centos.
I don't believe there are any backports done (beyond the stable patches applied
to 4.5.X), I think kcompat is just messed up and can be fixed likely with a
small patch (it probably already is fixed in our current kcomp
If you have a Sourceforge account you can post all of that information in a bug
entry at https://e1000.sf.net/bugs
-Original Message-
From: Rose, Gregory V [mailto:gregory.v.r...@intel.com]
Sent: Monday, March 14, 2016 10:54 AM
To: Reuben Farrelly ;
e1000-devel@lists.sourceforge.net
Su
Also because the problem is maybe related to SYN, maybe trying turning off
flow-director/ATR by doing something like:
ethtool -K ethx ntuple on
-Original Message-
From: Steffen Weber [mailto:steffen.we...@gmail.com]
Sent: Tuesday, December 08, 2015 12:12 PM
To: Skidmore, Donald C ;
e1
Hi Zack, everything is okay.
The first message is just a message from the kernel, just letting you know that
you're running an out-of-tree driver and there is no way to fix it, but there
is no harm either.
The second message is from the driver to let you know that the driver expects
that a new
Thanks for the detailed report, we will try to reproduce this ASAP, but it may
be a few days.
The behavior as described doesn't seem normal for the workload.
The only other information I see that would be useful is the ethtool -S output
from each of the active ports.
-Original Message-
Did you ever get any help on this issue?
The below failure shouldn't cause a system halt. You are getting a reset which
I wouldn't expect unless something else triggered it.
A bigger question is why are you getting reset during runtime? What kind of
traffic do you normally do?
-Origina
On Fri, 2015-04-17 at 05:24 +, Tal Lubko wrote:
>
> Hi
> Thanks again to Jeff Kirsher for the detailed answer regarding backporting
> the driver.After understanding no backporting is needed for the e1000 to work
> with 3.2.x (kcompat does the API adjustments) I've tried compiling the driver
On Thu, 2015-02-26 at 12:07 +, Ralf Grosse Boerger wrote:
> Hi,
>
> I have been measuring UDP roundtrip times with several different Intel
> Gigabit Ethernet Controllers (on two Haswell based systems, peer to
> peer connection).
> There seems to be a quite large variation in roundtrip time wit
The kcompat c and h files probably have some workaround firing based on the
kernel version. This could be messing you up, but I am surprised it would
compile.
If you get genirq to work on 2.6.18 that will be quite an achievement.
--
Jesse Brandeburg
> On Feb 16, 2015, at 6:47 AM, Tal Abudi
crap, this sat in my drafts
> From: Ben Greear [mailto:gree...@candelatech.com]
> It seems the cable I selected is not supported by the i40e driver/NIC.
>
> Does anyone know of a part number that *does* work?
Hi Ben,
Sorry for the delay, here is the known good cable list:
For QSFP+
XLDACBL1
X
If your interrupt is constantly moving from one core to another it causes a lot
of cache thrash and scheduler thrash which makes your networking very
inefficient.
You really don't want to be doing what you're trying to do, it won't work well
for you. That said, what was it you thought you were
You ended up with kernel-devel for 20.5, and have a kernel running 20.3
> [root@gfs-5 ixgbe-3.21.2]# uname -a
> Linux gfs-5 2.6.32-431.20.3.el6.x86_64 #1 SMP Thu Jun 19 21:14:45 UTC 2014
> x86_64 x86_64 x86_64 GNU/Linux
> kernel-devel-2.6.32-431.20.5.el6.x86_64
BTW, kernel-devel is the only pac
Hi Michael we are still not quite at official release of the drivers.
I believe the issue you report has been root caused and fixed already in the
latest firmware and drivers.
Thanks for the report, the official drivers should be available soon.
--
Jesse Brandeburg
> On Jul 4, 2014, at 6:1
I always just check for iommu and dmar in dmesg.
You should be able to boot with intel_iommu=off ?
--
Jesse Brandeburg
> On Jun 23, 2014, at 3:22 PM, "Ben Greear" wrote:
>
> I'm trying to debug a system at a remote site.
>
> It is showing worse performance than expected (an E5 2.4Ghz CPU
>
Forgive my top post.
With the new kernel you may be running into needing faster cleanup to increase
tx speed. try increasing the interrupt rate via ethtool -C ethX rx-usecs 10,
yes I said rx because there is only one rate control for the interrupt.
You can easily do line rate tx with 82599. T
Hi Stuart, you forgot to add {} around the multiple statements after the "if"
An easily made mistake btw that bites C developers all the time, so don't feel
bad. :-)
You want this:
if (e1000_maybe_stop_tx(tx_ring, count + 2)) {
printk(KERN_EMERG "e1000_maybe_stop_tx --sk"
Hi Stuart, you can use printk to print to syslog/dmesg, OR to track which
function calls are being made you can use the function tracer part of the
tracing infrastructure in the kernel.
If you use printk, then just rebuild the kernel module with make
M=drivers/net/ethernet/intel in your kernel
Scott be sure to try running turbostat on both old and new servers as I suspect
the 50us wake latency of C6 power state may cause drops.
The new kernels enable deeper sleep.
You can also try a bios setting to disable deep sleep states, leave on C1 only.
There was a program called cpudmalaten
On Wed, 2013-12-18 at 11:48 +, Morten Østergaard wrote:
> On Wed, 2013-12-18 at 14:14 +0400, Eugene Shatokhin wrote:
> > Could you also add a call to dump_stack() in your patch so as to get the
> > call trace in the system log when that strange event happens, not only
> > the warning?
> I add
Isn't 11:22:33:44:55:66 a multicast address? First octet is x11 & x01 ==
multicast.
-Original Message-
From: g...@iki.fi [mailto:g...@iki.fi]
Sent: Wednesday, December 04, 2013 3:59 PM
To: Fujinaka, Todd; e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] PROBLEM: Packets go ou
You have to ping something not on your subnet, those pings you saw are
localhost returned, not even going out on your network (definitively the case
because they are so fast).
-Original Message-
From: venkatakrishna pari [mailto:venkatpari.embed...@gmail.com]
Sent: Monday, October 28,
On Sat, 2013-09-07 at 08:44 +0200, Daniel Borkmann wrote:
> Nitpicking ... at some point in time i40e_status should be removed plus
> I40E_ERR_PARAM, I40E_SUCCESS, I40E_ERR_NO_MEMORY and the like, as we have
> int and -EINVAL, 0, -ENOMEM for that. ;-)
First, thanks Daniel for taking the time to r
On Sat, 2013-09-07 at 09:15 +0200, Daniel Borkmann wrote:
> Thanks for including SCTP! ;-)
:-)
> Here as well, I40E_ERR_NO_MEMORY vs -ENOMEM.
>
okay we will audit those and fix them.
>
> Nitpick: why s32 in the signature? There are a lot of such places, just int
> would have
> been fine pr
On Sep 5, 2013, at 11:15 PM, "Stephen Hemminger"
mailto:step...@networkplumber.org>> wrote:
Dumb question why is this named Kbuild instead of Makefile like almost
every other network driver?
All the new kids are doing it, we'll at least that is what I thought when I
made it.
Re-reading https:/
On Wed, 2013-09-04 at 23:19 -0400, David Miller wrote:
> You will fix the problems people are reporting with this patch series
> before I apply it.
Okay, the quickest path to that might be to drop the sysfs patch for
now. If that is acceptable I will re-spin the patches tonight.
On Mon, 2013-08-12 at 16:40 -0700, Alexander Duyck wrote:
> On 08/12/2013 03:28 PM, Alexey Stoyanov wrote:
> > I done reload of ixgbe with MQ=0,0 and RSS=1,1
> > There are no luck with speed.
> >
> > [ 3] local xxx.xxx.185.135 port 5001 connected with yy.yy.74.11 port 5001
> > [ ID] Interval
On Sun, 19 May 2013, Or Gerlitz wrote:
> On Sun, May 19, 2013 at 1:25 PM, Eliezer Tamir
> wrote:
> > This is an updated version of the code we posted on February.
>
> Last time you've placed a copy of the patchset in the rfc branch of
> git://github.com/jbrandeb/lls.git - can you repost there V2
I had a look over the ubuntu bug discussion at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1072722?comments=all
There is an NVM utility called flashrom that might be able to see your NVM
data. You will likely have to boot with iomem=relaxed boot parameter.
Your hardware is acting flak
Hi Dick, we need to know exactly what you are expecting to happen here. When
you saturate transmit and put lots of data on all tx queues, any ping or other
traffic that gets put in has to contend with the large amount of data in front
of it.
There is a simple test you can do, try to disable TS
You can enable flow-director on UDP packets with ethtool.
-Original Message-
From: Chris Friesen [mailto:chris.frie...@genband.com]
Sent: Wednesday, August 08, 2012 3:07 PM
To: Skidmore, Donald C
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] 82599, queues, interrupts, e
Andrew, sorry for the top post my other email client is not working, please
read this:
http://elinux.org/images/f/f9/Elc2008_pm_qos_slides.pdf
then try the python script on slide 11 (may want to adjust time). While that
script is running the c-states shouldn't go too low.
-Original Message
On Thu, 17 May 2012, Samuel Thibault wrote:
> Brandeburg, Jesse, le Thu 17 May 2012 17:04:04 -0700, a écrit :
> > > BTW, it also happens easily when request_irq takes some time to
> > > complete: since we enable E1000_TCTL_EN before that, the card can have
> > > tim
On Thu, 17 May 2012, Samuel Thibault wrote:
> Samuel Thibault, le Fri 18 May 2012 01:28:21 +0200, a écrit :
> > Dave, Tushar N, le Thu 17 May 2012 23:22:31 +, a écrit :
> > > I am interested in to see if you have actual test case and more
> > > importantly test data that shows that kernel a
Their company changed names/emails, the upstream driver was updated (in code)
maybe you should check that.
PS sorry for the top post.
-Original Message-
From: Ronciak, John [mailto:john.ronc...@intel.com]
Sent: Thursday, May 03, 2012 5:09 PM
To: Allan, Bruce W; Andy Cress; Linux NICS;
e1000 (pci/pci-x) parts support ipv4/tcp/udp stateless offload. We support a
thing called TSO (transmit segmentation), TCP/UDP transmit/receive checksum
offload, and ip transmit/receive checksum offload.
our parts are not TOE (tcp offload engine) parts, and we do not have any
firmware.
-O
sending this again as it didn't show up on the list for some reason (probably
rejected because I pgp signed the message)
-Original Message-
From: Jesse Brandeburg [mailto:jesse.brandeb...@intel.com]
Sent: Tuesday, December 06, 2011 12:10 PM
To: Michael Wang
Cc: e1000-devel@lists.sourcefo
Try disabling ASPM in the pcie configuration stuff in the BIOS, first.
-Original Message-
From: John Haechten [mailto:jhaech...@crossroads.com]
Sent: Monday, November 21, 2011 11:31 AM
To: Wyborny, Carolyn; Brandeburg, Jesse; e1000-devel@lists.sourceforge.net
Subject: RE: [E1000-devel
Can you also double check ASPM is Disabled in lspci -vvv? This sounds like
what happens when we lose PCIe link due to some instability of the design.
Also please make sure the device is being cooled well enough.
like so (for aspm):
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled-
Yes, it should work just fine, and the driver in the kernel should work without
any installation of a driver from sourceforge or intel.com (just make sure it
is enabled in the kernel you're using)
-Original Message-
From: Ashley Buckley [mailto:ashley.buck...@covisia.com]
Sent: Friday,
right?
-Original Message-
From: adi [mailto:a...@postpi.com]
Sent: Monday, October 17, 2011 10:45 AM
To: Brandeburg, Jesse
Subject: eth irq cpu affinity on 2 x 8 cores
I have a machine with 2 x 8 cores as a router with 2x 82576
(actually the machine has 2 x 82599 too, but it is still not
On Thu, 6 Oct 2011, Jesse Gross wrote:
> I'm seeing some strange packet reordering problems with Intel 82599
> based NICs using the ixgbe driver. It seems difficult to believe that
> I'm the only one running into this but it has shown up to some extent
> with every card of this type that I have
this is the right place, please inline your patch or make sure it is a text
file attachment.
-Original Message-
From: Venugopal Busireddy [mailto:v...@nextio.com]
Sent: Monday, September 19, 2011 10:14 AM
To: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] May be a FAQ!
H
On Thu, 15 Sep 2011, Lucas Nussbaum wrote:
> Hi,
>
> On 15/09/11 at 22:56 +, Ronciak, John wrote:
> > What I think is happening is that after it come out of suspend the device
> > memory mapping is either no longer mapped or it's somehow changed. The
> > reason I say this is:
> >
> > [
Transmit queues can be assigned priority and rate limit in the hardware
registers. You may have to enable DCB in order to control transmit queue
priority.
have you had a read through the "data sheet" from intel.com for 82599? If
there are specific hardware features that our driver does not s
On Tue, 26 Jul 2011, Ben Knight wrote:
> Hello
>
> We have found that to build the ixgbe module with an out-of-tree built
> kernel, we need to make the below change to ixgbe's Makefile.
>
> This should not break in-tree builds either, so it should be appropriate
> to apply upstream.
>
> Reg
On Mon, 25 Jul 2011, Baskar Duraikannu wrote:
> Hello -
> I am experiencing similar problem. We are using Intel 82572EI card
> with e1000e driver.
> ethtool is reporting the errors as rx_missed_errors.
> netstat is reporting them as RX_OVR error.
> We are using 2.6.18.238 kernel and driver versi
On Fri, 22 Jul 2011, Rama Puranam wrote:
> Hi,
>
> I am trying to enable 128 queues per Niantic port. I have four such ports.
do you need 128 tx queues or rx queues or both?
> My need to is to have the following configuration.
>
> FCoE -> Disabled.
>
> DCA -> Disabled
>
> FdirMode -> Disa
On Thu, 7 Jul 2011 07:25:41 -0700
Charles Wright wrote:
> Hello,
>
> I have a X520-DA ixgbe card with a Finisar FTLX8571D3BCL SFP+ module.
Charles, your X520-DA ixgbe adapter is configured in hardware to only
work with Direct Attach (DA) cables. The X520 adapters (without the DA)
are configur
On Wed, 2011-07-06 at 08:26 -0700, Ben Hutchings wrote:
> On Wed, 2011-07-06 at 16:53 +0200, Arkadiusz Miskiewicz wrote:
> > On Wednesday 06 of July 2011, Ben Hutchings wrote:
> > > On Wed, 2011-07-06 at 13:38 +0200, Arkadiusz Miskiewicz wrote:
> > > > 3.0.0rc6, thinkpad t400 notebook.
> > > >
> >
bug attach your
full dmesg, lspci -vvv output, dmidecode output.
sorry for the thrash, was reading too fast and misread.
Jesse
-Original Message-
From: Rao, Uthra R. (GSFC-672.0)[ADNET SYSTEMS INC]
[mailto:uthra.r@nasa.gov]
Sent: Monday, June 27, 2011 12:43 PM
To: Brandeburg, Jesse
On Mon, 2011-06-27 at 11:03 -0700, Jon Mason wrote:
> Use PCI_VENDOR_ID_* from pci_ids.h instead of creating #define locally.
>
> Signed-off-by: Jon Mason
Looks fine.
Acked-by: Jesse Brandeburg
--
All of the data gene
On Mon, 2011-06-27 at 10:52 -0700, Rao, Uthra R. (GSFC-672.0)[ADNET
SYSTEMS INC] wrote:
> Hello,
>
> We have purchased a Intel Ethernet Server Adapter X520-DA2 and put it in a
> Dell server with Red Hat Enterprise Linux 6.1 server operating system. After
> the server was rebooted I found the fo
On Wed, 22 Jun 2011, Ben Greear wrote:
> This is hacked and tainted 2.6.38.8 kernel, but no modifications to the
> e1000e driver.
>
> Didn't seem to cause any troubles.
How about info on a test to help reproduce the issue? RESETTING is set
either by the tx_timeout task or by the ethtool call
On Tue, 2011-06-14 at 10:30 -0700, Ben Greear wrote:
> >> How would a received skb be flagged as having a CRC error?
> >>
> >
> > maybe some skb->pkt_type = PACKET_INVALID; or something...
>
> Jesse: If I can get the ethtool related patches accepted, would
> you accept patches to e100 (and other
The generator box seems to be resetting the controller (and therefore the link)
Check out ethtool stats on both side and look for tx_timeout.
--
Jesse Brandeburg's iPhone
On Jun 13, 2011, at 1:35 PM, "Ben Greear" wrote:
> I have a traffic generator system with e1000e running pktgen, and emul
, removed other useless lists.
On Sat, 4 Jun 2011, Andrea Merello wrote:
> In e100 driver it seems that the intention was to accept bad frames in
> promiscuous mode and loopback mode.
> I think this is evident because of the following code in the driver:
>
> if (nic->flags & promiscuous || nic->
Adding e1000-devel, our list for the out-of-tree ixgbe driver (the issue is
reported below to be in both upstream and out-of-tree)
do you have jumbo frames enabled?
-Original Message-
From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
Behalf Of Stefan Majer
Sent
On Wed, 4 May 2011, Ed Ravin wrote:
> I have good news about the E31230 platform - I found a problem in my
> test environment that was constraining the packet generator traffic
> in the switch, before it reached the box under test. That's why I wasn't
> seeing any packet drops - the packets wer
@lists.sourceforge.net; Brandeburg, Jesse
Subject: Re: [E1000-devel] e1000: fix Tx hangs by disabling 64-bit DMA
Dave, Tushar N wrote:
> Can you disable tso?
Disabled. I'll get back with results later.
> If you already doing ignore_64bit_dma=1 then , we should make sure the w/o
> is working correctl
How are you measuring bandwidth?
-Original Message-
From: 박대영 [mailto:likebulle...@gmail.com]
Sent: Monday, April 11, 2011 4:49 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] I have a Problem in vf rate limit
hello I'm using a Ixgbe 3.3.8.
there are new feature vf rate
On Fri, 1 Apr 2011, Jon wrote:
> Hello List,
>
> I am trying to get a 82546G dual NIC Intel card to do bonding with vlans
> and a bridge for a xen server. I would like to be able to setup a bridge
> and then assign it to a VM(domU) so it is on a specific VLAN.
>
> I have bonded eth0 and eth
On Sat, 26 Feb 2011, Robin Humble wrote:
> Hi,
Hi Robin, its been a while...
> our cluster login nodes get these messages every few days, and on one
> occasion a crash ->
>
> 2011-02-22 15:00:30 do_IRQ: 13.123 No irq handler for vector (irq -1)
> 2011-02-18 12:26:55 do_IRQ: 12.180 No irq
On Thu, 3 Mar 2011, Mathias Krause wrote:
> Hello e1000e developers,
>
> I have a problem getting a specific wake-on-lan combination getting to
> work on my onboard 82574L PCIe adapter. I would like to wake the system
> from S3 by either an ARP request or an unicast packet send to the system,
>
On Wed, 2 Mar 2011, prasanna.panchamu...@riverbed.com wrote:
> This race conditions occurs with reentrant e1000_down(), which gets
> called by multiple threads while driver unload or reset.
> This patch fixes the race condition when one thread tries to destroy
> the memory allocated for tx buffe
On Tue, 1 Mar 2011, Lynch, Jonathan wrote:
> Hi Alex,
Alex is not available right now.
>
> the filtering works with this change in 3.2.9
excellent news
> Do you know why when the ixgbe module is loaded there is the following
> outputted in the console
> alloc irq_desc for 66 on node -1
>
ur machine can process (for
whatever reason) and increasing the fifo only will give you a marginal
(4kB or so) increasing in buffering.
>
> -Original Message-
> From: Brandeburg, Jesse [mailto:jesse.brandeb...@intel.com]
> Sent: Monday, February 28, 2011 11:05 AM
> To
added e1000-devel, responses inline...
On Wed, 23 Feb 2011, John Bermudez wrote:
> Hello All,
> I got your contact info in a forum.
> maybe you could give me a quick pointer.
>
> I have a device that is experiencing RX misses. I tried 1000/full and 100/full
> it occurs at both speeds. I seem to
On Wed, 23 Feb 2011, Stephen Hemminger wrote:
> Sparse complains because the e1000 driver is calling ioread on a pointer
> not tagged as __iomem.
>
> Signed-off-by: Stephen Hemminger
Seems fine, thanks Stephen.
Reviewed-by: Jesse Brandeburg
--
Please see
http://communities.intel.com/community/wired/blog/2009/10/22/updating-linux-kernel-drivers-with-release-drivers
And you could use this to build for cross compile:
cd igb*/src
make KSRC=/path/to/kernelsrc CC=/path/to/crosscc
Which I think should work, otherwise you can just use above
On Tue, 15 Feb 2011, Frank Schaefer wrote:
> Hi all,
>
> I've lately worked up a patch for the igb driver to expose the I2C
> interface (as /dev/i2c*) on applicable board assemblies. This allows
> direct querying of installed SFP modules, which is rather useful to
> us. Soon I plan to have a si
On Wed, 9 Feb 2011, Andy Cress wrote:
> Problem:
> When doing insmod ixgbe.ko on a 2.6.27 kernel with
> CONFIG_PREEMPT_DEBUG=y, it gives the error
>BUG: using smp_processor_id() in preemptible [] code:
>
> Resolution:
> I have tried the patch below, as suggested by Stephen Hemminger
On Mon, 31 Jan 2011, matt donohue wrote:
> Is it possible to set the link state to always be up?
sure, but you'll have to make driver changes. If you remove the
netif_carrier_off calls in the driver I don't think we'll ever bring link
down. Of course I've not tried this, and YMMV.
> If you
There are many design decisions in the driver that depend on NAPI. If you
disable it, the driver won't work, and even then you won't be guaranteed to get
one interrupt for every tx or rx packet. Sometimes you will be processing
packets with interrupts disabled and another packet will arrive.
Hi Eric, thanks for doing this work!
On Wed, 12 Jan 2011, Eric Dumazet wrote:
> Apparently e100 driver uses GFP_ATOMIC allocations in setup phase, and
> your machine doesnt have enough memory.
This part looks great.
> I would try following patch, allowing the use of GFP_KERNEL at init
> time, t
re related reports.
-Original Message-
From: Vasco Steinmetz [mailto:va...@kyberraum.net]
Sent: Wednesday, January 05, 2011 3:52 AM
To: Brandeburg, Jesse
Subject: Re: [E1000-devel] 2.6.36.1 e1000e - Detected Tx Unit Hang
Hi Jesse,
no I didn't run anything to check/fix eeproms. H
Hi Vasco, please post your ethtool -e ethX output for both interfaces.
have you run the fixeep script or something similar to check/fix your eeprom(s)
Jesse
-Original Message-
From: Vasco Steinmetz [mailto:va...@kyberraum.net]
Sent: Thursday, December 23, 2010 2:06 PM
To: e1000-devel@list
This time with the attachments.
** original message text **
Hi,
I added to DOM to get fiber stats in our routers some but code never
got include in kernel... So I'll though I'll do now try so is sitting
and have back-port this over again.
Now I don't get igb driver working seems there are mass
I'm forwarding this to the list in order to get feedback.
Thanks Robert for working on this!
--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the
On Tue, 7 Dec 2010, MJ embd wrote:
> Hi all,
>
> I am facing a problem in the initialization of 82752ei card.
> Running linux 2.6.32,
what hardware? your own design?
> Getting errors "Detected hardware hung"
>
> Logs:
> msi:#icr = 8004
> e1000e: eth0 NIC Link is Up 1000 Mbps Full Duple
On Wed, 17 Nov 2010, Nikola Ciprich wrote:
> On Wed, Nov 17, 2010 at 07:06:45PM +0100, Nikola Ciprich wrote:
> > Hello,
> > I'd like to ask some kind soul for help with following problem...
> > I have two identical machines, but on one of them, I'm getting lots
> > of following messages:
>
> O
On Thu, 11 Nov 2010, Holger Eitzenberger wrote:
> I've attached the patch against net-next-2.6. Please check if it's ok
> for you. I checked e1000, igb and ixgbe as well, they don't have that
> problem.
Holger,
I think the patch looks good and thanks. Great catch too! I see Jeff has
put i
On Tue, 9 Nov 2010, Holger Eitzenberger wrote:
> Hi,
>
> using e1000e driver version 1.2.10 and kernel version 2.6.32.24 I see
> the kernel go BUG() sporadically at the time 'ethtool -p eth0 3' comes
> back.
>
> Network hardware is four times 'Intel Corporation 82583V Gigabit Network
> Connect
On Mon, 2010-11-01 at 16:08 -0700, Nix wrote:
> 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
> Connection
> LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
This is a problem, L0s and L1 don't work
On Mon, 25 Oct 2010, Andy Cress wrote:
> Configuration:
> Motherboard S5000PAL
> NIC: 80003ES2LAN onboard NIC (dual)
>
> # ethtool eth0
> Settings for eth0:
> Supported ports: [ TP ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Ha
d? I do have an Intel box that I could boot a FC12 64bit livecd
that has the card. And send you the output of if this might help to
find the issue.
Jon
Quoting Jesse Brandeburg :
> On Fri, Oct 22, 2010 at 6:17 PM, wrote:
>> Quoting "Brandeburg, Jesse" :
>>
>>
On Fri, 22 Oct 2010, Bob Gilligan wrote:
> On 10/22/2010 3:41 PM, Brandeburg, Jesse wrote:
> > On Fri, 22 Oct 2010, Chris Friesen wrote:
> >> On 10/22/2010 11:06 AM, Chris Friesen wrote:
> >>> On 10/12/2010 11:08 AM, Chris Friesen wrote:
> >>>> On
On Thu, 21 Oct 2010, j...@destar.net wrote:
> I am still having this issue but it seems to only be on x86_64. I used
> a Knoppix disk to boot with and the card worked with no issues using a
> 32bit kernel. I downloaded the latest kernel from kernel.org and
> compiled it and the issue retur
On Fri, 22 Oct 2010, Chris Friesen wrote:
> On 10/22/2010 11:06 AM, Chris Friesen wrote:
> > On 10/12/2010 11:08 AM, Chris Friesen wrote:
> >
> >> On 10/08/2010 04:36 PM, Brandeburg, Jesse wrote:
> >>
> >>> seems reasonable, it sh
with DEBUG_PREEMPT set, you should probably take the issue up with
windriver, since they do support their own drivers and kernels.
Jesse
> -Original Message-
> From: Brandeburg, Jesse [mailto:jesse.brandeb...@intel.com]
> Sent: Thursday, October 21, 2010 2:44 PM
&g
Adding netdev... beware the top post ordering in the thread.
On Thu, 21 Oct 2010, Nikola Ciprich wrote:
> Ok, here're the steps to reproduce the problem:
>
> ip link set up dev eth0
> vconfig add eth0 10
> ip link set up dev eth0.10
> brctl addbr brtest
> # to bylo ok, sundá to až:
> brctl add
On Thu, 21 Oct 2010, Andy Cress wrote:
> My kernel configuration had CONFIG_PREEMPT=y, and the ixgbe 3.0.12
> module produced the following error message when it was loaded.
>BUG: using smp_processor_id() in preemptible [] code:
> Below is a patch that works for me to resolve this.
On Thu, 21 Oct 2010, Stephen Hemminger wrote:
> Signed-off-by: Stephen Hemminger
>
>
> --- a/drivers/net/e1000/e1000_main.c 2010-10-21 09:35:54.643519367 -0700
> +++ b/drivers/net/e1000/e1000_main.c 2010-10-21 09:36:01.380214771 -0700
> @@ -521,7 +521,7 @@ void e1000_down(struct e1000_adapt
1 - 100 of 346 matches
Mail list logo
