On Thu, Nov 22, 2018 at 09:27:24PM +0100, Pavel Machek wrote:
> Hi!
Hello!
> > > > > If I wanted it to work, what do I need to do? AFAICT phy autoprobing
> > > > > should just attach it as soon as it is compiled in?
> > > >
> > > > Nope. It is a switch, not a PHY. Switches are never
On Thu, Nov 22, 2018 at 02:21:23PM +0100, Pavel Machek wrote:
> > > If I wanted it to work, what do I need to do? AFAICT phy autoprobing
> > > should just attach it as soon as it is compiled in?
> >
> > Nope. It is a switch, not a PHY. Switches are never auto-probed
> > because they are not
On Sat, Nov 10, 2018 at 08:34:34PM +0100, Jean-Philippe Menil wrote:
> we're seeing unexpected crashes from kernel 4.15 to 4.18.17, using
> IPsec VTI interfaces, on several vpn hosts, since upgrade from 4.4.
I looked into this with Jean-Philippe, and it appears to be crashing
on a NULL pointer
nk layer allocation") and
appears to have been fixed by this patch, as applying this patch to
4.16.12 makes DHCP work for me again.
Tested-by: Lennert Buytenhek
> ---
> net/packet/af_packet.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/pac
lwtunnel encap attributes")
> > Signed-off-by: David Ahern <dsah...@gmail.com>
>
> Reported-by: João Taveira Araújo <joao.tave...@gmail.com>
>
> Reported-by: Lennert Buytenhek <buyt...@wantstofly.org>
>
> Acked-by: Roopa Prabhu <ro...@cumulusnetworks.com>
Tested-by: Lennert Buytenhek <buyt...@wantstofly.org>
Seems to work! Thanks!
Hi!
FWIW, this doesn't work:
# ip -6 route add 1234::/16 \
nexthop encap mpls 10 via fe80::1 dev ens3 \
nexthop encap mpls 20 via fe80::1 dev ens3
RTNETLINK answers: File exists
While this does:
# ip -6 route chg 1234::/16
On Sat, Feb 04, 2017 at 03:24:56PM -0800, Eric Dumazet wrote:
> Use napi_complete_done() instead of __napi_complete() to :
>
> 1) Get support of gro_flush_timeout if opt-in
> 2) Not rearm interrupts for busy-polling users.
> 3) use standard NAPI API.
> 4) get rid of baroque code and ease
On Wed, Jul 27, 2016 at 03:02:24PM +0800, zhuyj wrote:
> On ubuntu16.04 server 64 bit
> The attached script is run, the following will appear.
>
> Error: either "to" is duplicate, or "encap" is a garbage.
Looks like your installed iproute2 package doesn't grok MPLS.
Hi!
I am seeing pretty horrible TCP transmit performance (anywhere between
1 and 10 Mb/s, on a 10 Gb/s interface) when traffic is sent out over a
route that involves MPLS labeling, and this seems to be due to an
interaction between MPLS and TSO/GSO that causes all segmentable TCP
frames that are
tly.com>
Signed-off-by: Lennert Buytenhek <lbuyten...@fastly.com>
Acked-by: David Ahern <d...@cumulusnetworks.com>
Acked-by: Robert Shearman <rshea...@brocade.com>
---
net/core/neighbour.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/core/neighbou
a
> > softirq here, we can end up with an unexpected RCU grace period and
> > all the nastiness that that comes with.
> >
> > This patch makes neigh_xmit() take rcu_read_{,un}lock_bh() around the
> > code that expects to be treated as an RCU-bh read side critical se
On Mon, Jun 20, 2016 at 10:38:39AM -0600, David Ahern wrote:
> > OK, patch coming up. Thanks!
>
> can you build a kernel with rcu debugging enabled as well and run
> it through your tests?
git HEAD with CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
ects to be treated as an RCU-bh read side critical section.
Signed-off-by: David Barroso <dbarr...@fastly.com>
Signed-off-by: Lennert Buytenhek <lbuyten...@fastly.com>
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index f18ae91..769cece 100644
--- a/net/core/neighbou
On Mon, Jun 20, 2016 at 09:13:36AM -0700, Roopa Prabhu wrote:
> diff --git a/net/mpls/mpls_iptunnel.c b/net/mpls/mpls_iptunnel.c
> index fb31aa8..802956b 100644
> --- a/net/mpls/mpls_iptunnel.c
> +++ b/net/mpls/mpls_iptunnel.c
> @@ -105,12 +105,15 @@ static int
On Sun, Jun 19, 2016 at 08:19:20PM -0600, David Ahern wrote:
> > diff --git a/net/mpls/mpls_iptunnel.c b/net/mpls/mpls_iptunnel.c
> > index fb31aa8..802956b 100644
> > --- a/net/mpls/mpls_iptunnel.c
> > +++ b/net/mpls/mpls_iptunnel.c
> > @@ -105,12 +105,15 @@ static int mpls_output(struct net
Hi!
While trying to chase down a memory corruption issue that only occurs
when originating large amounts of MPLS tagged IP traffic, I came across
something in the MPLS output code for which I'm not entirely sure that
it's correct.
Specifically, there is the code path dst_output() ->
On Mon, May 30, 2016 at 04:17:52PM +0800, Herbert Xu wrote:
> > Commit 412ca1550cbecb2c ("macvlan: Move broadcasts into a work queue")
> > moved processing of all macvlan multicasts into a work queue. This
> > causes a noticable performance regression when there is heavy multicast
> > traffic on
On Fri, May 27, 2016 at 10:56:44AM -0700, Cong Wang wrote:
> > Commit 412ca1550cbecb2c ("macvlan: Move broadcasts into a work queue")
> > moved processing of all macvlan multicasts into a work queue. This
> > causes a noticable performance regression when there is heavy multicast
> > traffic on
Reported-by: Grant Zhang <gzh...@fastly.com>
Signed-off-by: Lennert Buytenhek <lbuyten...@fastly.com>
---
drivers/net/macvlan.c | 71 ---
1 file changed, 45 insertions(+), 26 deletions(-)
diff --git a/drivers/net/macvlan.c b/drive
On Sun, Feb 24, 2008 at 09:21:53AM +0100, Herbert Valerio Riedel wrote:
Currently, the ep93xx_eth driver doesn't care about the PHY state,
but it should, in order to tell the MAC when full duplex operation is
required; failure to do so causes degraded performance on full duplex
links.
, which is why I assume it got
dropped.
I have been carrying the patch in my own tree since then, and only
noticed recently that the patch never made it upstream.
cheers,
Lennert
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Cc: Petko Manolov [EMAIL PROTECTED]
--- linux-2.6.24-git7.orig
The RTL8150 driver uses an MTU of 1540 by default, which causes a
bunch of problems -- it prevents booting from NFS root, for one.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Cc: Petko Manolov [EMAIL PROTECTED]
--- linux-2.6.24-git7.orig/drivers/net/usb/rtl8150.c2008-01-24
23:58
On Wed, Dec 12, 2007 at 04:48:28PM +0800, Wang Chen wrote:
[PATCH 3/4] [NETDEV] ixp2000: rtnl_lock out of loop will be faster
Before this patch, it gets and releases the lock at each
iteration of the loop. Changing unregister_netdev to
unregister_netdevice and locking outside of the loop
On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
This commit made an incorrect assumption:
--
Author: Lennert Buytenhek [EMAIL PROTECTED]
Date: Fri Oct 19 04:10:10 2007 +0200
mv643xx_eth: Move ethernet register definitions into private header
Move
On Fri, Oct 26, 2007 at 05:40:22AM -0400, Jeff Garzik wrote:
arch/arm/mach-pxa/ssp.c|2 +-
arch/arm/mach-s3c2410/usb-simtec.c |2 +-
arch/arm/plat-omap/mailbox.c |2 +-
FWIW
Acked-by: Lennert Buytenhek [EMAIL PROTECTED]
-
To unsubscribe
On Thu, Oct 25, 2007 at 05:12:04AM -0400, Jeff Garzik wrote:
+struct rx_desc {
+u32 cmd_sts;
+u16 size;
+u16 count;
+u32 buf;
+u32 next;
+};
+
+struct tx_desc {
+u32 cmd_sts;
+u16 l4i_chk;
+u16 count;
+u32 buf;
+u32 next;
+};
should use
On Fri, Oct 19, 2007 at 05:56:54AM -0700, Dale Farnsworth wrote:
Isn't it a little too confusing to have two headers with the same name,
one in drivers/net and one in include/linux?
Perhaps we can fold the drivers/net one into drivers/net/mv643xx_eth.c?
Since nothing else includes
On Fri, Oct 19, 2007 at 09:30:48AM +0100, Christoph Hellwig wrote:
Move the mv643xx's ethernet-related register definitions from
include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since
they aren't of any use outside the ethernet driver.
Signed-off-by: Lennert Buytenhek [EMAIL
Since drivers/net/mv643xx_eth.c is the only user of
drivers/net/mv643xx_eth.h, there's not much use in having the header
file as a separate file, so merge the header into the driver.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/mv643xx_eth.c
On Thu, Oct 18, 2007 at 08:46:58PM -0700, Roland Dreier wrote:
+static void __iomem *mv643xx_eth_base;
+ return readl(((void __iomem *)mv643xx_eth_base) + offset);
Given the declaration of mv643xx_eth_base as void __iomem * already, I
don't understand why you need the cast to the
Most of the register defines in drivers/net/mv643xx_eth.h aren't
used at all. Nuke them -- we can always re-add them if/when we
need them, and meanwhile, they unnecessarily clutter up the
header file.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Acked-by: Tzachi Perelstein [EMAIL PROTECTED
constructs with (7 22).
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Acked-by: Tzachi Perelstein [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/mv643xx_eth.h
===
--- linux-2.6.orig/drivers/net/mv643xx_eth.h
+++ linux-2.6/drivers/net
On little-endian systems, configure the SDMA unit with
MV643XX_ETH_BLM_RX_NO_SWAP and MV643XX_ETH_BLM_TX_NO_SWAP.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Acked-by: Tzachi Perelstein [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/mv643xx_eth.h
Move the mv643xx's ethernet-related register definitions from
include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since
they aren't of any use outside the ethernet driver.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Acked-by: Tzachi Perelstein [EMAIL PROTECTED]
Index: linux-2.6
This patch series adds support for the Orion's ethernet MAC
(which is the same MAC as in the Discovery 643xx) to the mv643xx_eth
driver, and performs various random cleanups all over the driver.
Patches 1-3 are cleanups necessary to be able to support Orion.
Patch 4 enables mv643xx_eth for
On Thu, Oct 18, 2007 at 03:15:36AM +0200, Lennert Buytenhek wrote:
+#define PORT_CONF0x400
+#define PORT_CONF_EXT0x404
+#define PORT_MAC_LO 0x414
+#define PORT_MAC_HI 0x418
+#define PORT_SDMA0x41c
+#define
Now that all register address and bit defines are in private
namespace (drivers/net/mv643xx_eth.h), we can safely remove the
MV643XX_ETH_ prefix to conserve horizontal space.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Acked-by: Tzachi Perelstein [EMAIL PROTECTED]
Index: linux-2.6/drivers
, and includes the latter from the former.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Acked-by: Tzachi Perelstein [EMAIL PROTECTED]
Index: linux-2.6/include/linux/mv643xx.h
===
--- linux-2.6.orig/include/linux/mv643xx.h
+++ linux
Allow Orion ARM platforms to use the mv643xx_eth driver.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Acked-by: Tzachi Perelstein [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/Kconfig
===
--- linux-2.6.orig/drivers/net
Start counting mv643xx_eth register addresses from zero, instead of
from 0x2000 (MV643XX_ETH_SHARED_REGS.)
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Acked-by: Tzachi Perelstein [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/mv643xx_eth.c
On Tue, Oct 16, 2007 at 11:31:15PM +0200, Maxime Bizon wrote:
Hello,
Hi,
+#define PORT_CONF 0x400
+#define PORT_CONF_EXT 0x404
+#define PORT_MAC_LO0x414
+#define PORT_MAC_HI0x418
+#define PORT_SDMA 0x41c
+#define
,
jumbo frames, etc.
This patch is against 2.6.22.1, and the driver has not yet been
adapted to the recent NAPI changes. Nevertheless, we wanted to
get this out there for feedback/review.
Comments appreciated!
Signed-off-by: Tzachi Perelstein [EMAIL PROTECTED]
Signed-off-by: Lennert Buytenhek
On Fri, Aug 24, 2007 at 01:08:25AM +0100, TJ wrote:
An RFC 793 standard TCP handshake requires three packets:
client SYN server LISTENING
client SYN ACK server SYN_RECEIVED
client ACK server ESTABLISHED
client PSH ACK + data server
TCP_DEFER_ACCEPT is designed to increase
On Tue, Aug 14, 2007 at 02:11:05PM +0100, Stephen Hemminger wrote:
Bridge locking for /sys/class/net/br0/bridge/stp_enabled
was wrong. Another bug in bridge utilities makes it such that
this interface, meant it wasn't being used. The locking needs
to be removed from set_stp_state(), the
On Wed, Aug 08, 2007 at 07:07:33PM -0400, Chris Snook wrote:
From: Chris Snook [EMAIL PROTECTED]
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing compiler
On Fri, Jul 13, 2007 at 02:12:08AM +0200, Adrian Bunk wrote:
From: John Donoghue [EMAIL PROTECTED]
CONFIG_EP93XX_ETH=y, CONFIG_MII=n results in an obvious link error.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Lennert Buytenhek [EMAIL PROTECTED]
-
To unsubscribe from this list
On Sun, Jul 01, 2007 at 12:23:16PM +0200, Michael Buesch wrote:
More or less. You can't add the resistances like that, since the
bus isolation chip buffers the IDSEL signal, but it is correct that
if the host's IDSEL resistor is larger than a certain value, the
combination of the
On Sat, Jun 30, 2007 at 04:19:23PM +0100, Matthew Garrett wrote:
I'd agree that there's a need for a state where we power down as much as
possible (even at the cost of functionality), but where possible it
would also be nice to offer a state where the mac is powered down and
the phy left
On Sat, Jun 30, 2007 at 11:53:25PM +0200, Michael Buesch wrote:
When the interface is down (or driver removed), the BroadCom 44xx card
remains
powered on, and both its MAC and PHY is using up power.
This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
is halted,
On Sun, Jul 01, 2007 at 12:24:40AM +0200, Michael Buesch wrote:
Hm, I was going to measure the real power advantage with a
PCI-extender card. But my B44B0 card doesn't seem to work in
that extender card. It works perfectly fine sticked directly into
the motherboard, though, and other
On Wed, May 16, 2007 at 08:13:01AM +0100, Christoph Hellwig wrote:
+#ifndef __ARMEB__
+#warning Little endian mode not supported
+#endif
Personally I'm less fussed about WAN / LE support. Anyone with any
sense will run ixp4xx boards doing such a specialised network
operation as
On Wed, May 16, 2007 at 08:16:38PM +0930, Rod Whitby wrote:
So, if the author of these patches wishes to concentrate on big-endian
support first, then we will not say (and have not said) anything which
will block inclusion of a big-endian only version of this driver.
The NSLU2 people are the
On Wed, May 16, 2007 at 09:05:18PM +0930, Rod Whitby wrote:
So, if the author of these patches wishes to concentrate on big-endian
support first, then we will not say (and have not said) anything which
will block inclusion of a big-endian only version of this driver.
The NSLU2 people
On Wed, May 09, 2007 at 03:45:53PM +0100, Michael-Luke Jones wrote:
No-one is saying that this driver should not be mainlined before it
has LE support. All that I said was:
Personally I'd like LE ethernet tested and working before we push.
The alternative would be to explicitly state
On Wed, May 09, 2007 at 10:58:06AM +0200, Marcus Better wrote:
There _is_ an ARM BE version of Debian.
It's not an official port, but it's not maintained any worse than
the 'official' LE ARM Debian port is.
Hmm... That changes a bit. Perhaps we should forget about
that LE thing
On Tue, May 08, 2007 at 06:59:36PM +0200, Krzysztof Halasa wrote:
There may be up to 6 Ethernet ports (not sure about hardware
status, not yet supported even by Intel) - 7 queues * 128 entries
each = ~ 3.5 KB. Add 2 long queues (RX) for HSS and something
for TX, and then crypto, and maybe
On Wed, May 09, 2007 at 11:35:03AM +0200, Marcus Better wrote:
Does that mean that the Debian ARM people have their heads so far
up their collective asses that they think that every form of change
is bad and are unable to accept that some forms of change might be
for the better?
Well,
On Wed, May 09, 2007 at 12:35:40PM +0200, Mikael Pettersson wrote:
Does that mean that the Debian ARM people have their heads so far
up their collective asses that they think that every form of change
is bad and are unable to accept that some forms of change might be
for the better?
I'm not sure what the latest versions are, so I'm not sure which
patches to review and which patches are obsolete.
On Tue, May 08, 2007 at 02:46:28AM +0200, Krzysztof Halasa wrote:
+struct qmgr_regs __iomem *qmgr_regs;
+static struct resource *mem_res;
+static spinlock_t qmgr_lock;
+static
On Mon, May 07, 2007 at 02:07:16AM +0200, Krzysztof Halasa wrote:
+ * Ethernet port config (0x00 is not present on IXP42X):
+ *
+ * logical port 0x000x100x20
+ * NPE 0 (NPE-A) 1 (NPE-B) 2 (NPE-C)
+ * physical PortId 2
On Mon, May 07, 2007 at 09:18:00PM +0100, Michael-Luke Jones wrote:
Well, I'm told that (compatible) NPEs are present on other IXP CPUs.
Not sure about details.
If, by a combined effort, we ever manage to create a generic NPE
driver for the NPEs found in IXP42x/43x/46x/2000/23xx then the
On Mon, May 07, 2007 at 10:00:20PM +0200, Krzysztof Halasa wrote:
- the NPE can also be used as DMA engine and for crypto operations.
Both are not network related.
Additionally, the NPE is not only ixp4xx related, but is
also used in IXP23xx CPUs, so it could be placed in
On Tue, May 08, 2007 at 04:12:17PM +0200, Krzysztof Halasa wrote:
The queue manager interrupts should probably be implemented as an
irqchip, in the same way that GPIO interrupts are implemented. (I.e.
allocate 'real' interrupt numbers for them, and use the interrupt
cascade mechanism.)
On Tue, May 08, 2007 at 04:31:12PM +0200, Krzysztof Halasa wrote:
+/* Built-in 10/100 Ethernet MAC interfaces */
+static struct mac_plat_info ixdp425_plat_mac[] = {
+ {
+ .phy= 0,
+ .rxq= 3,
+ }, {
+ .phy= 1,
+
On Tue, May 08, 2007 at 05:28:21PM +0200, Krzysztof Halasa wrote:
I was always curious, why do people want to run ixp4xx in LE mode? What
are the benefits that overweight the obvious performance degradation?
Debian is indeed a valid reason.
I wonder if it would be much work to create BE
On Fri, Apr 27, 2007 at 12:52:08PM +0400, dmitry pervushin wrote:
+#elif defined(CONFIG_PXA3xx)
+#define SMC_CAN_USE_8BIT 1
+#define SMC_CAN_USE_16BIT1
+#define SMC_CAN_USE_32BIT0
+#define SMC_IO_SHIFT 0
+#define SMC_NOWAIT 1
+#define SMC_USE_PXA_DMA
On Thu, Apr 26, 2007 at 09:41:22AM -0400, David Acker wrote:
Here is a quote from Russell that describes what I believe is the main
problem:
http://www-gatago.com/linux/kernel/15457063.html
Has e100 actually been fixed to use the PCI DMA API correctly yet?
Looking at it, it doesn't look
On Tue, Apr 24, 2007 at 04:12:26PM -0700, Stephen Hemminger wrote:
The bridge code by default captures all spanning tree packets and
doesn't forward them. I propose that this might not be a good idea.
As far as I remember, the original bridge code did pass through BPDUs
when STP was disabled.
On Wed, Apr 11, 2007 at 04:36:49PM -0500, Kim Phillips wrote:
On Tue, Apr 10, 2007 at 04:57:23PM -0500, Kim Phillips wrote:
also adds RX TX delay bits to help boards with clock skew
problems.
snip
[...]
+
+ temp |= (MII_M_RX_DELAY | MII_M_TX_DELAY);
On Tue, Apr 10, 2007 at 05:20:52PM -0500, Kim Phillips wrote:
(note I'm coming from an embedded world here.)
Please read this:
http://marc.info/?l=linux-netdevm=116527863300952w=2
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
On Thu, Mar 22, 2007 at 03:52:55PM -0500, Bin He wrote:
Dear sir,
Hi,
I found your email address from kernel bridge source codes. I would
appreciate if you could look into my question a little bit.
The netdev@ mailing list is a better forum to ask such questions,
I've CC'ed this email
On Sun, Jan 07, 2007 at 03:11:34PM +0100, Harald Welte wrote:
So instead of using NAT to dynamically redirect traffic to local
addresses, we now rely on native non-locally-bound sockets and do
early socket lookups for inbound IPv4 packets.
It's good to see a solid implementation of this
On Thu, Jan 04, 2007 at 01:13:27PM +0100, KOVACS Krisztian wrote:
I'd also love to see the old tproxy API go away entirely. It was
always a bit of a pain to use.
It's gone with these patches: all you need is to bind() to foreign
addresses, like in the Linux 2.2 days.
That's how I
On Wed, Jan 03, 2007 at 05:33:57PM +0100, KOVACS Krisztian wrote:
The following set of patches implement transparent proxying support
loosely modeled on the Linux 2.2 transparent proxying functionality.
In a transparent http proxy server I wrote a while ago, we used to use
tproxy for making
On Tue, Dec 26, 2006 at 04:41:17PM -0500, Jeff Garzik wrote:
Small cleanup in the Cirrus Logic EP93xx ethernet driver: Check for NULL
pointer before dereferencing it instead of after. Remove unreferenced
variable.
Signed-off-by: Yan Burman [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL
On Tue, Dec 26, 2006 at 10:42:27PM +0100, Lennert Buytenhek wrote:
Small cleanup in the Cirrus Logic EP93xx ethernet driver: Check for NULL
pointer before dereferencing it instead of after. Remove unreferenced
variable.
Signed-off-by: Yan Burman [EMAIL PROTECTED]
Cc: Jeff Garzik
On Mon, Dec 18, 2006 at 12:04:19AM +0100, Francois Romieu wrote:
The former option is removed and platform code can now specify the
expected behavior.
Thanks a lot.
FYI, I submitted this patch for the n2100 side:
Index: linux-2.6.19/arch/arm/mach-iop32x/n2100.c
On Mon, Oct 30, 2006 at 07:28:37AM -0800, Stephen Hemminger wrote:
Could somebody explain, why bridge uses minimal MAC of the attached devices?
It makes this address instable, variable during bridge life-cycle, which is
not good for DHCP. For example, I want to attach multiple virtual
[ dropped subscriber-only openvz.org list ]
On Fri, Dec 15, 2006 at 07:52:36AM -0800, Stephen Hemminger wrote:
The bridge physical address is the minimum of all the attached devices.
This is done because the STP standard requires it. You can reset it
to be the same as any of the
On Mon, Dec 04, 2006 at 10:01:01AM -0800, Dan Nicolaescu wrote:
The Opencores Ethernet Controller is Verilog code that can be used to
implement an Ethernet device in hardware. It needs to be coupled with
a PHY and some buffer memory. Because of that devices that implement
this controller can
On Mon, Dec 04, 2006 at 10:27:52AM -0800, Dan Nicolaescu wrote:
The Opencores Ethernet Controller is Verilog code that can be used to
implement an Ethernet device in hardware. It needs to be coupled with
a PHY and some buffer memory. Because of that devices that implement
this
On Mon, Dec 04, 2006 at 10:27:52AM -0800, Dan Nicolaescu wrote:
I didn't know about platform drivers before your mail. I guess I
could convert it to that if that is the right thing to do.
(It might be an overkill given that the device is kind of simple and
embedded people prefer small
Fix unlikely(x) y test in ep93xx_eth.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Index: linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
===
--- linux-2.6.19-rc3.orig/drivers/net/arm/ep93xx_eth.c
+++ linux-2.6.19-rc3/drivers
Flooding the console with error messages for every RX FIFO overrun,
checksum error and framing error isn't very sensible. Each of these
errors can occur during normal operation, so stop printk'ing error
messages for RX errors at all.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Index
This patchset fixes three issues in ep93xx_eth. The first fix is for
an RX/TX lockup bug due to mishandling of the RX/TXstatus rings in the
driver, and is a showstopper. The second and third aren't really
showstopper bugs, but real issues nevertheless, and easy enough to fix.
In this new queue,
This patchset fixes three issues in ep93xx_eth. The first fix is for
an RX/TX lockup bug due to mishandling of the RX/TXstatus rings in the
driver, and is a showstopper. The second and third aren't really
showstopper bugs, but real issues nevertheless, and easy enough to fix.
Please apply for
ring, and if
there is a descriptor waiting, we take the hit of reading the descriptor
from memory anyway.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Index: linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
===
--- linux-2.6.19-rc3
On Sun, Oct 29, 2006 at 11:15:28AM -0700, Ray Lehtiniemi wrote:
Index: linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
===
--- linux-2.6.19-rc3.orig/drivers/net/arm/ep93xx_eth.c
+++ linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
On Fri, Oct 27, 2006 at 11:47:52PM +0200, Yakov Lerner wrote:
I'd like to find/gather estimates about 2.4 vs 2.6 share in [small]
linux routers in 2006. Can anyone offer estimates and/or references ?
For ARM devices, 2.4 is still definitely in the majority.
The reason for that appears to be
,
and there not being anything to set that back to PACKET_HOST even if
the destination MAC address matches the bridge interface's MAC address.
If this looks good, I'll prepare a proper commit message.
cheers,
Lennert
Signed-off-by: Tom Billman [EMAIL PROTECTED]
Signed-off-by: Lennert Buytenhek [EMAIL
On Thu, Oct 12, 2006 at 10:08:53AM +0200, Martin Schiller wrote:
I'm searching for a solution to suppress / delay the SYN-ACK packet of a
listening server (-application) until he has decided (e.g. analysed the
requesting ip-address or checked if the corresponding other end of a
connection is
The cirrus ep93xx is an ARM SoC that includes an ethernet MAC --
this patch adds a driver for that ethernet MAC.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Index: linux-2.6.18/drivers/net/arm/Kconfig
===
--- linux-2.6.18
The Cirrus Logic ep93xx is an ARM SoC that includes an ethernet MAC
-- this patch adds a driver for that ethernet MAC.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Index: linux-2.6.18/drivers/net/arm/Kconfig
===
--- linux
On Thu, Sep 21, 2006 at 07:10:02PM -0400, Jeff Garzik wrote:
+if (!(rstat0 RSTAT0_RFP)) {
+printk(KERN_CRIT ep93xx_rx: buffer not done
+ %.8x %.8x\n, rstat0, rstat1);
+BUG();
+}
+
On Mon, Sep 11, 2006 at 10:41:29PM +0200, Joerg Roedel wrote:
This driver implements the tunneling of Ethernet packets over IPv4
networks for Linux. It uses the protocol defined in RFC 3378.
Check out the thread [PATCH][RFC] etherip: Ethernet-in-IPv4 tunneling
that was on netdev in January of
The rtl8150 (ethernet) driver uses a default MTU of 1540, which causes
all kinds of problems with for example booting off NFS root. There isn't
really any reason why we shouldn't use the default of 1500.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
Index: linux-2.6.18-rc2/drivers/usb/net
On Tue, Sep 12, 2006 at 09:35:31PM +0200, Francois Romieu wrote:
+ /*
+ * Magic spell: some iop3xx ARM board needs the TxDescAddrHigh
+ * register to be written before TxDescAddrLow to work.
+ * Switching from MMIO to I/O access fixes the issue as well.
+ */
Not that
On Fri, Sep 08, 2006 at 10:23:36PM +0200, Francois Romieu wrote:
I suspect it's a chip bug. I rechecked with I/O space, and that
works okay, so this artifact (bug) only manifests itself when you
do the upper write in MMIO space.
Are there any plans to switch r8169 to the iomap API?
On Mon, Sep 04, 2006 at 06:39:29AM -0400, Jeff Garzik wrote:
1) Does e100 driver work on ARM?
FWIW, e100 seems to work okay for me on an intel ixp2400 (xscale based)
board, an ixp2850 (xscale based) board and an ixp2350 (xscale3 based)
board. ixp2350 works both with hardware coherency turned
On Mon, Sep 04, 2006 at 10:17:08PM +0200, Jürgen Schindele wrote:
i made a patch for an PXA270-evalboard with DM9000
ethernet contoller. The Interrupt can be high- or low-
active dependant of the wiring of the MDC-(57)pin.
Because of this hardware dependency you shoud be able
to configure
1 - 100 of 167 matches
Mail list logo
