On Thu, 6 Aug 2015 09:32:17 +0200
Stefan Assmann sassm...@kpanic.de wrote:
The driver doesn't clear buffer_info-dma after calling
dma_unmap_single() in all cases. This has been discovered by changing
the mtu twice, which caused the following backtrace.
should be for NET?
Looks good, thanks
Wolfgang Walter wrote:
it seems that e1000 enables flow-control (rx pause frames) even if
the switch does not advertise flow control. This seems to get a
problem as (at least some) switches then forward pause frames
directed to the card from other hosts. We think there are hosts which
indeed
Badalian Vyacheslav wrote:
Hello all.
Interesting think:
Have PC that do NAT. Bandwidth about 600 mbs.
Have 4 CPU (2xCoRe 2 DUO HT OFF 3.2 HZ).
irqbalance in kernel is off.
nat2 ~ # cat /proc/irq/217/smp_affinity
0001
this binds all 217 irq interrupts to cpu 0
nat2 ~ # cat
Andrew Morton wrote:
On Thu, 24 Jan 2008 03:03:11 -0800 (PST)
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9808
Summary: system hung with htb QoS
Product: Networking
Version: 2.5
KernelVersion: 2.6.23.9
Platform: All
Carsten Aulbert wrote:
PS: Am I right that the TCP_RR tests should only be run on a single
node at a time, not on both ends simultaneously?
yes, they are a request/response test, and so perform the bidirectional
test with a single node starting the test.
--
To unsubscribe from this list: send
Bill Fink wrote:
a 2.6.15.4 kernel. The GigE NICs are Intel PRO/1000
82546EB_QUAD_COPPER,
on a 64-bit/133-MHz PCI-X bus, using version 6.1.16-k2 of the e1000
driver, and running with 9000-byte jumbo frames. The TCP congestion
control is BIC.
Bill, FYI, there was a known issue with e1000
Bruce Allen wrote:
Details:
Kernel version: 2.6.23.12
ethernet NIC: Intel 82573L
ethernet driver: e1000 version 7.3.20-k2
motherboard: Supermicro PDSML-LN2+ (one quad core Intel Xeon X3220,
Intel 3000 chipset, 8GB memory)
Hi Bruce,
The 82573L (a client NIC, regardless of the class of
Frans Pop wrote:
There is one thing I don't understand, but that may well be just me...
From Linus' original patch:
+++ b/drivers/net/e1000/e1000_main.c
+ INTEL_E1000_ETHERNET_DEVICE(0x108C),
So, apparently support for 8086:108c was removed from the e1000
driver.
When it was
Bruce Allen wrote:
Hi Jesse,
It's good to be talking directly to one of the e1000 developers and
maintainers. Although at this point I am starting to think that the
issue may be TCP stack related and nothing to do with the NIC. Am I
correct that these are quite distinct parts of the
Tony Battersby wrote:
I am experiencing network tx hangs on a dual-port SK-9E22 with sky2 in
2.6.24. The problem is triggered by both ports transmitting at high
speed simultaneously. This problem is 100% quickly reproducible.
Here is the setup:
PC #1 with Intel PRO/1000 NIC:
e1000 IP
Andrew Morton wrote:
On Mon, 28 Jan 2008 05:32:00 -0800 (PST)
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9836
Problem Description: recently e1000 network drivers stopped working
when right after switching on or rebooting our Intel server. While
trying to 'modprobe
Andrew Morton wrote:
I'm also receiving this quite often:
Jan 15 12:23:17 ftp kernel: e1000: eth0: e1000_clean_tx_irq:
Detected Tx Unit Hang Jan 15 12:23:17 ftp kernel: Tx Queue
0
Jan 15 12:23:17 ftp kernel: TDH 2a
Jan 15 12:23:17 ftp kernel: TDT
David Miller wrote:
From: Robert Olsson [EMAIL PROTECTED]
Date: Fri, 18 Jan 2008 14:00:57 +0100
I don't understand the idea with semaphore for enabling/disabling
irq's either the overall logic must safer/better without it.
They must have had code paths where they didn't know if IRQs
David Miller wrote:
From: Brandeburg, Jesse [EMAIL PROTECTED]
Date: Tue, 15 Jan 2008 13:53:43 -0800
The tx code has an early exit that tries to limit the amount of tx
packets handled in a single poll loop and requires napi or interrupt
rescheduling based on the return value from
[EMAIL PROTECTED] wrote:
Quoting Frans Pop [EMAIL PROTECTED]:
(Note this isn't the final correct patch we should apply. There is
no reason why this revert back to the older -poll() logic here
should have any effect on the TX hang triggering...)
s/no reason/no obvious reason/ ? ;-)
The
Breno Leitao wrote:
When I run netperf in just one interface, I get 940.95 * 10^6 bits/sec
of transfer rate. If I run 4 netperf against 4 different interfaces, I
get around 720 * 10^6 bits/sec.
This is actually a known issue that we have worked with your company
before on. It comes down to
Kevin Wilson wrote:
Nonetheless, a somewhat recent change in your tree, that I could not
pinpoint on my own, caused the driver to stop functioning properly.
So after much searching in git/google/sources with no luck, I decided
to ask for a little assistance, maybe just a hint as to where the
Andrew Morton wrote:
On Thu, 13 Dec 2007 16:11:55 -0800
Ayaz Abdulla [EMAIL PROTECTED] wrote:
I would not include this patch until further testing is performed.
NVIDIA MCP chips use 3rd party PHY vendors. By powering down the
phy, it could have adverse affects on certain phys.
Ayaz
Joonwoo Park wrote:
/* If no Tx and not enough Rx work done, exit the polling mode */
if ((!tx_cleaned (work_done == 0)) ||
!netif_running(poll_dev)) {
quit_polling:
if (likely(adapter-itr_setting 3))
e1000_set_itr(adapter);
Joonwoo Park wrote:
2007/12/12, Brandeburg, Jesse [EMAIL PROTECTED]:
all drivers using NAPI in 2.6.24+ (NNAPI??) must return zero here,
after calling netif_rx_complete. netif_rx_complete plus work_done
!= 0 causes a bug.
Brandeburg,
Don't we need to return non-zero work_done after
Benjamin Herrenschmidt wrote:
The e1000 driver stores the content of the PCI resources into
unsigned long's before ioremapping. This breaks on 32 bits
platforms that support 64 bits MMIO resources such as ppc 44x.
This fixes it by removing those temporary variables and passing
directly the
forwarding whole message for netdev to review
Ian Wienand wrote:
Hi,
When rebooting today I got
Will now restart.
ACPI: PCI interrupt for device :00:03.0 disabled
GSI 20 (level, low) - CPU 1 (0x0100) vector 53 unregistered
Destroying IRQ53 without calling free_irq
WARNING: at
Andi Kleen wrote:
When the hw TX queue gains space, the driver self-batches packets
from the sw queue to the hw queue.
I don't really see the advantage over the qdisc in that scheme.
It's certainly not simpler and probably more code and would likely
also not require less locks (e.g. a
Emil Micek wrote:
What is the right behaviour according to specification? In iee802.3,
minFrameSize is 64bytes. I've never seen any document which'd say that
VLAN frames should be 68 bytes minimum.
e1000 only hardware pads to 64 bytes, but if you use the vlan module and
turn off the hardware
L F wrote:
On 9/17/07, Kok, Auke [EMAIL PROTECTED] wrote:
The statistic we were looking at _will_ increase when running in
half duplex, but if it increases when running in full duplex might
indicate a hardware failure. Probably you have fixed the issue with
the CAT6 cable.
Uhm, 'fixed' may
Kok, Auke wrote:
Marc Sigler wrote:
Hello everyone,
I have several systems with three integrated Intel 82559 (I *think*).
Does someone know if these boards support hardware interrupt
mitigation? I.e. is it possible to configure them to raise an IRQ
only if their hardware buffer is full
John Sigler wrote:
Jesse Brandeburg wrote:
Auke Kok wrote:
Marc Sigler wrote:
I have several systems with three integrated Intel 82559 (I
*think*).
Does someone know if these boards support hardware interrupt
mitigation? I.e. is it possible to configure them to raise an IRQ
only
Willy Tarreau wrote:
--- e100-3.5.17/src/e100.c.orig 2007-08-13 08:53:18 +0200
+++ e100-3.5.17/src/e100.c2007-08-13 09:24:56 +0200
@@ -2934,13 +2934,13 @@
printk(KERN_INFO PFX %s\n, DRV_COPYRIGHT);
}
#ifdef E100_USE_REBOOT_NOTIFIER
- retval =
Alan J. Wylie wrote:
We have been shipping Linux based servers to customers for several
years now, with few problems. Recently, however, a single customer has
been seeing kernel panics. Unfortunately, the customer is about 200
miles away, so physical access is limited. There are two ethernet
Rick Jones wrote:
Hi Rick, allow me to respond on my way out on a Friday... :-)
hpcpc109:~/netperf2_trunk# src/netperf -t TCP_RR -H 192.168.2.105 -D
1.0 -l 15 TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0
AF_INET to 192.168.2.105 (192.168.2.105) port 0 AF_INET : demo :
first burst 0
Adrian Bunk wrote:
Subject: laptops with e1000: lockups
References :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
Submitter : Dave Jones [EMAIL PROTECTED]
Handled-By : Jesse Brandeburg [EMAIL PROTECTED]
Status : problem is being debugged
this is being actively
On Sat, 14 Apr 2007, Adrian Bunk wrote:
Subject: laptops with e1000: lockups
References :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
Submitter : Dave Jones [EMAIL PROTECTED]
Handled-By : Jesse Brandeburg [EMAIL PROTECTED]
Status : problem is being debugged
Roberto Nibali wrote:
Sounds sane to me. My overall opinion on eepro100 removal is that
we're not there yet. Rare problem cases remain where e100 fails
but eepro100 works, and it's older drivers so its low priority for
everybody.
Needs to happen, though...
It seems that several Tyan
added Linux-pci
Jesse Brandeburg wrote:
On 1/16/07, Allen Parker [EMAIL PROTECTED] wrote:
Allen Parker wrote:
I have a PCI-E pro/1000 MT Quad Port adapter, which works quite well
under 2.6.19.2 but fails to see link under 2.6.20-rc5. Earlier
today I reported this to [EMAIL PROTECTED], but
Jeff Garzik wrote:
-IXGB_WRITE_REG_ARRAY(hw, RA, (i 1), 0);
+/* Write high reg first to disable the AV bit first */
IXGB_WRITE_REG_ARRAY(hw, RA, ((i 1) + 1), 0);
+IXGB_WRITE_REG_ARRAY(hw, RA, (i 1), 0);
Are you sure the order is guaranteed
Kenzo Iwami wrote:
ethtool processing holding semaphore
INTERRUPT
e1000_watchdog waits for semaphore to be released
The semaphore e1000_watchdog is waiting for can only be released when
ethtool resumes from interrupt after e1000_watchdog finishes
(basically a deadlock)
In
Kok, Auke wrote:
Add a new dynamic itr algorithm, with 2 modes, and make it the default
operation mode. This greatly reduces latency and increases small
packet performance, at the cost of some CPU utilization. Bulk
traffic throughput is unaffected.
Thanks to the generous testing of Rick Jones
Jeff Garzik wrote:
Kok, Auke wrote:
Deprecate mii-tool SIOCMIIREG ioctl. This ioctl is broken in e1000
and ethtool has this functionality in working order.
Signed-off-by: Jeff Kirsher [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
This doesn't deprecated anything, it changes
Stephan von Krawczynski wrote:
thank you for answering anyway. Though I think your answer covers
only the obvious half of the problem.
Indeed one might think that this solves the issue - as long as there
are only linux kernels involved. Unfortunately my setup is a bit more
complicated in
I'm enabling e1000 to offload IPv6 since the 2.6.18+ kernels support it.
The kernel I'm testing is 2.6.18-rc4.
Everything with the hardware offload is working fine, but it appears
that the GSO code may not correctly segment frames sometimes for IPv6
traffic.
I did a tcpdump on both ends with
Stephen Hemminger wrote:
On Fri, 25 Aug 2006 11:13:48 -0700
Brandeburg, Jesse [EMAIL PROTECTED] wrote:
I'm enabling e1000 to offload IPv6 since the 2.6.18+ kernels support
it. The kernel I'm testing is 2.6.18-rc4.
Yes, something is wrong with the GSO code. I am bisecting this bug
Stephen Hemminger wrote:
I think this the problem. Does it fix e1000? I am testing now.
TCP over IPV6 would incorrectly inherit the GSO settings on accepted
children.
--- linux-2.6.orig/net/ipv6/tcp_ipv6.c2006-08-03
09:09:16.0
-0700 +++ linux-2.6/net/ipv6/tcp_ipv6.c
Kok, Auke-jan H wrote:
Auke Kok wrote:
Jay Vosburgh wrote:
Running both 2.6.17.6 plus the e1000 7.2.7 from sourceforge, or
the e1000 in netdev-2.6#upstream (7.1.9-k4).
Starting up ethtool -p ethX then unplugging the cable
connected to the identified port is causing my system to
On Sat, 12 Aug 2006, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
Since the e1000 change is non-trivial I'm not going to bypass
the driver author on it, sorry.
What I did do was put the netdev_alloc_skb() change into my
tree, and since I'm co-author
On Mon, 7 Aug 2006, jamal wrote:
-#define E1000_TX_WEIGHT 64
- /* weight of a sort for tx, to avoid endless transmit
cleanup */
- if (count++ == E1000_TX_WEIGHT) break;
+ /* avoid endless transmit cleanup */
+ if (count++ ==
On Tue, 8 Aug 2006, Herbert Xu wrote:
-#define E1000_TX_WEIGHT 64
- /* weight of a sort for tx, to avoid endless transmit
cleanup */
- if (count++ == E1000_TX_WEIGHT) break;
+ /* avoid endless transmit cleanup */
+ if (count++ ==
-Original Message-
From: jamal [mailto:[EMAIL PROTECTED]
On Mon, 2006-07-08 at 13:53 -0700, Brandeburg, Jesse wrote:
we don't enable it right now, but you could use the TXQE (tx queue
empty)
interrupt to avoid the starvation case. I think it might flood you
with
TXQE
On Fri, 4 Aug 2006, Herbert Xu wrote:
jamal [EMAIL PROTECTED] wrote:
There is no need for tx_locking if you are already netif stopped
(transmit path will never be entered).
With this change under high speed forwarding i see anywhere
between 2-4Kpps improvement on a 2 CPU environment
On Fri, 28 Jul 2006, Greg KH wrote:
On Fri, Jul 28, 2006 at 03:06:17PM -0700, Auke Kok wrote:
The Intel(R) PRO/1000 82572EI card is fully supported by 7.0.33-k2 and
onward. Add the device ID so this card works with 2.6.17.y onward. This
device ID was accidentally omitted.
Sorry, but we
On Fri, 23 Jun 2006, Linas Vepstas wrote:
I've got another ixgb driver bug I'm struggling with; clues or hints
appreciated.
I've got a patch for PCI error recovery for the ixgb, which works on
many older kernels but seems to be broken on linux-2.6.17-rc6-mm2
(which is ixgb version 1.0.109).
On Mon, 5 Jun 2006, Rick Jones wrote:
Kok, Auke wrote:
It was brought to our attention that the prefetches break e1000 traffic
on xscale/arm architectures. Remove them for now. We'll let them
stay in mm for a while, or find a better solution to enable.
Out of curiousity, what
On Mon, 5 Jun 2006, Rick Jones wrote:
Brandeburg, Jesse wrote:
Hi Rick, according to our reporter, receives break. The prefetch (not
always, but sometimes) lets the processor get junk from the prefetched
area. Apparently this version of arm doesn't quite do as strict
enforcement of bus
Hi all, I've identified you as people who have at some point in the past
emailed one of the Linux lists with problems with e1000 and
sk_forward_alloc. It seems to be fairly widespread, but only seems to
have appeared with recent kernel changes (after 2.6.12...)
What I need from you is a
53 matches
Mail list logo
