Hello.
I think the IETF community is reaching consensus on deprecation of
RH0 (Routing Header Type 0). RH0 is now handled as unknown RH type,
e.g, accept it if segleft == 0, or send ICMPv6 Parameter Problem to
the sender.
[PATCH 1/3] [IPV6]: Restore semantics of Routing Header processing.
The fix for emerging security threat was overkill and it broke
basic semantic of IPv6 routing header processing. We should assume
RT0 (or even RT2, depends on configuration) as unknown RH type so
that we
- silently ignore the routing header if segleft == 0
- send ICMPv6 Parameter Problem message
Based on draft-ietf-ipv6-deprecate-rh0-00.txt.
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
---
Documentation/networking/ip-sysctl.txt |3 +-
include/linux/ipv6.h |4 +-
net/ipv6/datagram.c|3 +-
net/ipv6/exthdrs.c |
Because reversing RH0 is no longer supported by deprecation
of RH0, let's make IPV6_{RECV,2292}RTHDR boolean options.
Boolean are more appropriate from standard POV.
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
---
include/linux/ipv6.h |4 ++--
net/ipv6/ipv6_sockglue.c |8
From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 15:02:00 +0900 (JST)
I think the IETF community is reaching consensus on deprecation of
RH0 (Routing Header Type 0). RH0 is now handled as unknown RH type,
e.g, accept it if segleft == 0, or send ICMPv6 Parameter Problem
In article [EMAIL PROTECTED] (at Sun, 17 Jun 2007 23:17:49 -0700 (PDT)),
David Miller [EMAIL PROTECTED] says:
[PATCH 1/3] [IPV6]: Restore semantics of Routing Header processing.
[PATCH 2/3] [IPV6]: Do not send RH0 anymore.
[PATCH 3/3] [IPV6]: Make IPV6_{RECV,2292}RTHDR boolean options.
Ping Dave,
Since there doesn't seem to be any new ideas forthcoming, can we
please decide on either one of my two sumbitted patches?
Thanks,
Miklos
[CC'd Al Viro and Alan Cox, restored patch]
There are races involving the garbage collector, that can throw away
perfectly good packets
From: Miklos Szeredi [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 09:49:32 +0200
Ping Dave,
Since there doesn't seem to be any new ideas forthcoming, can we
please decide on either one of my two sumbitted patches?
You just need to be patient, we can't just put a bad patch
in because a better
From: Miklos Szeredi [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 09:49:32 +0200
Ping Dave,
Since there doesn't seem to be any new ideas forthcoming, can we
please decide on either one of my two sumbitted patches?
You just need to be patient, we can't just put a bad patch
in because a
On Mon, 2007-06-18 at 10:08 +0800, Zhu Yi wrote:
OK. This is the key of the discussion.
I agree.
Do we take wpa_supplicant the
only implementation of userspace MLME or even decision making (ie. DLS
config) daemon?
I think it's a combination of these facts. I don't think DLS decision
From: Miklos Szeredi [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 10:20:23 +0200
And is anyone working on a better patch?
I have no idea.
Those patches aren't bad in the correctness sense. So IMO any one
of them is better, than having that bug in there.
You're adding a very serious performance
And is anyone working on a better patch?
I have no idea.
Those patches aren't bad in the correctness sense. So IMO any one
of them is better, than having that bug in there.
You're adding a very serious performance regression, which is
about as bad as the bug itself.
No,
From: Miklos Szeredi [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 11:29:52 +0200
And is anyone working on a better patch?
I have no idea.
Those patches aren't bad in the correctness sense. So IMO any one
of them is better, than having that bug in there.
You're adding a very
And is anyone working on a better patch?
I have no idea.
Those patches aren't bad in the correctness sense. So IMO any one
of them is better, than having that bug in there.
You're adding a very serious performance regression, which is
about as bad as the bug
From: Miklos Szeredi [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 11:44:07 +0200
Secondarily, this bug has been around for years and nobody noticed.
The world will not explode if this bug takes a few more days or
even a week to work out. Let's do it right instead of ramming
arbitrary turds
Secondarily, this bug has been around for years and nobody noticed.
The world will not explode if this bug takes a few more days or
even a week to work out. Let's do it right instead of ramming
arbitrary turds into the kernel.
Fine, but just wishing a bug to get fixed won't
From: Miklos Szeredi [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 11:55:19 +0200
It's doing trylocks and releasing all those locks within the same spin
locked region, how the f**k can that deadlock?
The case I'm very concerned about is the interactions of your
new code with the
* Miklos Szeredi [EMAIL PROTECTED] 2007-06-18 11:44
Garbage collection only ever happens, if the app is sending AF_UNIX
sockets over AF_UNIX sockets. Which is a rather rare case. And which
is basically why this bug went unnoticed for so long.
So my second patch only affects the performance
* Miklos Szeredi [EMAIL PROTECTED] 2007-06-18 11:44
Garbage collection only ever happens, if the app is sending AF_UNIX
sockets over AF_UNIX sockets. Which is a rather rare case. And which
is basically why this bug went unnoticed for so long.
So my second patch only affects the
* Thomas Graf [EMAIL PROTECTED] 2007-06-18 12:32
* Miklos Szeredi [EMAIL PROTECTED] 2007-06-18 11:44
Garbage collection only ever happens, if the app is sending AF_UNIX
sockets over AF_UNIX sockets. Which is a rather rare case. And which
is basically why this bug went unnoticed for so
* Miklos Szeredi [EMAIL PROTECTED] 2007-06-18 12:39
You are wrong. Look in unix_release_sock():
if (atomic_read(unix_tot_inflight))
unix_gc(); /* Garbage collect fds */
unix_tot_inflight is the number of AF_UNIX sockets currently being
transferred over
* Thomas Graf [EMAIL PROTECTED] 2007-06-18 12:32
* Miklos Szeredi [EMAIL PROTECTED] 2007-06-18 11:44
Garbage collection only ever happens, if the app is sending AF_UNIX
sockets over AF_UNIX sockets. Which is a rather rare case. And which
is basically why this bug went unnoticed for
From: Miklos Szeredi [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 12:47:17 +0200
but it's not as if it's really going to affect performance
in real cases.
Since these circumstances are creatable by any user, we have
to consider the cases caused by malicious entities.
-
To unsubscribe from this
but it's not as if it's really going to affect performance
in real cases.
Since these circumstances are creatable by any user, we have
to consider the cases caused by malicious entities.
OK. But then the whole gc thing is already broken, since a user can
DoS socket creation/destruction.
On 16-06-2007 23:35, Marcin .lusarz wrote:
hi
after upgrading kernel from 2.6.20 to 2.6.21.3 i'm experiencing really
strange problem - my _both_ network cards dies after random uptime -
sometimes it's a few minutes, sometimes hours, sometimes it does not
happen for a couple of days...
today
From: Miklos Szeredi [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 12:55:24 +0200
I'm all for fixing this gc mess that we have now. But please don't
expect me to be the one who's doing it.
Don't worry, I only expect you to make the situation worse :-)
-
To unsubscribe from this list: send the line
I'm all for fixing this gc mess that we have now. But please don't
expect me to be the one who's doing it.
Don't worry, I only expect you to make the situation worse :-)
That's real nice. Looks like finding and fixing bugs in not
appreciated in the networking subsystem :-/
Miklos
-
To
From: David Miller [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 04:02:53 -0700 (PDT)
From: Miklos Szeredi [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 12:55:24 +0200
I'm all for fixing this gc mess that we have now. But please don't
expect me to be the one who's doing it.
Don't worry, I only
Adrian Bunk [EMAIL PROTECTED] wrote:
This patch fixes a NULL dereference spotted by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: David Howells [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
Adrian Bunk [EMAIL PROTECTED] wrote:
This patch removes dead code spotted by the Coverity checker.
This is the wrong solution. 'copied' should be updated.
David
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info
No, correctness always trumps performance. Lost packets on an AF_UNIX
socket are _unexceptable_, and this is definitely not a theoretical
problem.
If its so unacceptable why has nobody noticed until now - its a bug
clearly, it needs fixing clearly, but unless you can produce some kind of
On Jun 18 2007 12:47, Alan Cox wrote:
Do you want me to send the patch to Andrew instead? His attitude
towards bugfixes is rather better ;)
And it'll get NAKked and binned. DaveM is (as happens sometimes ;)) right
to insist on the code being clean and efficient.
Or see RFC 1925 number 7a.
I'm all for fixing this gc mess that we have now. But please don't
expect me to be the one who's doing it.
Don't worry, I only expect you to make the situation worse :-)
In any event, I'll try to find some time to look more at your patch.
But just like you don't want to be
Return the number of bytes buffered in rxrpc_send_data().
Signed-off-by: David Howells [EMAIL PROTECTED]
---
net/rxrpc/ar-output.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/rxrpc/ar-output.c b/net/rxrpc/ar-output.c
index 591c442..cc9102c 100644
---
On Mon, 18 Jun 2007 12:43:40 +0200
Thomas Graf [EMAIL PROTECTED] wrote:
* Miklos Szeredi [EMAIL PROTECTED] 2007-06-18 12:39
You are wrong. Look in unix_release_sock():
if (atomic_read(unix_tot_inflight))
unix_gc(); /* Garbage collect fds */
No, correctness always trumps performance. Lost packets on an AF_UNIX
socket are _unexceptable_, and this is definitely not a theoretical
problem.
If its so unacceptable why has nobody noticed until now - its a bug
clearly, it needs fixing clearly, but unless you can produce some kind
Is there any way to print the addresses the notifier is calling
to try and release net device references? I see:
net/core/dev/c::netdev_wait_allrefs():
while (atomic_read(dev-refcnt) != 0) {
if (time_after(jiffies, rebroadcast_time + 1 * HZ)) {
On Fri, 2007-15-06 at 09:01 +0800, Zhang Rui wrote:
I dont have much time to look at your code given travel, but did you
try to use your group id instead of the controller's?
i.e:
rtnl_open_byproto(rth, nl_mgrp(mydiscoveredacpiid), NETLINK_GENERIC)
Yes. It doesn't work if I use my
On Mon, 18 Jun 2007 13:08:49 +0200
Jarek Poplawski [EMAIL PROTECTED] wrote:
On 16-06-2007 23:35, Marcin .lusarz wrote:
hi
after upgrading kernel from 2.6.20 to 2.6.21.3 i'm experiencing really
strange problem - my _both_ network cards dies after random uptime -
sometimes it's a few
On Fri, Jun 15, 2007 at 01:33:14AM +1000, David Gundersen wrote:
In the mean-time I'll attach my patch for the r8168-8.001.00 realtek
driver here in case anybody else wants to have a play with it and see if
it helps them out.
Out of curiousity, does it work if you just do a single read (ie
Hello Yi,
On Mon, 2007-18-06 at 09:18 +0800, Zhu Yi wrote:
Would you respond the question I asked early,
I thought i did respond to all questions you asked but some may have
been lost in the noise.
in your model how to
define the queue wakeup strategy in the driver to deal with the PHL
On Mon, 18 Jun 2007 10:56:06 -0400
Chuck Ebbert [EMAIL PROTECTED] wrote:
Is there any way to print the addresses the notifier is calling
to try and release net device references? I see:
net/core/dev/c::netdev_wait_allrefs():
while (atomic_read(dev-refcnt) != 0) {
On Mon, 18 Jun 2007 10:56:06 -0400 Chuck Ebbert [EMAIL PROTECTED] wrote:
Is there any way to print the addresses the notifier is calling
to try and release net device references? I see:
net/core/dev/c::netdev_wait_allrefs():
while (atomic_read(dev-refcnt) != 0) {
On Fri, 2007-06-15 at 14:03 -0400, Zhu Han wrote:
On 6/15/07, Kieran Mansley [EMAIL PROTECTED] wrote:
The lock protects the use_count variable. The use_count variable
prevents the plugin module unloading while it is being used. I couldn't
just use the lock to prevent the module
[XFRM]: Fix MTU calculation for non-ESP SAs
My IPsec MTU optimization patch introduced a regression in MTU calculation
for non-ESP SAs, the SA's header_len needs to be subtracted from the MTU if
the transform doesn't provide a -get_mtu() function.
Reported-and-tested-by: Marco Berizzi [EMAIL
-- Forwarded message --
Date: Mon, 18 Jun 2007 12:05:49 -0400
From: Jeff Dike [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Guido Guenther [EMAIL PROTECTED], LKML [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: [PATCH] Allow group ownership of TUN/TAP devices
I recieved from Guido
On Sun, 17 Jun 2007 16:24:00 +0200
Michal Piotrowski [EMAIL PROTECTED] wrote:
Hi all,
Here is a list of some known regressions in 2.6.22-rc5
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Memory management
I get this crash running the chelsio cxgb3 module on 2.6.22-rc5. This
is regression. I believe Divy from Chelsio has already posted a fix for
this. This needs to be in 2.6.22...
Jeff do you have this fix queued for 2.6.22?
I think Divy's patches are here:
-Original Message-
From: Krishna Kumar [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 17, 2007 9:51 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Waskiewicz
Jr, Peter P; [EMAIL PROTECTED]; [EMAIL PROTECTED]; netdev@vger.kernel.org
Subject: [PATCH 1/2 - rev2]
Herbert Xu wrote:
On Fri, Jun 15, 2007 at 03:14:57PM -0700, David Miller wrote:
No, the questions should really be:
1. Is IPV6 supported over this media type.
yes: got to 2
no: stop
2. Is the device MTU = IPV6_MIN_MTU
yes: continue
no: stop
Autoconfiguration is a
YOSHIFUJI Hideaki / 吉藤英明 wrote:
IPSTATS_MIB_INHDRERRORS);
@@ -465,6 +440,8 @@ looped_back:
break;
#ifdef CONFIG_IPV6_MIP6
case IPV6_SRCRT_TYPE_2:
+ if (accept_source_route 0)
+ goto unknown_rh;
This patch is to support the new sch_rr (round-robin) qdisc being proposed
in NET for multiqueue network device support in the Linux network stack.
It uses q_prio.c as the template, since the qdiscs are nearly identical,
outside of the -dequeue() routine.
I'm soliciting feedback for a 2.6.23
Add tc support for the sch_rr qdisc. This qdisc supports multiple queues
on hardware. The syntax for sch_rr is the same as sch_prio.
Signed-off-by: Peter P Waskiewicz Jr [EMAIL PROTECTED]
---
include/linux/pkt_sched.h | 11
tc/Makefile |1
tc/q_rr.c
Please consider these patches for 2.6.23 inclusion.
This patchset is an updated version of previous multiqueue network device
support patches. The general approach of introducing a new API for multiqueue
network devices to register with the stack has remained. The changes include
adding a
Add the new sch_rr qdisc for multiqueue network device support.
Allow sch_prio to be compiled with or without multiqueue hardware
support.
Signed-off-by: Peter P Waskiewicz Jr [EMAIL PROTECTED]
---
include/linux/pkt_sched.h | 11 +
net/sched/Kconfig | 22 ++
net/sched/Makefile
Add a brief howto to Documentation/networking for multiqueue. It
explains how to use the multiqueue API in a driver to support
multiqueue paths from the stack, as well as the qdiscs to use for
feeding a multiqueue device.
Signed-off-by: Peter P Waskiewicz Jr [EMAIL PROTECTED]
---
Add the multiqueue hardware device support API to the core network
stack. Allow drivers to allocate multiple queues and manage them
at the netdev level if they choose to do so.
Signed-off-by: Peter P Waskiewicz Jr [EMAIL PROTECTED]
---
include/linux/etherdevice.h |3 +-
PJ Waskiewicz wrote:
diff --git a/net/sched/sch_prio.c b/net/sched/sch_prio.c
index 6d7542c..44ecdc6 100644
--- a/net/sched/sch_prio.c
+++ b/net/sched/sch_prio.c
}
+#ifdef CONFIG_NET_SCH_PRIO_MQ
+ /* setup queue to band mapping */
+ if (q-bands
PJ Waskiewicz wrote:
Add the multiqueue hardware device support API to the core network
stack. Allow drivers to allocate multiple queues and manage them
at the netdev level if they choose to do so.
Should be 2/3 and qdisc changes should be 3/3. Well actually the qdisc
sch_generic changes
Steve Wise wrote:
I get this crash running the chelsio cxgb3 module on 2.6.22-rc5. This
is regression. I believe Divy from Chelsio has already posted a fix for
this. This needs to be in 2.6.22...
Jeff do you have this fix queued for 2.6.22?
I think Divy's patches are here:
sky2 breaks reproducably in 2.6.22-rc5 when setting the interface
down and up again. Packets are not received on the other side,
after a short time tcpdump (on the sky2 side) shows
use-after-free patterns:
IP6 (hlim 255, next-header: ICMPv6 (58), length: 16)
fe80::215:f2ff:fe24:91f8 ff02::2:
On Mon, 18 Jun 2007 21:49:49 +0200
Patrick McHardy [EMAIL PROTECTED] wrote:
sky2 breaks reproducably in 2.6.22-rc5 when setting the interface
down and up again. Packets are not received on the other side,
after a short time tcpdump (on the sky2 side) shows
use-after-free patterns:
Haven't
Stephen Hemminger wrote:
On Mon, 18 Jun 2007 21:49:49 +0200
Patrick McHardy [EMAIL PROTECTED] wrote:
sky2 breaks reproducably in 2.6.22-rc5 when setting the interface
down and up again. Packets are not received on the other side,
after a short time tcpdump (on the sky2 side) shows
Does this fix it? It was possible for the PHY interrupt to race
while bringing link up.
--- a/drivers/net/sky2.c2007-06-18 12:56:29.0 -0700
+++ b/drivers/net/sky2.c2007-06-18 13:02:11.0 -0700
@@ -652,7 +652,6 @@ static void sky2_wol_init(struct sky2_po
static
Stephen Hemminger wrote:
Does this fix it? It was possible for the PHY interrupt to race
while bringing link up.
No, both problems are still present.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Mon, 18 Jun 2007 22:13:50 +0200
Patrick McHardy [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
Does this fix it? It was possible for the PHY interrupt to race
while bringing link up.
No, both problems are still present.
What hardware. Could you load with messages max: modprobe
PJ Waskiewicz wrote:
Add the multiqueue hardware device support API to the core network
stack. Allow drivers to allocate multiple queues and
manage them at
the netdev level if they choose to do so.
Should be 2/3 and qdisc changes should be 3/3. Well actually
the qdisc
Waskiewicz Jr, Peter P wrote:
/* Functions used for multicast support */ diff --git
a/include/linux/skbuff.h b/include/linux/skbuff.h index
e7367c7..8bcd870 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -215,6 +215,7 @@ typedef unsigned char *sk_buff_data_t;
*
PJ Waskiewicz wrote:
diff --git a/net/sched/sch_prio.c b/net/sched/sch_prio.c index
6d7542c..44ecdc6 100644
--- a/net/sched/sch_prio.c
+++ b/net/sched/sch_prio.c
}
+#ifdef CONFIG_NET_SCH_PRIO_MQ
+ /* setup queue to band mapping */
+ if (q-bands
Stephen Hemminger wrote:
On Mon, 18 Jun 2007 22:13:50 +0200
Patrick McHardy [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
Does this fix it? It was possible for the PHY interrupt to race
while bringing link up.
No, both problems are still present.
What hardware. Could you load
On Mon, 18 Jun 2007 22:43:50 +0200
Patrick McHardy [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
On Mon, 18 Jun 2007 22:13:50 +0200
Patrick McHardy [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
Does this fix it? It was possible for the PHY interrupt to race
while bringing
Waskiewicz Jr, Peter P wrote:
+band = TC_H_MIN(band) - 1;
+if (band q-bands) {
You copied an off-by-one from an old sch_prio version here.
Hmm. This is the sch_prio from the first 2.6.23-dev tree. I'll resync
and make sure it's the correct one.
Current 2.6.22-rc and net-2.6.23
Stephen Hemminger wrote:
On Mon, 18 Jun 2007 22:43:50 +0200
Patrick McHardy [EMAIL PROTECTED] wrote:
Unloading the driver (with your patch) crashed my box twice.
Was that under load or just idle?
Pretty much idle, maybe a few NTP broadcasts flying around.
I've
attached a log of loading
Hmm. This is the sch_prio from the first 2.6.23-dev tree. I'll
resync and make sure it's the correct one.
Current 2.6.22-rc and net-2.6.23 have
if (band = q-bands)
I just pulled 2.6.23 down, and see that is true. I must have had that
left over. I'll fix that.
I'm not
Waskiewicz Jr, Peter P wrote:
Nested netlink attributes, like most qdisc use, instead of
struct tc_rr_qopt (or additionally). The way you've done it
makes it hard to add further attributes later.
I'm going to need to think about this more, since I'm not immediately
getting what you're
From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= [EMAIL PROTECTED]
SACK processing code has been sort of russian roulette as no
validation of SACK blocks is previously attempted. It is not
very clear what all kinds of broken SACK blocks really mean
(e.g., one that has start and end sequence numbers
Hi,
SACK block validation to tcp-2.6 tree. Before preparing this, I rebased
tcp-2.6 to net-2.6 (not 2.6.23) because of DSACK patch in net-2.6 (some
conflicts will occur). I did some very basic testing with this. No
TCPSACKDiscards occured in it but it's kind of hard for me to fully
test the whole
From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= [EMAIL PROTECTED]
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/linux/snmp.h |1 +
net/ipv4/proc.c |1 +
net/ipv4/tcp_input.c |4 +++-
3 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/linux/snmp.h
Tim Durack [EMAIL PROTECTED] :
[snip]
Can you try 2.6.22-rc5 +
http://www.fr.zoreil.com/people/francois/misc/20070619-2.6.22-rc5-r8169-test.patch
It does not seem to work too bad here (tested with 2.6.22-rc5 + patch):
# grep bonding /etc/modprobe.conf
alias bond0 bonding
options bonding
On Mon, 2007-06-18 at 11:16 -0400, jamal wrote:
in your model how to
define the queue wakeup strategy in the driver to deal with the PHL full
situation? Consider about 1) both high prio and low prio packets could
come (you cannot predict it beforehand)
I am assuming by come you mean
On Mon, 2007-06-18 at 11:01 -0400, jamal wrote:
On Fri, 2007-15-06 at 09:01 +0800, Zhang Rui wrote:
I dont have much time to look at your code given travel, but did you
try to use your group id instead of the controller's?
i.e:
rtnl_open_byproto(rth, nl_mgrp(mydiscoveredacpiid),
From: Zhang Rui [EMAIL PROTECTED]
Export ACPI events via Generic Netlink.
An acpi_event genetlink family message is sent
when an ACPI event is generated.
Note: The behavior of how ACPI event works nowadays is not changed.
Use genetlink to export ACPI event instead of
Thanks Peter for testing out. I forgot to mention that I had also ran a 64
process
netperf (tcp udp) on 2--CPU SMP systems without any issues.
Dave, does it make sense to add this to 2.6.23 ? Herbert and Peter had
earlier reviewed
Patch 2/2 and said they were OK with it.
thanks,
- KK
[EMAIL
From: Krishna Kumar2 [EMAIL PROTECTED]
Date: Tue, 19 Jun 2007 09:05:28 +0530
Dave, does it make sense to add this to 2.6.23 ? Herbert and Peter
had earlier reviewed Patch 2/2 and said they were OK with it.
What does Jamal think of it :-)
-
To unsubscribe from this list: send the line
Hi Dave,
I have copied him in these patches, so he doesn't have to read the netdev
to get them :)
- KK
David Miller [EMAIL PROTECTED] wrote on 06/19/2007 09:28:31 AM:
From: Krishna Kumar2 [EMAIL PROTECTED]
Date: Tue, 19 Jun 2007 09:05:28 +0530
Dave, does it make sense to add this to
On Mon, Jun 18, 2007 at 08:10:00AM -0700, Stephen Hemminger wrote:
On Mon, 18 Jun 2007 13:08:49 +0200
Jarek Poplawski [EMAIL PROTECTED] wrote:
...
It looks like skge driver enables different device than probbed.
Maybe you've something old/wrong about eth0/eth1 in /etc configs?
More likely
From: Patrick McHardy [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 18:09:11 +0200
[XFRM]: Fix MTU calculation for non-ESP SAs
My IPsec MTU optimization patch introduced a regression in MTU calculation
for non-ESP SAs, the SA's header_len needs to be subtracted from the MTU if
the transform
From: James Morris [EMAIL PROTECTED]
Date: Mon, 18 Jun 2007 12:16:31 -0400 (EDT)
-- Forwarded message --
Date: Mon, 18 Jun 2007 12:05:49 -0400
From: Jeff Dike [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Guido Guenther [EMAIL PROTECTED], LKML [EMAIL PROTECTED],
[EMAIL
On Mon, Jun 18, 2007 at 08:10:00AM -0700, Stephen Hemminger wrote:
On Mon, 18 Jun 2007 13:08:49 +0200
Jarek Poplawski [EMAIL PROTECTED] wrote:
On 16-06-2007 23:35, Marcin .lusarz wrote:
hi
after upgrading kernel from 2.6.20 to 2.6.21.3 i'm experiencing really
strange problem - my
89 matches
Mail list logo
