Yes it's what i'm looking for. I don't understand how to change the
arp_ip_target with the gateway, arp_ip_target is a module option.
- Message d'origine
De : Jay Vosburgh [EMAIL PROTECTED]
À : [EMAIL PROTECTED]
Cc : netdev@vger.kernel.org
Envoyé le : Jeudi, 10 Janvier 2008, 0h26mn 38s
Hello all.
I try more then 2 month resolve problem witch my shaping. Maybe you can
help for me?
Sheme:
+---+
+ - | Shaping PC 1 | -+
/ +---+ \
++
Well, it's 2.6.24-rc7 already - any news?
I put this into my net-2.6 tree last night since Jeff asked
me to look over critical networking driver stuff for a little
while.
Thanks, they are upstream now and it did fix tulip in my PPC - network
is stable again.
--
Meelis Roos ([EMAIL
This patch makes necessary changes in the Neptune driver to support
the new Marvell PHY. It also adds support for the LED blinking
on Neptune cards with Marvell PHY. All registers are using defines
in the niu.h header file as is already done for the BCM8704 registers.
diff -uprN -X
From: Mirko Lindner [EMAIL PROTECTED]
Date: Thu, 10 Jan 2008 10:33:01 +0100
This patch makes necessary changes in the Neptune driver to support
the new Marvell PHY. It also adds support for the LED blinking
on Neptune cards with Marvell PHY. All registers are using defines
in the niu.h
The neightbl_fill_parms() is called under the write-locked
tbl-lock and accesses the parms-dev. The negh_parm_release()
calls the dev_put(parms-dev) without this lock. This
creates a tiny race window on which the parms contains
potentially stale dev pointer.
To fix this race it's enough to move
For proper link bandwidth sharing i guess something like network counters
have to be shared between PC's (with proper locking). I didn't heard anything
like this
IMHO a ways to do this:
Split destination network to multiple parts and do routes on Cisco. Let's say
you have:
192.168.0.0/16
and u
From: Daniel Lezcano [EMAIL PROTECTED]
Date: Wed, 09 Jan 2008 17:45:33 +0100
The following patchset makes the ipv6 sysctl to handle multiple
network namespaces. Each instance of a network namespace as its own
set of sysctl values, that means the behavior of the ipv6 stack can be
different
Hi,
On Wed, Jan 09, 2008 at 09:26:53PM +0100, Karsten Keil wrote:
Reading the section you reference, we do follow all the MUST requirements,
and
we log an error. Given that the disable section is a SHOULD, I think we
can at
least be somewhat more restrictive in our implementation.
cat /proc/net/atm/arp causes the NULL pointer dereference in the
get_proc_net+0xc/0x3a. This happens as proc_get_net believes that the
parent proc dir entry contains struct net.
Fix this assumption for net/atm case.
The problem is introduced by the commit c0097b07abf5f92ab135d024dd41bd2aada1512f
seq_open_net requires that first field of the seq-private data to be
struct seq_net_private. In reality this is a single pointer to a struct net
for now. The patch makes code consistent.
Signed-off-by: Denis V. Lunev [EMAIL PROTECTED]
---
diff --git a/include/net/neighbour.h
On Wed, Jan 09, 2008 at 03:32:12PM -0800, David Miller wrote:
From: Karsten Keil [EMAIL PROTECTED]
Date: Wed, 9 Jan 2008 16:36:56 +0100
If the address is a link-local address formed from an interface
identifier based on the hardware address, which is supposed to be
uniquely
| So maybe the cause triggering this oops is somewhere else.
|
| yes, probably. sorry - i didn`t tell or maybe i didn`t know when writing
| my first mail to module authors and forget to add that before forwarding here.
|
| for me , the problem does not happen with suse kernel of the day
|
From: Denis V. Lunev [EMAIL PROTECTED]
Date: Wed, 09 Jan 2008 21:03:03 +0300
This set adds namespace support for routing tables rules
manipulation in the different namespaces. So, one could create a
namespace and setup IPv4 routing there how he wants.
All 19 patches applied, thanks Denis.
--
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 10 Jan 2008 13:56:53 +0300
The neightbl_fill_parms() is called under the write-locked
tbl-lock and accesses the parms-dev. The negh_parm_release()
calls the dev_put(parms-dev) without this lock. This
creates a tiny race window on which the
From: Denis V. Lunev [EMAIL PROTECTED]
Date: Thu, 10 Jan 2008 14:28:53 +0300
cat /proc/net/atm/arp causes the NULL pointer dereference in the
get_proc_net+0xc/0x3a. This happens as proc_get_net believes that the
parent proc dir entry contains struct net.
Fix this assumption for net/atm
From: Denis V. Lunev [EMAIL PROTECTED]
Date: Thu, 10 Jan 2008 14:30:44 +0300
The iterator state-ns.neigh_sub_iter initialization is moved from
arp_seq_open to clip_seq_start for convinience. This should not be a problem
as the iterator will be used only after the seq_start callback.
From: Denis V. Lunev [EMAIL PROTECTED]
Date: Thu, 10 Jan 2008 14:32:19 +0300
seq_open_net requires that first field of the seq-private data to be
struct seq_net_private. In reality this is a single pointer to a struct net
for now. The patch makes code consistent.
Signed-off-by: Denis V.
David Miller wrote:
From: Daniel Lezcano [EMAIL PROTECTED]
Date: Wed, 09 Jan 2008 17:45:33 +0100
The following patchset makes the ipv6 sysctl to handle multiple
network namespaces. Each instance of a network namespace as its own
set of sysctl values, that means the behavior of the ipv6 stack
On Wed, Jan 09, 2008 at 04:09:57PM -0500, Vlad Yasevich wrote:
Neil Horman wrote:
On Thu, Jan 10, 2008 at 01:38:57AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article [EMAIL PROTECTED] (at Wed, 9 Jan 2008 16:36:56 +0100), Karsten
Keil [EMAIL PROTECTED] says:
So I think we should disable the
From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 9 Jan 2008 11:37:27 +0100
[NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
In rt_cache_get_next(), no need to guard seq-private by a rcu_dereference()
since seq is private to the thread running this function. Reading seq.private
From: maximilian attems [EMAIL PROTECTED]
Date: Wed, 9 Jan 2008 11:21:10 +0100
sfuzz can easily trigger any of those.
move the printk message to the corresponding comment:
makes the intention of the code clear and easy
to pick up on an scheduled removal.
as bonus simplify the braces
Hi All,
I have few questions about EQL driver
*) Why the tx_queue_len is set as 5?. For example if we bond 3 lines
and each has 1000 as tx_queue_len, will the bonding line(eql)
tx_queue_len be sum of these three tx_queue_len?. In this case, will the
bonding line(eql)tx_queue_len be 3000?
On Tue, 8 Jan 2008, Ilpo Järvinen wrote:
On Mon, 7 Jan 2008, David Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 8 Jan 2008 06:00:07 +0100
On Mon, Jan 07, 2008 at 07:37:00PM -0800, David Miller wrote:
The vast majority of them are one, two, and three liners.
The ipv6_devconf_(all) and ipv6_devconf_dflt are currently
global, but should be per-namespace.
This set moves them on the struct net. Or, more precisely,
on the struct netns_ipv6, which is already added.
Unfortunately, many code in the ipv6 cannot yet provide a
correct struct net to get the
The addrconf sysctls and neigh sysctls are registered and
unregistered always in pairs, so they can be joined into
one (well, two) functions, that accept the struct inet6_dev
and do all the job.
This also get rids of unneeded ifdefs inside the code.
Signed-off-by: Pavel Emelyanov [EMAIL
Hi David
Here is DECNET part, shadowing commit 0bcceadceb0907094ba4e40bf9a7cd9b080f13fb
([IPV4] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache )
Thank you
[DECNET] ROUTE: fix rcu_dereference() uses in /proc/net/decnet_cache
In dn_rt_cache_get_next(), no need to guard seq-private by
Hi All,
If a server has multiple processors and N number of ethernet cards, is
it possible to handle transmission by each processor separately? .In
other words, each processor will be responsible for tx of few ethernet
cards?.
Example: Server has 4 processors and 8 ethernet cards. is it
This is the core. Declare and register the pernet subsys for
addrconf. The init callback the will create the devconf-s.
The init_net will reuse the existing statically declared confs,
so that accessing them from inside the ipv6 code will still
work.
The register_pernet_subsys() is moved above
All its users are in net/ipv6/addrconf.c's sysctl handlers.
Since they already have the struct net to get from, the
per-net ipv6_devconf_dflt can already be used.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
net/ipv6/addrconf.c |6 +++---
1 files changed, 3 insertions(+), 3
This error code will be needed to abort the namespace
creation if needed.
Probably, this is to be checked when a new device is
created (currently it is ignored).
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
net/ipv6/addrconf.c |6 +++---
1 files changed, 3 insertions(+), 3
This includes passing the net to __addrconf_sysctl_register
and saving this on the ctl_table-extra2 to be used in
handlers (those, needing it).
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
net/ipv6/addrconf.c | 24 ++--
1 files changed, 14 insertions(+), 10
Actually the net-ipv6.devconf_all can be used in a few places,
but to keep the /proc/sys/net/ipv6/conf/ sysctls work consistently
in the namespace we should use the per-net devconf_all in the
sysctl forwarding handler.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
net/ipv6/addrconf.c |
Hi All,
I am just wondering how TCP/IP stack runs in SMP kernel with multi
processor environment?. will TCP/IP stack be on one processor or it is
shared among the different processors?
thanks
Jeba
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
On Thu, 10 Jan 2008 14:05:46 +
Jeba Anandhan [EMAIL PROTECTED] wrote:
Hi All,
If a server has multiple processors and N number of ethernet cards, is
it possible to handle transmission by each processor separately? .In
other words, each processor will be responsible for tx of few
Hello,
I am trying to learn the IPV4 ipip tunnel code (net/ipv4/ipip.c)
and I have two little questions about
semantics of variables:
ipip_fb_tunnel_init - what does fb stand for ?
In tunnels_wc : what does wc stand for ?
Regards,
Andy
--
To unsubscribe from this list: send the line
On Thu, Jan 10, 2008 at 11:58:09AM +1100, Herbert Xu wrote:
On Wed, Jan 09, 2008 at 03:19:10PM -0800, Jay Vosburgh wrote:
No that's not the point. The point is to move the majority of the code
into process context so that you can take the RTNL. Once you have taken
the RTNL you can
When I studied the neighbor code I puzzled over what
the NUD can mean for quite a long time.
Finally I asked Alexey and he said that this was smth
like neighbor unreachability detection.
Does it worth adding a comment helping future developers
understand what's going on?
Signed-off-by: Pavel
On Thu, Jan 10, 2008 at 12:06:35PM +0300, Badalian Vyacheslav wrote:
Hello all.
I try more then 2 month resolve problem witch my shaping. Maybe you can
help for me?
Sheme:
+---+
+ - | Shaping PC 1 | -+
Andrew Morton wrote:
Distribution: iptables 1.4.0 was used with kernel 2.6.23 and iptables 1.3.8
with 2.6.22.15
Hardware Environment: 3 interfaces, 2 interfaces bridged to form br0, and
another connects to internet using pppoe.
Software Environment: bridge, multipath routing
Problem Description:
Am Donnerstag, 10. Januar 2008 schrieb Christian Borntraeger:
Am Donnerstag, 10. Januar 2008 schrieb Christian Borntraeger:
Am Dienstag, 18. Dezember 2007 schrieb Rusty Russell:
To me this points to doing interrupt suppression a different way. If
we
have a -disable_cb() virtio function,
[VLAN]: nested VLAN: fix lockdep's recursive locking warning
Allow vlans nesting other vlans without lockdep's warnings (max. 2 levels
i.e. parent + child). Thanks to Patrick McHardy for pointing a bug in the
first version of this patch.
Reported-by: Benny Amorsen
Signed-off-by: Jarek
Jarek Poplawski wrote:
As a matter of fact I started to doubt it's a real problem: 2 vlan
headers in the row - is it working?
Yes, apparently some people are using this.
Anyway, as Patrick pointed, the previous patch was a bit buggy, and
deeper nesting needs a little more (if it's can work
Hi Eric,
Thanks for the reply. I have one more doubt. For example, if we have 2
processor and 4 ethernet cards. Only CPU0 does all work through 8 cards.
If we set the affinity to each ethernet card as CPU number, will it be
efficient?.
Will this be default behavior?
# cat /proc/interrupts
[MACVLAN]: Prevent nesting macvlan devices
Don't allow to nest macvlan devices since it will cause lockdep warnings and
isn't really useful for anything.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 80a76fbde679793a17482a3dd842386801fca66b
tree
Hello,
I've perceived that there is a performance issue when running netperf
against 4 e1000 links connected end-to-end to another machine with 4
e1000 interfaces.
I have 2 4-port interfaces on my machine, but the test is just
considering 2 port for each interfaces card.
When I run netperf in
Breno Leitao wrote:
Hello,
I've perceived that there is a performance issue when running netperf
against 4 e1000 links connected end-to-end to another machine with 4
e1000 interfaces.
I have 2 4-port interfaces on my machine, but the test is just
considering 2 port for each interfaces
Ben,
I am facing the performance issue when we try to bond the multiple
interfaces with virtual interface. It could be related to this thread.
My questions are,
*) When we use mulitple NICs, will the performance of overall system be
summation of all individual lines XX bits/sec. ?
*) What are
Hi all,
I've got an issue that's popped up with a deployed system running
2.6.10. I'm looking for some help figuring out why incoming network
packets aren't being processed fast enough.
After a recent userspace app change, we've started seeing packets being
dropped by the ethernet hardware
Hi Eric,
While testing the current network namespace stuff merged in net-2.6.25,
I bumped into the following problem with the /proc/net/ entries.
It doesn't always display the actual data of the current namespace,
but sometime displays data from other namespaces.
I bisected the problem to the
To classid x:y = mark=markx|y (classid :y = -j MARK --set-mark y, etc).
--- linux-2.6.23-gentoo-r2/net/sched/Kconfig
+++ linux-2.6.23-gentoo-r2.fixed/net/sched/Kconfig
@@ -222,6 +222,16 @@
To compile this code as a module, choose M here: the
module will be called sch_ingress.
On Thu, 2008-01-10 at 16:36 +, Ben Hutchings wrote:
When I run netperf in just one interface, I get 940.95 * 10^6 bits/sec
of transfer rate. If I run 4 netperf against 4 different interfaces, I
get around 720 * 10^6 bits/sec.
snip
I take it that's the average for individual
Chris Friesen wrote:
Hi all,
I've got an issue that's popped up with a deployed system running
2.6.10. I'm looking for some help figuring out why incoming network
packets aren't being processed fast enough.
After a recent userspace app change, we've started seeing packets being
dropped
Dzianis Kahanovich wrote:
--- linux-2.6.23-gentoo-r2/net/sched/sch_ingress.c
+++ linux-2.6.23-gentoo-r2.fixed/net/sched/sch_ingress.c
@@ -161,2 +161,5 @@
skb-tc_index = TC_H_MIN(res.classid);
+#ifdef CONFIG_NET_SCH_INGRESS_TC2MARK
+skb-mark =
Kok, Auke wrote:
You're using 2.6.10... you can always replace the e1000 module with the
out-of-tree version from e1000.sf.net, this might help a bit - the version in
the
2.6.10 kernel is very very old.
Do you have any reason to believe this would improve things? It seems
like the problem
Chris Friesen wrote:
Hi all,
I've got an issue that's popped up with a deployed system running
2.6.10. I'm looking for some help figuring out why incoming network
packets aren't being processed fast enough.
After a recent userspace app change, we've started seeing packets being
dropped
Many many things to check when running netperf :)
*) Are the cards on the same or separate PCImumble bus, and what sort of bus
*) is the two interface performance two interfaces on the same four-port
card, or an interface from each of the two four-port cards?
*) is there a dreaded (IMO)
Arnaldo Carvalho de Melo wrote:
Em Thu, Jan 10, 2008 at 03:26:59PM +, Jeba Anandhan escreveu:
Hi Eric,
Thanks for the reply. I have one more doubt. For example, if we have 2
processor and 4 ethernet cards. Only CPU0 does all work through 8 cards.
If we set the affinity to each ethernet
Breno Leitao wrote:
On Thu, 2008-01-10 at 16:36 +, Ben Hutchings wrote:
When I run netperf in just one interface, I get 940.95 * 10^6 bits/sec
of transfer rate. If I run 4 netperf against 4 different interfaces, I
get around 720 * 10^6 bits/sec.
snip
I take it that's the average for
This is a resubmission of a new driver for Solarflare network controllers.
The driver supports several types of PHY (10Gbase-T, XFP, CX4) on six
different 10G and 1G boards.
Hardware based on this network controller is now available from SMC as
part numbers SMC10GPCIe-XFP and SMC10GPCIe-10BT.
I also tried to increase my interface MTU to 9000, but I am afraid that
netperf only transmits packets with less than 1500. Still investigating.
It may seem like picking a tiny nit, but netperf never transmits
packets. It only provides buffers of specified size to the stack. It is
then the
1) Interrupts are being processed on both cpus:
[EMAIL PROTECTED]:/root cat /proc/interrupts
CPU0 CPU1
30:17037564530785 U3-MPIC Level eth0
IIRC none of the e1000 driven cards are multi-queue, so while the above
shows that interrupts from eth0 have been
Andy,
-Original Message-
From: Andy Johnson [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 10, 2008 6:35 AM
To: netdev@vger.kernel.org
Subject: ipip tunnel code (IPV4)
Hello,
I am trying to learn the IPV4 ipip tunnel code (net/ipv4/ipip.c)
and I have two little questions
Chris Friesen wrote:
Kok, Auke wrote:
You're using 2.6.10... you can always replace the e1000 module with the
out-of-tree version from e1000.sf.net, this might help a bit - the
version in the
2.6.10 kernel is very very old.
Do you have any reason to believe this would improve things? It
Rick Jones wrote:
1) Interrupts are being processed on both cpus:
[EMAIL PROTECTED]:/root cat /proc/interrupts
CPU0 CPU1
30:17037564530785 U3-MPIC Level eth0
IIRC none of the e1000 driven cards are multi-queue
the pci-express variants are, but the
On , Joonwoo Park wrote:
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -6262,6 +6262,10 @@ static void __iwl_down(struct iwl_priv *priv)
/* tell the device to stop sending interrupts */
iwl_disable_interrupts(priv);
+
Stephen Hemminger schrieb:
On Wed, 9 Jan 2008 16:03:00 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 9 Jan 2008 13:05:34 -0800 (PST)
[EMAIL PROTECTED] wrote:
Benjamin Thery [EMAIL PROTECTED] writes:
Hi Eric,
While testing the current network namespace stuff merged in net-2.6.25,
I bumped into the following problem with the /proc/net/ entries.
It doesn't always display the actual data of the current namespace,
but sometime displays data from
Jeff Garzik wrote:
Looks pretty decent. Main comments (style mostly, driver operation path
seems sound):
thanks again for the comments. I am about to send an updated patch just before
my
vacation and before I do let me just quickly touch on your comments below:
* kill the bitfields and
Hello Stephen!
I've rebased the patches branch we carry in debian on top of the new
080108 release of iproute2.
See patches branch of git://git.debian.org/git/collab-maint/pkg-iproute
I've dropped one of the patches you picked up[1], so there's now one of the
old ones left and a new manpage for
Jeff,
A couple more fixes for 2.6.24. The one from Mattias Nissler is already
in your upstream tree...FYI.
Let me know if there are problems!
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
---
Jeff,
This is additive on top of the pull request posted on Tuesday evening:
http://marc.info/?l=linux-wirelessm=119985065704687w=2
If you pull this one, you will get that one as well.
Please let me know if there are any problems!
Thanks,
John
---
Individual patches are available
On tor, 2008-01-10 at 20:54 +0100, Andreas Henriksson wrote:
An additional patch will be provided in a followup mail (not available in
Debian) that was created by request from Patrick McHardy. This one makes max
rounds configurable (and 0 means try to infinity, so you can restore old
On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
That wasn't the only purpose, Herbert. Making sure that calls to
dev_set_mac_address were called from process context was important at
the time of the coding as well since at least the tg3 driver took locks
that could not be
Herbert Xu [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
That wasn't the only purpose, Herbert. Making sure that calls to
dev_set_mac_address were called from process context was important at
the time of the coding as well since at least the tg3
[EMAIL PROTECTED] wrote:
Yes it's what i'm looking for. I don't understand how to change the
arp_ip_target with the gateway, arp_ip_target is a module option.
If you're running a relatively recent bonding driver (version
3.0.0 or later), the arp_ip_targets can be changed on the fly via
Andy Gospodarek [EMAIL PROTECTED] wrote:
[...]
That wasn't the only purpose, Herbert. Making sure that calls to
dev_set_mac_address were called from process context was important at
the time of the coding as well since at least the tg3 driver took locks
that could not be taken reliably in
On Thu, Jan 10, 2008 at 04:03:53PM -0500, Andy Gospodarek wrote:
Sure, but where do you call that function while holding the bond lock?
If I recall correctly, the problem was that tg3, et al, did
things that might sleep, and bonding was calling from a timer context,
which couldn't
On Thu, Jan 10, 2008 at 04:31:22PM +0100, Patrick McHardy wrote:
...
No, this seems fine, thanks. Even better would be a way to get
the last lockdep subclass through lockdep somehow, but I couldn't
find a clean way for this. So I've applied your patch and also
fixed macvlan.
As a matter of
On Thu, Jan 10, 2008 at 12:50:46PM -0800, Jay Vosburgh wrote:
Herbert Xu [EMAIL PROTECTED] wrote:
On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
That wasn't the only purpose, Herbert. Making sure that calls to
dev_set_mac_address were called from process context was
Breno Leitao wrote:
When I run netperf in just one interface, I get 940.95 * 10^6 bits/sec
of transfer rate. If I run 4 netperf against 4 different interfaces, I
get around 720 * 10^6 bits/sec.
This is actually a known issue that we have worked with your company
before on. It comes down to
On Thu, Jan 10, 2008 at 02:49:22PM -0500, John W. Linville wrote:
Jeff,
A couple more fixes for 2.6.24. The one from Mattias Nissler is already
in your upstream tree...FYI.
Let me know if there are problems!
Please disregard this request. The 'upstream-jgarzik-2' request is still valid.
On Thu, Jan 10, 2008 at 10:08:16PM +0100, Jarek Poplawski wrote:
...
But still some 'quirks' are possible there: removing and adding
devices 'properly' would often require resetting of many subclasses,
...Hmm, probably they are always removed from/with the children, then no
problem! (I know, I
James Chapman wrote:
What's changed in your application? Any real-time threads in there?
From the top output below, looks like SigtranServices is consuming all
your CPU...
There are two cpus, and SigtranServices is multithreaded with many
threads. Most of these threads are affined to
On Thu, 2008-10-01 at 17:05 -0200, Dzianis Kahanovich wrote:
To classid x:y = mark=markx|y (classid :y = -j MARK --set-mark y,
etc).
--- linux-2.6.23-gentoo-r2/net/sched/Kconfig
+++ linux-2.6.23-gentoo-r2.fixed/net/sched/Kconfig
@@ -222,6 +222,16 @@
[..]
[2nd try -- turns-out the Mattis Nissler patch needed an extra tweak.
It will probably also cause build breakage when you rebase since
rt2x00lib_txdone(...) becomes rt2x00pci_txdone(rt2x00dev,...) in 2.6.25,
so FYI... :-)
This also includes another patch (the 4 byte boundary one) which
is already
Here's what I think is a better patch. Or maybe just simpler.
However, I'm still unsure what the effect of this patch on
file descriptor passing might be. Reading the prior code,
and the parallel portions/comments in unix_dgram_recvmsg(),
it looks like there's been a lot of uncertainty as to
and the parallel portions/comments in unix_dgram_recvmsg(),
it looks like there's been a lot of uncertainty as to how
file descriptor passing should be handled durning MSG_PEEK
operations. To quote:
The specs basically don't answer the question. What is critical is that
the behaviour does
I try arp monitoring but it doesn't work! Test an ip, the interface must have
an address, and the dhcpcd is launch by ifplugd if bond0 is linked ... so it
goes around in circles.
So i return to miimon, and i figured out that bond detect when wlan0 is
associated and set it active interface. But
Eric Dumazet wrote, On 01/09/2008 11:37 AM:
...
[NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
...
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index d337706..28484f3 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -283,12 +283,12 @@ static struct rtable
Spotted-by: [EMAIL PROTECTED]
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
---
drivers/net/ipg.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index dbd23bb..cd1650e 100644
--- a/drivers/net/ipg.c
+++
Please pull from branch 'ipg-fixes' in repository
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git ipg-fixes
to get the changes below.
I have tested the driver with a PIV HT based motherboard. The network
controller is connected to a fast ethernet switch (yeah, I'm cheap).
A
The Tx skb release could not free more than one skb per call.
Add it to the fact that the xmit handler does not check for
a queue full condition and you have a recipe to leak quickly.
Let's release every pending Tx descriptor which has been given
back to the host CPU by the network controller.
On Fri, Jan 11, 2008 at 12:10:42AM +0100, Jarek Poplawski wrote:
Eric Dumazet wrote, On 01/09/2008 11:37 AM:
...
[NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
...
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index d337706..28484f3 100644
--- a/net/ipv4/route.c
+++
The current logic will only request an ack for the first pending
packet. No irq is triggered as soon as the CPU submits a few
packets a bit quickly. Let's request an irq for every packet
instead.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
---
drivers/net/ipg.c |5 +
1 files
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
---
drivers/net/ipg.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index 9752902..b234b29 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -1994,7 +1994,7 @@ static int
On Fri, Jan 11, 2008 at 12:10:42AM +0100, Jarek Poplawski wrote:
It seems this optimization could've a side effect: if during such a
loop updates are done, and r is seen !NULL during while() check, but
NULL after rcu_dereference(), the listing/counting could stop too
soon. So, IMHO, probably
Kok, Auke wrote:
All,
here is the third version of the igb (82575) ethernet controller driver. This
driver was previously posted 2007-07-13 and 2007-12-11. Many comments received
were addressed:
- removed indirection wrappers in the same way as e1000e and ixgbe.
- cleaned up largely against
Jeff Garzik wrote:
Kok, Auke wrote:
All,
here is the third version of the igb (82575) ethernet controller
driver. This
driver was previously posted 2007-07-13 and 2007-12-11. Many comments
received
were addressed:
- removed indirection wrappers in the same way as e1000e and ixgbe.
-
Hi Joonwoo,
We already did something similiar in our code base. Could you please
take a look at this patch?
http://intellinuxwireless.org/repos/?p=iwlwifi.git;a=commitdiff;h=57aa02255e9d7be5e2494683fc2793bd1d0707e2
Thanks,
-yi
On Wed, 2008-01-09 at 20:02 +0900, Joonwoo Park wrote:
Eleminiate
1 - 100 of 142 matches
Mail list logo
