-stable review patch. If anyone has any objections, please let us know.
--
Fix bridge netfilter to handle case where interface is deleted
from bridge while packet is being processed (on other CPU).
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=5803
Signed-off-by: Stephen Hem
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Date: Wed, 08 Feb 2006 14:59:06 +0900
> I see. The following patch is OK?
This breaks existing 32-bit programs which really want a 32-bit value
there.
Please sit and think about this problem for some time before proposing
more patches.
We have a whole c
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: Re: [PATCH] Packet socket: fix for 64-bit kernel and 32-bit userland
Date: Wed, 08 Feb 2006 14:59:06 +0900
> From: "David S. Miller" <[EMAIL PROTECTED]>
> Subject: Re: [PATCH] Packet socket: fix for 64-bit kernel and 32-bit userland
> Date: Tue, 0
From: "David S. Miller" <[EMAIL PROTECTED]>
Subject: Re: [PATCH] Packet socket: fix for 64-bit kernel and 32-bit userland
Date: Tue, 07 Feb 2006 21:48:02 -0800 (PST)
> From: FUJITA Tomonori <[EMAIL PROTECTED]>
> Date: Wed, 08 Feb 2006 14:41:41 +0900
>
> > From: "David S. Miller" <[EMAIL PROTECTED
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Date: Wed, 08 Feb 2006 14:41:41 +0900
> From: "David S. Miller" <[EMAIL PROTECTED]>
> Subject: Re: [PATCH] Packet socket: fix for 64-bit kernel and 32-bit userland
> Date: Tue, 07 Feb 2006 21:36:06 -0800 (PST)
>
> > > tpacket_hdr structure includes 'unsig
From: "David S. Miller" <[EMAIL PROTECTED]>
Subject: Re: [PATCH] Packet socket: fix for 64-bit kernel and 32-bit userland
Date: Tue, 07 Feb 2006 21:36:06 -0800 (PST)
> > tpacket_hdr structure includes 'unsigned long' though kernel and
> > userland shares it in the mmapped ring buffer.
> >
> > See
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Date: Wed, 08 Feb 2006 14:24:49 +0900
> tpacket_hdr structure includes 'unsigned long' though kernel and
> userland shares it in the mmapped ring buffer.
>
> Seems it would be better to fix all data structures in the header file
> than fixing only tpacket
Mike Christie and I've developed the SCSI Userspace target
framework. Target LLDs (for Fibre channel, iSCSI HBAs, etc) pass SCSI
commands to SCSI commands to the user-space daemon. The daemon
executes the commands and sends the results back to the LLDs.
Please refer scsi-ml for further details.
h
tpacket_hdr structure includes 'unsigned long' though kernel and
userland shares it in the mmapped ring buffer.
Seems it would be better to fix all data structures in the header file
than fixing only tpacket_hdr structure.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
Signed-off-by: Mike Chr
bond_release returns EINVAL without releasing the bond lock if the
slave device is not being bonded by the bond. The following patch
ensures that the lock is released in this case.
Signed-off-by: Stephen J. Bevan <[EMAIL PROTECTED]>
Acked-by: Jay Vosburgh <[EMAIL PROTECTED]>
---
--- linux-2.6.
From: Horms <[EMAIL PROTECTED]>
Date: Wed, 8 Feb 2006 12:09:29 +0900
> Unfortunately this seems like it is going to be more tedious than
> we first thought. I would guess writing some sort of tool to analyse
> symbols and headers is the way to go. Else it seems more or less
> impossible to clean
> Unfortunately this seems like it is going to be more tedious than
> we first thought. I would guess writing some sort of tool to analyse
> symbols and headers is the way to go. Else it seems more or less
> impossible to clean up headers, even on a small scale.
>
Search the netdev archives or look
On Wed, Feb 08, 2006 at 01:36:11PM +1100, Herbert Xu wrote:
> Horms <[EMAIL PROTECTED]> wrote:
> >
> >> Looks bogus to me. Why are we removing linux/modules.h from ip_vs_app.c
> >> when it uses things like EXPORT_SYMBOL?
> >
> > Given that the code still compiles, I guess linux/modules.h is inclu
Horms <[EMAIL PROTECTED]> wrote:
>
>> Looks bogus to me. Why are we removing linux/modules.h from ip_vs_app.c
>> when it uses things like EXPORT_SYMBOL?
>
> Given that the code still compiles, I guess linux/modules.h is included
> in some other header that is included. I'm happy to put linux/modu
On Wed, Feb 08, 2006 at 12:19:32PM +1100, Herbert Xu wrote:
> Horms <[EMAIL PROTECTED]> wrote:
> > Dave,
> >
> > please apply.
>
> Looks bogus to me. Why are we removing linux/modules.h from ip_vs_app.c
> when it uses things like EXPORT_SYMBOL?
Given that the code still compiles, I guess linux
On Tue, 7 Feb 2006 17:50:03 -0800, Pradeep Vincent <[EMAIL PROTECTED]> wrote:
>One more attempt. Attaching the diff file as well.
>
>Signed off by: Pradeep Vincent <[EMAIL PROTECTED]>
>
>--- old/net/core/neighbour.cWed Nov 9 16:48:10 2005
>+++ new/net/core/neighbour.cTue Feb 7 17:38:26 2
On Tue, Feb 07, 2006 at 05:41:45PM +0200, Denis Vlasenko wrote:
> On Friday 03 February 2006 14:14, Denis Vlasenko wrote:
> > Standalone acx driver had several fixes since
> > acxsm fork, this patch merges them:
> > - initial support for new TNETW1450 USB chip
> > - support for firmware 2.3.1.31
>
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Date: Tue, 7 Feb 2006 17:41:28 -0800 (Pacific Standard Time)
> so we generally call dev_alloc_skb to get the receive buffers to give to
> our hardware. When we use multiple receive buffers what is the right way
> to allocate memory to give buffers to t
One more attempt. Attaching the diff file as well.
Signed off by: Pradeep Vincent <[EMAIL PROTECTED]>
--- old/net/core/neighbour.cWed Nov 9 16:48:10 2005
+++ new/net/core/neighbour.cTue Feb 7 17:38:26 2006
@@ -14,6 +14,7 @@
* Vitaly E. Lavrovreleasing NULL neighbor in neig
On Tue, 7 Feb 2006, Herbert Xu wrote:
David S. Miller <[EMAIL PROTECTED]> wrote:
>
> I think we should revert that thing, it's caused more grief than
> anything else. I thought it was a complete waste of time from the
> get-go even assuming that fraglists within fraglists never occur...
I share
David S. Miller <[EMAIL PROTECTED]> wrote:
>
> I think we should revert that thing, it's caused more grief than
> anything else. I thought it was a complete waste of time from the
> get-go even assuming that fraglists within fraglists never occur...
I share your feelings towards this patch. How
Horms <[EMAIL PROTECTED]> wrote:
> Dave,
>
> please apply.
Looks bogus to me. Why are we removing linux/modules.h from ip_vs_app.c
when it uses things like EXPORT_SYMBOL?
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apa
Rick Jones wrote:
Ben Greear wrote:
Rick Jones wrote:
In the realm of straw ideas, how often are netdevs added and removed,
and would leaving a tombstone behind consume too much memory?
In certain cases...say, with vlans, you could very often create and
destroy net devices. I think that
David S. Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Tue, 07 Feb 2006 16:39:52 -0800
Rick Jones wrote:
In the realm of straw ideas, how often are netdevs added and removed,
and would leaving a tombstone behind consume too much memory?
In certain cases...say, with vlans, you co
Ben Greear wrote:
Rick Jones wrote:
In the realm of straw ideas, how often are netdevs added and removed,
and would leaving a tombstone behind consume too much memory?
In certain cases...say, with vlans, you could very often create and
destroy net devices. I think that giving up and leaking
David S. Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Tue, 07 Feb 2006 15:54:06 -0800
What do you think about having no ref counting, and upon removal of
a network device, we notify each logic unit that deals with skbs
or other things that link to the netdev and ask it to clean all
David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 07 Feb 2006 16:29:34 -0800
In the realm of straw ideas, how often are netdevs added and
removed, and would leaving a tombstone behind consume too much
memory?
That could work.
Another idea is to revisit the scheme of st
From: Ben Greear <[EMAIL PROTECTED]>
Date: Tue, 07 Feb 2006 16:39:52 -0800
> Rick Jones wrote:
> > In the realm of straw ideas, how often are netdevs added and removed,
> > and would leaving a tombstone behind consume too much memory?
>
> In certain cases...say, with vlans, you could very often
Rick Jones wrote:
In the realm of straw ideas, how often are netdevs added and removed,
and would leaving a tombstone behind consume too much memory?
In certain cases...say, with vlans, you could very often create and
destroy net devices. I think that giving up and leaking the memory
is not a
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 07 Feb 2006 16:29:34 -0800
> In the realm of straw ideas, how often are netdevs added and
> removed, and would leaving a tombstone behind consume too much
> memory?
That could work.
Another idea is to revisit the scheme of storing just the
ifindex
In the realm of straw ideas, how often are netdevs added and removed, and would
leaving a tombstone behind consume too much memory?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ker
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 7 Feb 2006 16:19:42 -0800
> Also, isn't a lot of the problem reduced if network devices
> are affinitied?
Not for routing/firewalling, we touch the destination device's
counters on input softing of the source device.
-
To unsubscribe from thi
On Tue, 07 Feb 2006 16:11:51 -0800 (PST)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Ben Greear <[EMAIL PROTECTED]>
> Date: Tue, 07 Feb 2006 15:54:06 -0800
>
> > What do you think about having no ref counting, and upon removal of
> > a network device, we notify each logic unit that deals
From: Ben Greear <[EMAIL PROTECTED]>
Date: Tue, 07 Feb 2006 15:54:06 -0800
> What do you think about having no ref counting, and upon removal of
> a network device, we notify each logic unit that deals with skbs
> or other things that link to the netdev and ask it to clean all
> references to the
Eric Dumazet wrote:
David S. Miller a écrit :
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 08 Feb 2006 00:23:45 +0100
Some devices are *never* unregistered : loopback, or statically
linked drivers, thus we are refcounting them for nothing.
Statically linked drivers can have netdev's t
David S. Miller a écrit :
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 08 Feb 2006 00:23:45 +0100
Some devices are *never* unregistered : loopback, or statically linked
drivers, thus we are refcounting them for nothing.
Statically linked drivers can have netdev's that get unregistered
an
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 08 Feb 2006 00:23:45 +0100
> Some devices are *never* unregistered : loopback, or statically linked
> drivers, thus we are refcounting them for nothing.
Statically linked drivers can have netdev's that get unregistered
and free'd up. For example
Struct net_device's atomic refcnt are probably one of the hotest memory spots
in a SMP/NUMA network router or network server.
This counter is constantly incremented/decremented each time a network packet
is handled, or a IP route is added/deleted in route cache. This is *not* SMP
nor NUMA frie
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Date: Tue, 7 Feb 2006 14:11:46 -0800 (Pacific Standard Time)
> A recent commit in 2.6.14 broke this, see this git commit:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=bc8dfcb93970ad7139c976356bfc99d7e251deaf
>
>
On Tue, Feb 07, 2006 at 11:14:49PM +0100, Adrian Bunk wrote:
> Jean-Luc Leger <[EMAIL PROTECTED]> reported the following:
>
> from drivers/net/Kconfig:
> config IBM_EMAC_PHY_RX_CLK_FIX
> bool "PHY Rx clock workaround"
> depends on IBM_EMAC && (405EP || 440GX || 440EP || 440GR)
> ->
Jean-Luc Leger <[EMAIL PROTECTED]> reported the following:
from drivers/net/Kconfig:
config IBM_EMAC_PHY_RX_CLK_FIX
bool "PHY Rx clock workaround"
depends on IBM_EMAC && (405EP || 440GX || 440EP || 440GR)
-> maybe this is 440GP ?
The non-existing CONFIG_440GR is also present in t
For a while now with e1000, we've been trying to optimize our jumbo frame
memory utilization by using multiple 2k buffers chained together (see
rx_skb_top in e1000_main.c) using frag_list. Up until 2.6.14, this
worked.
A recent commit in 2.6.14 broke this, see this git commit:
http://git.ker
Hi,
On Tue, Feb 07, 2006 at 12:57:43AM -0700, Pradeep Vincent wrote:
> In 2.4.21, arp code uses gc_timer to check for stale arp cache
> entries. In 2.6, each entry has its own timer to check for stale arp
> cache. 2.4.29 to 2.4.32 kernels (atleast) use neither of these timers.
> This causes proble
John,
Softmac scanning fails because the stop flag is not cleared before scanning is started. The attached
one-line patch fixes this.
Signed-Off-By: Larry Finger <[EMAIL PROTECTED]>
diff --git a/net/ieee80211/softmac/ieee80211softmac_scan.c
b/net/ieee80211/softmac/ieee80211softmac_scan.c
ind
Olaf Kirch <[EMAIL PROTECTED]> wrote:
>
> People have been testing with the patch below, which seems to fix the
> problem partially. They still see connection hangs however (things
> only clear up when they start a new ping or new ssh). So the patch
> is obvsiouly not sufficient, and something els
Add _{get,set}_encodeext and improve logging in _encode
The code in _{get,set}_encode has been reordered a bit so we have
better logging (function entry and exit) and _{get,set}_encodeext have
been implemented as a wrapper for the ieee80211 stack functions.
diff --git a/ioctl.
Dan Williams wrote:
AFAIK anything less than 5.40.x doesn't work anyway. The latest stuff
(5.60.x) has worked fine. I previously had 5.30.17, which tended to
hang the card after a while. Anyway, perhaps we require people to
update their firmware. Not sure.
What's the minimum firmware versio
Hajo Noerenberg wrote:
I've bought four new e1000 cards (PCI id 8086:107c, chip label 82541PI),
three of them are working without problems (i386, kernel 2.4.x).
One of them is installed in an AMD64 SMP system (Athlon dual core 4GB).
It gets detected, link is reported to be up, but no data goes t
Does /proc/interrupts show the interrupts incrementing for the
interface?
-Jeb
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Hajo Noerenberg
> Sent: Tuesday, February 07, 2006 3:22 AM
> To: netdev@vger.kernel.org
> Subject: e1000 not working on AM
On Thu, 2006-02-02 at 13:37 +, Mike Crowe wrote:
>> I'm running the Debian 2.6.15 kernel from backports.org on a
>> machine with two Opteron 275s. I am getting a BUG in tg3.c quite
>> reliably if I ping flood the machine from a few others and cause a
>> bit of other network activity. Sometimes
[patch 2/2] s390: some qeth driver fixes
From: Frank Pavlic <[EMAIL PROTECTED]>
- fixed kernel panic when using EDDP support in Layer 2 mode
- NULL pointer exception in qeth_set_offline fixed.
- setting EDDP in Layer 2 mode did not set NETIF_F_(SG/TSO)
flags when
[patch 1/2] s390: lcs performance enhancements
From: Klaus Wacker <[EMAIL PROTECTED]>
- When flood pinging (with large packet size) an LCS device,
about 90 % of all packets are dropped by driver.
- increased number of lcs IO buffers to 32.
- use netif_stop_queue
Hello John,
On Friday 03 February 2006 14:14, Denis Vlasenko wrote:
> Standalone acx driver had several fixes since
> acxsm fork, this patch merges them:
> - initial support for new TNETW1450 USB chip
> - support for firmware 2.3.1.31
>
> Also we had one report that acxsm is actually working.
> T
Hi,
there's a problem with IPsec that has been bugging some of our users
for the last couple of kernel revs. Every now and then, IPsec will
freeze the machine completely. This is with openswan user land,
and with kernels up to and including 2.6.16-rc2.
I managed to debug this a little, and what h
On Tue, Feb 07, 2006 at 04:15:31PM +0100, Andi Kleen wrote:
> On Tuesday 07 February 2006 15:54, Benjamin LaHaise wrote:
>
> > + if (size > ((sk->sk_sndbuf >> 1) - 64))
> > + size = (sk->sk_sndbuf >> 1) - 64;
>
> This is really surprising. Are you double plus sure gcc
Instead of doing a memset then initialization of the fields of the scm
structure, just initialize all the members explicitly. Prevent reloading
of current on x86 and x86-64 by storing the value in a local variable for
subsequent dereferences. This is worth a ~7KB/s increase in af_unix
bandwid
On Tuesday 07 February 2006 15:54, Benjamin LaHaise wrote:
> + if (size > ((sk->sk_sndbuf >> 1) - 64))
> + size = (sk->sk_sndbuf >> 1) - 64;
This is really surprising. Are you double plus sure gcc doesn't
do this automatically?
-Andi
-
To unsubscribe from this l
The patch below replaces a divide by 2 with a shift -- sk_sndbuf is an
integer, so gcc emits an idiv, which takes 10x longer than a shift by 1.
This improves af_unix bandwidth by ~6-10K/s. Also, tidy up the comment
to fit in 80 columns while we're at it.
-ben
Signed-off-by: B
I've bought four new e1000 cards (PCI id 8086:107c, chip label 82541PI),
three of them are working without problems (i386, kernel 2.4.x).
One of them is installed in an AMD64 SMP system (Athlon dual core 4GB).
It gets detected, link is reported to be up, but no data goes through
(in fact _sometim
On Fri, Feb 03, 2006 at 10:01:17AM -0800, Stephen Hemminger wrote:
>
> static unsigned char *skb_pull_rcsum(struct sk_buff *skb, unsigned int len)
> {
> if (unlikely(len > skb->len))
> return NULL;
> if (skb->ip_summed == CHECKSUM_HW)
> skb->csum = csum_sub(
On Sat, 4 Feb 2006, Adrian Bunk wrote:
> This patch contains the following possible cleanups:
> - make needlessly global code static
Good catch.
> - #if 0 the following unused global functions:
> - name_table.c: tipc_nametbl_print()
> - name_table.c: tipc_nametbl_dump()
> - net.c: tipc_net
Hi all,
in the same way of this patch, why dst_entry are stored for
RAW socket ? In case of specific IPSec rules for ICMPv6,
xfrm state can be different for the same destination.
Attached, a proposed patch.
Regards,
Nicolas
[IPV6] Don't store dst_entry for RAW socket
Signed-off-by: Nicolas DIC
Please pull from 'upstream-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
drivers/net/8139too.c| 38 +--
drivers/net/Kconfig |7 -
drivers/net/bonding/bond_main.c | 15 ++-
drivers/net/b
63 matches
Mail list logo
