On Tue, 2008-02-19 at 15:45 +0100, Patrick McHardy wrote:
> That would break iptables compilation, which already includes
> linux/in.h in some files. I guess the best fix for now is to
> include netinet/in.h in busybox and long-term clean this up
> properly.
It looks like iptables is fairly broke
Fix typos on Kconfig for PowerPC 4xx on-chip ethernet driver.
Signed-off-by: Satoru Takeuchi <[EMAIL PROTECTED]>
---
Index: 2.6.25-rc2/drivers/net/ibm_newemac/Kconfig
===
--- 2.6.25-rc2.orig/drivers/net/ibm_newemac/Kconfig 2008-0
On Thu, Feb 21, 2008 at 05:07:37PM -0800, Andrew Morton wrote:
> It would be good if you could test the latest Linux snapshot please, see if
> we've already fixed this, thanks.
This is slightly difficult; it's a production machine.
I _might_ be able to do it tomorrow, but no guarantees.
/* Stein
(please respond via emailed reply-to-all, not via the bugzilla web
interface, thanks)
On Thu, 21 Feb 2008 13:13:13 -0800 (PST) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=10061
>
>Summary: Hang in md5_resync
>Product: IO/Storage
>Ver
Am 22.02.2008 01:40 schrieb Tilman Schmidt:
>>
>> [NETFILTER]: nf_conntrack: fix smp_processor_id() in preemptible code
>> warning
>
> Yes, it does; and the system also survives substantially longer.
> (IOW, it hasn't crashed on me so far.)
Which of course it did the second after I sent off
Am 21.02.2008 12:28 schrieb Patrick McHardy:
>
> Could you test whether this patch fixes the netfilter
> warnings please?
> commit 736b33102292be0d75be1e950ca9bcd5361db7dd
> Author: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Thu Feb 21 12:26:01 2008 +0100
>
> [NETFILTER]: nf_conntrack: fi
This patch adds functions to setup and read the CHIPCO IRQ.
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
---
drivers/ssb/driver_chipcommon.c | 10 ++
include/linux/ssb/ssb_driver_chipcommon.h |4
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/dri
Adding netdev list.
Original patch can be found at: http://lkml.org/lkml/2008/2/21/171
Wappler Marcel wrote:
> This patch fixes a DHCP issue of the kernel: some DHCP servers
> (i.e. in the Linksys WRT54Gv5) are very strict about the contents
> of the DHCPDISCOVER packet they receive from clients.
Fix some spelling errors and inconsistencies in comment blocks.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000e/82571.c | 10 +-
drivers/net/e1000e/defines.h | 10 +-
drivers/net/e1000e/hw.h |4 ++--
drivers/net/e1000e/ich8lan.c | 24 ++
This simplifies the 82571/2/3 family initialization a bit
and removes an initialization table no longer needed.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
---
drivers/net/e1000e/82571.c | 12 +---
1 files changed, 1 insertions(+), 11 del
This counter is valuable to determine if the system is unable
to timely return buffers to the hardware and this counter starts
to increase well before the hardware starts to drop packets. If
users experience rx_no_buffer_count increasing, they should increase
the amount of descriptors. That will pr
Daniel Lezcano a écrit :
Eric Dumazet wrote:
Hi David
This is an RFC, based on net-2.6 for convenience only.
Thank you
[RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
Loopback transmit function loopback_xmit() actually calls netif_rx()
to queue
a skb to the softnet que
From: Jesse Brandeburg <[EMAIL PROTECTED]>
this patch avoids a denial of service from an evildoer sending a
continuous stream of flow control at our adapter that is plugged
into a non-flow control enabled switch.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000e/netdev.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 7824bc2..fc5c63f 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000e/lib.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000e/lib.c b/drivers/net/e1000e/lib.c
i
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000e/e1000.h |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e10
On Thu, 2008-02-21 at 14:05 +0100, Johannes Berg wrote:
> On Thu, 2008-02-21 at 13:54 +1100, Benjamin Herrenschmidt wrote:
> > On Tue, 2008-02-19 at 22:38 +0100, Johannes Berg wrote:
> > > I started getting this warning with recent kernels:
> >
> > Do that help ?
> >
> > In gem_poll(), do:
> >
On Thu, 2008-02-21 at 19:00 +0100, Eric Dumazet wrote:
> Some oprofile results obtained while using tbench on a 2x2 cpu machine
> were very surprising.
>
> For example, loopback_xmit() function was using high number of cpu
> cycles to perform the statistic updates, supposed to be real cheap
> s
In commit 56addd6eeeb4e11f5a0af7093ca078e0f29140e0 the VLAN multicast list
handling was reworked. Unfortunately, a variable initialization was missed,
and multicast over vlan devices has been broken since 2.6.23-rc1 (apparently
not too many people use this). Trivial fix below, which might be a ca
Eric Dumazet wrote:
Hi David
This is an RFC, based on net-2.6 for convenience only.
Thank you
[RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
Loopback transmit function loopback_xmit() actually calls netif_rx() to
queue
a skb to the softnet queue, and arms a softirq so
On Thursday 21 February 2008, Kok, Auke wrote:
> Kok, Auke wrote:
> > Kok, Auke wrote:
> >> Andrew Morton wrote:
> >>> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <[EMAIL PROTECTED]>
> >>> wrote:
> >>>
> ... and possibly reboot/poweroff (it flows by too fast to be legible).
>
> >
On Thu, 2008-02-21 at 13:54 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2008-02-19 at 22:38 +0100, Johannes Berg wrote:
> > I started getting this warning with recent kernels:
>
> Do that help ?
>
> In gem_poll(), do:
>
> - work_done += gem_rx(gp, budget);
> + work_done += gem_rx(gp, budge
David Miller <[EMAIL PROTECTED]> wrote [02.20.08]:
> From: Jim Westfall <[EMAIL PROTECTED]>
> Date: Wed, 20 Feb 2008 21:46:48 -0800
>
> > static inline void llc_pdu_init_as_test_rsp(struct sk_buff *skb,
> > struct sk_buff *ev_skb)
> > {
> > struc
Hi David
This is an RFC, based on net-2.6 for convenience only.
Thank you
[RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
Loopback transmit function loopback_xmit() actually calls netif_rx() to
queue
a skb to the softnet queue, and arms a softirq so that this skb can be
Kok, Auke wrote:
> Kok, Auke wrote:
>> Andrew Morton wrote:
>>> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <[EMAIL PROTECTED]>
>>> wrote:
>>>
... and possibly reboot/poweroff (it flows by too fast to be legible).
[ 8803.850634] ACPI: Preparing to enter system sleep state S3
Patrick McHardy wrote:
Joe Perches wrote:
This removes the __pure from print_mac, so reject as appropriate...
Add some type safety to print_mac by using struct print_mac_buf *
instead of char *.
And adds back the overhead of two completely unnecessary
function calls to the VLAN fastpath.
Joe Perches wrote:
On Thu, 2008-02-21 at 11:17 +0100, Johannes Berg wrote:
Yeah, I saw that discussion. I think it's fine, it's just something we
need to be aware of. In fact, I Joe had a patch (that seems to have
gotten lost?) to make DECLARE_MAC_BUF() declare a structure with the u8
pointer
Some oprofile results obtained while using tbench on a 2x2 cpu machine
were very surprising.
For example, loopback_xmit() function was using high number of cpu
cycles to perform
the statistic updates, supposed to be real cheap since they use percpu data
pcpu_lstats = netdev_priv(dev);
On Thu, 2008-02-21 at 11:17 +0100, Johannes Berg wrote:
> Yeah, I saw that discussion. I think it's fine, it's just something we
> need to be aware of. In fact, I Joe had a patch (that seems to have
> gotten lost?) to make DECLARE_MAC_BUF() declare a structure with the u8
> pointer in it instead to
David Miller wrote:
From: Harvey Harrison <[EMAIL PROTECTED]>
Date: Thu, 21 Feb 2008 02:01:19 -0800
In this case, it's being passed to a debugfs create function, could it
instead use sysfs_format_mac?
Just assigning print_mac() to a local variable then passing that to
debugfs_create_dir() wil
On Wed, Feb 20, 2008 at 09:15:30PM -0500, John W. Linville wrote:
> Here are a slew of developments intended for 2.6.26. The patches are
> too diverse to comment upon in this summary... :-)
David,
This is additive on top of the pull request from last night. Only
Pavel's fix for the brown-paper
On Thu, 2008-02-21 at 02:05 -0800, David Miller wrote:
> >From another perspective adding that __pure attribute to print_mac()
> might not have been the best idea. But I can't think of another
> way to eliminate the "passing print_mac() args to pr_debug()
> still generates calls to print_mac() eve
Jarek Poplawski wrote, On 02/21/2008 01:08 PM:
...
> Another, probably simpler way would be to move almost all pppol2tp_xmit
...
Actually, the simplest off all seems to be now this old idea to maybe make
sk_dst_lock globally softirq immune. At least I think it's worth of testing,
to check for the
Add more missing initializations of the new nl_info.nl_net field in
IPv6 stack.
This field will be used when network namespaces are fully supported.
Signed-off-by: Benjamin Thery <[EMAIL PROTECTED]>
---
net/ipv6/addrconf.c |9 +
net/ipv6/route.c|6 ++
2 files changed, 15
On Fri, 22 Feb 2008 00:07:31 +0900 (JST)
Atsushi Nemoto <[EMAIL PROTECTED]> wrote:
> > I'm willing to take your word for it, but some documentation would be
> > really nice...
>
> Well, simple grepping drivers/net/phy enlighten us ;)
Yeah, the patch certainly looks correct as far as I can tell
Stephen Hemminger wrote:
On Thu, 21 Feb 2008 12:28:50 +0100
Patrick McHardy <[EMAIL PROTECTED]> wrote:
diff --git a/net/netfilter/nf_conntrack_core.c
b/net/netfilter/nf_conntrack_core.c
index 327e847..b77eb56 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_c
On Thu, 21 Feb 2008 12:28:50 +0100
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Tilman Schmidt wrote:
> > Still, X came up fine, I could log in (Gnome feeling subjectively
> > a bit sluggish), call up a web page from the Internet in Firefox,
> > and start perusing the logs, when the whole system f
On Wed, Feb 20, 2008 at 10:15:10PM -0800, David Miller wrote:
> > ssb: Fix the GPIO API
>
> This could have had a much better changelog, it's way too terse.
You're right. I'll try to police those better.
Thanks,
John
--
John W. Linville
[EMAIL PROTECTED]
--
To unsubscribe from this lis
Excuse me for sending broken mail...
On Thu, 21 Feb 2008 15:12:46 +0100, Haavard Skinnemoen <[EMAIL PROTECTED]>
wrote:
> I have to admit that even after looking through include/linux/phy.h and
> include/linux/mii.h, I don't have the faintest idea what values we can
> expect to find in the "speed"
Ilpo Järvinen wrote:
On Wed, 20 Feb 2008, Vlad Yasevich wrote:
Ilpo Järvinen wrote:
I added inline to sctp_add_cmd and appropriate comment there to
avoid adding another call into the call chain. This works at least
with "gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13)". Alternatively,
__sctp_add_c
On Thu, 21 Feb 2008 15:12:46 +0100, Haavard Skinnemoen <[EMAIL PROTECTED]>
wrote:
> I have to admit that even after looking through include/linux/phy.h and
> include/linux/mii.h, I don't have the faintest idea what values we can
> expect to find in the "speed" field of phydev. The comment above st
On Thu, 21 Feb 2008 22:50:54 +0900 (JST)
Atsushi Nemoto <[EMAIL PROTECTED]> wrote:
> Fix NCFGR.SPD setting on 10Mbps. This bug was introduced by
> conversion to generic PHY layer in kernel 2.6.23.
>
> Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/net/macb.c b/dri
Pavel Emelyanov wrote:
Patrick McHardy wrote:
Pavel Emelyanov wrote:
Patrick McHardy wrote:
It would be nicer to replace the entire hand-made name
allocation to remove the 100 device limit.
Actually, I thought the same, but fixing % in names looks like a
BUG-fix for 2.6.25, while removing t
Patrick McHardy wrote:
> Pavel Emelyanov wrote:
>> Patrick McHardy wrote:
>>
>>> It would be nicer to replace the entire hand-made name
>>> allocation to remove the 100 device limit.
>>>
>> Actually, I thought the same, but fixing % in names looks like a
>> BUG-fix for 2.6.25, while removing the h
Pavel Emelyanov wrote:
Patrick McHardy wrote:
It would be nicer to replace the entire hand-made name
allocation to remove the 100 device limit.
Actually, I thought the same, but fixing % in names looks like a
BUG-fix for 2.6.25, while removing the hand-made name allocation
looks like an en
On Thu, 2008-02-21 at 13:00 +0100, Patrick McHardy wrote:
> I already sent it to Dave for 2.6.25 (I assume that what you meant,
> it was introduced after 2.6.24), its currently sitting in net-2.6
> and should hit Linus' tree next time he pulls from Dave.
I actually meant 2.6.24.x, because I thoug
Patrick McHardy wrote:
> Pavel Emelyanov wrote:
>> Four tunnel drivers (ip_gre, ipip, ip6_tunnel and sit) can
>> receive a pre-defined name for a device from the userspace.
>> Since these drivers call the register_netdevice() after this
>> (rtnl_lock is held), the device's name may contain a '%'
Pavel Emelyanov wrote:
Four tunnel drivers (ip_gre, ipip, ip6_tunnel and sit) can
receive a pre-defined name for a device from the userspace.
Since these drivers call the register_netdevice() after this
(rtnl_lock is held), the device's name may contain a '%'
character.
Not sure how bad is th
On Thu, Feb 21, 2008 at 09:53:56AM +, James Chapman wrote:
> Jarek Poplawski wrote:
...
> The _bh locking fixes in pppol2tp combined with your ppp_generic change
> solved that problem. So I then added data traffic into the mix (since
> this will happen in a real network) and found that lock
Four tunnel drivers (ip_gre, ipip, ip6_tunnel and sit) can
receive a pre-defined name for a device from the userspace.
Since these drivers call the register_netdevice() after this
(rtnl_lock is held), the device's name may contain a '%'
character.
Not sure how bad is this to have a device with a
David Woodhouse wrote:
On Tue, 2008-02-19 at 15:45 +0100, Patrick McHardy wrote:
That would break iptables compilation, which already includes
linux/in.h in some files. I guess the best fix for now is to
include netinet/in.h in busybox and long-term clean this up
properly.
Yeah, that makes sen
On Tue, 2008-02-19 at 15:45 +0100, Patrick McHardy wrote:
> That would break iptables compilation, which already includes
> linux/in.h in some files. I guess the best fix for now is to
> include netinet/in.h in busybox and long-term clean this up
> properly.
Yeah, that makes sense.
Can we push t
Tilman Schmidt wrote:
Still, X came up fine, I could log in (Gnome feeling subjectively
a bit sluggish), call up a web page from the Internet in Firefox,
and start perusing the logs, when the whole system froze: neither
mouse nor keyboard would react anymore, and only the Wind^Wreset
button would
On Wed, 20 Feb 2008 23:26:24 -0800
Harvey Harrison <[EMAIL PROTECTED]> wrote:
> Dave,
>
> Somewhere between 2.6.25-rc1 and -rc2 something changed that produces a
> few hundred sparse warnings in ni52.c.
I gave it a massive clean up but I've not annotated it
>
> I see Alan touched it last.
>
>
David Miller wrote:
From: Joonwoo Park <[EMAIL PROTECTED]>
Date: Thu, 21 Feb 2008 14:36:32 +0900
The function ebt_do_table doesn't take NF_DROP as a verdict from the targets.
Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
Whoops, good catch :-)
Patrick, if you want you can just signoff on
Skip the prefix length matching in source address selection for
orchid -> non-orchid addresses.
Overlay Routable Cryptographic Hash IDentifiers (RFC 4843,
2001:10::/28) are currenty not globally reachable. Without this
check a host with an ORCHID address can end up preferring those over
regular ad
Add a new label for Overlay Routable Cryptographic Hash Identifiers
(RFC 4843) prefix 2001:10::/28 to help proper source address
selection.
ORCHID addresses are used by for example Host Identity Protocol. They are
global and routable, but they currently need support from both endpoints
and there
When print_mac() was marked as __pure to avoid emitting a function
call in pr_debug() scenarios, a warning in this code surfaced since
it relies on the fact that the buffer is modified and doesn't use
the return value. This patch makes it use the return value instead.
Signed-off-by: Johannes Berg
On Thu, 2008-02-21 at 02:05 -0800, David Miller wrote:
> From: Harvey Harrison <[EMAIL PROTECTED]>
> Date: Thu, 21 Feb 2008 02:01:19 -0800
>
> > In this case, it's being passed to a debugfs create function, could it
> > instead use sysfs_format_mac?
>
> Just assigning print_mac() to a local vari
On Thu, 2008-02-21 at 02:12 -0800, David Miller wrote:
> From: Harvey Harrison <[EMAIL PROTECTED]>
> Date: Thu, 21 Feb 2008 02:08:18 -0800
>
> > Really, that should have read:
> >
> > Sparse warning introduced since -rc2:
> > ..etc
> >
> > Harvey's best guess is this commit...
>
> I think the c
On Thu, 2008-02-21 at 02:05 -0800, David Miller wrote:
> From: Harvey Harrison <[EMAIL PROTECTED]>
> Date: Thu, 21 Feb 2008 02:01:19 -0800
>
> > In this case, it's being passed to a debugfs create function, could it
> > instead use sysfs_format_mac?
>
> Just assigning print_mac() to a local varia
From: Harvey Harrison <[EMAIL PROTECTED]>
Date: Thu, 21 Feb 2008 02:08:18 -0800
> Really, that should have read:
>
> Sparse warning introduced since -rc2:
> ..etc
>
> Harvey's best guess is this commit...
I think the commit you originally blamed got added in 2.6.24,
so it would be very difficul
On Thu, 2008-02-21 at 02:03 -0800, David Miller wrote:
> From: Johannes Berg <[EMAIL PROTECTED]>
> Date: Thu, 21 Feb 2008 10:54:59 +0100
>
> > It modifies the buffer, and I think it's more likely that the warning
> > was introduced by
> ...
> > [NET]: Elminate spurious print_mac() calls.
>
>
From: Johannes Berg <[EMAIL PROTECTED]>
Date: Thu, 21 Feb 2008 10:54:59 +0100
> It modifies the buffer, and I think it's more likely that the warning
> was introduced by
...
> [NET]: Elminate spurious print_mac() calls.
Right and that's what I just suggested in another reply.
Harvey how did
From: Harvey Harrison <[EMAIL PROTECTED]>
Date: Thu, 21 Feb 2008 02:01:19 -0800
> In this case, it's being passed to a debugfs create function, could it
> instead use sysfs_format_mac?
Just assigning print_mac() to a local variable then passing that to
debugfs_create_dir() will make the warning g
On Thu, 2008-02-21 at 01:57 -0800, David Miller wrote:
> From: Harvey Harrison <[EMAIL PROTECTED]>
> Date: Thu, 21 Feb 2008 01:34:27 -0800
>
> > commit 0795af5729b18218767fab27c44b1384f72dc9ad
> > Author: Joe Perches <[EMAIL PROTECTED]>
> > Date: Wed Oct 3 17:59:30 2007 -0700
> >
> > [NET]:
On Thu, 2008-02-21 at 01:34 -0800, Harvey Harrison wrote:
> commit 0795af5729b18218767fab27c44b1384f72dc9ad
> Author: Joe Perches <[EMAIL PROTECTED]>
> Date: Wed Oct 3 17:59:30 2007 -0700
>
> [NET]: Introduce and use print_mac() and DECLARE_MAC_BUF()
>
> This is nicer than the MAC_
Jarek Poplawski wrote:
On Wed, Feb 20, 2008 at 10:37:57PM +, James Chapman wrote:
Jarek Poplawski wrote:
(testing patch #1)
But I hope you tested with the fixed (take 2) version of this patch...
Yes I did. :)
But I just got another lockdep error (attached).
Since it's quite experiment
commit 0795af5729b18218767fab27c44b1384f72dc9ad
Author: Joe Perches <[EMAIL PROTECTED]>
Date: Wed Oct 3 17:59:30 2007 -0700
[NET]: Introduce and use print_mac() and DECLARE_MAC_BUF()
This is nicer than the MAC_FMT stuff.
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
Si
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2)
This removes
* functions for which updates have been provided in the preceding patches and
* the @av_vec_len field - it is no longer necessary since the buffer length is
now always computed dynamically;
* conditional debugging code (CONFIG_IP_DCCP_ACKVEC).
The reason for removing the conditi
This patch replaces an almost identical replication of code: large parts
of dccp_parse_options() re-appeared as ccid2_ackvector() in ccid2.c.
Apart from the duplication, this caused two more problems:
1. CCIDs should not need to be concerned with parsing header options;
2. one can not assume tha
This completes the implementation of a circular buffer for Ack Vectors, by
extending the current (linear array-based) implementation. The changes are:
(a) An `overflow' flag to deal with the case of overflow. As before, dynamic
growth of the buffer will not be supported; but code will be ad
This provides a routine to consistently update the buffer state when the
peer acknowledges receipt of Ack Vectors; updating state in the list of Ack
Vectors as well as in the circular buffer.
While based on RFC 4340, several additional (and necessary) precautions were
added to protect the consiste
This patch uupdates the code which registers new packets as received, using the
new circular buffer interface. It contributes a new algorithm which
* supports both tail/head pointers and buffer wrap-around and
* deals with overflow (head/tail move in lock-step).
The updated code is
This patch
* separates Ack Vector housekeeping code from option-insertion code;
* shifts option-specific code from ackvec.c into options.c;
* introduces a dedicated routine to take care of the Ack Vector records;
* simplifies the dccp_ackvec_insert_avr() routine: the BUG_ON was redundant,
si
The problem with Ack Vectors is that
i) their length is variable and can in principle grow quite large,
ii) it is hard to predict exactly how large they will be.
Due to the second point it seems not a good idea to reduce the MPS;
i particular when on average there is enough room for the Ack V
This fixes an oversight from an earlier patch.
The issue is that Ack Vectors must not be parsed on request sockets, since
the Ack Vector feature depends on the selection of the (TX) CCID. During the
initial handshake the CCIDs are undefined, and so RFC 4340, 10.3 applies:
"Using CCID-specific op
This aggregates Ack Vector processing (handling input and clearing old state)
into one function, for the following reasons and benefits:
* all Ack Vector-specific processing is now in one place;
* duplicated code is removed;
* ensuring sanity: from an Ack Vector point of view, it is better to cl
This is a re-packaged resubmission (reduction from about 20 small patches) of
the
Ack Vector patch set, which accomplishes two main things.
First, it completes the implementation of a circular Ack Vector buffer. So far
the buffer was implemented as a linear array which dropped packets on overfl
On Wed, Feb 20, 2008 at 10:37:57PM +, James Chapman wrote:
> Jarek Poplawski wrote:
>
(testing patch #1)
>>
>> But I hope you tested with the fixed (take 2) version of this patch...
>
> Yes I did. :)
>
> But I just got another lockdep error (attached).
>
>> Since it's quite experimental (t
81 matches
Mail list logo
