Re: [E1000-devel] networking probs in next-20081203
Alexey Dobriyan wrote:
> On Wed, Dec 03, 2008 at 05:18:34PM -0800, Andrew Morton wrote:
>> x86_64, CONFIG_E1000E=y.
>>
>> Current Linus mainline is OK, but with linux-next I'm seeing the following:
>>
>> - During boot I see a "cannot open /proc/net/dev" fly past. But when
>> it gets to the login prompt, I can read /proc/net/dev.
>
> I _suspect_ it might me something with /proc/net changes (again) and initcall
> ordering.
>
> Andrew, as rejectless quick test, you can do
>
> git checkout -f 26b0d981e7dd1d5b4852ed5719bd1388c7994163# sic
>
> which is the last tree merged before proc tree in that next tree.
>
>> - Networking won't come up. `ifup eth0' says "determining ip address
>> ... failed", and the failure is immediate.
>>
>> - eth0 appears in the ifconfig oputput as normal - it just won't come up.
>>
>> - nothing interesting in dmesg
>>
>>
>> Here's the dmesg: http://userweb.kernel.org/~akpm/dmesg-dead-net.txt
>> (that dmesg was generated with E1000=y, E1000E=y, but that doesn't seem
>> to matter)
>>
>> The .config: http://userweb.kernel.org/~akpm/config-dead-net.txt
perhaps this line has something to do with it?
[ 50.539326] type=1400 audit(1228348149.537:4): avc: denied { mount } for
pid=11636 comm="ifconfig" name="/" dev=proc/net ino=4026531842
scontext=system_u:system_r:ifconfig_t:s0
tcontext=system_u:object_r:unlabeled_t:s0
tclass=filesystem
maybe try disabling selinux?
Auke
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] Changing the ethX names
Carsten Aulbert wrote: > Hi Auke, > > Kok, Auke wrote: >> if you have udev installed and running you can just edit: >> >> /etc/udev/rules.d/70-persistent-net.rules >> >> to rename the devices persistently. No ugly firmware hacks needed. > > That's too far down the road as the kernel needs to make the inquieries > already and udev is not installed at that point (we are doing a 'FAI' > installation and the kernel gets fed something which looks like: > > kernel kernel/vmlinuz-2.6.23.1-faiinstall > append root=/dev/nfs > nfsroot=/srv/fai/nfsroot,v3,tcp,rsize=32768,wsize=32768 > ip=:eth0:dhcp FAI_FLAGS=verbose,sshd,createvt,reboot > FAI_ACTION=install console=tty0 > > > as you can see there is nfsroot involved which in turn needs dhcp and > this needs... a correct interface to work with :( > > Any other ideas? what's in a name? is it really that bad that your device has a name that is less-than logical? *shrug* with an initrd you can have udev run from a minimal initrd doing the renaming and mount the filesystem, or just use `ifrename` from said initrd. maybe that works? if you really have to resolve to reordering the probing, you're solving the wrong problem IMHO, and creating a non-portable solution. Auke - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] Changing the ethX names
if you have udev installed and running you can just edit: /etc/udev/rules.d/70-persistent-net.rules to rename the devices persistently. No ugly firmware hacks needed. Auke Carsten Aulbert wrote: > Hi all, > > 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 on-board > NICs while the install kernel sees the on-board only as eth2 and eth3. > > The kernel documentation says one should use the ether (or now better) > the netdev directive for changing the order of the built-in drivers, but > as this guy[1], I have not succeeded so far. For the ether directive not > all parameters were mandatory, if they are now for netdev, how can I > find all the values? When 'entering the firmware' via CTRL+S I can get > the IRQ, the I/O address as well as the memory start address, but I have > no idea about the memory_end address. > > Can someone give me a hint? > > Cheers > > Carsten > > [1] That's the only one I found so far: http://lkml.org/lkml/2005/3/10/213 > -- > Dr. Carsten Aulbert - Max Planck Institute for Gravitational Physics > Callinstrasse 38, 30167 Hannover, Germany > Phone/Fax: +49 511 762-17185 / -17193 > http://www.top500.org/system/9234 | http://www.top500.org/connfam/6/list/31 > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > E1000-devel mailing list > E1000-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/e1000-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] (Help) too many interrupts on Intel Pro Network interface.(e1000e)
also, please note that this might actually be perfectly ok! if you are experiencing high traffic, then having 20k interrupts per second might be just fine for your system. lowering the interruptthrottlerate might actually not change the impact on your system at all. But it will increase network latency when traffic is normal (low). Cheers, Auke Tantilov, Emil S wrote: > Checkout the README included with the driver. You can adjust the int/sec by > using the InterruptThrottleRate parameter. Also enable NAPI - this will > reduce the interrupts in heavy loads. > > Thanks, > Emil > > -Original Message- > From: Taehwan Weon [mailto:[EMAIL PROTECTED] > Sent: Monday, November 10, 2008 10:58 PM > To: e1000-devel@lists.sourceforge.net > Subject: [E1000-devel] (Help) too many interrupts on Intel Pro Network > interface.(e1000e) > > Dear experts, > > This is my first post. > > In these days, I am looking for a solution to avoid 'too many > interrups on my network card' > while network load test. > When I checked with /proc/interrupts, I could see about 20,000 > interrupts/s on my onboard network > controller. > > My test target is configured as following: >OS : linux with kernel of '2.6.27.5' with SMP configured. >CPU: 4 core xeon CPUs >Network : one on-board 82571-chipset based intel Pro 1000 >one PCIX type Intel Pro 1000 > > > Generated TCP traffic followed the scenario as shown below: > (1) connect to my target machine described above > (2) send one request packet(about under 250 byte) > (3) get one reply packet (about under 1K) > (4) close the connection > > > When I generated the traffic at rate of about 7,000 reqs/sec, > I found about 20,000 network interrupts on the target machine. > Even also, I sometimes found ' possible SYN flooding on port 80. > Sending cookies' > from /var/log/messages. > > I think 7000reqs/sec means more than 49,000 real packets which > contains TCP control packets like > SYN, SYN/ACK, etc. > > I want to find a balanced tuned parameters with some reasonble latency. > Any help/hint would be highly appreciated. > > Thanks in advance. > > PS) The only useful message from dmesg output would be > "e1000e :07:00.0: setting latency timer to 64". Currently I didn't > touch anything of e1000e drivers. > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] Bug introduced in e1000 driver - 2.6.26.5 -> 2.6.27-rc8
Jon Wikne wrote: > Hi, > > On a system I have, the e1000 driver stopped working in the transition > from 2.6.26.5 -> 2.6.27-rc8. > > When I compile the e1000 tree from 2.6.26.5 under 2.6.27-rc8, it works! this is not a bug. you have a device for which support was moved from the e1000 driver to the e1000e driver. Please use the e1000e driver from now on. Cheers, Auke > 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit > Ethernet Controller (Copper) (rev 01) > 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit > Ethernet Controller (Copper) (rev 01) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] [PATCH] e1000e: release hw semaphore after successfully writing EEPROM
looks totally valid to me indeed! Reviewed-by: Auke Kok <[EMAIL PROTECTED]> Auke Arthur Jones wrote: > Since e1000e has been existance in linux-2.6, we've > never released the hardware semaphore after a successful > write to the SPI EEPROM. I guess we don't write to > SPI EEPROM much -- but those few of us that do appreciate > it when we can later read from the EEPROM without having > to reboot. > > Found-by: Nick Van Fossen <[EMAIL PROTECTED]> > Signed-off-by: Arthur Jones <[EMAIL PROTECTED]> > --- > drivers/net/e1000e/lib.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/e1000e/lib.c b/drivers/net/e1000e/lib.c > index f1f4e9d..6492107 100644 > --- a/drivers/net/e1000e/lib.c > +++ b/drivers/net/e1000e/lib.c > @@ -2012,6 +2012,7 @@ s32 e1000e_write_nvm_spi(struct e1000_hw *hw, u16 > offset, u16 words, u16 *data) > } > > msleep(10); > + nvm->ops.release_nvm(hw); > return 0; > } > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] questions about Intel e1000 Drivers
Ken Lee wrote: > Hi Auke, > > Could you point me the link where I can download the reference driver? I > searched the mailing list using "bypass" as the keyword but none of the 18 > hits > pointed me to that. I can't find this either. All I know is when I worked for the LAN group that these adapters were shipped with a cd-rom with a prototype driver source to customers so that they could develop their own drivers. I don't have any such cd's myself nor would I have access to that now that I don't work in the LAN group anymore. Unfortunately I can only eyeball my friendly former colleagues and see if they can come up with a download location for this prototype (testing) driver. And even if you get that driver, it's pretty much guaranteed to not work anymore with recent kernel versions. The only document I can reference you to that is readily available is the e1000 SDM's on e1000.sf.net. YMMV. >>> These (development) adapters were never sold for the general market > That is interesting. If you google around, you see many places selling this > product as today. When I ordered it last week, I didn't get the impression > that > the adapters were not meant for the general market. Who sold this adapter to you? Have you asked them for documentation? here's the product brief: http://www.intel.com/network/connectivity/products/prodbrf/313394.pdf Please note the wording for the driver support: "OS Suport: - Linux* and FreeBSD* OS support reference drivers" AFAICR this "reference" driver worked. somewhat. But was far from stable and definately not ready for production environments :) Cheers, Auke > > Ken > > > -Original Message- From: Kok, Auke [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 16, 2008 1:24 PM To: Ken Lee Cc: Allan, Bruce W; > e1000-devel@lists.sourceforge.net Subject: Re: [E1000-devel] questions about > Intel e1000 Drivers > > Allan, Bruce W wrote: >> Hi Ken, >> >> I'm not familiar with the string "PT Quad Port Bypass Server Adapter" but I > > These (development) adapters were never sold for the general market and there > is no support available in the e1000/e1000e linux drivers, nor will that > likely > be ever added. > > A special prototype driver source can be downloaded from the intel.com website > as far as I can remember (in an SDK kit). The mailing list history might have > a > reference to that. > > Cheers, > > Auke - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] questions about Intel e1000 Drivers
Allan, Bruce W wrote: > Hi Ken, > > I'm not familiar with the string "PT Quad Port Bypass Server Adapter" but I These (development) adapters were never sold for the general market and there is no support available in the e1000/e1000e linux drivers, nor will that likely be ever added. A special prototype driver source can be downloaded from the intel.com website as far as I can remember (in an SDK kit). The mailing list history might have a reference to that. Cheers, Auke - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] [PATCH] e100: Add missing dma sync for proper operation with non-coherent caches.
David Daney wrote: > I am running the e100 driver on a MIPS 4KEc system (32 bit mips with > non-coherent DMA). There was a problem where received packets would > get 'stuck' for several seconds at a time and then be released all at > once. > > The cause was that if an interrupt were received when no RX packets > were available, the status for the receive buffer would be stuck in > the cache, so when the next interrupt arrived the old status value was > read (indicating no packets available) instead of the new value. > > The fix is to call pci_dma_sync_single_for_device on the RX if the > packet is not available to invalidate the cache so that at the next > interrupt valid status is returned. > > The driver currently calls pci_dma_sync_single_for_cpu before reading > the status, and this is indeed needed for cases like the R1 CPU > where the cache can be polluted by speculative execution, but for most > machines it is a nop. > > The patch was tested on 2.6.17-rc4 on a MIPS 4KEc. lol, that's a bit old :) A LOT of work has gone into 2.6.26+'s version of e100 that addresses specifically non-coherent DMA machines, including a patch that looks very close to what you write below here. can you test the latest git tree and see if you still need (a modified or updated version) of your patch? I know for sure that the guys maintaining e100 do not have anything close to your system, so they can't test that. Cheers, Auke > > Signed-off-by: David Daney <[EMAIL PROTECTED]> > --- > drivers/net/e100.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/e100.c b/drivers/net/e100.c > index 19d32a2..fb8d551 100644 > --- a/drivers/net/e100.c > +++ b/drivers/net/e100.c > @@ -1840,6 +1840,11 @@ static int e100_rx_indicate(struct nic *nic, struct rx > *rx, > > if (readb(&nic->csr->scb.status) & rus_no_res) > nic->ru_running = RU_SUSPENDED; > + /* We are done looking at the buffer. Prepare it for > + * more DMA. */ > + pci_dma_sync_single_for_device(nic->pdev, rx->dma_addr, > +sizeof(struct rfd), > +PCI_DMA_FROMDEVICE); > return -ENODATA; > } > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] Need help to identify Intel PCI-E Gigabit adapters
Marek Michalkiewicz wrote: > Does anyone here recognize the Intel PCI-E Gigabit Ethernet adapters > sold on this auction: > > http://allegro.pl/item396852185.html > > Larger pictures (linked from the auction): > > http://www.computer-recycling.pl/allegro/1857/1.JPG > http://www.computer-recycling.pl/allegro/1857/2.JPG > http://www.computer-recycling.pl/allegro/1857/3.JPG > http://www.computer-recycling.pl/allegro/1857/4.JPG > > I guess the cards are pre-2006 (old Intel logo on the 1st picture :). > Google "D33745" (label on the 4th picture) doesn't find anything useful. > What chip is under the heatsink, is it supported by the e1000 driver? > > Unfortunately, the seller doesn't know (only says the adapters are > fully functional, but sold with no drivers), and there are no earlier > buyers to ask yet. look like single-port 82571's to me. should work fine with the e1000e(!) driver... Cheers, Auke (!) e1000 driver no longer supports pci-express parts since recently, use the e1000e driver instead. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] [Bugme-new] [Bug 10990] New: e1000/e1000e driver doesn't work with gigabit connection
>> When plugged into a 10/100/1000 porting, forcing: >> ethtool -s eth0 autoneg off speed 1000 duplex full gigabit requires autonegotiation, and if you force speeds you would have to force it on both ends anyway. The above configuration is therefore not a valid configuration. I suggest changing the autonegotiation mask, which leaves autoneg enabled: ethtool -s eth0 advertise 0x20 this is supported and should accomplish what you want. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] [TCP]: TCP_DEFER_ACCEPT causes leak sockets
Ingo Molnar wrote: > * Kok, Auke <[EMAIL PROTECTED]> wrote: > >>> Any ideas about what i should try next? >> have you tried e1000e? > > will try it. > > But even it if solves the problem it's a nasty complication: given how > many times i have to bisect back into the times when there was only > e1000 around, how do i handle the transition? I have automated bisection > tools, etc. and i bisect very frequently. > > It's a real practical problem for me: if i have E1000E=y in my .config > and go back to an older kernel, i lose that .config setting in 'make > oldconfig'. Then when the bisection run happens to go back into the > E1000E times, 'make oldconfig' picks up E1000E with a default-off > setting - and things break or work differently. > > no other Linux driver i'm using forces me to do that and i rely on many > of them and i rely on proper 'make oldconfig' behavior on a daily basis. > Until now i was able to do automatic bisection back for _years_, to the > v2.6.19 times. You broke that. > > And that's just one driver out of thousands of Linux drivers. Imagine > what happened to bisectability and migration quality if every driver > version update was this careless about its installed base as > e1000/e1000e. > > The e1000 -> e1000e migration it was not only done in an incompetent, > amateurish way, you also ignored real feedback and that combined > together is totally lame and inacceptable behavior in my book. You > should not expect praise and roses from me as long as you do stupid > things like that. where were you when we discussed this? We took over a year and a half to get to a final plan and many people responded and provided feedback. In the end Jeff Garzik and many community members suggested a plan and this is what I implemented. In not a single way did I force anything down anyones throat. I did exactly what the community wanted me to do, and in the way that it seemed best by everyone. You only complain and do not provide a single solution to your problem. Your continued screaming and whining is totally not productive nor constructive at all, and frankly is insulting since you completely ignore the fact that we worked with the the community more than two-year to come to some maintainable situation. All you do is complain. Direct your problems to the network stack and driver maintainers since they approved and worked with me to implement the changes. *** NOTE: I NO LONGER MAINTAIN E1000/E1000E, nor do I represent them or speak for them. *** I frankly suggested that you try e1000e because this might provide valuable information for the people who are taking this ingrateful job after me. This was meant in a productive and constructive way. your flame is totally inappropriate and unprofessional. Either come up with a solution or start working on one, like I did when I took the much hated job as e1000 maintainer. I am totally open to suggestions and if needed I will work with the current e1000/e1000e maintainers on working something out if I see a better solution than the current situation. Until I see such a thing I can't do much else than ignore your childish whining. Auke - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] [TCP]: TCP_DEFER_ACCEPT causes leak sockets
Ingo Molnar wrote: > * David Miller <[EMAIL PROTECTED]> wrote: > >> From: Ingo Molnar <[EMAIL PROTECTED]> >> Date: Tue, 17 Jun 2008 11:27:06 +0200 >> >>> when i originally reported it i debugged it back to missing e1000 TX >>> completion IRQs. I tried various versions of the driver to figure >>> out whether new workarounds for e1000 cover it but it was fruitless. >>> There is a 1000 msec internal watchdog timer IRQ within e1000 that >>> gets things going if it's stuck. >> Then that explains your latency, the chip is getting stuck and TX >> interrupts stop, right. > > note that the 1000 msecs timer is AFAIK internal to the e1000 > _hardware_, not the driver itself. I.e. probably the firmware detects > and works around a hung transmitter. This is not detectable from the OS > (it's not an OS timer), but it can be observed by a lot of testing on a > totally quiescent system - which i did back then ;-) > > i also played a lot with the various knobs of the e1000, none of which > seemed to help. > > /me digs in archives > > i reported it to the e1000 folks in 2006: > > Date: Mon, 4 Dec 2006 11:24:00 +0100 > > against 2.6.19. The original report is below - with a trace and various > things i tried to debug this. > > i eventually got the suggestion from Auke to set RxIntDelay=8 which > seemed to work around the issue - but since i use a built-in driver i > dont have that setting here (RxIntDelay=8 is a module load parameter and > not exposed via Kconfig methods) and the e1000 driver does not seem to > have changed its default setting for RxIntDelay. > > 2.6.18-1.2849.fc6 was the last kernel that worked fine. > > Ingo > > > > Date: Wed, 13 Dec 2006 22:09:22 +0100 > From: Ingo Molnar <[EMAIL PROTECTED]> > To: Auke Kok <[EMAIL PROTECTED]> > Subject: Re: e1000: 2.6.19 & long packet latencies > Cc: Jesse Brandeburg <[EMAIL PROTECTED]>, > "Ronciak, John" <[EMAIL PROTECTED]> > > Jesse, et al., > > i'm having a weird packet processing latency problem with the e1000 > driver and recent kernels. > > The symptom is this: if i connect to a T60 laptop (which has an on-board > e1000) from the outside, i see large delays in network activity, and ssh > sessions are very sluggish. > > ping latencies show it best under a dynticks kernel (but vanilla 2.6.19 > is affected too): > > titan:~/linux/linux> ping e > PING europe (10.0.1.15) 56(84) bytes of data. > 64 bytes from europe (10.0.1.15): icmp_seq=1 ttl=64 time=0.340 ms > 64 bytes from europe (10.0.1.15): icmp_seq=2 ttl=64 time=757 ms > 64 bytes from europe (10.0.1.15): icmp_seq=3 ttl=64 time=1001 ms > 64 bytes from europe (10.0.1.15): icmp_seq=4 ttl=64 time=1001 ms > 64 bytes from europe (10.0.1.15): icmp_seq=5 ttl=64 time=0.356 ms > 64 bytes from europe (10.0.1.15): icmp_seq=6 ttl=64 time=2127 ms > 64 bytes from europe (10.0.1.15): icmp_seq=7 ttl=64 time=1002 ms > 64 bytes from europe (10.0.1.15): icmp_seq=8 ttl=64 time=0.320 ms > 64 bytes from europe (10.0.1.15): icmp_seq=9 ttl=64 time=1002 ms > 64 bytes from europe (10.0.1.15): icmp_seq=10 ttl=64 time=2004 ms > 64 bytes from europe (10.0.1.15): icmp_seq=11 ttl=64 time=1002 ms > 64 bytes from europe (10.0.1.15): icmp_seq=12 ttl=64 time=0.303 ms > 64 bytes from europe (10.0.1.15): icmp_seq=13 ttl=64 time=1000 ms > 64 bytes from europe (10.0.1.15): icmp_seq=14 ttl=64 time=2010 ms > 64 bytes from europe (10.0.1.15): icmp_seq=15 ttl=64 time=1009 ms > 64 bytes from europe (10.0.1.15): icmp_seq=16 ttl=64 time=0.283 ms > > i have traced this and the 1000/2000 msecs values come from some sort of > e1000-internal 'heartbeat' interrupt. What seems to happen is that RX > packet processing is delayed indefinitely and the IRQ just does not > arrive. > > NOTE: the vanilla 2.6.19 kernel shows this too, but the ping delays are > 1/HZ. > > here's a (filtered) trace of such a delay. IRQ 0x219 is the e1000 > interrupt: > > -0 0D.h1 761236us : do_IRQ (c0272a9b 219 0) > IRQ_219-356 0 761412us+: e1000_intr (handle_IRQ_event) > IRQ_219-356 0 761416us : e1000_clean_rx_irq (e1000_intr) > IRQ_219-356 0 761418us+: e1000_clean_tx_irq (e1000_intr) > -0 0D.h1 2760093us : do_IRQ (c0272a9b 219 0) > IRQ_219-356 0 2760268us+: e1000_intr (handle_IRQ_event) > IRQ_219-356 0 2760273us : e1000_clean_rx_irq (e1000_intr) > IRQ_219-356 0 2760275us : e1000_clean_tx_irq (e1000_intr) > -0 0D.h1 3804499us : do_IRQ (c0272a9b 219 0) > IRQ_219-356 0 3804674us+: e1000_intr (handle_IRQ_event) > IRQ_219-356 0 3804679us+: e1000_clean_rx_irq (e1000_intr) > IRQ_219-356 0 3804761us : e1000_clean_tx_irq (e1000_intr) > IRQ_219-356 0 3804763us : e1000_clean_rx_irq (e1000_intr) > IRQ_219-356 0 3804765us : e1000_clean_tx_irq (e1000_intr) > softirq--7 0 3804810us : net_rx_action (ksoftirqd) > softirq--5 0D.h. 3805425us : do_IRQ (c01598ac 219 0) > IRQ_219-356 0 3805499us+: e1000_int
Re: [E1000-devel] e100 compiling on Ubuntu 8.04
Valentin Ecker wrote: > hi there! > > Im trying to build the e100 module on my ubuntu 8.04. (i would like to modify > them for my special needs further) > I have the source and the headers in /usr/src you shouldn't build e100 on newer systems from the standalone tarball - please use the e100 module that ubuntu provides instead. the separate e100 driver on e1000.sf.net is purely provided for people with really old kernels that want an update. all the latest changes are only available in all the new distros. Auke - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
Re: [E1000-devel] tx_flow_control_xoff e1000 stat
Don Ash wrote: > Hi, > > I see this counter (and tx_flow_control_xon) increases constantly for IPV4 > forwarding on RHEL 3 (driver used e1000-7.0.38). > Does it mean the nic transmit buffer is full and packets are being dropped? no. it means that flow control is active and sending xon/xoff packets. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel
