On Thu, 08 Mar 2007 10:35:13 +0900 (JST), Atsushi Nemoto [EMAIL PROTECTED]
wrote:
netpoll_rx() should be invokable from hardware interrupt context.
What is the crash you are seeing?
The problem is not netpoll_rx(). It should be called from irq context.
The problem is, netif_receive_skb()
On Mon, Mar 12, 2007 at 10:22:36PM -0800, Andrew Morton wrote:
On Mon, 12 Mar 2007 13:53:11 -0700 (PDT) David Miller [EMAIL PROTECTED]
wrote:
...
And there is absolutely no negotiations about this, I've held back on
this for nearly 2 years, and nothing has happened, this code is not
On Tuesday 13 March 2007 10:32, Evgeniy Polyakov wrote:
On Fri, Mar 02, 2007 at 11:52:47AM +0300, Evgeniy Polyakov
([EMAIL PROTECTED]) wrote:
So, I ask network developers about testing environment for socket lookup
benchmarking. What would be the best test case to determine performance
of the
On Tue, Mar 13, 2007 at 11:08:27AM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Tuesday 13 March 2007 10:32, Evgeniy Polyakov wrote:
On Fri, Mar 02, 2007 at 11:52:47AM +0300, Evgeniy Polyakov
([EMAIL PROTECTED]) wrote:
So, I ask network developers about testing environment for socket
On Friday 09 March 2007 21:56, Stephen Hemminger wrote:
Linsys Contractor Mithlesh Thukral wrote:
NetXen: This will fix a softlock seen on some machines.
The reason was too much time was spent waiting for writes to go through.
Signed-off by: Mithlesh Thukral [EMAIL PROTECTED]
---
Hi All,
I will be sending bug fixes to NetXen: 1G/10G Ethernet driver in subsequent
mails.
The patches are with respect to netdev#upstream-fixes.
Regards,
Mithlesh Thukral
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
NetXen: Set the MTU for the right port depending upon the port number
for XG cards.
Signed-off by: Mithlesh Thukral [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic_hw.c |5 -
1 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/netxen/netxen_nic_hw.c
David Miller [EMAIL PROTECTED] writes:
From: Rick Jones [EMAIL PROTECTED]
Date: Mon, 12 Mar 2007 17:05:39 -0700
Being paranoid - are there no worries about the alignment of dest?
If it's an issue, it's an issue elsewhere too, as the places
where Stephen took this idiomatic code from is
On Tuesday 13 March 2007 15:01, Andi Kleen wrote:
David Miller [EMAIL PROTECTED] writes:
From: Rick Jones [EMAIL PROTECTED]
Date: Mon, 12 Mar 2007 17:05:39 -0700
Being paranoid - are there no worries about the alignment of dest?
If it's an issue, it's an issue elsewhere too, as the
Hello.
Mark Brown wrote:
Subject: natsemi: Fix NAPI for interrupt sharing
The interrupt status register for the natsemi chips is clear on read and
was read unconditionally from both the interrupt and from the NAPI poll
routine, meaning that if the interrupt service routine was called (for
The ICMP rate limiting state can be shorts, we don't send that many ICMPs.
Changing flags to short and reorder fields to be sorted by size to avoid holes.
Move cold fields towards the end.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Index: linux-2.6.21-rc3-net/include/net/dst.h
Hello.
Mark Brown wrote:
Moving netdev_rx() would fix that one but there's some others too -
there's one in the timer routine if the chip crashes. In the case you
Erm, sorry, I'm not seeing it -- could you point with finger please?
:-)
In netdev_timer() when the device is using
below is a patch that just removes dead code/initializers without any
effect (first access is an assignment) that I stumbled accross while
reading the source.
Signed-off-by: Florian Zumbiehl [EMAIL PROTECTED]
Acked-by: Michal Ostrowski [EMAIL PROTECTED]
---
drivers/net/pppoe.c | 21
below you find a patch that fixes a memory leak when a PPPoE socket is
release()d after it has been connect()ed, but before the PPPIOCGCHAN ioctl
ever has been called on it.
This is somewhat of a security problem, too, since PPPoE sockets can be
created by any user, so any user can easily
below you find a patch that (hopefully) fixes a race between an interface
going down and a connect() to a peer on that interface. Before,
connect() would determine that an interface is up, then the interface
could go down and all entries referring to that interface in the
item_hash_table would be
pppoe_flush_dev() kicks all sockets bound to a device that is going down.
In doing so, locks must be taken in the right order consistently (sock lock,
followed by the pppoe_hash_lock). However, the scan process is based on
us holding the sock lock. So, when something is found in the scan we must
On Tuesday 13 March 2007 15:10, Eric Dumazet wrote:
On Tuesday 13 March 2007 14:48, Andi Kleen wrote:
The ICMP rate limiting state can be shorts, we don't send that many ICMPs.
Changing flags to short and reorder fields to be sorted by size to avoid
holes. Move cold fields towards the end.
On Tuesday 13 March 2007 15:31, Andi Kleen wrote:
Ok. When you do such changes you should always add a comment, otherwise
it will be always destroyed with the next change.
But it seems highly fragile to me anyways because it depends on the exact
value of RTAX_MAX which tends to change
On Tuesday 13 March 2007 15:44, Eric Dumazet wrote:
Also, 'lastuse' could use a u32 too, I even had a patch for this one...
Here is the patch I have here for lastuse u32 conversion, not for inclusion
yet because not yet tested (only compiled)
[PATCH] NET : abstract lastuse (from struct
Hi,
I'm not sure whether this is really worth it, but it looked so
extremely inefficient that I couldn't resist - so let's hope providers
will keep PPPoE around for a while, at least until terabit dsl ;-)
The new code produces the same results as the old version and is
~ 3 to 6 times faster for
Hi,
here another patch for the PPPoX/E code that makes sure that ENOTTY is
returned for unknown ioctl requests rather than 0 (and removes another
unneeded initializer which I didn't bother creating a separate patch for).
Florian
Hi,
and the last one for now: Acquire the sock lock in pppoe_sendmsg()
before accessing the sock - and in particular avoid releasing the lock
even though it hasn't been acquired.
Florian
---
Signed-off-by: Florian Zumbiehl
The tc35815 driver lacks a call to pci_dma_sync_single_for_device() on
receiving. Recent fix of MIPS dma_sync_single_for_cpu() reveal this
bug.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
This patch can be applied to netdev-2.6 tree or 2.6.21-rc3-mm2.
diff --git a/drivers/net/tc35815.c
o The AX.25 Howto is unmaintained since several years. I've replaced it
with a wiki at http://www.linux-ax25.org which provides more uptodate
information.
o Change default for AX25_DAMA_SLAVE to Y. AX25_DAMA_SLAVE only compiles
in support for DAMA but doesn't activate it. I hope this
Alex Sidorenko wrote:
Here are the values from live kernel (obtained with 'crash') when the host was
in SWS state:
full_space=708 full_space/2=354
free_space=393
window=76
In this case the test from my original fix, (window full_space/2),
succeeds. But John's test
free_space
On Wed, 14 Mar 2007 01:02:20 +0900 (JST)
Atsushi Nemoto [EMAIL PROTECTED] wrote:
The tc35815 driver lacks a call to pci_dma_sync_single_for_device() on
receiving. Recent fix of MIPS dma_sync_single_for_cpu() reveal this
bug.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
This patch
Stephen Hemminger [EMAIL PROTECTED] writes:
/*
* FIXME: On x86 and some other CPUs the split into user and softirq parts
* is not needed because addl $1,memory is atomic against interrupts (but
* atomic_inc would be overkill because of the lock cycles). Wants new
*
On Tue, Mar 13, 2007 at 04:53:54PM +0300, Sergei Shtylyov wrote:
Mark Brown wrote:
confused and eventually locks up. Before locking up it will usually
report one or more oversided packets so this is a useful hint that we
should reset the recieve state machine in order to recover from this.
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 13 Mar 2007 14:38:32 +0100
But memcmp() has a strong semantic (in libc). memcmp(a, b, 6) should
do 6 byte compares and conditional branches, regardless of a/b
alignment. Or use the x86 rep cmpsb instruction that basically
has the same cost.
On Mon, 2007-03-12 at 10:56 -0700, Jean Tourrilhes wrote:
I did that in the e-mail to Jouni. The problem is that most
people are unfamiliar with decoding iwevents, so can't grasp the
explanation.
Basically, for iwpoint, we have an outer lenght and an inner
length. If they don't
On Tue, 13 Mar 2007 12:39:54 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Tue, 13 Mar 2007 14:38:32 +0100
But memcmp() has a strong semantic (in libc). memcmp(a, b, 6) should
do 6 byte compares and conditional branches, regardless of a/b
It isn't any faster to test a boolean global variable than do a
simple check for empty list.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
net/core/dev.c | 18 +-
1 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index
On Tue, Mar 13, 2007 at 08:42:05PM +0100, Johannes Berg wrote:
On Mon, 2007-03-12 at 10:56 -0700, Jean Tourrilhes wrote:
I did that in the e-mail to Jouni. The problem is that most
people are unfamiliar with decoding iwevents, so can't grasp the
explanation.
Basically, for
On Sun, 25 Feb 2007 12:02:23 -0500
jamal [EMAIL PROTECTED] wrote:
cheers,
jamal
applied both patches
--
Stephen Hemminger [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sun, 4 Mar 2007 20:14:53 +0100 (MET)
Patrick McHardy [EMAIL PROTECTED] wrote:
This patchset consists of four parts:
- minor TBF time conversion fix
- consolidation of time calculations: consolidate commonly used expressions
with the goal of making it easier to audit for integer
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22
We're getting close...
Thanks a lot!
- Arnaldo
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo
For the common, open coded 'skb-h.raw = skb-data' operation, so that we can
later turn skb-h.raw into a offset, reducing the size of struct sk_buff in
64bit land while possibly keeping it as a pointer on 32bit.
This one touches just the most simple cases:
skb-h.raw = skb-data;
skb-h.raw =
For the quite common 'skb-h.raw - skb-data' sequence.
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
drivers/net/atl1/atl1_main.c | 10 +-
drivers/net/cassini.c |6 ++
drivers/net/cxgb3/sge.c|7 ---
For the cases where the transport header is being set to a offset from
skb-data.
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
include/linux/skbuff.h |6 ++
net/ax25/af_ax25.c | 20
net/ax25/ax25_in.c
For consistency with all the other skb-h.raw accessors.
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
include/linux/sctp.h |9 +
net/sctp/input.c | 14 +-
net/sctp/ipv6.c |4 ++--
net/sctp/protocol.c | 10 --
4 files changed, 20
The ip_hdrlen() buddy, created to reduce the number of skb-h.th- uses and to
avoid the longer, open coded equivalent.
Ditched a no-op in bnx2 in the process.
I wonder if we should have a BUG_ON(skb-h.th-doff 5) in tcp_optlen()...
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
drivers/net/sk98lin/skge.c |4 ++--
drivers/net/skge.c |2 +-
include/linux/ip.h |5 +
include/linux/skbuff.h |1 -
net/ipv4/xfrm4_mode_tunnel.c |6 +++---
net/ipv6/xfrm6_mode_tunnel.c |
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
include/linux/igmp.h | 21 +
include/linux/skbuff.h |1 -
net/ipv4/igmp.c| 22 +++---
net/ipv4/ipmr.c|2 +-
4 files changed, 33 insertions(+), 13 deletions(-)
From
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
drivers/net/gianfar.c |4 ++--
drivers/net/ioc3-eth.c|2 +-
drivers/net/mv643xx_eth.c |2 +-
include/linux/skbuff.h|1 -
include/linux/udp.h |9 +
include/net/udplite.h |2 +-
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
include/linux/icmp.h |9 +
include/linux/skbuff.h |1 -
net/dccp/ipv4.c|4 ++--
net/ipv4/ah4.c |4 ++--
net/ipv4/esp4.c|4 ++--
net/ipv4/icmp.c| 14 +++---
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
drivers/net/atl1/atl1_main.c |7 ---
drivers/net/bnx2.c |8
drivers/net/chelsio/sge.c |2 +-
drivers/net/cxgb3/sge.c|2 +-
drivers/net/e1000/e1000_main.c | 11 ++-
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
include/linux/ipv6.h |5 +
include/linux/skbuff.h |1 -
net/ipv6/xfrm6_mode_beet.c |4 ++--
net/ipv6/xfrm6_mode_tunnel.c |8
4 files changed, 11 insertions(+), 7 deletions(-)
From
These are a bit more subtle, they are of this type:
- skb-h.raw = payload;
__skb_pull(skb, payload - skb-data);
+ skb_reset_transport_header(skb);
__skb_pull results in:
skb-data = skb-data + payload - skb-data;
skb-data = payload;
So after __skb_pull we have skb-data
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
net/sctp/input.c |8
net/sctp/ipv6.c |5 ++---
2 files changed, 6 insertions(+), 7 deletions(-)
From b9c0a34313240c6f74bcc5587a496493480daf7d Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
For the places where we need a pointer to the transport header, it is
still legal
to touch skb-h.raw directly if just adding to, subtracting from or setting it
to another layer header.
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
drivers/net/appletalk/ltpc.c|7 +--
On 3/13/07, Arnaldo Carvalho de Melo [EMAIL PROTECTED] wrote:
Introduce tcp_hdrlen() and tcp_optlen():
The ip_hdrlen() buddy, created to reduce the number of skb-h.th- uses and to
avoid the longer, open coded equivalent.
+static inline unsigned int tcp_hdrlen(const struct sk_buff *skb)
+{
+
On 3/13/07, Jesse Brandeburg [EMAIL PROTECTED] wrote:
acme, good stuff, but does the * 4 generate equivalent assembly
with gcc 3/4 as 2 ?
I could assume that the compiler would be smart enough, but every time
I assume I know what the compiler is doing I get myself in trouble.
nevermind, I
On Tue, 13 Mar 2007 12:04:18 -0700, Stephen Hemminger [EMAIL PROTECTED] wrote:
+ * 1.35Fix an usage of streaming DMA API.
*/
Please don't use comments as changelog anymore. It gets out of date.
The use of change control systems has made this practice obsolete.
OK, Jeff, should I
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly
On Tue, Mar 13, 2007 at 01:39:12AM -0700, Roland McGrath wrote:
The OPEN_MAX constant is an arbitrary number with no useful relation to
anything. Nothing should be using it. This patch changes SCM_MAX_FD to
use NR_OPEN instead of OPEN_MAX. This increases the size of the struct
scm_fp_list
On Mon, Mar 12, 2007 at 10:07:33AM -0400, Jeff Garzik wrote:
Pekka Enberg wrote:
Hi,
On 3/12/07, Valerie Henson [EMAIL PROTECTED] wrote:
--- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip_core.c
+++ tulip-2.6-mm-linux/drivers/net/tulip/tulip_core.c
@@ -17,11 +17,11 @@
#define DRV_NAME
-#define SCM_MAX_FD (OPEN_MAX-1)
+#define SCM_MAX_FD (NR_OPEN-1)
This is a bad idea. [...]
Ok. My only agenda is to get rid of OPEN_MAX.
I then propose the following instead.
Thanks,
Roland
---
[PATCH] avoid OPEN_MAX in SCM_MAX_FD
The OPEN_MAX constant is an arbitrary number with no
Hi Stephen,
On Mon, Mar 12, 2007 at 02:11:56PM -0700, Stephen Hemminger wrote:
Oh BTW, I have a newer version with a first approximation of the
cbrt() before the div64_64, which allows us to reduce from 3 div64
to only 2 div64. This results in a version which is twice as fast
as the
On Tue, 13 Mar 2007, Roland McGrath wrote:
The OPEN_MAX constant is an arbitrary number with no useful relation to
anything. Nothing should be using it. SCM_MAX_FD is just an arbitrary
constant and it should be clear that its value is chosen in net/scm.h
and not actually derived from
I'd actually prefer this as part of the remove OPEN_MAX patch.
Ok. (But now you're going to argue with me about remove OPEN_MAX,
and you haven't said you have any problem with changing SCM_MAX_FD,
so why make it wait?)
That said, it actually worries me that you should call _SC_OPEN_MAX.
On Tue, 13 Mar 2007, Roland McGrath wrote:
Ok, fine. But PATH_MAX is a real constant that has some meaning in the
kernel. It's perfectly correct to use PATH_MAX as a constant on a system
like Linux that defines it and means what it says. Conversely, OPEN_MAX
has no useful relationship
This is an experimental to the iproute2 command set.
The version number includes the kernel version to denote what features are
supported. The same source should build on older systems, but obviously the
newer kernel features won't be available. As much as possible, this package
tries to be
On 12/03/07, Tejun Heo [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
On Tue, 13 Mar 2007 04:03:00 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
1. the controller has IRQ stuck high (infrequent but possible)
2. the IRQ is already requested by another device
3. the
63 matches
Mail list logo
