part:
> > MAINTAINERS file lists Lennert as maintainer, let me add him.
> > Strange thing is that the MAINTAINERS entry for arm/iop32x has no
> > F entry, therefore the get_maintainers scripts will never list him
> > as addressee. The script lists Russell as "odd
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 auto-probe
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 guara
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 de
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
p attributes")
> > Signed-off-by: David Ahern
>
> Reported-by: João Taveira Araújo
>
> Reported-by: Lennert Buytenhek
>
> Acked-by: Roopa Prabhu
Tested-by: Lennert Buytenhek
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 maintena
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 M
_read_{,un}lock_bh() around the code that
expects to be treated as an RCU-bh read side critical section, as this
seems a safer option than fixing it in the callers.
Fixes: 4fd3d7d9e868f ("neigh: Add helper function neigh_xmit")
Signed-off-by: David Barroso
Signed-off-by: Lennert Buyten
irq 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 section.
> >
>
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 CONFIG_DEBUG_LOCK_A
as an RCU-bh read side critical section.
Signed-off-by: David Barroso
Signed-off-by: Lennert Buytenhek
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index f18ae91..769cece 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -2467,13 +2467,17 @@ int neigh_xmit(int index,
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 mpls_output
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 *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() -> lwtunnel_outp
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 t
Reported-by: Grant Zhang
Signed-off-by: Lennert Buytenhek
---
drivers/net/macvlan.c | 71 ---
1 file changed, 45 insertions(+), 26 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index cb01023..02934a5 100644
--- a/d
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
>
up to that question at the time, 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
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-
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 loo
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 definit
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 PROT
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
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/mv
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
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.
> >
&g
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
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 Perelst
cro arguments.
* Replace "(1<<24) | (1<<23) | (1<<22)" type 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
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]>
Inde
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/m
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
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/m
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]
, 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/lin
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 ARCH_O
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
> >
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
> > +#
,
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 Buy
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 incre
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 compile
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 <[EMAI
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 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,
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 h
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 lef
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 NS
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 th
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 netw
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 s
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 th
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?
>
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
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
> > th
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 creat
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
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 mechan
On Tue, May 08, 2007 at 04:47:31PM +0400, Alexey Zaytsev wrote:
> > As with Christian's driver, I don't know whether an SRAM allocator
> > makes much sense. We can just set up a static allocation map for the
> > in-tree drivers and leave out the allocator altogether. I.e. I don't
> > think it's
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 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 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
On Tue, May 08, 2007 at 03:19:22AM +0200, Krzysztof Halasa wrote:
> diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c
> b/arch/arm/mach-ixp4xx/ixdp425-setup.c
> index ec4f079..f20d39d 100644
> --- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
> +++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
> @@ -101,10 +10
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;
> +stat
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
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.
> >
>
> >
> > > [...]
> > > +
> > > + temp |= (MII_M_RX_DELAY | MII_
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-netdev&m=116527863300952&w=2
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL P
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.
This doesn't make sense at all.
RGMII specifies that clock and data are generated simultaneously. The
necessary 1.5-2ns of clock delay is either achieved by rout
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 th
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 implementatio
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
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 o
the
very file being patched, I'm not sure whether anything else'll help, but
fine, whatever.
The patch below adds a MAINTAINERS entry for everything I would
appreciate being CC'ed on, someone please apply it.
---
From: Lennert Buytenhek &l
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.
> > >
> > &g
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 <[
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
[ 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 th
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
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 c
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
> > > t
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 c
rom a full 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
===
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,
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 PROTE
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
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/ep93x
Flooding the console with an RX FIFO overrun error for every single
dropped packet isn't very sensible. The hardware is very underpowered
according to today's standards, and RX FIFO overrun errors can be
triggered quite easily, so don't report them at all.
Signed-off-by: Le
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/net/arm/ep93xx_eth.c
@@ -334,7
rom a full 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
===
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 2.
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
_OTHERHOST,
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-of
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
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
===
---
1 - 100 of 195 matches
Mail list logo
