Arkadiusz Miskiewicz wrote:
Hello,
hi, sorry to hear about your problem.
I have a problem with e1000e driver on SR2520 intel platform, running
2.6.25.5 kernel.
When e1000e driver is loaded the IPMI connection to the machine is
lost. This machine has two ethernet ports that share normal
Srivatsa Vaddagiri wrote:
Hi,
I happened to look at a system which was exhibiting poor ping
performance with e1000 driver (in 2.6.25) and had some questions
regarding that.
...
Upon some investigation, I found that the interrupt count field in
/proc/interrupts (associated with eth1)
would you accept a module option that did the same thing? We could also
add the kernel option so that you could change the default in the driver
at compile time. Seems like both would be a good solution.
I have a similar report from another user, he proposed a module option
fix_broken_bmc
?? wrote:
Hi all:
I'm a newbie.
I had change the e1000e driver for use Tx checksum offload always,
and remove the ipv6.
why did you make driver changes? what are you trying to achieve? It looks like
you've just changed the driver just to change it. Did it work before for you?
BUT,
Neil Horman wrote:
On Tue, Aug 05, 2008 at 01:15:29PM +0100, Ben Hutchings wrote:
REcently observed a problem wherein, if a BMC or other IPMI
device
is attached to a NIC, multicast frames can be consumed by the
aformentioned device without ever being seen by the driver. Since
multicast
Jiri Slaby wrote:
There were 2 omitted readb's used on an iomap space. eliminate them
by using ioread8 instead.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
Cc: Jeff Kirsher [EMAIL PROTECTED]
Cc: Jesse Brandeburg [EMAIL PROTECTED]
Cc: Bruce Allan [EMAIL PROTECTED]
Cc: PJ Waskiewicz [EMAIL
Kumar Narayanan wrote:
1. Is the MAC controller 82575 full-duplex? More specifically, if I
use Intel Pro/1000 VT will it be able to send and receiver 1Gbps of
traffic at the same time?
Yes, of course, and for all packet sizes our hardware is capable of line
rate, up to the limitations of the
Can you try forcing the switch to only advertise 1000/FD in its autoneg
advertisement?
You could also try forcing the driver to advertise only 1Gb/FD using
AutoNeg=0x20,0x20 for e1000/e1000e driver (or use ethtool to set
advertisement mask using ethtool -s ethx advertise 0x20)
AFAIK we currently
Roman Chertov wrote:
I have a question regarding multi-queue support. I noticed that
current NAPI code only deals with one queue; however, it appears that
the
support for multiple rings is there.
Which driver are you referring to? In general yes, we support multiple
RX queues with NAPI
Roman Chertov wrote:
each queue gets its own msi-x vector and each queue only gets packets
which match the RSS hash for that queue. There are separate hardware
resources for each queue and the driver has a ring struct for each
queue to maintain separate state.
Can you point me to some
Pierre Ossman wrote:
I've just noticed that the e1000e has delightfully made poo poo all
over my EEPROM (something David Vrabel also has reported). Shit
happens and all that I guess, but how do I get the thing back in a
working order? Couldn't find anything useful on the interwebs...
were
Leigh Sharpe wrote:
what does ethtool -i eth13 say?
[EMAIL PROTECTED]:~$ sudo ethtool -i eth13
driver: e1000
version: 7.1.9-k4-NAPI
firmware-version: N/A
bus-info: :08:0b.0
[EMAIL PROTECTED]:~$
also, can you tell us if you see the Intel AMT bios pre-boot screen
come up?
No
: Thursday, August 28, 2008 3:16 PM
To: Brandeburg, Jesse
Cc: e1000-devel@lists.sourceforge.net; Kirsher, Jeffrey T; Allan, Bruce
W; Waskiewicz Jr, Peter P; Ronciak, John; [EMAIL PROTECTED]
Subject: Re: how to repair correupted EEPROM/NVM?
Any verdict on this part?
On Tue, 26 Aug 2008 20:46:01 +0200
Pierre Ossman wrote:
On Fri, 29 Aug 2008 09:05:15 -0700
Jesse Brandeburg [EMAIL PROTECTED] wrote:
I'm concerned that you're actually having some other driver problem
that isn't getting reported, like a wierd semaphore issue or
something. can you build the e1000e-0.4.1.7.tar.gz driver from
Pierre Ossman wrote:
On Fri, 29 Aug 2008 11:20:03 -0700
Brandeburg, Jesse [EMAIL PROTECTED] wrote:
hm, this article points to the ibautil program which can restore your
eeprom, I didn't know we had this available (and I'm not sure if it
will work on your hardware) This tool is from my
Pierre Ossman wrote:
On Fri, 29 Aug 2008 11:20:03 -0700
Brandeburg, Jesse [EMAIL PROTECTED] wrote:
hm, this article points to the ibautil program which can restore your
eeprom, I didn't know we had this available (and I'm not sure if it
will work on your hardware) This tool is from my
Chris Jones wrote:
Hi
Brandeburg, Jesse wrote:
yeah, running ibautil appears to pretty well kill many part's NVM.
Ah, damn.
upon some follow up questions it appears that ibautil should only ever
be run on Intel branded PCI/PCI-X/PCIe adapters that plug into a slot.
It may have a bug which
-8) after the long weekend.
Jesse
-Original Message-
From: Leigh Sharpe [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 28, 2008 6:43 PM
To: Brandeburg, Jesse; Tantilov, Emil S
Cc: e1000-devel@lists.sourceforge.net
Subject: RE: [E1000-devel] Port showing link down at random times
Eth13
Chris Jones wrote:
Hi
Brandeburg, Jesse wrote:
Yes, not all bioses will upgrade the NVM for the lan. Chances are
good that if the file size is larger it will upgrade more of the NVM,
hopefully upgrading the LAN NVM as well (check the release notes)
None of the release notes
Randy Dunlap wrote:
From: Randy Dunlap [EMAIL PROTECTED]
ixgbe needs to be restricted to the same build config (m/y)
as DCA since it calls the dca_*() functions.
ixgbe_main.c:(.text+0xd9c09): undefined reference to `dca3_get_tag'
Thanks Randy for catching that, you're correct.
Acked-by:
Bill Gatliff wrote:
John Winters wrote:
Bill Gatliff wrote:
[snip]
The MAC Address will be reset to 00:00:00:00:00:00, which is invalid
and requires you to set the proper MAC address manually before
continuing
to enable this network device.
the Linux kernel actually can make up a mac
On Wed, 24 Sep 2008, Breno Leitao wrote:
I just found an issue related to ixgb that seems to be a regression.
After the interface is up and running (packets already transmitted), if
I try to change the MTU, running ifconfig ethX mtu 70, for example,
causes the following warning[1].
Brice Goglin wrote:
Adrian Bunk wrote:
But considering that igb is in a similar situation it would be nice
if all 3 drivers would handle it the same way.
Jesse,
What do you think of the below patch?
Seems like a much better solution. I can have Jeff Kirsher work on the
equivalent
Sanjoy Mahajan wrote:
There is also lots of opportunity for BIOS bugs to be effecting
things so please make sure that you have the latest bios.
I was about to burn the CD to update the bios to 2.23 when the failure
recurred. So, with the caveat that the bios is still 2.20, I've
attached
Richard Scobie wrote:
Is it a fair assumption that if I am setting jumbo frames on Intel
interfaces in both Windows Vista and Linux, that an MTU of 9000 is
exactly the same on both, or do I need to adjust this figure by the
header size on one or the other?
AFAIK, yes. MTU pretty much means
Richard Scobie wrote:
A 10Gb FAQ at the Intel site states:
Can I connect two Intel 10 GbE Server Adapters back-to-back without a
switch?
Yes, you can connect two Intel 10 GbE Server Adapters together
without a switch. However, this type of unit-to-unit connection will
yield very limited
Sanjoy Mahajan wrote:
hm, does your kernel have CONFIG_PM defined?
It does have that defined:
ok
if it happens again please include lspci -vvv before and after
ethtool -r (see below)
I will. Now I'm running BIOS 2.23, so I'm curious whether that
'upgrade' fixes the problem.
I say
Richard Scobie wrote:
Brandeburg, Jesse wrote:
That text is a bit outdated...
Thanks and good news :)
One other question. The README for the Linux driver hosted on the
Intel website, dated June 17 2008, states that LRO is required to be
disabled if forwarding or bridging is required
You most likely need a bios update, and probably a firmware update for your
BMC. Do you happen to have a supermicro system?
-Original Message-
From: Lakshmana Reddy [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 04, 2008 3:29 PM
To: e1000-devel@lists.sourceforge.net
Subject:
Carsten Aulbert wrote:
sorry to bother you such a thing, but I'm not getting anywhere right
now. I've a server with four NICs which are all powered by the e1000
driver. Two are on the Supermicro main board and two are added via an
add-on card. It seems that I can only PXE boot from the two
Anders Grafström wrote:
Brandeburg, Jesse wrote:
On Fri, 31 Oct 2008, Russell King - ARM Linux wrote:
On Thu, Oct 30, 2008 at 05:27:59PM +0100, Anders Grafström wrote:
The e100 driver triggers BUG_ON(buf-direction != dir)
by doing pci_map_single(..., PCI_DMA_BIDIRECTIONAL
Irwin Estes wrote:
Jeff,
Is it possible to obtain the source of the patch? Is there something
that we can do to future proof our build notes for the kernel/module
that allows for functional use of IPMI?
Thank you,
- Irwin
The patch was posted on 11-14 to the mailing lists and
[EMAIL PROTECTED] wrote:
I am experiencing rx_missed_errors with Intel 82541 based gige and
e1000
8.0.6 on 32Bbit 33MHz PCI. In my opinion, the network load is not so
heavy - 15 kpps and 90 Mbit/s at peaktimes. CPU load is no more than
30%. I know it is old hardware ([EMAIL PROTECTED]), but
Ted Romer wrote:
Thanks for your help, my Dell *Precision* 650 (you were right about
that) now responds to Wake on Lan, and ethtool output includes
Supports Wake-on: umbg
Wake-on: g
Attached is a proposed patch that implements a
WakeOnLan82545EMEnable option so that Linux
hong zhang wrote:
List,
My e1000 is built as default and MTU=1500. After e1000.ko is
insmoded, ping -c 1 -s 1400 www.google.com works fine. But ping
-c 1 -s 1600 www.google.com does not work.
I check e1000_main.c and see:
skb-data_len = 0 and skb_shinfo(skb)-gso_size = 0.
I see skb
Bashir Rategh wrote:
Hello
We had been advised to contact you regarding the issue of 2 Tx and 2
Rx queue for the card:
Intel® PRO/1000 CT Desktop Adapter
On the Intel site it says it can have 2 Tx and 2 Rx queue at the same
time
The URL on intel site is:
Optimized queues: 2
Chris Caputo wrote:
Just a heads-up on a possible e1000 or e1000e driver issue on linux
kernel
2.6.27.10 while running IPTraf 3.0.0.
I was playing around with this program. The different options, such
as IP traffic monitor seemed to work fine. When I tried the LAN
Station
Monitor
Hi Alberto:
Alberto Nava wrote:
I work for Espial, a VOD software vender in bay area. We have had
good relationship with
Intel in the pass qualifying platform and Ethenert adpater for
VidoeOnDemand application.
A few years back we worked together on the definition of UDP
segmentation
The code was refactored, e1000_hw.c became all the split out files you list
below.
I saw your message on netdev too, we're the only ones that ever reply to intel
related issues, it seems :-)
so what is the actual connection type on your ethernet, is it a directly
connected fiber port? Is it
Jonathan Fournier wrote:
so what is the actual connection type on your ethernet, is it a
directly connected fiber port? Is it a serdes blade? forgive me
I've never tested one of the ATCA platforms.
I just found out more documentation for that platform, since most ATCA
switch are
Patrick Schreurs wrote:
I can't seem to find an option to disable multiqueue in the igb driver
which comes with the 2.6.28.x kernel. The module parameter IntMode is
not supported.
With 6 nics operational i now use 54 interrupts. My hardware (Dell
PE1950 / Intel 5000X chipset), spreads all
Greg KH wrote:
On Mon, Jan 26, 2009 at 09:01:36PM +0100, Jesper Krogh wrote:
Greg KH wrote:
We (the -stable team) are announcing the release of the 2.6.27.13
kernel. It contains a wide range of bugfixes, and all users of the
2.6.27 kernel series are strongly encouraged to upgrade.
I'll also
Billy Huang wrote:
Hello,
I got the following error while compile e1000 driver in linux2.6.26.7.
Any clue for this?
Thanks
CC drivers/net/e1000/e1000_param.o
drivers/net/e1000/e1000_param.c, line 60: error: union unnamed
has no
field arr
Chris Caputo wrote:
On Mon, 5 Jan 2009, Brandeburg, Jesse wrote:
Chris Caputo wrote:
Just a heads-up on a possible e1000 or e1000e driver issue on linux
kernel
2.6.27.10 while running IPTraf 3.0.0.
I was playing around with this program. The different options, such
as IP traffic monitor
Is it your opinion that it is possible to route 64 byte packets close to wire
speed with unmodified e1000e drivers? and unmodified kernel?
From: Brandeburg, Jesse [mailto:jesse.brandeb...@intel.com]
Sent: Thursday, February 19, 2009 11:44 AM
To: Carl Petersen
Subject: RE: quick question regarding e1000
standard questions, what exact kernel, what igb driver version, what does cat
/proc/interrupts look like, are you running msi-x in 2.6 kernel?
is it the in-kernel version?
if so you're running NAPI for sure, and NAPI pushes the packet drops back down
to the hardware device when the stack/cpu
]
Sent: Saturday, February 28, 2009 11:45 PM
To: e1000.sf
Cc: Brandeburg, Jesse
Subject: Sometimes, it will have to work with a swich
dragon wrote:
When connecting two computers (with one e1000 each) back to back, I
tried simple rx/tx
work but found some problems.
Situation:
Computer
Hi Carsten, any update?
Carsten Aulbert wrote:
Hi Jesse,
sorry for the late reply, too much other work to rank this question
high enough.
I was able to work around the problem by adding netconsole module
loading to a dhclient hook.
Brandeburg, Jesse schrieb:
0d:00.0 0200: 8086:108c
you might be able to tune ITR using ethtool -C ethx rx-usecs N
you may also want to increase or decrease the number of receive buffers using
ethtool -G ethx rx N
if the stack consumes too many cycles per packet it is normal for the driver to
drop frames, that is what is architected to happen
On Wed, 11 Mar 2009, Dave Jones wrote:
Fedora rawhide kernels have been carrying a set of DMA debugging patches
from dwmw2 for a while. I just booted up a box which contains two of these..
01:00.0 Ethernet controller: Intel Corporation 82575EB Gigabit Network
Connection (rev 02)
01:00.1
On Wed, 11 Mar 2009, Gary W. Smith wrote:
I asked this last week but didn't get a response. I have a supermicro
apologies for the slow response.
server with a dual intel nic that uses the e0100 driver. I'm using
CentOS 5.2 and when I do anything network intensive I lose connectivity
for a
are working better,
Jesse
From: Gary W. Smith [mailto:g...@primeexalia.com]
Sent: Thursday, March 12, 2009 2:45 PM
To: Gary W. Smith; Brandeburg, Jesse
Cc: e1000-devel@lists.sourceforge.net
Subject: RE: [E1000-devel] Detected Tx Unit Hang
That was a bad example
good idea to include e1000-devel@lists.sourceforge.net on these kinds of
requests.
On Sun, 15 Mar 2009, Pelle Svensson wrote:
Is there any functionality inside the driver for DHCP request.
I see in the source that there is some kind of DHCP filter f the tx stream.
Can the drive issue DHCP
On Fri, 13 Mar 2009, Ben Greear wrote:
I have selected build-firmware-into-kernel
but it seems e100 is still unhappy in 2.6.29-rc7.
e100 :02:01.0: firmware: requesting e100/d102e_ucode.bin
e100: eth4: e100_request_firmware: Failed to load firmware
e100/d102e_ucode.bin: -2
can you post
Ingo Molnar wrote:
* Lubomir Rintel lkund...@v3.sk wrote:
On Wed, March 18, 2009 8:04 am, Ingo Molnar wrote:
( e1000e Cc:s added. A new debug feature, CONFIG_DMA_API_DEBUG=y,
has triggered the warning below in e1000_put_txbuf(). )
http://lkml.org/lkml/2009/3/2/318
We are still
On Tue, 17 Mar 2009, Dave Boutcher wrote:
Eric, based on your inability to recreate this, I tried on some other
hardware I had lying around that has an AMD chipset built-in NIC.
I could not recreate the problem on that hardware. I'm starting to
think this is an e1000 problem. In both the
On Wed, 18 Mar 2009, Ingo Molnar wrote:
http://lkml.org/lkml/2009/3/2/318
We are still looking for more testing from the general community of
this patch, in particular if any tx hangs are reported. Thanks in
advance for any reports.--
Yeah - already picked it up into
Douglas Geiger wrote:
I am trying to get Linux up and running on my new (2009) Mac Pro (the
4,1 model). I currently have Ubuntu Jaunty (Alpha 6) installed, and
amy working to get the Gig-E interfaces working. It looks like they
should
be supported by the e1000e module, but the PCI ID's
Tony Breeds wrote:
GCC warns:
drivers/net/ixgbe/ixgbe_main.c: In function
'ixgbe_sfp_config_module_task':
drivers/net/ixgbe/ixgbe_main.c:3920: warning: suggest parentheses
around operand of '!' or change '' to '' or '!' to '~'
Which I think is right. Bracket to remove ambiguity.
On Fri, 10 Apr 2009, Vlad Yasevich wrote:
Hi Folks
Any comments, questions, opinions???
The silence has been stunning. Does anyone else have
access to the hardware to test this thing?
Apologies, of course we have the hardware. In fact this is still sitting
in my mailbox flagged for
looks like you might be disabling interrupts and then not re-enabling them, and
/ or losing a receive interrupt.
you also may need to consider generating an interrupt every two seconds from a
timer using ICS register, which might help you catch any missed interrupt
causes.
In this test you
Hi Anna,
On Tue, 14 Apr 2009, Fischer, Anna wrote:
I am running ixgbe 1.3.56.5-NAPI on a Linux 2.6.18 kernel (SMP, two CPUs):
filename: /lib/modules/2.6.18.8/kernel/drivers/net/ixgbe/ixgbe.ko
version:1.3.56.5-NAPI
snip
I load the driver with InterruptType=2,2 MQ=1,1 RSS=2,2
Filka Michal wrote:
Hi all,
I need a help with following issue.
I have a board with six Ethernet cards (all e1000). Two of them are
currently used (eth0, eth2).
If I do ifdown eth0 and then ifup eth0 it lasts at least 30s (ping
reports destination host unreachable) until the card
added maintainer's list
On Wed, 15 Apr 2009, Ed Swierk wrote:
A recent patch to e1000, intended to avoid a race in the interrupt code,
seems to prevent the watchdog timer from resuming properly. It neuters
the effect of
/* fire a link change interrupt to start the watchdog */
Aditya Rajgarhia wrote:
Hi,
I updated to kernel 2.6.29.1 (from 2.6.22) yesterday and my Intel
82566MM fails to work now (eth0 is not recognized). First, I noticed
that the new kernel uses e1000e for this controller rather than e1000,
but I get the following in dmesg:
e1000e: Intel(R)
On Fri, 17 Apr 2009, Holger Eitzenberger wrote:
Kernel v2.6.16.y (+ patches)
e1000e v0.5.11.2
Hi,
Hi again Holger,
I'm facing NVM corruption on both ports a dual port NIC module:
PCI: Enabling device :09:00.0 ( - 0003)
ACPI: PCI Interrupt :09:00.0[A] - GSI 19 (level,
On Fri, 17 Apr 2009, Azeem Khan wrote:
I see almost 80% spurious interrupts inside the e1000 irq handler
(e1000_intr) when receiving frames. NAPI is enabled and functional.
Please help me understand why. Here are more details.
Configuration:
--
I have a PC with an onboard
On Sun, 19 Apr 2009, Andrey Luzgin wrote:
We have repeating problems on several servers with different versions of
the driver e1000e with kernel 2.6.28.9 (this version because of tproxy
is necessary to us). All servers is Intel® Server Systems SR1560SF with
one additional NIC 82572EI Gigabit
On Mon, 20 Apr 2009, Benzi wrote:
Flow control is disabled.
okay good.
Can you explain please why *decreasing* (and not increasing) the tx ring
buffer will help avoiding tx_restart_queue?
the memory allocation and number of cachelines/pages being accessed goes
from 1 page (at 256
On Mon, 20 Apr 2009, Holger Eitzenberger wrote:
e1000e: write protect ICHx NVM to prevent malicious write/erase
no, doesn't apply to this hardware, as it is not ICH (integrated LOM) it
is a standalone 82571 with an actual discreet eeprom chip per port.
to include our modules
On Fri, 24 Apr 2009, Holger Eitzenberger wrote:
Other than that I'm fine evaluating that patch in our testlab.
any news on the evaluation?
after checking the driver I think it's best to continously do a
offline selftest, as the driver seems to use the SWSM/SWSM2 registers
somewhere
On Sat, 25 Apr 2009, Jiaqing Du wrote:
Hi, List
I'm playing with two Intel 10 Gigabit CX4 Dual Port Server Adapters located
at two different machines and connected by network cables directly. These
two cards sit on two x8 PCIe slots.
The tuning I did includes setting interrupt affinity
On Mon, 27 Apr 2009, Yanping Du wrote:
On a single 10GE link, we tuned and got netperf 9.4Gb/s (with 1500
MTU) and ~9.9Gb/s with jumbo frame.
82598 has only a PCIe GEN 1 (2.5 Gb/s per lane)
But when running netperf tcp traffic to the two 10GE links on the card
at the same time, we
Breno Leitao wrote:
Jesse,
Brandeburg, Jesse wrote:
Also, what kind of system, and how fast is your memory?
netperf test to localhost is a decent indication of memory
bandwidth. netserver netperf -T0,0 -C -c
netperf -T0,1 -C -c
netperf -T0,2 -C -c
What are the minimum/expected output
vikram wrote:
I am vikram, a graduate student in Arizona State University.
I am trying to bring up one set up where i am using igb driver e1000,
where in i would like to send the Ip packets across all the queues
associated with the port instead just one or two. I know some hash
algorithm in
On Thu, 14 May 2009, vikram wrote:
thanks a lot. that was of great help.
Also it would be great if you can tell me where i can study about the
hash function on both sides? is there any document on net?.
search for receive side scaling at microsoft.com for RSS.
for transmit, you'll just
.
-Original Message-
From: john M [mailto:johnmt...@gmail.com]
Sent: Thursday, May 14, 2009 12:45 PM
To: Brandeburg, Jesse
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] Help regarding TSO support
its related to how much your tcp window size is being opened up from
Hi Khanh, Emil has some suggestions, but in addition can you try booting the
kernel with pci=bios, and then if that doesn't work use pci=biosirq
The other interesting boot option might be acpi=off, and acpismp=force
I believe what you're basically seeing is a bios compatibility problem with the
dmesg (dmesg.txt.gz) please, and output of ethtool -e ethX
(ethtool.txt), as well?
-Original Message-
From: Nguyen, Khanh D (IS) [mailto:khanh.d.ngu...@ngc.com]
Sent: Friday, May 29, 2009 2:17 PM
To: Brandeburg, Jesse; Tantilov, Emil S; e1000-de...@lists.sf.net
Cc: Yu, Feng-Ger (IS); Stabile
On Mon, 1 Jun 2009, vikram wrote:
I found this peculiar thing regarding the hashing in RSS. According to the
hashing algorithm, for a particular source and destination ip address and
port numbers, the packets should be always hashed to the same queue since
the hashing algorithm uses only a
On Wed, 3 Jun 2009, Lal wrote:
On Mon, Jun 1, 2009 at 9:21 PM, Brandeburg, Jesse
jesse.brandeb...@intel.com wrote:
Peter, you're correct, however the tx queue interface is protected by
locks (qdisc lock, netdev lock) in the stack. And newer kernel
versions of e1000 don't even have
On Mon, 15 Jun 2009, Frank Dauer wrote:
I am using ixgbe-2.0.34.3, kernel 2.4.36, glibc-2.2.5 and gcc 2.96.
When I build ixgbe I get the following error:
ixgbe_param.c: In function `ixgbe_check_options':
ixgbe_param.c:950: parse error before `char'
ixgbe_param.c:956: `pstring' undeclared
And lastly, please try without bonding when performance tuning to eliminate
bonding from being the issue.
Also, with the slower cpu you're likely hurting your throughput with the high
interrupt rates.
Using TSO on the transmit side may be precluded by the bonding driver in F9
(not sure) and
You've found the right place, we need as much of the below information you can
provide.
This is a useful set of information that we almost always ask for when trying
to solve a problem:
* Summary of bug (one line):
* Detailed description of bug:
* Reproducible with steps:
You should see a decrease in CPU with DCA on.
If you run the ethregs utility from sourceforge and grep DCA you'll see that
the lower 16 bits are configured differently for each cpu assigned an
interrupt, when DCA is enabled.
Are you running with MSI-X enabled?
There is another patch we can
On Tue, 23 Jun 2009, Sangjin Han wrote:
Are you running with MSI-X enabled?
Yes, as well as RSS.
There is another patch we can add which enables DCA for data of
received packets, but you need to run a test which actually accesses
the data (usually not benchmarks)
My
On Tue, 23 Jun 2009, Kristiadi Himawan wrote:
I have problem with the high utilization on the one of cpu's core when
using irq affinity and now i'm trying to get multiple tx rx feature to
balance it. My NIC is Intel Ethernet controller 82571EB PRO/1000 PT with
Dual Port Server Adapter, it's
1GbE: 82575/82576
10GbE: 82598/82599
Your OS and hardware must support MSI-X
-Original Message-
From: Lal [mailto:learner.ker...@gmail.com]
Sent: Wednesday, June 24, 2009 4:49 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] HW flow seperation
An old discussion at
On Mon, 29 Jun 2009, Andrew Morton wrote:
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Thu, 18 Jun 2009 13:45:38 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=13568
http://msdn.microsoft.com/en-us/library/ms795616.aspx
-Original Message-
From: 배영부 [mailto:r...@piolink.com]
Sent: Monday, June 29, 2009 7:28 PM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] [ixgbe] In RSS, I'd like to know algorithm that select
rx packet descriptor
Just FYI, our development tree is internal only for our out of tree driver, but
we send patches to the kernel ASAP, after they have passed testing.
-Original Message-
From: Nix [mailto:n...@esperi.org.uk]
Sent: Saturday, June 06, 2009 9:46 AM
To: Waskiewicz Jr, Peter P
Cc:
On Mon, 8 Jun 2009, Lal wrote:
I am using 2.6.21 kernel and CONFIG_E1000_NAPI is defined. It's a
multi-core system.
In e1000_intr the interface, over which packet is received, is queued
in poll_list (per cpu based).
this is the key.
Later net_rx_action invokes dev-poll which
On Wed, 1 Jul 2009, Yosuke HIZUME wrote:
I'm using e1000e-0.5.8.13 *Non-NAPI* on kernel 2.6.10 with 82573L.
I found the receiving data was occasionally corrupted just after I
changed the mtu or the speed and duplex setting.
you also apparently are not using MSI interrupts.
Then I inserted
On Wed, 1 Jul 2009, Yosuke HIZUME wrote:
I understand as follows. Is it right understanding?
Yes.
- Irq11 for eth0 is shared with uhci_hdc and dsppci2 because MSI is
unavailable.
- When the interrupt for either uhci_hdc or dsppci2 is asserted, we can see
e1000_intr() called with
On Wed, 1 Jul 2009, 배영부 wrote:
I'm still evaluating RSS feature of Intel 82598EB AF 10G ethernet card.
I think this is my last problem.
that is computed hash value of NIC.
Before the evaluation, I wrote a simulation code to simulate ComputeHash
function according to datasheet.
and I checked
I don't think that can ever happen. The only useful case of this might be when
in VMDq mode and a broadcast packet was replicated to all the different VMs.
-Original Message-
From: Benzi [mailto:lb.weiss...@gmail.com]
Sent: Wednesday, July 22, 2009 7:23 AM
To:
On Mon, 7 Sep 2009, Yu Zhiwei wrote:
Hello, e1000 developers,
I was trying to nfsroot with USB stick from my server, but failed to get IP
address from DHCP server most of time. I am sure that network configuration
is good, because I can nfsroot with e1000 on another server. This kernel
On Fri, 9 Oct 2009, Chris Friesen wrote:
I've got some general questions around the expected behaviour of the
82576 igb net device. (On a dual quad-core Nehalem box, if it matters.)
As a caveat, the box is running Centos 5.3 with their 2.6.18 kernel.
It's using the 1.3.16-k2 igb driver
On Fri, 16 Oct 2009, Richard Scobie wrote:
I'm have just put together a Nehalem system (1 x Xeon),
2.6.30.8-64.fc11.x86_64, which has quad onboard 82576 and noticed during
testing using just a single interface, that the RX queues on the other 3
were receiving interrupts - observed in
Wow, thanks Bill, that explanation was spot on, and very well put. Thanks for
taking the time to respond.
Jesse
-Original Message-
From: Bill Paul [mailto:wp...@windriver.com]
Sent: Monday, October 19, 2009 4:17 PM
To: scott.co...@gs.com
Cc: e1000-devel@lists.sourceforge.net
Subject:
1 - 100 of 224 matches
Mail list logo
