David Miller wrote:
From: Ben Greear [EMAIL PROTECTED]
Date: Thu, 17 May 2007 21:23:16 -0700
Vlan code uses several of the methods, so I'm not sure how it will save
any memory
Feeling particularly dense today?
Ahh, yes indeed.
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela
Hi,
Fix looks good. I have couple of comments,
1) Return from s2io_updt_stats function if the PCI bus is offline
(pci_channel_offline).
if (pci_channel_offline(pdev))
return;
2) No Need to call netif_wake_queue() in s2io_io_resume as
netif_device_attach() will take
Hello,
On Thu, 17 May 2007, Patrick McHardy wrote:
But what is preferred is to use VIP in ICMP.
ip route add local VIP dev lo table user_defined
returns RTCF_LOCAL but inet_addr_type() does not return RTN_LOCAL,
we fix one thing but break another :)
Actually
The conservative spurious RTO response did not queue CWR even
though the sending rate was lowered. Whenever reduction happens
regardless of reason, CWR should be sent (forgetting to send it
is not very fatal though).
A better approach would be to queue CWR when one of the sending
rate reducing
From: Julian Anastasov [EMAIL PROTECTED]
Date: Fri, 18 May 2007 11:40:54 +0300 (EEST)
On Thu, 17 May 2007, Patrick McHardy wrote:
In any case some better solution than the current one needs to be
found, allowing users to send spoofed packets is far worse than
using a non-desired source
State could become inconsistent in two cases:
1) Userspace disabled FRTO by tuning sysctl when one of the TCP
flows was in the middle of FRTO algorithm (and then RTO is
again triggered)
2) SACK reneging occurs during FRTO algorithm
A simple solution is just to abort the previous FRTO when
Hi Urs, Hello Paul,
i assume Paul refers to the can_rx_delete_all() function that adds each
receive list entry for rcu removal using the can_rx_delete RCU callback,
right?
So the idea would be to create a second RCU callback - e.g.
can_rx_delete_list() - that removes the complete list
On Friday 18 May 2007 06:17, Jeff Garzik wrote:
Mithlesh Thukral wrote:
NetXen: Changes related to registers and their access routines
This patch updates the various access routines to access different
control and status settings present in different register locations.
This will fix
On Wed, 2007-16-05 at 23:25 -0400, jamal wrote:
This patch now includes two changed drivers (tun and e1000). I have
tested tun with this patch. I tested e1000 earlier and i couldnt find
any issues - although as the tittle says its a WIP.
As before you need net-2.6. You also need the qdisc
Provide two helper functions (xenbus_for_each_frontend,
xenbus_for_each_backend) to allow drivers to iterate the xenbus frontend
and backend buses.
diff -r 4f67d849e788 linux-2.6-xen-
sparse/drivers/xen/xenbus/xenbus_probe.c
--- a/linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_probe.c Tue Apr 03
Add accel option to vif xend config to allow users to specify which
interfaces should be accelerated using which plugin modules.
diff -r 194f5b88d257 tools/python/xen/xend/server/netif.py
--- a/tools/python/xen/xend/server/netif.py Tue Apr 17 09:04:51 2007
+0100
+++
Add support to Xen netback to support accelerated plugin module
diff -r da9639486bf2 linux-2.6-xen-sparse/drivers/xen/netback/common.h
--- a/linux-2.6-xen-sparse/drivers/xen/netback/common.h Fri May 18
10:36:47 2007 +0100
+++ b/linux-2.6-xen-sparse/drivers/xen/netback/common.h Fri May 18
11:02:49
This is a repost of some earlier patches to the xen-devel mailing list,
with a number of changes thanks to some useful suggestions from others.
Apologies for the short delay in getting this next version ready.
I've also CC'd netdev@vger.kernel.org as some of the files being patched
may be merged
David Acker wrote:
Kok, Auke wrote:
Jeff Garzik wrote:
Can you resend against the latest kernel (2.6.22-rc1)?
And what does Intel think?
I'm expecting at least a reply from Milton as the patch was sent to
him. I haven't yet tested it but will certainly do so. At first glance
it looks OK,
On Wednesday 16 May 2007 17:37, Anton Blanchard wrote:
Hi Hugh,
It's interesting that compat_core_sys_select() shows this kmalloc(0)
failure but core_sys_select() does not. That's because core_sys_select()
avoids kmalloc by using a buffer on the stack for small allocations (and
0 sure
Kok, Auke wrote:
Jeff Garzik wrote:
Can you resend against the latest kernel (2.6.22-rc1)?
And what does Intel think?
I'm expecting at least a reply from Milton as the patch was sent to him.
I haven't yet tested it but will certainly do so. At first glance it
looks OK, and I'll try to put
On May 17, 2007, at 8:53 PM, Jeff Garzik wrote:
Kim Phillips wrote:
On Tue, 15 May 2007 17:45:19 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Kim Phillips wrote:
It was agreed that phy-connection-type was a better name for
the interface-type property, so this patch renames it.
Also, the
On Fri, May 18, 2007 at 11:19:01AM +0200, Oliver Hartkopp wrote:
Hi Urs, Hello Paul,
i assume Paul refers to the can_rx_delete_all() function that adds each
receive list entry for rcu removal using the can_rx_delete RCU callback,
right?
So the idea would be to create a second RCU
Hm, this is indeed one step further, than i thought :-)
Thanks for this nifty solution!
I will doublecheck your suggestion with Urs and then we'll change it in
our next patch update (after some more feedback on this mailing list).
Additional feedback is welcome.
Tnx best regards,
Oliver
David Acker wrote:
David Acker wrote:
Kok, Auke wrote:
Jeff Garzik wrote:
Can you resend against the latest kernel (2.6.22-rc1)?
And what does Intel think?
I'm expecting at least a reply from Milton as the patch was sent to
him. I haven't yet tested it but will certainly do so. At first
On Fri, 18 May 2007 09:07:42 -0500
Kumar Gala [EMAIL PROTECTED] wrote:
On May 17, 2007, at 8:53 PM, Jeff Garzik wrote:
Kim Phillips wrote:
On Tue, 15 May 2007 17:45:19 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Kim Phillips wrote:
It was agreed that phy-connection-type was a better
Kok, Auke wrote:
David Acker wrote:
David Acker wrote:
Done. Below is a patch against 2.6.22-rc1. It combines removing the
s-bit patch and applying the patch I previously sent.
Oops. I missed one state in that patch. Since the el-bit buffer will
normally not complete due to a zero size,
David Acker wrote:
Kok, Auke wrote:
David Acker wrote:
David Acker wrote:
Done. Below is a patch against 2.6.22-rc1. It combines removing the
s-bit patch and applying the patch I previously sent.
Oops. I missed one state in that patch. Since the el-bit buffer will
normally not complete
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
Documentation/networking/ip-sysctl.txt | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt
b/Documentation/networking/ip-sysctl.txt
index ce16e6a..44ba8d4 100644
---
Kok, Auke wrote:
First impression just came in: It seems RX performance is dropped to
10mbit. TX is unaffected and runs at 94mbit/tcp, but RX the new code
seems to misbehave and fluctuate, dropping below 10mbit after a few
netperf runs and staying there...
ideas?
I found the problem.
Herbert Xu wrote:
Mark Huth [EMAIL PROTECTED] wrote:
This patch provides a performance optimization in the pfkey_add path.
Prior versions have a serious performance problem when adding a large
number of SAs to a node. For example, if a backup node needs to be
loaded with the SAs previously
On Thu, May 17, 2007 at 09:28:53AM +1000, Michael Ellerman wrote:
On Wed, 2007-05-16 at 17:00 -0500, Linas Vepstas wrote:
- pr_err(Not enough memory to allocate rx buffer\n);
+ pr_err(%s: Not enough memory to allocate rx buffer\n,
+
On Thu, May 17, 2007 at 08:46:00PM -0400, Jeff Garzik wrote:
Linas Vepstas wrote:
applied
Thanks
--linas
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Acker wrote:
Kok, Auke wrote:
First impression just came in: It seems RX performance is dropped to
10mbit. TX is unaffected and runs at 94mbit/tcp, but RX the new code
seems to misbehave and fluctuate, dropping below 10mbit after a few
netperf runs and staying there...
ideas?
I
Ilpo Järvinen wrote:
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
Documentation/networking/ip-sysctl.txt | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt
b/Documentation/networking/ip-sysctl.txt
index
On Wed, May 16, 2007 at 05:01:27PM -0400, Florin Malita wrote:
In libertas_process_rxed_packet() and process_rxed_802_11_packet() the
skb is dereferenced after being passed to netif_rx (called from
libertas_upload_rx_packet). Spotted by Coverity (1658, 1659).
Relocating the
Baruch Even wrote:
Ilpo Järvinen wrote:
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
Documentation/networking/ip-sysctl.txt | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt
John W. Linville wrote:
Also, libertas_upload_rx_packet() unconditionally returns 0 so the error
check is dead code - might as well take it out.
Is this merely an implementation detail? Or an absolute fact?
I believe it's an absolute fact that got lost among implementation
details
Rick Jones wrote:
as an asside, tcp_max_ssthresh sounds like the maximum value ssthresh
can take-on. is that correct, or is this more of a once ssthresh is
above this, behave in this new way? If that is the case, while the
I don't like it either, but you'll have to talk to Sally Floyd
Hello Paul,
as you may see in the attached SVN-log i changed some code according
your suggestions.
I additionally made some clarifications of function names.
If you would like to see the af_can.c completely please visit:
On Fri, May 18, 2007 at 02:34:12PM +1000, Herbert Xu wrote:
Actually, I think we should just probe for the specific algorithm
requested rather than everything. See patch below.
Doh, forgot to actually remove the probe call :)
[IPSEC] pfkey: Load specific algorithm in pfkey_add rather than
Hello,
diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
index 7053026..111f23d 100644
--- a/drivers/net/smc91x.h
+++ b/drivers/net/smc91x.h
@@ -279,6 +279,40 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg)
...
+#define SMC_outb(v, a, r)
On Fri, 18 May 2007 23:46:21 +0200
Mariusz Koz__owski [EMAIL PROTECTED] wrote:
Hello,
diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
index 7053026..111f23d 100644
--- a/drivers/net/smc91x.h
+++ b/drivers/net/smc91x.h
@@ -279,6 +279,40 @@ SMC_outw(u16 val, void __iomem
diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
index 7053026..111f23d 100644
--- a/drivers/net/smc91x.h
+++ b/drivers/net/smc91x.h
@@ -279,6 +279,40 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg)
...
+#define SMC_outb(v, a, r) __ __
On Friday 18 May 2007, Andrew Morton wrote:
On Fri, 18 May 2007 23:46:21 +0200
Mariusz Koz__owski [EMAIL PROTECTED] wrote:
Hello,
diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h
index 7053026..111f23d 100644
--- a/drivers/net/smc91x.h
+++ b/drivers/net/smc91x.h
@@ -279,6
We have several reports now of hitting this assertion in
netif_rx_complete(), inlined in e1000_clean():
BUG_ON(!test_bit(__LINK_STATE_RX_SCHED, dev-state));
[c0431162] __queue_work+0x51/0x5e
[c059eea1] et_rx_action+0x94/0x185
[c042837d] __do_softirq+0x5d/0xba
[c0407837]
Chuck Ebbert wrote:
We have several reports now of hitting this assertion in
netif_rx_complete(), inlined in e1000_clean():
BUG_ON(!test_bit(__LINK_STATE_RX_SCHED, dev-state));
[c0431162] __queue_work+0x51/0x5e
[c059eea1] et_rx_action+0x94/0x185
[c042837d] __do_softirq+0x5d/0xba
4:03pm Kok, Auke said:
Chuck Ebbert wrote:
We have several reports now of hitting this assertion in
netif_rx_complete(), inlined in e1000_clean():
BUG_ON(!test_bit(__LINK_STATE_RX_SCHED, dev-state));
[c0431162] __queue_work+0x51/0x5e
[c059eea1] et_rx_action+0x94/0x185
Daniel Schaffrath [EMAIL PROTECTED] wrote:
I was wondering what the purpose of the bit shifts in tcp_get_info
right after the jiffies conversion might be. What's the time unit
after that shift?
info-tcpi_rtt = jiffies_to_usecs(tp-srtt)3;
info-tcpi_rttvar =
On Fri, 18 May 2007 14:09:03 -0400
John W. Linville [EMAIL PROTECTED] wrote:
On Wed, May 16, 2007 at 05:01:27PM -0400, Florin Malita wrote:
In libertas_process_rxed_packet() and process_rxed_802_11_packet() the
skb is dereferenced after being passed to netif_rx (called from
Stephen Hemminger wrote:
netif_rx() used to return a value in older kernels.
netif_rx() returns a value in current kernels.
Jeff
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Eugene Teo [EMAIL PROTECTED] wrote:
diff --git a/net/llc/llc_conn.c b/net/llc/llc_conn.c
index 3b8cfbe..28a3994 100644
--- a/net/llc/llc_conn.c
+++ b/net/llc/llc_conn.c
@@ -323,7 +323,8 @@ int llc_conn_remove_acked_pdus(struct sock *sk, u8 nr, u16
*how_many_unacked)
if (!q_len)
Randy Dunlap wrote:
On Sat, 19 May 2007 13:13:07 +0800 Eugene Teo wrote:
skb_peek() might return an empty list. skb should be checked before calling
llc_pdu_sn_hdr() with it.
Spotted by the Coverity checker.
Signed-off-by: Eugene Teo [EMAIL PROTECTED]
[...]
Oh, and your patch has
48 matches
Mail list logo
