Jarek Poplawski wrote:
On Wed, Jan 16, 2008 at 06:02:00AM +0100, Patrick McHardy wrote:
...
This would need support from the qdiscs to do it properly. Looks
non-trivial for HTB/HFSC/CBQ, but the others shouldn't be that hard.
Yes. At first I've thought this would need quite a lot of work, but
Yes, thats one possibility (without the dummy device though please).
But I wonder what this would actually be useful for. I don't think
replacing the root qdisc by a different type is a common scenario,
for the same type you can simply use tc qdisc change, tc class
change and tc class
On Wed, Jan 16, 2008 at 09:05:47AM +0100, Patrick McHardy wrote:
...
Yes, thats one possibility (without the dummy device though please).
But I wonder what this would actually be useful for. I don't think
replacing the root qdisc by a different type is a common scenario,
for the same type you
Jarek Poplawski пишет:
On Wed, Jan 16, 2008 at 09:05:47AM +0100, Patrick McHardy wrote:
...
Yes, thats one possibility (without the dummy device though please).
But I wonder what this would actually be useful for. I don't think
replacing the root qdisc by a different type is a common
On Wednesday 16 January 2008, David Miller wrote:
Ok, here is the patch I'll propose to fix this. The goal is to make
it as simple as possible without regressing the thing we were trying
to fix.
Looks good to me. Tested with -rc8.
Cheers,
FJP
--
To unsubscribe from this list: send the line
applied to 2.6.24-rc7-git2
Have messages
Also have regression after apply patch.
System may do above 800mbs traffic before patch. After its exit polling
mode? (4 CPU, 1 cpu get 100% si (process ksoftirqd/0), 3 CPU is IDLE)
After patch system was go to exit polling mode at above 600mbs.
Thanks.
On Wed, Jan 16, 2008 at 11:35:35AM +0300, Badalian Vyacheslav wrote:
...
I simple recreate all rules. I change idea from do many add,change,delete
because have many kernel panics on many kernels 2.6.x
First i have panics on delete filter operation... was fix it... great..
then have panics on
With the removal the the rgmii-interface device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/rgmii.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
On Wed, Jan 16, 2008 at 10:37:10AM +0100, Stefan Roese wrote:
With the removal the the rgmii-interface device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
In fact, this patch should go in before the one changing the dts
files.
--
On Tue, 15 Jan 2008, Ritesh Kumar wrote:
Hi,
I am using linux 2.6.20 and am trying to limit the receiver window
size for a TCP connection. However, it seems that auto tuning is not
turning itself off even after I use the syscall
rwin=65536
setsockopt(sock, SOL_SOCKET, SO_RCVBUF, rwin,
On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
With the removal the the rgmii-interface device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
I need to test if it works on CAB,
In tree net-2.6.25, commit 96793b482540f3a26e2188eaf75cb56b7829d3e3
made a mistake.
In that patch, David L added a icmp_out_count() in ip_push_pending_frames(),
remove icmp_out_count() from icmp_reply(). But he forgot to remove
icmp_out_count() from icmp_send() too.
Since icmp_send and
From: Frans Pop [EMAIL PROTECTED]
Date: Wed, 16 Jan 2008 09:56:08 +0100
On Wednesday 16 January 2008, David Miller wrote:
Ok, here is the patch I'll propose to fix this. The goal is to make
it as simple as possible without regressing the thing we were trying
to fix.
Looks good to me.
http://bugzilla.kernel.org/show_bug.cgi?id=9493
The fib allows making identical routes with 'ip route replace'.
This patch makes the fib return -EEXIST if replacement would cause duplication.
Signed-off-by: Joonwoo Park [EMAIL PROTECTED]
---
net/ipv4/fib_hash.c |3 +++
1 files changed, 3
http://bugzilla.kernel.org/show_bug.cgi?id=9493
The fib allows making identical routes with 'ip route replace'.
This patch makes the fib return -EEXIST if replacement would cause duplication.
Signed-off-by: Joonwoo Park [EMAIL PROTECTED]
---
net/ipv4/fib_trie.c |3 +++
1 files changed, 3
Hello All,
I am sure that the TDM bus driver model/framework will make us put a lot
more programming effort without
any assurance of the code being accepted by the Linux community,
especially as there are many
Telephony/VoIP stack implementations in Linux such as the Sangoma
WANPIPE Kernel suite
Wang Chen [EMAIL PROTECTED] wrote:
In tree net-2.6.25, commit 96793b482540f3a26e2188eaf75cb56b7829d3e3
made a mistake.
In that patch, David L added a icmp_out_count() in ip_push_pending_frames(),
remove icmp_out_count() from icmp_reply(). But he forgot to remove
icmp_out_count() from
OK, revised with help from Herbert. Also, I have attached a test program and
a script to run it (it short-circuits two tun devices, so you can run it with
the patch applied and see big packets flowing).
This implements partial checksum and GSO support for tun/tap.
We use the virtio_net_hdr: it
The problem with introducing IFF_GSO_HDR is that it needs to set dev-features
(to enable GSO, checksumming, etc), which is supposed to be done before
register_netdevice(), ie. as part of TUNSETIFF.
Unfortunately, TUNSETIFF has always just ignored flags it doesn't understand,
so there's no good
From: Badalian Vyacheslav [EMAIL PROTECTED]
Date: Wed, 16 Jan 2008 12:02:28 +0300
Also have regression after apply patch.
BTW, if you are using the e1000e driver then this initial
patch will not work.
My more recent patch posting for this problem, will.
I include it again below for you:
From: [EMAIL PROTECTED]
Date: Wed, 16 Jan 2008 18:04:53 +0800
In SMP, if a bridge fdb is being created when another CPU at the same time
delete the bridge, this newly created fdb may incur a leakage:
netdev@vger.kernel.org (CC:'d) is the proper place to report
things like this.
'linux-net' is
From: Badalian Vyacheslav [EMAIL PROTECTED]
Date: Wed, 16 Jan 2008 12:02:28 +0300
applied to 2.6.24-rc7-git2
Have messages
Also have regression after apply patch.
System may do above 800mbs traffic before patch. After its exit polling
mode? (4 CPU, 1 cpu get 100% si (process ksoftirqd/0), 3
On 15-01-2008 07:36, Makito SHIOKAWA wrote:
Fix some RTNL lock taking:
* RTNL (mutex; may sleep) must not be taken under read_lock (spinlock; must be
atomic). However, RTNL is taken under read_lock in bond_loadbalance_arp_mon()
and bond_activebackup_arp_mon(). So change code to take RTNL
On Mon, 2008-14-01 at 20:20 -0200, Dzianis Kahanovich wrote:
jamal wrote:
[..]
Did that make sense?
After current #endif - may be.
I am afraid that would be counter to expected behavior.
Default is meant to apply when no value has been defined. Mark of 0 for
example doesnt mean default.
On Wed, Jan 16, 2008 at 12:19:51PM +0900, Makito SHIOKAWA wrote:
This patch is supposing a case that bond_mii_monitor() is invoked in
bond_open(), and after that, 0 is set to miimon via sysfs (see same place
on other monitors).
Though message in bonding_store_miimon() says miimon value
Hello,
A question about compiling as module using the 2.6.25 git tree:
I had git cloned the 2.6.25 DaveM tree.
I ran make menuconfig.
In many cases I see in the help:
To compile this code as a module, choose M here: the
module will be called ...
For example, in Packet Generator or in 802.1d
Timo,
Thanks for the effort you are putting on this.
I would just speak to the concepts instead of the code - hopefully that
would simulate a discussion (and shorten my email)
On Sun, 2008-13-01 at 14:26 +0200, Timo Teräs wrote:
Hi all,
The problem with IPsec SP/SA dumping is that they
jamal wrote:
On Sun, 2008-13-01 at 14:26 +0200, Timo Teräs wrote:
I tried to address all these problems, and added the xfrm_policy
and xfrm_state structure to a new linked list that is used solely
for dumping. This way the dumps can be done in O(n) and have an
iterator point to them. I also
On Wed, 16 Jan 2008 20:53:59 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
With the removal the the rgmii-interface device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
The two following patches do trivial changes to facilitate the
implementation of the network namespace in some protocols.
The first one pass the dst_ops as parameter to the gc functions.
The second patch just adds a netns pointer field into the dst_ops
structure.
--
--
To unsubscribe from this
The garbage collection function receive the dst_ops structure as
parameter. This is useful for the next incoming patchset because
it will need the dst_ops (there will be several instances) and
the network namespace pointer (contained in the dst_ops).
The protocols which do not take care of the
The network namespace pointer can be stored into the dst_ops structure.
This is usefull when there are multiple instances of the dst_ops for a
protocol. When there are no several instances, this field will be never
used in the protocol. So there is no impact for the protocols which do
implement
Hi,
I have posted this patch in the past with absolutely no reply.
I would appreciate some sort of feedback of the form
interested/not interested. Should I just drop it?
ethtool -S only supports devices that have custom code written to
print the stats.
A lot of drivers use struct
Herbert Xu [EMAIL PROTECTED] wrote on 01/16/2008 03:49:01 AM:
Actually having the icmp_out_count call in ip_push_pending_frames seems
inconsistent. Having it there means that we count raw socket ICMP
packets
too. But we don't do that for any other protocol, e.g., raw UDP packets
don't get
David Miller writes:
On Wednesday 16 January 2008, David Miller wrote:
Ok, here is the patch I'll propose to fix this. The goal is to make
it as simple as possible without regressing the thing we were trying
to fix.
Looks good to me. Tested with -rc8.
Thanks for
I noticed ip route list was slower than cat /proc/net/route on a machine
with a full Internet
routing table (214392 entries : Special thanks to Robert ;) )
This is similar to problem reported in commit
d8c9283089287341c85a0a69de32c2287a990e71
Fix is to avoid scanning the begining of fz_hash
Dan Nicolaescu wrote:
Hi,
I have posted this patch in the past with absolutely no reply.
I would appreciate some sort of feedback of the form
interested/not interested. Should I just drop it?
I like it, but why not offer this for all devices since they all have
these stats.
Could add
Ben Greear [EMAIL PROTECTED] writes:
Dan Nicolaescu wrote:
Hi,
I have posted this patch in the past with absolutely no reply.
I would appreciate some sort of feedback of the form interested/not
interested. Should I just drop it?
I like it, but why not offer
Dan Nicolaescu wrote:
Ben Greear [EMAIL PROTECTED] writes:
Dan Nicolaescu wrote:
Hi,
I have posted this patch in the past with absolutely no reply.
I would appreciate some sort of feedback of the form interested/not
interested. Should I just drop it?
I like
On Wed, 16 Jan 2008 05:59:21 +0100
Patrick McHardy [EMAIL PROTECTED] wrote:
Patrick McHardy wrote:
Very nice catch, that explains quite a few bug reports about
refcnt leaks. Your patch looks correct and performs the copying
in the logically correct place, it would be nicer to keep this
On Wed, 16 Jan 2008 18:04:53 +0800
[EMAIL PROTECTED] wrote:
In SMP, if a bridge fdb is being created when another CPU at the same time
delete the bridge, this newly created fdb may incur a leakage:
CPU0:
static void del_nbp(struct net_bridge_port *p)
{
/*
* CPU1 enter
On 1/16/08, Bill Fink [EMAIL PROTECTED] wrote:
On Tue, 15 Jan 2008, Ritesh Kumar wrote:
Hi,
I am using linux 2.6.20 and am trying to limit the receiver window
size for a TCP connection. However, it seems that auto tuning is not
turning itself off even after I use the syscall
Ritesh Kumar wrote:
On 1/16/08, Bill Fink [EMAIL PROTECTED] wrote:
On Tue, 15 Jan 2008, Ritesh Kumar wrote:
Hi,
I am using linux 2.6.20 and am trying to limit the receiver window
size for a TCP connection. However, it seems that auto tuning is not
turning itself off even after I use the
On Wed, Jan 16, 2008 at 07:58:36AM +0100, Jarek Poplawski wrote:
On Wed, Jan 16, 2008 at 11:17:08AM +1100, Herbert Xu wrote:
...
Well people are always going to operate on this model for commercial
reasons. FWIW I used to work for a company that stuck to a specific
version of the Linux
Dave,
One more fix for rfkill in 2.6.24...note that this branch is based
on 2.6.24-rc8.
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-davem/
---
The following changes since commit
Jeff,
A few more fixes for 2.6.24...note that this branch is based
on 2.6.24-rc8.
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
---
The following changes since commit
net/sctp/sm_statefuns.c: In function 'sctp_sf_do_5_1C_ack':
net/sctp/sm_statefuns.c:484: warning: 'error' may be used uninitialized in this
function
It is not obvious that this is a false positive.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
On Wed, Jan 16, 2008 at 09:04:58PM +0100, Willy Tarreau wrote:
...
you can work with latest release provided that you always have a fallback
to an earlier one. That way, you don't bet too much on something you don't
completely control. If it works, it tells you you'll be able to completely
jamal [EMAIL PROTECTED] wrote:
There are two issues that are inter-mingled in there. The most important
is pf_key not being robust on dump. The other being the accurracy of
IMHO doing significant work on af_key is a waste of time. It has no
advantages at all over xfrm_user since neither is
David Stevens [EMAIL PROTECTED] wrote:
The patch was to support the ICMPMsgStats table. Since none of
certain
types of output ICMP messages are generated by the kernel, but are
required
by the RFC, counting raw sockets is intentional (and the only way those
ICMP
types can be
[EMAIL PROTECTED] wrote on 01/16/2008 03:17:29 PM:
Fair enough. How about moving this code back into icmp.c and just
add a new count call in raw.c? The push pending function is used on
the UDP fast path so the leaner it is the better.
I started out with it there, but it certainly
David Stevens said the following on 2008-1-17 0:23:
Wang,
I think your patch is correct; did you test the same case for
IPv6?
I've tested IPv4, but IPv6 not yet.
If Davem accept this one, I will see the IPv6, or you take care of it.
--
WCN
--
To unsubscribe from this list: send
On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
[..]
Creating a separate af_key patch would not be a big problem. I was
just hoping avoiding it as the xfrm_state / xfrm_policy changes
modify the API and requires changing af_key also.
The way dumping is done by xfrm_user is consistent
On Thu, 2008-17-01 at 09:58 +1100, Herbert Xu wrote:
IMHO doing significant work on af_key is a waste of time. It has no
advantages at all over xfrm_user since neither is portable. So we
should discourage people from using af_key wherever possible.
I wouldnt disagree except some apps like
On Wed, Jan 16, 2008 at 08:39:40PM -0500, jamal wrote:
I wouldnt disagree except some apps like racoon which depend on pfkey
are unfortunately beyond repair. Timo has a pretty good handle on the
Racoon doesn't use pfkey dumping as far as I know.
Cheers,
--
Visit Openswan at
Ben Greear [EMAIL PROTECTED] writes:
Dan Nicolaescu wrote:
Ben Greear [EMAIL PROTECTED] writes:
Dan Nicolaescu wrote:
Hi,
I have posted this patch in the past with absolutely no reply.
I would appreciate some sort of feedback of the form
But, since during this change from sysfs cancel_delayed_work_sync()
could be probably used, and it's rather efficient with killing
rearming works, it seems this check could be unnecessary yet.
What going to be cancelled in bonding_store_miimon() when setting miimon to 0
is arp monitor, not mii
Maybe I'm wrong, but since this read_lock() is given and taken anyway,
it seems this looks a bit better to me (why hold this rtnl longer
than needed?):
read_unlock(bond-lock);
rtnl_unlock();
read_lock(bond-lock);
Seems better.
On the other hand,
jamal wrote:
On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
No. I'm not creating second copies of the SADB/SPD entries. The entries
are just added to one more list.
Ah, sorry - yes, that sounds reasonable.
So what happens if i delete an entry; does it get removed from the list?
Herbert Xu wrote:
jamal [EMAIL PROTECTED] wrote:
There are two issues that are inter-mingled in there. The most important
is pf_key not being robust on dump. The other being the accurracy of
IMHO doing significant work on af_key is a waste of time. It has no
advantages at all over
I assume that these ancient network drivers were trying to find out if
an irq is available. eepro.c expecting +EBUSY was doubly wrong.
I'm not sure that can_request_irq() is the right thing, but these drivers
are definitely wrong.
request_irq should BUG() on bad input, and these would have been
Is there any reason why these bugs should be treated gently? The
caller might not want to check NR_IRQS and IRQ_NOREQUEST cases, but
a NULL handler or NULL dev_id w/ shared are coding bugs.
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
---
kernel/irq/manage.c |7 +++
1 file changed, 3
There is no Documentation/networking/e1000e.txt.
Signed-off-by: Jason Uhlenkott [EMAIL PROTECTED]
Cc: Auke Kok [EMAIL PROTECTED]
---
Index: linux/drivers/net/Kconfig
===
--- linux.orig/drivers/net/Kconfig 2008-01-16
David Miller wrote:
From: Brandeburg, Jesse [EMAIL PROTECTED]
Date: Tue, 15 Jan 2008 13:53:43 -0800
The tx code has an early exit that tries to limit the amount of tx
packets handled in a single poll loop and requires napi or interrupt
rescheduling based on the return value from
From: Timo_Teräs [EMAIL PROTECTED]
Date: Thu, 17 Jan 2008 08:27:14 +0200
I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
So I'd say pfkey might be a bit more portable. Though netlink is definitely
more robust and extensive.
The RFCs say absolutely nothing about policy
From: Brandeburg, Jesse [EMAIL PROTECTED]
Date: Wed, 16 Jan 2008 23:09:47 -0800
We spent Wednesday trying to reproduce (without the patch) these issues
without much luck, and have applied the patch cleanly and will continue
testing it. Given the simplicity of the changes, and the community
On Thursday 17 January 2008, David Miller wrote:
From: Brandeburg, Jesse [EMAIL PROTECTED]
We spent Wednesday trying to reproduce (without the patch) these issues
without much luck, and have applied the patch cleanly and will continue
testing it. Given the simplicity of the changes, and
David Miller wrote:
From: Timo_Teräs [EMAIL PROTECTED]
Date: Thu, 17 Jan 2008 08:27:14 +0200
I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
So I'd say pfkey might be a bit more portable. Though netlink is definitely
more robust and extensive.
The RFCs say
From: Timo_Teräs [EMAIL PROTECTED]
Date: Thu, 17 Jan 2008 09:38:15 +0200
David Miller wrote:
From: Timo_Teräs [EMAIL PROTECTED]
Date: Thu, 17 Jan 2008 08:27:14 +0200
I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
So I'd say pfkey might be a bit more portable.
69 matches
Mail list logo
