Just to clarify an apparent misunderstanding that has snuck into this
thread:
1) There are quite a few people/groups out there who are using TIPC's
socket API, so the protocol as a whole is being used and should remain
in the kernel.
2) There are portions of TIPC's native API which are intended f
Andrew Morton wrote:
> On Wed, 21 Feb 2007 16:57:59 -0800
> [EMAIL PROTECTED] wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=8053
>>
>>Summary: net/ieee80211/ieee80211_crypt_tkip.c spams kernel
>> message buffer
>> Kernel Version: 2.6.20.1
>>
On 2/25/07, David Miller <[EMAIL PROTECTED]> wrote:
From: "Arnaldo Carvalho de Melo" <[EMAIL PROTECTED]>
Date: Sat, 24 Feb 2007 23:49:50 -0200
> Oops, now with the patch.
Thanks, applied.
I'll queue this one up for -stable too.
Thanks!
- Arnaldo
-
To unsubscribe from this list: send the lin
From: "Arnaldo Carvalho de Melo" <[EMAIL PROTECTED]>
Date: Sat, 24 Feb 2007 23:49:50 -0200
> Oops, now with the patch.
Thanks, applied.
I'll queue this one up for -stable too.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More m
Oops, now with the patch.
- Arnaldo
On 2/24/07, Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote:
Hi David,
Please consider applying, this was found on your latest
net-2.6 tree while playing around with that ip_hdr() + turn
skb->nh/h/mac pointers as offsets on 64 bits idea :-)
S
Hi David,
Please consider applying, this was found on your latest
net-2.6 tree while playing around with that ip_hdr() + turn
skb->nh/h/mac pointers as offsets on 64 bits idea :-)
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Regards,
- Arnaldo
-
To unsubscribe from th
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sat, 24 Feb 2007 23:50:21 +0100
> In the CONFIG_IPV6=m, CONFIG_SUNRPC=m case, this will result in no IPV6
> support here.
>
> If you are going this way, a Kconfig helper variable might be better:
>
> config SUNRPC_IPV6
> bool
> default y i
From: Divy Le Ray <[EMAIL PROTECTED]>
Populate Rx free list with pages.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h |9 +
drivers/net/cxgb3/sge.c | 318 +++
2 files changed, 235 insertions(+), 92 deletions(-)
d
From: Divy Le Ray <[EMAIL PROTECTED]>
Offload packets may be DMAed long after their SGE Tx descriptors are done
so they must remain mapped until they are freed rather than until their
descriptors are freed. Unmap such packets through an skb destructor.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTE
From: Divy Le Ray <[EMAIL PROTECTED]>
Update FW version to 3.2
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/t3_hw.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index 365a7f5..ec06ad6 1006
From: Divy Le Ray <[EMAIL PROTECTED]>
Add all-in-sw lro support.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h | 21 ++
drivers/net/cxgb3/common.h |1
drivers/net/cxgb3/cxgb3_ioctl.h |1
drivers/net/cxgb3/cxgb3_main.c | 16 ++
drivers/net
From: Divy Le Ray <[EMAIL PROTECTED]>
Improve the traffic recovery after the HW ran out of response queue entries.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/adapter.h |2 ++
drivers/net/cxgb3/sge.c | 15 ++-
2 files changed, 16 insertions(+), 1 d
From: Divy Le Ray <[EMAIL PROTECTED]>
Clean up some private ioctls.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_ioctl.h | 33 +--
drivers/net/cxgb3/cxgb3_main.c | 48 +++
2 files changed, 15 insertio
From: Divy Le Ray <[EMAIL PROTECTED]>
sysfs attributes are now managed per port, no longer per adapter.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_main.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/net/cxg
Hi Jeff,
I'll be resending the series of incremental patches originally submitted
on 02/22/07.
The series take in account Yoshifuji's comments.
Patch 2 - ioctl cleanup - is updated to secure backward compatibility.
The ioctls are now explicitly numbered.
Patch 6 is also updated with minor chan
On Tue, Feb 13, 2007 at 11:55:10AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <[EMAIL PROTECTED]> (at Mon, 12 Feb 2007 21:35:59 -0500 (EST)),
> Pete Clements <[EMAIL PROTECTED]> says:
>
> > Quoting YOSHIFUJIHideaki/=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=
> > > In article <[EMAIL PROTECT
Michal Piotrowski wrote:
Hi Philip,
Philip Guo napisał(a):
Hi,
I am a graduate student working on finding bugs in Linux drivers using
an automated research tool. I think I've found a possible bug in
net/tc35815.c, and I'd appreciate it if you could confirm/disconfirm it.
Thanks,
Philip
---
Dirk <[EMAIL PROTECTED]> :
[...]
> Are there any additional tests I can do that would be helpfull to you?
Not immediately. I am offline for rugby + party.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
On 2/24/07, Francois Romieu <[EMAIL PROTECTED]> wrote:
Thanks for testing.
Can you try the patch below on top of:
http://www.fr.zoreil.com/people/francois/misc/20070223-2.6.21-rc1-r8169-test.patch
Don't hurry: it's saturday. :o)
... removed patch itself...
I applied both patches (*test.patc
[SKGE]: Fix deadlock in skge_tx_timeout
dev_watchdog() already holds the device lock, don't take it again in
skge_tx_clean().
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 0b1cfafa6f6b8a168d5811d1f65cf540942c52b1
tree 4d3f252d6618adfe812e9da95cd496bb798e7c7b
parent 1ca949299260a
On Fri, Feb 23, 2007 at 17:05:27 -0800, Stephen Hemminger wrote:
> Since there already two users of full 64 bit division in the kernel,
> and other places maybe hiding out as well. Add a full 64/64 bit divide.
>
> Yes this expensive, but there are places where it is necessary.
> It is not clear if
On Sat, 2007-02-24 at 17:40 +0100, Patrick McHardy wrote:
> Peter Zijlstra wrote:
> > On Sat, 2007-02-24 at 17:17 +0100, Patrick McHardy wrote:
> >
> >
> >>I don't really see why
> >>queueing is special though, dropping the packets in the ruleset
> >>will break things just as well, as will routin
Peter Zijlstra wrote:
> On Sat, 2007-02-24 at 17:17 +0100, Patrick McHardy wrote:
>
>
>>I don't really see why
>>queueing is special though, dropping the packets in the ruleset
>>will break things just as well, as will routing them to a blackhole.
>>I guess the user just needs to be smart enough
On Sat, 2007-02-24 at 17:17 +0100, Patrick McHardy wrote:
> I don't really see why
> queueing is special though, dropping the packets in the ruleset
> will break things just as well, as will routing them to a blackhole.
> I guess the user just needs to be smart enough not to do this.
Its user-spa
Peter Zijlstra wrote:
> On Sat, 2007-02-24 at 16:27 +0100, Patrick McHardy wrote:
>
>>> } else if ((verdict & NF_VERDICT_MASK) == NF_QUEUE) {
>>>+if (unlikely((*pskb)->emergency)) {
>>>+printk(KERN_ERR "nf_hook: NF_QUEUE encountered for "
>>>+
On Sat, 2007-02-24 at 16:27 +0100, Patrick McHardy wrote:
> Peter Zijlstra wrote:
> > Emergency skbs should never touch user-space, however NF_QUEUE is fully user
> > configurable. Notify the user of his mistake and try to continue.
> >
> > --- linux-2.6-git.orig/net/netfilter/core.c 2007-02-14 12:
Peter Zijlstra wrote:
> Emergency skbs should never touch user-space, however NF_QUEUE is fully user
> configurable. Notify the user of his mistake and try to continue.
>
> --- linux-2.6-git.orig/net/netfilter/core.c 2007-02-14 12:09:07.0
> +0100
> +++ linux-2.6-git/net/netfilter/core.c
Stephen Hemminger wrote:
> Here is an experimental patch that changes the packet scheduler to use
> ktime instead of gettimeofday. This should be faster on 64 bit and avoid some
> of
> the math overhead issues with previous code.
>
> Also since it uses monotonic clock, it won't cause timing glitc
Hi Philip,
Philip Guo napisał(a):
> Hi,
>
> I am a graduate student working on finding bugs in Linux drivers using
> an automated research tool. I think I've found a possible bug in
> net/tc35815.c, and I'd appreciate it if you could confirm/disconfirm it.
>
> Thanks,
> Philip
>
> ---
> net/tc
LDB wrote:
kalash nainwal wrote:
On 2/22/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
Hello,
I am working on optimizing the TCP-code for a certain type of TCP-stream,
and to make one of my optimizations work I need to copy data from one SKB
(the data field of the skb) to another SK
Dirk <[EMAIL PROTECTED]> :
[...]
> I tried running 2.6.21-rc1 with the patch you mentioned, but it still
> has thesame speed problem. Building the driver with or without NAPI
> support makes no difference.
Thanks for testing.
Can you try the patch below on top of:
http://www.fr.zoreil.com/people
kalash nainwal wrote:
> On 2/24/07, Kristian Evensen <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> I have been looking quite deeply into the TCP-code, but there is one
>> thing I simply dont manage to understand. Can the code process more than
>> one skb on a socket at the time, or is it strictly one
Dmitriy Monakhov <[EMAIL PROTECTED]> writes:
> This thread looks dead but issue was't fixed.
>
> Jiri Kosina <[EMAIL PROTECTED]> writes:
>>> > - pci_enable_device(pdev);
>>> > + ret = pci_enable_device(pdev);
>>> > + if (ret) {
>>> > + printk(KERN_ERR "sk98lin: Cannot enable PCI device %s
On 2/22/07, Francois Romieu <[EMAIL PROTECTED]> wrote:
Can you try the patch below against 2.6.21-rc1:
http://www.fr.zoreil.com/people/francois/misc/20070221-2.6.21-rc1-r8169-test.patch
I tried running 2.6.21-rc1 with the patch you mentioned, but it still
has thesame speed problem. Building th
kalash nainwal wrote:
> On 2/22/07, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> I am working on optimizing the TCP-code for a certain type of TCP-stream,
>> and to make one of my optimizations work I need to copy data from one SKB
>> (the data field of the skb) to another SKB (da
>
> 1. When did you start using GNU/Linux OS?
Not sure. Perhaps 2000.
> 2. What is your level of involvement?
> newbie/ user/ developer (delete as appropriate)
user
> 3. Why are you using Linux?
Stability, keyboard-orientation (don't run a desktop), more fun.
> 4. Is Linux fun? How?
Yes.
On 2/22/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
Hello,
I am working on optimizing the TCP-code for a certain type of TCP-stream,
and to make one of my optimizations work I need to copy data from one SKB
(the data field of the skb) to another SKB (data field).
Currently I am using memcp
On 2/24/07, Kristian Evensen <[EMAIL PROTECTED]> wrote:
Hello,
I have been looking quite deeply into the TCP-code, but there is one
thing I simply dont manage to understand. Can the code process more than
one skb on a socket at the time, or is it strictly one and one?
E.g say that you are going
Using 2.6.21-rc1 (x86-64) I can get an oops in the forcedeth driver in
usually under about 5s with heavy network load (near line-rate GE, a
simpy using netcat and /dev/zero from one host to another suffices).
In nv_rx_done we have:
if (flags & NV_TX_LASTPACKET) {
if (flags
39 matches
Mail list logo
