This series introduces a compile error
drivers/net/ethernet/cisco/enic/enic_main.c: In function 'enic_probe':
drivers/net/ethernet/cisco/enic/enic_main.c:2490:3: error: label
'err_out_vnic_unregister' used but not defined
goto err_out_vnic_unregister;
^
scripts/Makefile.build:258: recipe for
On Thu, 6 Aug 2015 09:32:17 +0200
Stefan Assmann 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 Stefan!
Acked-b
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
> ind
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
>
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
>>
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 e10
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
Carsten Aulbert wrote:
> We are using MSI, /proc/interrupts look like:
> n0003:~# cat /proc/interrupts
> 378: 17234866 0 0 0 PCI-MSI-edge
> eth1
> 379: 129826 0 0 0 PCI-MSI-edge
> eth0
> (sorry for the line break).
>
> What we
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
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 w
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 m
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
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
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: TD
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 i
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 inte
[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 reas
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
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.
>
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 th
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.
>>
>
> B
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);
> netif_rx_co
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
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
> /home/insecure/ianw/programs/git-kernel
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.
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, '
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 configu
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 bu
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 = pci_r
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 etherne
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 burs
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 activ
> 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 be
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 seem
John wrote:
> Jesse Brandeburg wrote:
>> What would you like to do? At this stage I would like e100 to work
>> better than it is, but I'm not sure what to do next.
>
> Hello everyone,
>
> I'm resurrecting this thread because it appears we'll need to support
> these motherboards for several month
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 PROTE
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 orde
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)
>
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
Stephan von Krawczynski wrote:
> I can confirm that the setup seems to work if enlarging the hw if mtu
> to 1508. This is good.
Okay, good to hear.
> Nevertheless I think that the receive buffer size of a
> physical device should always be MAX(all virtual device mtu +
> tags and the like), you kn
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" an
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
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
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, some
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 all
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 causi
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, a
> -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.
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 (
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++ == tx_rin
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 en
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.
>
> Sor
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.
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
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, wh
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 reproduci
I apologize for my misconfigured email client, this is my correct
address
PS machine rebuilds suck.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jesse Brandeburg
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mess
>NETDEV WATCHDOG: eth2: transmit timed out
>Debug: sleeping function called from invalid context at mm/slab.c:2088
>in_atomic():1, irqs_disabled():0
>[] __might_sleep+0x92/0xa0
>[] __kmalloc+0x81/0x90
>[] proc_create+0x86/0x100
>[] proc_mkdir_mode+0x1d/0x60
>[] register_handler_proc+0x6c/0x80
>[] s
59 matches
Mail list logo
