| [NET]: Supporting UDP-Lite (RFC 3828) in Linux
| applied to net-2.6.20, thanks Gerrit.
Many thanks indeed. During these changes I accidentally
forgot to restore udp_push_pending_frames to its static state.
Can you please consider the attached patch --
[NET/IPv4]: Make
* Kumar Gala [EMAIL PROTECTED] 2006-11-14 15:08
And was wondering what the status of this work was. I'm interested
in being able to force packets for a local address out a real
ethernet device.
I'm working on it. For now, use SO_BINDTODEVICE.
-
To unsubscribe from this list: send the line
From: Gerrit Renker [EMAIL PROTECTED]
Date: Wed, 15 Nov 2006 07:58:17 +
[NET/IPv4]: Make udp_push_pending_frames static
udp_push_pending_frames is only referenced within
net/ipv4/udp.c and hence can remain static.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
On Wed, 2006-11-15 at 01:11 +0100, Jiri Benc wrote:
I wouldn't say useless. It's actually a hack (and you yourself described
in (7) why it is currently necessary). We'll need to live with it or
cripple the stack to support only very basic features or rewrite the Linux
networking core. Choose
On Tue, 14 Nov 2006 18:10:50 -0800, Simon Barber wrote:
I disagree that the master device is a hack
It's a clever hack but still a hack. The Linux network interfaces
wasn't designed for the sort of things we do with master interface.
Actually, the networking core doesn't support the concept of
I would go further - and perhaps move some of the meta-data that is in
the skb-cb into a d80211 specific hardware header. This would allow
sniffers to directly attach to the master device and both send and
receive frames complete with the meta data. It would also reduce the
amount of cb
On Wed, 15 Nov 2006 10:16:18 +0100, Johannes Berg wrote:
During the tx handlers phase that copy of skb-cb is extended quite a
lot with other information determined in the tx handlers. The result is a
structure that doesn't fit into cb anymore. This is a reason for not using
cb to pass tx
On Wed, 2006-11-15 at 10:43 +0100, Jiri Benc wrote:
In particular:
- The operations that make sense for user to perform on wiphy/master
interface are different than the ones on virtual interfaces. It isn't
this way now.
Which particular operations do you have in mind? Granted, you won't
On Wed, 2006-11-15 at 11:05 +0100, Jiri Benc wrote:
I wasn't in times when there was no cfg80211. But now... yes, you're
right. The sysfs ieee80211 class exports just some interesting
informations (we already agreed that add_interface and remove_interface
would go away). Feel free to move it
Hi,
Even if the total lock time can be reduced, it's possible that interrupt
handler is executed while the interrupted code is still holding the
semaphore.
I think your method only decrease the frequency of this problem.
Why does reducing the lock time solve this problem?
there are several
Kenzo Iwami wrote:
Hi,
Even if the total lock time can be reduced, it's possible that interrupt
handler is executed while the interrupted code is still holding the
semaphore.
I think your method only decrease the frequency of this problem.
Why does reducing the lock time solve this problem?
On Tue, 2006-11-14 at 10:22 +0800, Hong Liu wrote:
Resend the patch according to Johannes's comments.
Thanks :)
Still put he tkip_key in tx_control structure.
Having the tkip_key in there is actually pretty bad for when/if we want
to push the tx_control into skb-cb (possibly combined with
Hello,
From the previous response that i received, now i have the code and
now m browsing thru it.
1. if i understood correctly.. The discussion thread : wireless notes
/ pre d80211 merge discussion applies to the directory net/d80211/
from git:..
2. Test environment to setup for d80211
Signed-off-by: Ron Mercer [EMAIL PROTECTED]
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index ec640f6..b23ab70 100644
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -22,6 +22,7 @@ #include linux/interrupt.h
#include linux/errno.h
#include linux/ioport.h
#include
We have variants of kmalloc and kmem_cache_alloc that leave leak
tracking to the caller. This is used for subsystem-specific allocators
like skb_alloc.
To make skb_alloc node-aware we need similar routines for the node-aware
slab allocator, which this patch adds.
Note that the code is rather
For node-aware skb allocations we need information about the node
in struct net_device or struct device. Davem suggested to put
it into struct device which this patch does.
In particular:
- struct device gets a new int numa_node member if CONFIG_NUMA is set
- there are two new helpers,
This is the final version of the node-aware skb allocations,
implementing davem's suggestion of storing the numa node in
struct device. I'd love to get this into 2.6.20 now that I
don't hear negative comments about it anymre, but I wonder
how. The first patch toches mm/slab.c, the second struct
Node-aware allocation of skbs for the receive path.
Details:
- __alloc_skb gets a new node argument and cals the node-aware
slab functions with it.
- netdev_alloc_skb passed the node number it gets from dev_to_node
to it, everyone else passes -1 (any node)
Signed-off-by: Christoph
borked again. Patch applied cleanly when I mailed it to myself, but not from
list. Third
try all will be corrected.
oops, that patch is borked (line-wrapped). will resend ASAP.
Ron Mercer.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
David Miller wrote:
However, I wonder if we want to set this differently than the way this
patch does it. Depending on how far off the memory size is from a power
of two (exactly equal to a power of two is the worst case), and if total
memory 128M, it can be substantially less than 3/4.
On Wed, 2006-11-15 at 22:27 +0530, Udayan Singh wrote:
1. if i understood correctly.. The discussion thread : wireless notes
/ pre d80211 merge discussion applies to the directory net/d80211/
from git:..
Right. I CCed you because you seemed interested in d80211.
2. Test environment to
Include of_platform header, and use
new of_[un]register_platform_driver() fns.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
please consider for 2.6.20
drivers/net/ucc_geth.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c
Simon Barber wrote:
I disagree that the master device is a hack - I also disagree that we
should use 802.11 format frames anywhere but internally inside the
802.11 stack. The 802.11 specification does not use 802.11 format frames
to communicate with the upper layers - it uses almost exactly the
On Wednesday 15 November 2006 04:10, John W. Linville wrote:
It is my pleasure to announce that the SFLC [1] has assisted the ar5k
developers in evaluating the development history of Reyk Floeter's
OpenBSD reverse-engineered Atheros HAL, ar5k [2]. SFLC's assessment
leads to the conclusion
On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote:
Now that it seems to be ok to use these openbsd sources, should I port
them to my driver framework?
I looked over the ar5k code and, well, I don't like it. ;)
I don't really like having a HAL. I'd rather prefer a real driver
Michael Buesch wrote:
Yeah, ok. I'll look what I can do. First I'll have to read the code.
and understand it. DMA stuff seems to be really obfuscated though
dozens of callbacks, heh. :)
I'd certainly like to see solid Atheros chipset support in mainline.
If you need any hardware or other
On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote:
On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote:
Now that it seems to be ok to use these openbsd sources, should I port
them to my driver framework?
I looked over the ar5k code and, well, I don't like it. ;)
I
Hello!
On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote:
On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote:
Now that it seems to be ok to use these openbsd sources, should I port
them to my driver framework?
I looked over the ar5k code and, well, I don't like it. ;)
Hey all,
I ran 2.6.19-rc3 for almost two weeks or so with no difficulties (none related
to the bcm43xx driver, at least). However, Andrew asked me to double check the
latest release to see if my problem report against 2.6.18 (hard locks) was
fixed. Good news is that it still is fixed. Bad news is
On Wednesday 15 November 2006 20:39, Pavel Roskin wrote:
Hello!
On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote:
On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote:
Now that it seems to be ok to use these openbsd sources, should I port
them to my driver
On 11/15/06, Johannes Berg [EMAIL PROTECTED] wrote:
On Wed, 2006-11-15 at 22:27 +0530, Udayan Singh wrote:
1. if i understood correctly.. The discussion thread : wireless notes
/ pre d80211 merge discussion applies to the directory net/d80211/
from git:..
Right. I CCed you because you
On Thu, 2006-11-16 at 02:34 +0530, Udayan Singh wrote:
ok. you are referring to bcm43xx , etc
right, all of those drivers use d80211.
lets say we have development happening in d80211 driver. now if i want
to participate in the development of the (d80211), i can do it in a
much better manner
Hi Jeff,
It looks like you didn't apply this patch to #upstream for 2.6.20 so far. We
would really like to get ith in 2.6.20 (we already missed 2.6.19 by a couple
days :)). But, I guess we need some testing in -mm first, so...
thanks,
Brice
Brice Goglin wrote:
Physical pages are used
On Wed, 15 Nov 2006 18:37:01 +0100
Christoph Hellwig [EMAIL PROTECTED] wrote:
+#ifdef CONFIG_NUMA
+#define dev_to_node(dev) ((dev)-numa_node)
+#define set_dev_node(dev, node) ((dev)-numa_node = node)
+#else
+#define dev_to_node(dev) (-1)
+#define set_dev_node(dev, node) do
This is a demo only. IMHO the network device code should take care of bringing
down network devices and restoring them on resume. Some distro's do this with
scripts
and many devices do it themselves in the suspend code. But doing it in the main
netdevice code is best, and means that many network
[TG3]: Disable TSO on 5906 if CLKREQ is enabled.
Due to hardware errata, TSO must be disabled if the PCI Express clock
request is enabled on 5906. The chip may hang when transmitting TSO
frames if CLKREQ is enabled.
Update version to 3.69.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff
My stuff really should have been in response to a differnt mail thread.
driver support for Chelsio T210 10Gb ethernet in 2.6.x
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Compiling the program which uses a lot sysctl syscalls, gives me this
warning on Debian unstable:
warning: the `sysctl' syscall has been removed from 2.6.18+ kernels,
direct access to `/proc/sys' should be used instead.
Is it true? And what can be used as alternative which would work with both
On Nov 16 2006 00:03, Hasso Tepper wrote:
Compiling the program which uses a lot sysctl syscalls, gives me this
warning on Debian unstable:
warning: the `sysctl' syscall has been removed from 2.6.18+ kernels,
direct access to `/proc/sys' should be used instead.
Is it true?
Well it was
Hi,
This patch adds support for the latest Chelsio adapter, T3.
Since some files are bigger than the 40kB advertized in the submit
guidelines, a monolithic patch against 2.6.19-rc5 is posted at the
following URL: http://service.chelsio.com/kernel.org/cxgb3.patch.bz2
Please advise on any other
On Wed, 15 Nov 2006 16:11:36 -0800
divy [EMAIL PROTECTED] wrote:
Hi,
This patch adds support for the latest Chelsio adapter, T3.
Since some files are bigger than the 40kB advertized in the submit
guidelines, a monolithic patch against 2.6.19-rc5 is posted at the
following URL:
On Thursday 16 November 2006 01:11, divy wrote:
This patch adds support for the latest Chelsio adapter, T3.
Since some files are bigger than the 40kB advertized in the submit
guidelines, a monolithic patch against 2.6.19-rc5 is posted at the
following URL:
-stable review patch. If anyone has any objections, please let us know.
--
From: Michael Buesch [EMAIL PROTECTED]
Drain the Microcode TX-status-FIFO before we enable IRQs.
This is required, because the FIFO may still have entries left
from a previous run. Those would immediately
On Wed, 2006-11-15 at 16:33 -0800, Stephen Hemminger wrote:
On Wed, 15 Nov 2006 16:11:36 -0800
divy [EMAIL PROTECTED] wrote:
Hi,
This patch adds support for the latest Chelsio adapter, T3.
Since some files are bigger than the 40kB advertized in the submit
guidelines, a monolithic
Hi.
Michael Buesch wrote:
Well, it never worked for me. But I gave up trying about
half a year ago. But maybe it's just stupid me. ;)
Well, we have various support channels (an IRC channel besides two
mailing lists, for example) that you are welcome to make use of in case
of problems :)
Roland / All:
The following series implements the Chelsio T3 iWARP/RDMA Driver to
be considered for inclusion in 2.6.20. It depends on the Chelsio
T3 Ethernet Driver which is also under review now for 2.6.20
(http://marc.theaimsgroup.com/?l=linux-netdevm=116363600816597w=2).
The patches are
Support provider-specific data in ib_uverbs_cmd_req_notify_cq().
The Chelsio iwarp provider library needs to pass information to the
kernel verb for re-arming the CQ.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/core/uverbs_cmd.c |9 +++--
Code to manipulate the QP.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_qp.c | 996 +
1 files changed, 996 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_qp.c
Functions to manipulate CQs.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_cq.c | 231 +
1 files changed, 231 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cq.c
Debug code to dump various data structs, some of which are in
adapter memory.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/core/cxio_dbg.c | 205 +++
1 files changed, 205 insertions(+), 0 deletions(-)
diff --git
Provider methods to support the Linux RDMA verbs.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_provider.c | 1186 +++
drivers/infiniband/hw/cxgb3/iwch_provider.h | 390 +
drivers/infiniband/hw/cxgb3/iwch_user.h | 68 ++
Core functions to carve up adapter memory, stag, qp, and cq IDs.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/core/cxio_resource.c | 357 ++
drivers/infiniband/hw/cxgb3/core/cxio_resource.h | 70
2 files changed, 427 insertions(+), 0
Code to discover all the T3 devices and register them
with the T3 RDMA Core and the Linux RDMA Core.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch.c | 222
drivers/infiniband/hw/cxgb3/iwch.h | 134 ++
Functions to register memory regions.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_mem.c | 175
1 files changed, 175 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_mem.c
T3 WQE and CQE structures, defines, etc...
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/core/cxio_wr.h | 658
1 files changed, 658 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_wr.h
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/Kconfig |1 +
drivers/infiniband/Makefile |1 +
drivers/infiniband/hw/cxgb3/Kconfig | 27 +++
drivers/infiniband/hw/cxgb3/Makefile| 12
The RDMA Core interfaces with the T3 HW and ULLD providing a low level
RDMA interface.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/core/cxio_hal.c | 1306 +++
drivers/infiniband/hw/cxgb3/core/cxio_hal.h | 201
2 files changed, 1507
Code to handle async events coming from the T3 RDMA Core.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_ev.c | 228 +
1 files changed, 228 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_ev.c
Rafael J. Wysocki wrote:
On Wednesday, 15 November 2006 00:21, Miles Lane wrote:
Hello,
The last three MM kernels have fail to give me a working bcm43xx driver.
The odd thing is that dmesg output seems to indicate that the driver
is working okay. NetworkManager doesn't see the driver, though.
Ray Lee wrote:
Michael Buesch wrote:
On Wednesday 15 November 2006 20:01, Ray Lee wrote:
Suggestions? Requests for shudder even more info?
Yeah, enable bcm43xx debugging.
Sigh, didn't even think to look for that. Okay, enabled and compiling a new
kernel. This will take a few days to
On 11/15/06, Larry Finger [EMAIL PROTECTED] wrote:
Rafael J. Wysocki wrote:
On Wednesday, 15 November 2006 00:21, Miles Lane wrote:
Hello,
The last three MM kernels have fail to give me a working bcm43xx driver.
The odd thing is that dmesg output seems to indicate that the driver
is
Larry Finger wrote:
Ray Lee wrote:
Michael Buesch wrote:
On Wednesday 15 November 2006 20:01, Ray Lee wrote:
Suggestions? Requests for shudder even more info?
Yeah, enable bcm43xx debugging.
Sigh, didn't even think to look for that. Okay, enabled and compiling
a new kernel. This will take
62 matches
Mail list logo
