Hello!
Seems you found a race when rmmod is done before it's fully started
Try:
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 733d86d..ac0b4b1 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -160,7 +160,7 @@
#include asm/div64.h /* do_div */
#include asm/timex.h
This patch series is a second version (see below link to V1) of the suggested
changes to the bonding driver such that it would be able to support non
ARPHRD_ETHER
netdevices for its High-Availability (active-backup) mode.
The motivation is to enable the bonding driver on its HA mode to work with
Signed-off-by: Or Gerlitz [EMAIL PROTECTED]
Index: net-2.6.20/drivers/net/bonding/bond_main.c
===
--- net-2.6.20.orig/drivers/net/bonding/bond_main.c 2006-11-30
10:54:23.0 +0200
+++
Signed-off-by: Or Gerlitz [EMAIL PROTECTED]
Index: net-2.6.20/drivers/net/bonding/bond_main.c
===
--- net-2.6.20.orig/drivers/net/bonding/bond_main.c 2006-11-30
11:53:06.0 +0200
+++
Signed-off-by: Or Gerlitz [EMAIL PROTECTED]
Index: net-2.6.20/drivers/net/bonding/bond_sysfs.c
===
--- net-2.6.20.orig/drivers/net/bonding/bond_sysfs.c2006-11-30
10:45:53.0 +0200
+++
John W. Linville wrote:
The following changes since commit 0579e303553655245e8a6616bd8b4428b07d63a2:
Linus Torvalds:
Merge branch 'for-linus' of git://git.kernel.org/.../drzeus/mmc
are found in the git repository at:
Francois Romieu wrote:
This changes the type of variable i in rtl8169_init_one()
from unsigned int to int. i is checked for 0 later,
which can never happen for unsigned. This results in broken
error handling.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Signed-off-by: Francois Romieu
tc qdisc add dev eth1 handle : ingress
tc filter add dev eth1 protocol ip parent : pref 99 basic \
flowid 1:1 action pass random determ drop 0
^
the above cause a division by zero in the kernel on the first
packet in.
Signed-off-by: Kim
Oops, it seems I missed some chunks.
New patch attached.
---
Subject: net: vm deadlock avoidance core
In order to provide robust networked block devices there must be a guarantee
of progress. That is, the block device must never stall because of (physical)
OOM, because the device itself might be
Jarek Poplawski wrote:
[NET_SCHED] sch_cbq:
[PATCH 2.6.19-rc6 with Fix endless loops set of patches]
- P. McHardy's Fix endless loops patch supplement
(cbq_graft, cbq_qlen_notify, cbq_delete, cbq_class_ops)
- deactivating of active classes when q.qlen drops to zero
(cbq_drop)
-
Jarek Poplawski wrote:
[NET_SCHED] sch_htb:
[PATCH 2.6.19-rc6 with Fix endless loops set of patches]
- turn intermediate classes into leaves again when their
last child is deleted (struct htb_class changed)
Looks good to me too, but it still seems to be missing
class level adjustment
Jarek Poplawski wrote:
On Thu, Nov 30, 2006 at 01:26:34PM +0100, Patrick McHardy wrote:
Jarek Poplawski wrote:
[NET_SCHED] sch_htb:
[PATCH 2.6.19-rc6 with Fix endless loops set of patches]
- turn intermediate classes into leaves again when their
last child is deleted (struct htb_class
The change for PMAD support introduced a bug, where the ownership of RX
descriptors was given back to the LANCE in the wrong way. Occasional
lockups would happen as a result. This is a fix for this problem.
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
Tested with the onboard LANCE
First, sorry for letting you wait so long ..
Russell Stuart wrote:
On Tue, 2006-10-24 at 18:19 +0200, Patrick McHardy wrote:
No, my patch works for qdiscs with and without RTABs, this
is where they overlap.
Could you explain how this works? I didn't see how
qdiscs that used RTAB to
On Thu, Nov 30, 2006 at 01:26:34PM +0100, Patrick McHardy wrote:
Jarek Poplawski wrote:
[NET_SCHED] sch_htb:
[PATCH 2.6.19-rc6 with Fix endless loops set of patches]
- turn intermediate classes into leaves again when their
last child is deleted (struct htb_class changed)
Looks
Nordlund Kim (Nokia-NET/Helsinki) wrote:
tc qdisc add dev eth1 handle : ingress
tc filter add dev eth1 protocol ip parent : pref 99 basic \
flowid 1:1 action pass random determ drop 0
^
the above cause a division by zero in the kernel on
The onboard LANCE of I/O ASIC systems is not a TURBOchannel device, at
least from the software point of view. Therefore it does not rely on any
kernel TURBOchannel bus services and can be supported even if support for
TURBOchannel has not been enabled in the configuration.
Signed-off-by:
Below is an example script i was using to configure bonding in my testing
Or.
--- /dev/null 2006-10-30 17:30:04.465997856 +0200
+++ bond_init_sysfs.bash2006-11-30 12:51:05.109565889 +0200
@@ -0,0 +1,25 @@
+#!/bin/bash
+
+BOND_IP=192.168.10.118
+BOND_NETMASK=255.255.255.0
+
+SLAVE_A=ib0
Or Gerlitz wrote:
Index: net-2.6.20/drivers/net/bonding/bonding.h
===
--- net-2.6.20.orig/drivers/net/bonding/bonding.h 2006-11-30
10:54:23.0 +0200
+++ net-2.6.20/drivers/net/bonding/bonding.h2006-11-30
On Thu, 30 Nov 2006, ext Patrick McHardy wrote:
I think it should reject an invalid configuration or handle
the zero case correctly by not dividing.
You are correct. Not returning -EINVAL, because someone might
want to use the value zero in some future gact_prob algorithm?
Signed-off-by: Kim
Nordlund Kim (Nokia-NET/Helsinki) wrote:
On Thu, 30 Nov 2006, ext Patrick McHardy wrote:
I think it should reject an invalid configuration or handle
the zero case correctly by not dividing.
You are correct. Not returning -EINVAL, because someone might
want to use the value zero in some
On Thursday 30 November 2006 12:20, Jeff Garzik wrote:
Francois Romieu wrote:
This changes the type of variable i in rtl8169_init_one()
from unsigned int to int. i is checked for 0 later,
which can never happen for unsigned. This results in broken
error handling.
Signed-off-by:
The main purpose of this patch is to clean-up the bonding code so that
several important operations are not done in the incorrect (softirq)
context. Whenever a kernel is compiled with CONFIG_DEBUG_SPINLOCK_SLEEP
all sorts of backtraces are spewed to the log since might_sleep will
kindly remind us
Daniel Lezcano wrote:
Brian Haley wrote:
Eric W. Biederman wrote:
I think for cases across network socket namespaces it should
be a matter for the rules, to decide if the connection should
happen and what error code to return if the connection does not
happen.
There is a potential in this
Yukon hardware will lose multicast membership data and promiscuous mode
information if a link is disconnected and reconnected without taking the
interface down. A call to yukon_reset in yukon_link_down will clear the
hardware's multicast list, so it needs to be added back on link_up.
It does
Vlad Yasevich wrote:
Daniel Lezcano wrote:
Brian Haley wrote:
Eric W. Biederman wrote:
I think for cases across network socket namespaces it should
be a matter for the rules, to decide if the connection should
happen and what error code to return if the connection does not
happen.
There is a
On Thu, Nov 30, 2006 at 05:38:16PM +0100, Daniel Lezcano wrote:
Vlad Yasevich wrote:
Daniel Lezcano wrote:
Brian Haley wrote:
Eric W. Biederman wrote:
I think for cases across network socket namespaces it should
be a matter for the rules, to decide if the connection should
happen and
Robert Olsson wrote:
Hello!
Seems you found a race when rmmod is done before it's fully started
Try:
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 733d86d..ac0b4b1 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -160,7 +160,7 @@
#include asm/div64.h /* do_div
On Mon, 23 Oct 2006, Maciej W. Rozycki wrote:
I'm not too enthusiastic about requiring the ethernet drivers to call
phy_disconnect in a separate thread after close is called. Assuming
there's
not some sort of squash work queue function that can be invoked with
rtnl_lock held, I think
The first patch sent by Amit on 29 Nov applied, but the following three
patches did not apply to Jeff's #upstream tree. Here are the corrected
2nd, 3rd, and 4th patches, with a repeat of the 1st for completeness.
There is a 5th patch which fixes a bug caused by casting a 16-bit
variable into a
Signed-off-by: Amit S. Kale [EMAIL PROTECTED]
diff -Nupr netdev-2.6/drivers/net/netxen.orig/netxen_nic_main.c
netdev-2.6/drivers/net/netxen/netxen_nic_main.c
--- netdev-2.6/drivers/net/netxen.orig/netxen_nic_main.c2006-11-29
12:13:58.0 -0800
+++
NetXen: 1G/10G Ethernet Driver updates
- These fixes take care of driver on machines with 4G memory
- Driver cleanup
Signed-off-by: Amit S. Kale [EMAIL PROTECTED]
Signed-off-by: Don Fry [EMAIL PROTECTED]
diff -Nupr netdev-2.6/drivers/net/netxen.two/netxen_nic_ethtool.c
Fix for pointer casting error.
Signed-off-by: Don Fry [EMAIL PROTECTED]
diff -Nupr netdev-2.6/drivers/net/netxen.four/netxen_nic_hw.c
netdev-2.6/drivers/net/netxen/netxen_nic_hw.c
--- netdev-2.6/drivers/net/netxen.four/netxen_nic_hw.c 2006-11-30
10:06:24.0 -0800
+++
On Thu, 30 Nov 2006, Peter Zijlstra wrote:
+unsigned int kmem_cache_objs_to_pages(struct kmem_cache *cachep, int nr)
+{
+ return ((nr + cachep-num - 1) / cachep-num) cachep-gfporder;
cachep-num refers to the number of objects in a slab of gfporder.
thus
return (nr + cachep-num - 1) /
The NetXen patches fix many problems in the current #upstream version of
the driver. It has warts and probably lots of bugs still, but it is
better than what is queued for mainline inclusion at this time. Please
apply to 2.6.20.
--
Don Fry
[EMAIL PROTECTED]
-
To unsubscribe from this list:
On Thu, 2006-11-30 at 10:55 -0800, Christoph Lameter wrote:
On Thu, 30 Nov 2006, Peter Zijlstra wrote:
+unsigned int kmem_cache_objs_to_pages(struct kmem_cache *cachep, int nr)
+{
+ return ((nr + cachep-num - 1) / cachep-num) cachep-gfporder;
cachep-num refers to the number of
On Thu, 30 Nov 2006, Peter Zijlstra wrote:
Right, perhaps my bad in wording the intent; the needed information is
how many more pages would I need to grow the slab with in order to store
so many new object.
Would you not have to take objects currently available in
caches into account? If you
On Thu, 2006-11-30 at 10:52 -0800, Christoph Lameter wrote:
On Thu, 30 Nov 2006, Peter Zijlstra wrote:
The slab has some unfairness wrt gfp flags; when the slab is grown the gfp
flags are used to allocate more memory, however when there is slab space
available, gfp flags are ignored.
On Thu, 2006-11-30 at 11:06 -0800, Christoph Lameter wrote:
On Thu, 30 Nov 2006, Peter Zijlstra wrote:
Right, perhaps my bad in wording the intent; the needed information is
how many more pages would I need to grow the slab with in order to store
so many new object.
Would you not have
On Thu, 2006-11-30 at 10:52 -0800, Christoph Lameter wrote:
I would think that one would need a rank with each cached object and
free slab in order to do this the right way.
Allocation hardness is a temporal attribute, ie. it changes over time.
Hence I do it per slab.
-
To unsubscribe from
On Thu, 30 Nov 2006, Peter Zijlstra wrote:
No, the forced allocation is to test the allocation hardness at that
point in time. I could not think of another way to test that than to
actually to an allocation.
Typically we do this by checking the number of free pages in a zone
compared to the
On Thu, 30 Nov 2006, Peter Zijlstra wrote:
On Thu, 2006-11-30 at 10:52 -0800, Christoph Lameter wrote:
I would think that one would need a rank with each cached object and
free slab in order to do this the right way.
Allocation hardness is a temporal attribute, ie. it changes over
Andy Gospodarek [EMAIL PROTECTED] wrote:
The main purpose of this patch is to clean-up the bonding code so that
several important operations are not done in the incorrect (softirq)
context. Whenever a kernel is compiled with CONFIG_DEBUG_SPINLOCK_SLEEP
all sorts of backtraces are spewed to the
On Thu, 2006-11-30 at 11:33 -0800, Christoph Lameter wrote:
On Thu, 30 Nov 2006, Peter Zijlstra wrote:
No, the forced allocation is to test the allocation hardness at that
point in time. I could not think of another way to test that than to
actually to an allocation.
Typically we do
On Thu, 2006-11-30 at 11:37 -0800, Christoph Lameter wrote:
On Thu, 30 Nov 2006, Peter Zijlstra wrote:
On Thu, 2006-11-30 at 10:52 -0800, Christoph Lameter wrote:
I would think that one would need a rank with each cached object and
free slab in order to do this the right way.
On Thu, 30 Nov 2006, Peter Zijlstra wrote:
Sure, but there is nothing wrong with using a slab page with a lower
allocation rank when there is memory aplenty.
What does a slab page with a lower allocation rank mean? Slab pages have
no allocation ranks that I am aware of.
-
To unsubscribe from
On 11/30/06, Jay Vosburgh [EMAIL PROTECTED] wrote:
Andy Gospodarek [EMAIL PROTECTED] wrote:
The main purpose of this patch is to clean-up the bonding code so that
several important operations are not done in the incorrect (softirq)
context. Whenever a kernel is compiled with
On Thu, 2006-11-30 at 12:11 -0800, Christoph Lameter wrote:
On Thu, 30 Nov 2006, Peter Zijlstra wrote:
Sure, but there is nothing wrong with using a slab page with a lower
allocation rank when there is memory aplenty.
What does a slab page with a lower allocation rank mean? Slab pages
On Thu, 30 Nov 2006, Peter Zijlstra wrote:
Sure, but there is nothing wrong with using a slab page with a lower
allocation rank when there is memory aplenty.
What does a slab page with a lower allocation rank mean? Slab pages have
no allocation ranks that I am aware of.
I just added
On Thursday 30 November 2006 03:15, David Miller wrote:
From: Phil Oester [EMAIL PROTECTED]
Date: Wed, 29 Nov 2006 17:49:04 -0800
Getting an oops on boot here, caused by commit
e81c73596704793e73e6dbb478f41686f15a4b34 titled
[NET]: Fix MAX_HEADER setting.
Reverting that patch fixes
On Wed, Nov 29, 2006 at 04:16:06PM +0100, Krzysztof Halasa wrote:
Krzysztof Halasa [EMAIL PROTECTED] writes:
I wound't care less btw.
s/wound/couldn/, eh those foreign languages...
So, you say, you don't care about David Miller's credits?
It isn't nice. He could be very disappointed...
On Wed, Nov 29, 2006 at 07:56:58PM -0600, Wenji Wu wrote:
Yes, when CONFIG_PREEMPT is disabled, the problem won't happen. That is why
I put for 2.6 desktop, low-latency desktop in the uploaded paper. This
problem happens in the 2.6 Desktop and Low-latency Desktop.
CONFIG_PREEMPT is only for
Hello,
This patch adds missing brackets.
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
include/linux/mv643xx.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.19-rc6-mm2-a/include/linux/mv643xx.h 2006-11-16
05:03:40.0 +0100
+++
On Thu, Nov 30, 2006 at 08:35:04AM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
what was observed here were the effects of completely throttling TCP
processing for a given socket. I think such throttling can in fact be
desirable: there is a /reason/ why the process context was preempted: in
On Thu, Nov 30, 2006 at 10:35:37AM +0100, Mariusz Kozlowski wrote:
Hello,
This patch adds missing brackets.
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
include/linux/mv643xx.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
---
Evgeniy Polyakov wrote:
On Thu, Nov 30, 2006 at 08:35:04AM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
Doesn't the provided solution is just a in-kernel variant of the
SCHED_FIFO set from userspace? Why kernel should be able to mark some
users as having higher priority?
What if workload of
On Thu, Nov 30, 2006 at 09:07:42PM +1100, Nick Piggin ([EMAIL PROTECTED]) wrote:
Doesn't the provided solution is just a in-kernel variant of the
SCHED_FIFO set from userspace? Why kernel should be able to mark some
users as having higher priority?
What if workload of the system is targeted to
+#define MV643XX_ETH_DEFAULT_RX_UDP_QUEUE_4 ((121))
Mariusz, please remove the extra parenthesis instead of adding
an extra one, like:
#define MV643XX_ETH_DEFAULT_RX_UDP_QUEUE_4 (121)
and resubmit.
Sure. Here it goes. Second try:
This patch fixes some mv643xx macros.
* Evgeniy Polyakov [EMAIL PROTECTED] wrote:
David's line of thinking for a solution sounds better to me. This
patch does not prevent the process from being preempted (for
potentially a long time), by any means.
It steals timeslices from other processes to complete tcp_recvmsg()
From: Mariusz Kozlowski [EMAIL PROTECTED]
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
---
include/linux/mv643xx.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.19-rc6-mm2-a/include/linux/mv643xx.h
We can make explicitl preemption checks in the main loop of
tcp_recvmsg(), and release the socket and run the backlog if
need_resched() is TRUE.
This is the simplest and most elegant solution to this problem.
I am not sure whether this approach will work. How can you make the explicit
On Thu, 2006-11-30 at 09:33 +, Christoph Hellwig wrote:
On Wed, Nov 29, 2006 at 07:56:58PM -0600, Wenji Wu wrote:
Yes, when CONFIG_PREEMPT is disabled, the problem won't happen. That is
why I put for 2.6 desktop, low-latency desktop in the uploaded paper.
This problem happens in the
The solution is really simple and needs no kernel change at all: if you
want the TCP receiver to get a larger share of timeslices then either
renice it to -20 or renice the other tasks to +19.
Simply give a larger share of timeslices to the TCP receiver won't solve the
problem. No matter what
Signal notifications.
This type of notifications allows to deliver signals through kevent queue.
One can find example application signal.c on project homepage.
If KEVENT_SIGNAL_NOMASK bit is set in raw_u64 id then signal will be
delivered only through queue, otherwise both delivery types are
Pipe notifications.
diff --git a/fs/pipe.c b/fs/pipe.c
index f3b6f71..aeaee9c 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -16,6 +16,7 @@
#include linux/uio.h
#include linux/highmem.h
#include linux/pagemap.h
+#include linux/kevent.h
#include asm/uaccess.h
#include asm/ioctls.h
@@ -312,6
Socket notifications.
This patch includes socket send/recv/accept notifications.
Using trivial web server based on kevent and this features
instead of epoll it's performance increased more than noticebly.
More details about various benchmarks and server itself
(evserver_kevent.c) can be found
Timer notifications.
Timer notifications can be used for fine grained per-process time
management, since interval timers are very inconvenient to use,
and they are limited.
This subsystem uses high-resolution timers.
id.raw[0] is used as number of seconds
id.raw[1] is used as number of
Kevent posix timer notifications.
Simple extensions to POSIX timers which allows
to deliver notification of the timer expiration
through kevent queue.
Example application posix_timer.c can be found
in archive on project homepage.
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git
Generic event handling mechanism.
Kevent is a generic subsytem which allows to handle event notifications.
It supports both level and edge triggered events. It is similar to
poll/epoll in some cases, but it is more scalable, it is faster and
allows to work with essentially eny kind of events.
Description.
diff --git a/Documentation/kevent.txt b/Documentation/kevent.txt
new file mode 100644
index 000..2e03a3f
--- /dev/null
+++ b/Documentation/kevent.txt
@@ -0,0 +1,240 @@
+Description.
+
+int kevent_init(struct kevent_ring *ring, unsigned int ring_size,
+ unsigned int
poll/select() notifications.
This patch includes generic poll/select notifications.
kevent_poll works simialr to epoll and has the same issues (callback
is invoked not from internal state machine of the caller, but through
process awake, a lot of allocations and so on).
Signed-off-by: Evgeniy
sorry for the delay, your mail got marked as spam. In the future
please copy networking issues to netdev@vger.kernel.org, and be sure
to copy the maintainers of the driver you're having problems with
(they are in the MAINTAINERS file)
On 11/22/06, Amin Azez [EMAIL PROTECTED] wrote:
I notice a
From: Wenji Wu [EMAIL PROTECTED]
Date: Thu, 30 Nov 2006 10:08:22 -0600
If the higher prioirty processes become runnable (e.g., interactive
process), you better yield the CPU, instead of continuing this process. If
it is the case that the process within tcp_recvmsg() is expriring, then, you
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Thu, 30 Nov 2006 13:22:06 +0300
It steals timeslices from other processes to complete tcp_recvmsg()
task, and only when it does it for too long, it will be preempted.
Processing backlog queue on behalf of need_resched() will break
fairness too -
From: Ingo Molnar [EMAIL PROTECTED]
Date: Thu, 30 Nov 2006 11:32:40 +0100
Note that even without the change the TCP receiving task is already
getting a disproportionate share of cycles due to softirq processing!
Under a load of 10.0 it went from 500 mbits to 74 mbits, while the
'fair'
* Wenji Wu [EMAIL PROTECTED] wrote:
The solution is really simple and needs no kernel change at all: if
you want the TCP receiver to get a larger share of timeslices then
either renice it to -20 or renice the other tasks to +19.
Simply give a larger share of timeslices to the TCP
On Thursday, 30 November 2006 02:04, Rafael J. Wysocki wrote:
On Thursday, 30 November 2006 00:26, Andrew Morton wrote:
On Thu, 30 Nov 2006 00:08:21 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Wednesday, 29 November 2006 22:31, Rafael J. Wysocki wrote:
On Wednesday, 29
* David Miller [EMAIL PROTECTED] wrote:
I want to point out something which is slightly misleading about this
kind of analysis.
Your disk I/O speed doesn't go down by a factor of 10 just because 9
other non disk I/O tasks are running, yet for TCP that's seemingly OK
:-)
disk I/O is
From: Ingo Molnar [EMAIL PROTECTED]
Date: Thu, 30 Nov 2006 21:30:26 +0100
disk I/O is typically not CPU bound, and i believe these TCP tests /are/
CPU-bound. Otherwise there would be no expiry of the timeslice to begin
with and the TCP receiver task would always be boosted to 'interactive'
It steals timeslices from other processes to complete tcp_recvmsg()
task, and only when it does it for too long, it will be preempted.
Processing backlog queue on behalf of need_resched() will break
fairness too - processing itself can take a lot of time, so process
can be scheduled away in
* David Miller [EMAIL PROTECTED] wrote:
disk I/O is typically not CPU bound, and i believe these TCP tests
/are/ CPU-bound. Otherwise there would be no expiry of the timeslice
to begin with and the TCP receiver task would always be boosted to
'interactive' status by the scheduler and
if you still have the test-setup, could you nevertheless try setting the
priority of the receiving TCP task to nice -20 and see what kind of
performance you get?
A process with nice of -20 can easily get the interactivity status. When it
expires, it still go back to the active array. It just
* Ingo Molnar [EMAIL PROTECTED] wrote:
[...] Instead what i'd like to see is more TCP performance (and a
nicer over-the-wire behavior - no retransmits for example) /with the
same 10% CPU time used/. Are we in rough agreement?
put in another way: i'd like to see the TCP bytes transferred
From: Ingo Molnar [EMAIL PROTECTED]
Date: Thu, 30 Nov 2006 21:49:08 +0100
So i dont support the scheme proposed here, the blatant bending of the
priority scale towards the TCP workload.
I don't support this scheme either ;-)
That's why my proposal is to find a way to allow input packet
On Thu, 30 Nov 2006 21:21:27 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On Thursday, 30 November 2006 02:04, Rafael J. Wysocki wrote:
On Thursday, 30 November 2006 00:26, Andrew Morton wrote:
On Thu, 30 Nov 2006 00:08:21 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
On
Sorry! Sign off included this time.
This patch disables auditing in ipsec when CONFIG_AUDITSYSCALL is
disabled in the kernel.
This patch also includes a bug fix for xfrm_state.c as a result of
original ipsec audit patch.
regards,
Joy
Signed-off-by: Joy Latten [EMAIL PROTECTED]
On Wed, 2006-11-29 at 19:32 -0500, James Morris wrote:
On Wed, 29 Nov 2006, James Morris wrote:
On Wed, 29 Nov 2006, Joy Latten wrote:
This patch disables auditing in ipsec when CONFIG_AUDITSYSCALL is
disabled in the kernel.
This patch also includes a bug fix for xfrm_state.c
On Thu, 30 Nov 2006, Joy Latten wrote:
I ran a stress test overnight using labeled ipsec on a patched lspp55 kernel
using racoon last week.
The additional patch to xfrm_state.c was my fault when rebasing to
2.6.19-rc6 to send upstream. I plan to run an ipv4 and ipv6 stress test
tonight
Don Fry [EMAIL PROTECTED] :
NetXen: 1G/10G Ethernet Driver updates
- Temparature monitoring and device control
- Memory footprint reduction
- Driver changes to support newer version of firmware
Signed-off-by: Amit S. Kale [EMAIL PROTECTED]
Signed-off-by: Don Fry [EMAIL
Don Fry wrote:
The NetXen patches fix many problems in the current #upstream version of
the driver. It has warts and probably lots of bugs still, but it is
better than what is queued for mainline inclusion at this time. Please
apply to 2.6.20.
Please resync with netdev#upstream, and update
From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Date: Fri, 24 Nov 2006 14:38:07 +0900
This patch adds encapsulation family.
Signed-off-by: Miika Komu [EMAIL PROTECTED]
Signed-off-by: Diego Beltrami [EMAIL PROTECTED]
Signed-off-by: Kazunori Miyazawa [EMAIL PROTECTED]
Applied to net-2.6.20,
From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Date: Fri, 24 Nov 2006 14:38:17 +0900
This patch adds netlink interface of the family
Signed-off-by: Miika Komu [EMAIL PROTECTED]
Signed-off-by: Diego Beltrami [EMAIL PROTECTED]
Signed-off-by: Kazunori Miyazawa [EMAIL PROTECTED]
Applied to
From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Date: Thu, 30 Nov 2006 10:54:26 +0900
Hello,
I found a bug in my previous patch for af_key.
The patch breaks transport mode.
This is a fixed version.
Signed-off-by: Miika Komu [EMAIL PROTECTED]
Signed-off-by: Diego Beltrami [EMAIL PROTECTED]
From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Date: Fri, 24 Nov 2006 14:38:39 +0900
What is going on here?
+ /* Without this, the atomic inc below segfaults */
+ if (encap_family == AF_INET6) {
+ rt-peer = NULL;
+
From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Date: Fri, 24 Nov 2006 14:38:52 +0900
+static inline void ip6ip_ecn_decapsulate(struct sk_buff *skb)
+{
+ if (INET_ECN_is_ce(ipv6_get_dsfield(skb-nh.ipv6h)))
+ IP_ECN_set_ce(skb-h.ipiph);
+}
+
Please fix this extra tab
e.g.
usb 1-7: rx_urb_complete() *** first fragment ***
usb 1-7: rx_urb_complete() *** second fragment ***
drivers/net/wireless/zd1211rw/zd_mac.c:1063 ASSERT
(((current_thread_info()-preempt_count) (((1UL (12))-1) ((0 +
8) + 8 VIOLATED!
[f0299448] zd_mac_rx+0x3e7/0x47a [zd1211rw]
This is needed for NetworkManager users to connect to WPA networks.
Pointed out by Matthew Campbell.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
---
zd_mac.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
Index: linux-2.6/drivers/net/wireless/zd1211rw/zd_mac.c
From: Ulrich Kunitz [EMAIL PROTECTED]
Support for multicast adresses is implemented by supporting the
set_multicast_list() function of the network device. Address
filtering is supported by a group hash table in the device.
This is based on earlier work by Benoit Papillaut. Fixes multicast packet
From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Date: Fri, 24 Nov 2006 14:39:01 +0900
This patch fixes mtu calculation of IPv4
ip_append_data should refer the mtu of dst not path.
if dst is stacked, path is the actual dst_entry in
the routing table.
therefore the mtu of path equals link mtu
From: Kazunori MIYAZAWA [EMAIL PROTECTED]
Date: Fri, 24 Nov 2006 14:39:17 +0900
ip6_append_data should refer mtu of dst
because of the same reasone of the previous patch.
Same comments of mine for ipv4 side of this change also apply here.
-
To unsubscribe from this list: send the line
1 - 100 of 119 matches
Mail list logo
