* Re: [PATCH] net: Cleanup redundant tests on unsigned
From: David Miller @ 2009-10-29 8:40 UTC (permalink / raw)
To: roel.kluin; +Cc: netdev, akpm
In-Reply-To: <4AE1D2D9.5000906@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 23 Oct 2009 17:59:21 +0200
> optlen is unsigned so the `< 0' test is never true.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atm: Cleanup redundant tests on unsigned
From: David Miller @ 2009-10-29 8:40 UTC (permalink / raw)
To: roel.kluin; +Cc: chas, netdev, akpm
In-Reply-To: <4AE1D553.8010406@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 23 Oct 2009 18:09:55 +0200
> The variables are unsigned so the `< 0' test always fails, the
> other part of the test catches wrapped values.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Cleanup redundant tests on unsigned
From: David Miller @ 2009-10-29 8:40 UTC (permalink / raw)
To: roel.kluin; +Cc: netdev, eis, linux-x25, akpm
In-Reply-To: <4AE1CA14.10304@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 23 Oct 2009 17:21:56 +0200
> If there is data, the unsigned skb->len is greater than 0.
>
> rt.sigdigits is unsigned as well, so the test `>= 0' is
> always true, the other part of the test catches wrapped
> values.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Introduce dev_get_by_index_rcu()
From: David Miller @ 2009-10-29 8:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, netdev
In-Reply-To: <4ADD4839.9010500@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 20 Oct 2009 07:18:49 +0200
> [PATCH net-next-2.6] net: Introduce dev_get_by_index_rcu()
>
> Some workloads hit dev_base_lock rwlock pretty hard.
> We can use RCU lookups to avoid touching this rwlock.
>
> netdevices are already freed after a RCU grace period, so this patch
> adds no penalty at device dismantle time.
>
> dev_ifname() converted to dev_get_by_index_rcu()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH 1/7] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area
From: Akinobu Mita @ 2009-10-29 8:53 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, FUJITA Tomonori, David S. Miller, sparclinux,
Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Greg Kroah-Hartman, Lothar Wassmann, linux-usb, Roland Dreier,
Yevgeny Petrilin, netdev, Tony Luck, Fenghua Yu, linux-ia64,
linux-altix, Joerg Roedel
In-Reply-To: <20091028131141.523854cb.akpm@linux-foundation.org>
2009/10/29 Andrew Morton <akpm@linux-foundation.org>:
>
> Why were these patches resent? What changed?
>
> Everybody who is going to review these patches has already reviewed
> them and now they need to review them all again?
I resent the patches because the iommu-helper change was not correct
and I introduced serious bug in bitmap_find_next_zero_area()
if align_mask != 0 in follow-up patch then those were dropped from
the -mm tree.
Only [PATCH 1/7] and [PATCH 2/7] have changes since the first submission of
this patch set.
* [PATCH 1/7]
- Rewrite bitmap_set() and bitmap_clear()
- Let bitmap_find_next_zero_area() check the last bit of the limit
- Add kerneldoc for bitmap_find_next_zero_area()
* [PATCH 2/7]
- Convert find_next_zero_area() to use bitmap_find_next_zero_area() correctly
iommu-helper doesn't want to search the last bit of the limist in bitmap
* [PATCH 3/7] - [PATCH 7/7]
- No changes
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 2%interest rate loan.
From: global loan company @ 2009-10-27 10:50 UTC (permalink / raw)
contact us for 2%interest rate loan.
^ permalink raw reply
* 2%interest rate loan.
From: global loan company @ 2009-10-27 10:52 UTC (permalink / raw)
contact us for 2%interest rate loan.
^ permalink raw reply
* RE: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: Kumar Gopalpet-B05799 @ 2009-10-29 9:32 UTC (permalink / raw)
To: netdev; +Cc: David Miller, avorontsov
In-Reply-To: <20091028.024325.134189895.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Wednesday, October 28, 2009 3:13 PM
>To: Kumar Gopalpet-B05799
>Cc: netdev@vger.kernel.org
>Subject: Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for
>etsec2.0 devices.
>
>From: Sandeep Gopalpet <sandeep.kumar@freescale.com>
>Date: Tue, 27 Oct 2009 22:25:18 +0530
>
>> This patch adds mdio support for etsec2.0 devices.
>>
>> Modified the fsl_pq_mdio structure to include the new mdio members.
>>
>> Signed-off-by: Sandeep Gopalpet <sandeep.kumar@freescale.com>
>
>This is the third time you've submitted this patch, and for
>the third time it DOES NOT apply to net-next-2.6 at all when I
>try to apply this gianfar patch series.
>
>You must be patching against another tree that has some
>changes that conflict with this one.
>
>Sort this out before submitting this again.
>
>If you submit once more this same series, and it doesn't apply
>properly to net-next-2.6, I will flat our ignore your
>submissions for a week or so.
>
>You are wasting that much of my time by doing this over and over.
>
>Get your act together.
>
>
Hi All,
I couldn't find the following commit on the net-next-2.6 tree:
commit e72701acbe0b35e52d3f04d442837c06b4e64f1c
Author: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Wed Oct 14 14:54:52 2009 -0700
net: Fix OF platform drivers coldplug/hotplug when compiled as
modules
Some OF platform drivers are missing module device tables, so they
won't
load automatically on boot. This patch fixes the issue by adding
proper
MODULE_DEVICE_TABLE() macros to the drivers.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The same commit is present on the linux-next tree
I cloned the 2 trees from the following links:
linux-next from:
http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
And net-next-2.6 from:
http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
The absence of the above mentioned commit in the net-next-2.6 tree is
causing
some issues with patches getting applied.
Can you let me know if the net-next-2.6 tree that I am cloning is the
proper one ?
I based all my patches on net-next-2.6 tree cloned from the above link.
But some how when David tries to apply
my patches they fail. I took a diff at the linux-next and net-next-2.6
and the said commit is missing.
-Thanks
Sandeep
^ permalink raw reply
* Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: David Miller @ 2009-10-29 9:45 UTC (permalink / raw)
To: B05799; +Cc: netdev, avorontsov
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B950352@zin33exm22.fsl.freescale.net>
From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
Date: Thu, 29 Oct 2009 15:02:44 +0530
> The absence of the above mentioned commit in the net-next-2.6 tree
> is causing some issues with patches getting applied.
You should never use linux-next as you base for working against
other people's trees.
Instead, clone net-next-2.6 and work purely against that when sending
me patches.
^ permalink raw reply
* Re: [RFC] net,socket: introduce build_sockaddr_check helper to catch overflow at build time
From: David Miller @ 2009-10-29 10:00 UTC (permalink / raw)
To: gorcunov; +Cc: netdev
In-Reply-To: <20091024163226.GA5204@lenovo>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Sat, 24 Oct 2009 20:32:26 +0400
> net,socket: introduce DECLARE_SOCKADDR helper to catch overflow at build time
>
> proto_ops->getname implies copying protocol specific data
> into storage unit (particulary to __kernel_sockaddr_storage).
> So when we implement new protocol support we should keep such
> a detail in mind (which is easy to forget about).
>
> Lets introduce DECLARE_SOCKADDR helper which check if
> storage unit is not overfowed at build time.
>
> Eventually inet_getname is switched to use DECLARE_SOCKADDR
> (to show example of usage).
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
I like this, applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: nfs broken in net-next?
From: Yinghai Lu @ 2009-10-29 10:03 UTC (permalink / raw)
To: Suresh Jayaraman; +Cc: David Miller, Linux Kernel Mailing List, NetDev
In-Reply-To: <4AE9430B.3060105@suse.de>
On Thu, Oct 29, 2009 at 12:23 AM, Suresh Jayaraman <sjayaraman@suse.de> wrote:
> On 10/29/2009 01:43 AM, Yinghai Lu wrote:
>> pk12-3214-189-102:~ # mount -t nfs 10.6.75.100:/data/shared/pxeboot /x
>> mount.nfs: rpc.statd is not running but is required for remote locking.
>> mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
>
> rpc.statd on client should have be started by mount.nfs when a nfs
> filesystem is mounted. Is this not happening for some reason or do you
> see any errors in syslog?
>
>>
>> using opensuse11.1
>>
>
> Are you using 11.1 betas? I know of a problem where non-root user mounts
> fail to start rpc.statd in betas that got fixed later:
>
> http://marc.info/?l=linux-nfs&m=122748525624094&w=2
>
> Is the problem seen only recently (after updating to net-next)?
>
only happen with net-next.
linus tree and tip tree are ok.
YH
^ permalink raw reply
* [PATCH] net: fix kmemcheck annotations
From: Eric Dumazet @ 2009-10-29 10:10 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
struct sk_buff kmemcheck annotations enlarged this structure by 8/16 bytes
Fix this by moving 'protocol' inside flags1 bitfield,
and queue_mapping inside flags2 bitfield.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 0c68fbd..defd51d 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -354,8 +354,8 @@ struct sk_buff {
ipvs_property:1,
peeked:1,
nf_trace:1;
+ __be16 protocol:16;
kmemcheck_bitfield_end(flags1);
- __be16 protocol;
void (*destructor)(struct sk_buff *skb);
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
@@ -367,7 +367,6 @@ struct sk_buff {
#endif
int iif;
- __u16 queue_mapping;
#ifdef CONFIG_NET_SCHED
__u16 tc_index; /* traffic control index */
#ifdef CONFIG_NET_CLS_ACT
@@ -376,6 +375,7 @@ struct sk_buff {
#endif
kmemcheck_bitfield_begin(flags2);
+ __u16 queue_mapping:16;
#ifdef CONFIG_IPV6_NDISC_NODETYPE
__u8 ndisc_nodetype:2;
#endif
^ permalink raw reply related
* RE: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: Kumar Gopalpet-B05799 @ 2009-10-29 10:11 UTC (permalink / raw)
To: netdev; +Cc: avorontsov, David Miller
In-Reply-To: <20091029.024546.90958594.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Thursday, October 29, 2009 3:16 PM
>To: Kumar Gopalpet-B05799
>Cc: netdev@vger.kernel.org; avorontsov@ru.mvista.com
>Subject: Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for
>etsec2.0 devices.
>
>From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
>Date: Thu, 29 Oct 2009 15:02:44 +0530
>
>> The absence of the above mentioned commit in the
>net-next-2.6 tree is
>> causing some issues with patches getting applied.
>
>You should never use linux-next as you base for working
>against other people's trees.
>
>Instead, clone net-next-2.6 and work purely against that when
>sending me patches.
This is the tree I generated the patches against initially.
The initial set of patches were generated against this tree:
(http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git)
Can you please confirm that the above tree is correct.
After you reported the failure,
I merged against the linux-next tree, therein I too got a similar
failure.
The reason being the commit from Anton present in linux-next and absent
on net-next.
The patches sent by me applies cleanly to the above mentioned
net-next-2.6 tree.
--
Thanks
Sandeep
^ permalink raw reply
* Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: David Miller @ 2009-10-29 10:16 UTC (permalink / raw)
To: B05799; +Cc: netdev, avorontsov
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B95035E@zin33exm22.fsl.freescale.net>
From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
Date: Thu, 29 Oct 2009 15:41:22 +0530
> This is the tree I generated the patches against initially.
> The initial set of patches were generated against this tree:
> (http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git)
>
> Can you please confirm that the above tree is correct.
Yes.
> The patches sent by me applies cleanly to the above mentioned
> net-next-2.6 tree.
It may have applied cleanly when you sent them, but by the
time I applied them it didn't.
Resend a fresh patch set against a fresh net-next-2.6 checkout
and let's see what happens :-)
^ permalink raw reply
* Re: [PATCH] net: fix kmemcheck annotations
From: David Miller @ 2009-10-29 10:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE96A1D.8050300@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 29 Oct 2009 11:10:37 +0100
> @@ -367,7 +367,6 @@ struct sk_buff {
> #endif
>
> int iif;
> - __u16 queue_mapping;
> #ifdef CONFIG_NET_SCHED
> __u16 tc_index; /* traffic control index */
> #ifdef CONFIG_NET_CLS_ACT
> @@ -376,6 +375,7 @@ struct sk_buff {
> #endif
>
> kmemcheck_bitfield_begin(flags2);
> + __u16 queue_mapping:16;
> #ifdef CONFIG_IPV6_NDISC_NODETYPE
> __u8 ndisc_nodetype:2;
> #endif
We may be trading size for performance here, I wonder if
it's wise to move queue_mapping like that and what
locality change we get as a result.
^ permalink raw reply
* Re: [PATCH] Re: PACKET_TX_RING: packet size is too long
From: David Miller @ 2009-10-29 10:19 UTC (permalink / raw)
To: gombasg; +Cc: netdev, johann.baudy
In-Reply-To: <20091015201028.GA9780@boogie.lpds.sztaki.hu>
From: Gabor Gombas <gombasg@sztaki.hu>
Date: Thu, 15 Oct 2009 22:10:29 +0200
> Currently PACKET_TX_RING forces certain amount of every frame to remain
> unused. This probably originates from an early version of the
> PACKET_TX_RING patch that in fact used the extra space when the (since
> removed) CONFIG_PACKET_MMAP_ZERO_COPY option was enabled. The current
> code does not make any use of this extra space.
>
> This patch removes the extra space reservation and lets userspace make
> use of the full frame size.
>
> Signed-off-by: Gabor Gombas <gombasg@sztaki.hu>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] Re: PACKET_TX_RING: packet size is too long
From: Gabor Gombas @ 2009-10-29 10:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, johann.baudy
In-Reply-To: <20091029.031917.255459167.davem@davemloft.net>
On Thu, Oct 29, 2009 at 03:19:17AM -0700, David Miller wrote:
> From: Gabor Gombas <gombasg@sztaki.hu>
> Date: Thu, 15 Oct 2009 22:10:29 +0200
>
> > Currently PACKET_TX_RING forces certain amount of every frame to remain
> > unused. This probably originates from an early version of the
> > PACKET_TX_RING patch that in fact used the extra space when the (since
> > removed) CONFIG_PACKET_MMAP_ZERO_COPY option was enabled. The current
> > code does not make any use of this extra space.
> >
> > This patch removes the extra space reservation and lets userspace make
> > use of the full frame size.
> >
> > Signed-off-by: Gabor Gombas <gombasg@sztaki.hu>
>
> Applied, thanks!
Thanks! Does it have a chance to be included in 2.6.32, or it is too
late in the rc series?
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
---------------------------------------------------------
^ permalink raw reply
* RE: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: Kumar Gopalpet-B05799 @ 2009-10-29 10:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev, avorontsov
In-Reply-To: <20091029.031610.04742718.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Thursday, October 29, 2009 3:46 PM
>To: Kumar Gopalpet-B05799
>Cc: netdev@vger.kernel.org; avorontsov@ru.mvista.com
>Subject: Re: [PATCH v2 4/7] fsl_pq_mdio: Add Support for
>etsec2.0 devices.
>
>From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
>Date: Thu, 29 Oct 2009 15:41:22 +0530
>
>> This is the tree I generated the patches against initially.
>> The initial set of patches were generated against this tree:
>>
>(http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
>> )
>>
>> Can you please confirm that the above tree is correct.
>
>Yes.
Thank you. I cloned this tree again about 2 hours ago (and updated it 5
mins ago as well).
git describe:
v2.6.32-rc3-464-gb37b62f
The last commit is: b37b62fea1d1bf68ca51818f8eb1035188efd030
>
>> The patches sent by me applies cleanly to the above mentioned
>> net-next-2.6 tree.
>
>It may have applied cleanly when you sent them, but by the
>time I applied them it didn't.
The PATCH v2 series applied cleanly to the above clone.
>
>Resend a fresh patch set against a fresh net-next-2.6 checkout
>and let's see what happens :-)
Ok. But there is NO change to the patch set.
--
Thanks
Sandeep
^ permalink raw reply
* Re: [PATCH] Re: PACKET_TX_RING: packet size is too long
From: David Miller @ 2009-10-29 10:40 UTC (permalink / raw)
To: gombasg; +Cc: netdev, johann.baudy
In-Reply-To: <20091029102923.GA15314@boogie.lpds.sztaki.hu>
From: Gabor Gombas <gombasg@sztaki.hu>
Date: Thu, 29 Oct 2009 11:29:24 +0100
> On Thu, Oct 29, 2009 at 03:19:17AM -0700, David Miller wrote:
>
>> From: Gabor Gombas <gombasg@sztaki.hu>
>> Date: Thu, 15 Oct 2009 22:10:29 +0200
>>
>> > Currently PACKET_TX_RING forces certain amount of every frame to remain
>> > unused. This probably originates from an early version of the
>> > PACKET_TX_RING patch that in fact used the extra space when the (since
>> > removed) CONFIG_PACKET_MMAP_ZERO_COPY option was enabled. The current
>> > code does not make any use of this extra space.
>> >
>> > This patch removes the extra space reservation and lets userspace make
>> > use of the full frame size.
>> >
>> > Signed-off-by: Gabor Gombas <gombasg@sztaki.hu>
>>
>> Applied, thanks!
>
> Thanks! Does it have a chance to be included in 2.6.32, or it is too
> late in the rc series?
It will be merged to Linus for 2.6.23
^ permalink raw reply
* Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: David Miller @ 2009-10-29 10:43 UTC (permalink / raw)
To: B05799; +Cc: netdev, avorontsov
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B950364@zin33exm22.fsl.freescale.net>
From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
Date: Thu, 29 Oct 2009 16:03:30 +0530
> The PATCH v2 series applied cleanly to the above clone.
It absolutely does NOT!
And I just tried it again to verify this, and you can try it yourself:
http://vger.kernel.org/~davem/bundle-640.mbox
davem@sunset:~/src/GIT/net-next-2.6$ git am --signoff bundle-640.mbox
Applying: gianfar: Add per queue structure support
Applying: gianfar: Introduce logical group support.
Applying: gianfar: Add Multiple Queue Support
Applying: fsl_pq_mdio: Add Suport for etsec2.0 devices.
error: patch failed: drivers/net/fsl_pq_mdio.c:405
error: drivers/net/fsl_pq_mdio.c: patch does not apply
Patch failed at 0004 fsl_pq_mdio: Add Suport for etsec2.0 devices.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
davem@sunset:~/src/GIT/net-next-2.6$
So stop telling me it applies cleanly.
Because I've tried to do it multiple times and it absolutely does not.
^ permalink raw reply
* Re: [PATCH] net: fix kmemcheck annotations
From: Eric Dumazet @ 2009-10-29 10:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091029.031748.235701096.davem@davemloft.net>
David Miller a écrit :
>
> We may be trading size for performance here, I wonder if
> it's wise to move queue_mapping like that and what
> locality change we get as a result.
I agree, but could not convince me it makes a difference.
On 64bit arches, queue_mapping doesnt change its cache line location
(0xa4 -> 0xa8)
On 32bit arches, sizeof(sk_buf)=0xB0, rx and tx paths touch all
of 3 cache lines anyway.
Only thing I can think at this moment is to reorder skb so that TX
completion path dont touch all cache lines (putting together cb[]
and some not touched fields). We could probably gain one cache line miss.
It's a bit hard because of the next/prev fields that must
be first members of structure, but I believe you had some work in progress
in this area, to stick a standard list_head ?
^ permalink raw reply
* Re: [PATCH 3/3] net: TCP thin dupack
From: Andreas Petlund @ 2009-10-29 10:48 UTC (permalink / raw)
To: William Allen Simpson
Cc: netdev, linux-kernel, shemminger, ilpo.jarvinen, davem
In-Reply-To: <4AE7AFC4.3040805@gmail.com>
Den 28. okt. 2009 kl. 03.43 skrev William Allen Simpson:
> Andreas Petlund wrote:
>> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
>> index e64368d..f4a05ff 100644
>> --- a/include/linux/tcp.h
>> +++ b/include/linux/tcp.h
>> @@ -97,6 +97,7 @@ enum {
>> #define TCP_CONGESTION 13 /* Congestion control algorithm */
>> #define TCP_MD5SIG 14 /* TCP MD5 Signature (RFC2385) */
>> #define TCP_THIN_RM_EXPB 15 /* Remove exp. backoff for
>> thin streams*/
>> +#define TCP_THIN_DUPACK 16 /* Fast retrans. after 1
>> dupack */
>>
> I've not had the chance to examine the rest, but I've been poking at a
> patch series that's used 15 for over a year, so could you try 16 and
> 17?
Thank you for the feedback. I will address this in the next patch
iteration.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 11:12 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel, John W. Linville
In-Reply-To: <200910282256.00407.bzolnier@gmail.com>
On Wednesday 28 October 2009 22:56:00 Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 28 October 2009 22:10:32 John W. Linville wrote:
> > Dave,
> >
> > I let my patches pile-up! Yikes!!
> >
> > This request includes the usual ton of stuff for -next -- driver
> > updates, fixes for some earlier -next stuff, a few cfg80211 changes to
> > accomodate the libertas driver, etc. Of note is the rt2800pci support
> > added to the rt2x00 family.
>
> Unfortunately rt2800pci support is non-functioning at the moment... :(
>
> > Pleaset let me know if there are problems!
>
> I find it rather disappointing that all my review comments regarding
> rt2800pci support were just completely ignored and then the initial
> patch was merged just as it was..
>
> The way rt2800usb and rt2800pci drivers are designed really results
> in making the task of adding working support for RT28x0 and RT30x0
> chipsets to rt2x00 infrastructure more difficult and time consuming
> than it should be... :(
What is even more disappointing (especially after all that "working with"
preaching) is that the patch is now in net-next-2.6..
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* GRANT AWARD - 2009
From: grantnotification @ 2009-10-29 11:58 UTC (permalink / raw)
You have been choosen by the U.N Foundation to receive a grant donation of
$1,000 000.00USD.Your Qualification Numbers(G-999-747,UZ-900 77),Contact
Ewa Morgan with Name,Address,country for claim: fedilityclaimsagantdept@gmail.com
United Nations Foundation.
http://www.unfoundation.org/
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: David Miller @ 2009-10-29 12:15 UTC (permalink / raw)
To: bzolnier-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <200910291212.41656.bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 29 Oct 2009 12:12:41 +0100
> What is even more disappointing (especially after all that "working with"
> preaching) is that the patch is now in net-next-2.6..
John is the wireless maintainer, I take his tree in since the changes
in there have his blessing.
If you have a problem with some change in there, work it out with him
and he'll send the fixed up changes to me thereafterwards.
I don't really see what the big deal is, any change can be reverted.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox