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
al core xeon 2.33 GHz
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:
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 A is rx enabled only and always ready to receive packets.
> Computer B is both rx and tx enabled. B sends packets at high rate
> about
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 ca
n [mailto:dragon...@tom.com]
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 f
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, Jess
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 wi
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:0
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
.* -p1 < file.patch
here is the download link
https://sourceforge.net/tracker2/download.php?group_id=42302&atid=447451&file_id=298629&aid=1460945
From: Gary W. Smith [mailto:g...@primeexalia.com]
Sent: Thursday, March 12, 2009 9:16 AM
To: Brandeburg,
re using this patch:
https://sourceforge.net/tracker2/download.php?group_id=42302&atid=447449&file_id=283326&aid=2007017
its the e1000_disable_dac.patch file.
From: Gary W. Smith [mailto:g...@primeexalia.com]
Sent: Thursday, March 12, 2009 12:55 PM
To:
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
Greg KH wrote:
> On Fri, Mar 13, 2009 at 03:10:51PM -0700, Andrew Morton wrote:
>>
>> I fired up this kernel up on my FC8 laptop and I see
>> http://userweb.kernel.org/~akpm/p3130212.jpg
>>
>> On the next two boot attempts, the kernel came up OK.
>>
root issue:
seems that something with the 2.6
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 y
On Mon, 16 Mar 2009, Pelle Svensson wrote:
> Your assumption about the Intel AMT seems right!
>
> Log Tracking DHCP Request when plugged net cable in:
>
> - Power on and load Fedora -> No DHCP Request from BIOS until Desktop up
> - ifdown eth0 -> DHCP Request
> - Restart Fedora -> DHCP Request d
Ingo Molnar wrote:
> * Lubomir Rintel 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 look
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
On Wed, 18 Mar 2009, Dave Boutcher wrote:
> If you go back in this thread I had a dead easy unprivileged user-land
> testcase
> that causes frame loss. We ran into this in a production environment
> (and I kind
> of glossed over how long it took to figure out why the hell we were dropping
> frame
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
On Sun, 15 Mar 2009, Andrew Morton wrote:
> > http://bugzilla.kernel.org/show_bug.cgi?id=12876
> > I get the following OOPS when I down the e1000 network interface:
> >
> > irq 18: nobody cared (try booting with the "irqpoll" option)
> > Pid: 9014, comm: udevd Tainted: GW 2.6.29-0.237.rc7
Wu Fengguang wrote:
> Don't do the num_tx_queues based masking on calculating tx queue
> index.
>
> 1) num_tx_queues is not always power-of-2, because it also depends on
>the online cpu numbers. So the masking could be a performance bug
>on a 6 cpu system.
> 2) queue_mapping will be limit
Wu Fengguang wrote:
> Move the update of real_num_tx_queues from
> ixgbe_acquire_msix_vectors() to ixgbe_set_num_queues(), to ensure it
> be always in sync with num_rx_queues.
>
> Signed-off-by: Wu Fengguang
besides the typo in the description, the change looks sane. Jeff please take
it into
Richard Scobie wrote:
> I just read the following in a recent patch for ixgbe:
>
> "MSI-X allocation broke after the 82599 merge on systems with more
> than 8 CPU cores. 82598 drops back into MSI mode, which isn't
> sufficient to
> run full, efficient 10G line rate."
>
> I have a Supermicro X7DW
Zsolt Foldvari wrote:
> On Wed, 1 Apr 2009 08:30:31 -0700
> "Ronciak, John" wrote:
>
>> The attachment didn't make it. It was only a single of "".
>> Please try to send it again.
>
> Now gzip'ed, maybe that was the problem...
>
> Zsolt
FYI, our list strips most kinds of attachments beside
On Thu, 2 Apr 2009, Chris Markle wrote:
> My system is a fc1 system (yeah I know... :( ):
>
> [r...@xxx root]# uname -a
> Linux xxx 2.4.22-1.2174.nptlsmp #1 SMP Wed Feb 18 16:21:50 EST 2004
> i686 i686 i386 GNU/Linux
>
> running a pretty old (5.2.16) version of the e1000 driver:
>
> [r...@xxx
Hi Jesper,
On Sun, 5 Apr 2009, Jesper Krogh wrote:
> I have a 2.6.27.20 system in production, the e1000 drivers seem pretty
> "noisy" allthough everything appears to work excellent.
well, nice to hear its working, but wierd about the messages.
> dmesg here: http://krogh.cc/~jesper/dmesg-ko-2.
zsolt foldvari wrote:
> On Wed, Apr 1, 2009 at 11:15 PM, Brandeburg, Jesse
> wrote:
>> Zsolt Foldvari wrote:
>>> On Wed, 1 Apr 2009 08:30:31 -0700
>>> "Ronciak, John" wrote:
>>>
>>>> The attachment didn't make it. It was only
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 fo
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 m
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
> 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
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 */
> ew
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
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
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 onbo
On Mon, 20 Apr 2009, Nir Drang wrote:
> Hi All, we are trying to change the igb driver to support UDP
> segmentation in linux. the chipset we use is 82576. as it appears the
> stack supports it but the function igb_tso_adv assumes its a tcp message
> and set the context with TCP parameters. we w
Benzi wrote:
> Hi,
>
> I see this stat being increased meaning the tx ring is getting full
> and i want to avoid that. it might be that the cleanup of tx ring
> buffer is slow. In e1000 there is TxIntDelay that you recomment to
> lower its value for faster tx cleanup. IS there something similar fo
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 Gigabi
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 desc
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 inclu
On Tue, 21 Apr 2009, Benzi wrote:
> OK thanks for the clarification.
> Regarding tx ring size setting: what about if the CPU is not the
> bottleneck (i.e., i still have cpu headroom)? i mean if i have
> tx_restart_queue events when i have plenty of cpu idle i probably need
> to increase the tx
On Tue, 21 Apr 2009, Holger Eitzenberger wrote:
> > > > 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.
>
> > holger, you're welcome to try this patch, it was made against net-2.6 from
>
Breno Leitao wrote:
> According to the "PCI Error Recovery" document, if after a recovery,
> the
> bus is disabled, the error_detected function should return
> PCI_ERS_RESULT_DISCONNECT. Actually ixgbe error_detected function is
> always returning PCI_ERS_RESULT_NEED_RESET, even if the bus is in
>
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
> so
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 af
On Sat, 25 Apr 2009, Stefaan wrote:
> I've recently bought four Intel PRO/1000 MT Dual Port Server Adapters
> (PCI/PCI-X). To my surprise, they seem to fail whenever two gigabit
> links are plugged into the same nic, to recover only after a reboot.
> After experimenting, the issue seems to be driv
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, w
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
>&g
Hi Dawid,
Dawid Golunski wrote:
> I use e1000 drive with 82545EM NIC.
> Sometimes during high bursts of traffic I get the "Detected Tx Unit
> Hang" errors:
>
> May 6 16:15:35 r32 kernel: EXT3-fs error (device loop0):
> ext3_journal_start_sb: Detected aborted journal
> May 6 16:15:35 r32 kernel:
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
> algorit
zsolt foldvari wrote:
> Hi!
>
> On Wed, Apr 8, 2009 at 2:12 AM, Brandeburg, Jesse
> wrote:
>> Your full dmesg from boot would have been more useful, but I think
>> you have the issue of dma with these 32 bit controllers failing when
>> you have lots of ram.
>
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
its related to how much your tcp window size is being opened up from the remote
end. If you have a remote end client running and LRO/GRO enabled driver the
window will proabably open much more
-Original Message-
From: john M [mailto:johnmt...@gmail.com]
Sent: Thursday, May 14, 2009 12
x27;t a driver issue.
-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 b
Hi did you ever figure this issue out? Can you use –C –c option to netperf to
measure CPU?
Do you have LRO enabled on the receiver?
From: Jiaqing Du [mailto:jiaq...@gmail.com]
Sent: Tuesday, April 28, 2009 5:26 AM
To: Brandeburg, Jesse
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000
On Sun, 3 May 2009, zhang.xu-m...@inventectj.com wrote:
> Dear sirs，
>
> I am a software engineer， working at Inventec Tianjin Company.
>
> I found an issue with the driver for the Intel(r) 82571 PCI-E
> gigabit adapters, version 0.5.18.3, release date 3/23/2009.
>
>
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
Can you send a full 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, Fe
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 the tx_ring lock any more (in the driver).
On the receive side the napi polling is per cpu and protects the driver from
re-entr
On Sun, 31 May 2009, Nix wrote:
> I've just compiled a 64-bit kernel for a couple of quad-core Nehalems
> (one L5520, one Core i7) for the first time. Both were using 32-bit
> kernels happily before, and one (the Core i7) is happy afterwards: but
> the other sees two ksoftirqd threads saturating
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
On Wed, 3 Jun 2009, Lal wrote:
> I am using 7.3.20-k2-NAPI version of e1000 driver on Linux 2.6.21
>
> On a moderate traffic rx_no_buffer_count remains constant, but on
> heavy traffic rx_no_buffer_count keeps increasing.
>
> rx_no_buffer_count: 4094038
> rx_no_buffer_count: 4094038
>
On Wed, 3 Jun 2009, Lal wrote:
> On Mon, Jun 1, 2009 at 9:21 PM, Brandeburg, Jesse
> 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
apcismp=off =>
did not work
do all of the above again (sorry!) withOUT noapic.
-Original Message-
From: Nguyen, Khanh D (IS) [mailto:khanh.d.ngu...@ngc.com]
Sent: Friday, May 29, 2009 3:06 PM
To: Brandeburg, Jesse
Cc: Yu, Feng-Ger (IS); Stabile, John S (IS); DaCosta, Ted; M
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' undec
On Sun, 14 Jun 2009, Zang Roy-R61911 wrote:
> Hi, guys
> I am trying to port E1000 82572EI Intel PCIE card in U-boot.
> Now the phy can be aoto linked up and I can also receive data, but the
> package I send can not go out.
>
> I print some register:
>
> roy :e1000_transmit tctl = 3003f0fa:
> ro
On Tue, 16 Jun 2009, Joerg Roedel wrote:
> today I got this dma-debug warning with the ixgbe driver with a kernel
> near 2.6.30-rc8.
Hi Joerg, thanks for the report, I thought we had fixed all of these
already but we must have missed this one.
> [ cut here ]
> WARNING: at
en, Khanh D (IS) [mailto:khanh.d.ngu...@ngc.com]
Sent: Monday, June 15, 2009 4:16 PM
To: Brandeburg, Jesse
Cc: Yu, Feng-Ger (IS); Stabile, John S (IS); DaCosta, Ted; Muller, Bill (IS);
Pongmanopap, Tony (IS); Tantilov, Emil S; e1000-de...@lists.sf.net
Subject: RE: [E1000-devel] e1000e problem with Intel 82574L P
On Wed, 17 Jun 2009, Tharindu Rukshan Bamunuarachchi wrote:
> we are developing internal application (actually automated trading
> system) on SuSE 11.
> however, we are using 2.6.29 stock kernel.
>
> our applications are just using TCP/IP for inter-process communication.
> while increasing transac
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 th
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 add
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)
>
> M
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
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
http:/
On Thu, 21 May 2009, Nix wrote:
> On 20 May 2009, n...@esperi.org.uk spake thusly:
>
> > All is not well with the out-of-tree driver, though: 0.5.18.3 doesn't
> This is because the enumization of irqreturn_t conflicts with kcompat.h
> quite badly: you can't #ifdef-check for the presence of enums
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 queue.
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: e1000-devel@li
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 invo
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 inserte
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 ICR.I
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 ch
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: e1000-devel@lists.sourcefo
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 kerne
I CCd the maintainers list, which since you are talking about the out of
tree driver (I think) is probably more appropriate for future postings.
On Wed, 9 Sep 2009, Michal Soltys wrote:
> While experimenting a bit with intel PRO/1000 CT nic (reported by lspci as
> Intel
> Corporation 82574L Gi
On Mon, 21 Sep 2009, Richard Scobie wrote:
> Jesse Brandeburg wrote the following a while back:
>
> "do you have prefetchers enabled in your bios? you should turn off
> adjacent cache line prefetcher and hardware prefetch. If you have the
> prefetchers enabled it erases or makes worse performan
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 /pr
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: R
On Thu, 22 Oct 2009, Roger Oksanen wrote:
> Hi,
> I got hit by bug #14265
> (ifconfig: page allocation failure. order:5, mode:0x8020 w/ e100) and
> investigated the driver a bit. The high-order cbs allocation isn't
> really needed and can be satisfied by allocating one page at a time
> as the
On Fri, 20 Nov 2009, Luca Deri wrote:
> I would like to force RSS to balance packets from the same TCP
> connection to be sent on the same queue. Today RSS splits them into two
> different queues.
>
> How can I do that?
Luca, I'm a little confused. If it is the same TCP connection by
definiti
In the short term, you can always put the port into D3 using setpci (once the
driver is unloaded), which will take down the link if wake on is disabled.
Linux unfortunately doesn't have good device power management controls yet.
If you would like us to look into this feature as a feature reques
I believe that behavior is expected, 82575/576 don't support timestamp all as I
recall.
-Original Message-
From: Ali Gholami Rudi [mailto:aligr...@gmail.com]
Sent: Wednesday, November 11, 2009 9:52 AM
To: e1000-devel@lists.sourceforge.net
Subject: [E1000-devel] HWTSTAMP_FILTER_ALL for ig
On Mon, 7 Dec 2009, Andrew Morton wrote:
> > When I power up my system the NIC is working properly.
> > After every reboot the NIC is not working. I mean the eth0 is created, but
> > neither dhcpcd gets IP nor static setup helps
We have a userspace tool called ethregs downloadable from
http://d
On Tue, 15 Dec 2009, Vishal Verma -X (vishaver - Embedded Resource Group at
Cisco) wrote:
> I am currently using 82571EB chip over fiber medium, along with
> kernel 2.6.23.9.
>
> Few of our use-case scenarios involve shutting down and start of
> interface.
> On fiber medium, interface shutd
On Thu, 17 Dec 2009, Roger Oksanen wrote:
> e100: Fix broken cbs accounting due to missing memset.
>
> Alan Stern noticed that e100 caused slab corruption.
> commit 98468efddb101f8a29af974101c17ba513b07be1 changed
> the allocation of cbs to use dma pools that don't return zeroed memory,
> especia
201 - 300 of 346 matches
Mail list logo
