Larry Finger wrote:
> Ray Lee wrote:
>> Michael Buesch wrote:
>>> On Wednesday 15 November 2006 20:01, Ray Lee wrote:
Suggestions? Requests for even more info?
>>> Yeah, enable bcm43xx debugging.
>>
>> Sigh, didn't even think to look for that. Okay, enabled and compiling
>> a new kernel. This
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
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 :)
By
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 http://vger.kernel.org/majordo
[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 -
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
> > guidelin
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
b/d
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
drivers/i
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
b/drivers/inf
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
b/drivers/infiniband/h
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 +
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
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 a/drivers/infiniband/hw
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
b/drivers/infiniband/hw/cxgb3/iw
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
b/drivers/infiniband/hw/cxgb3/iwch
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 +++--
drivers/infiniband
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-netdev&m=116363600816597&w=2).
The patches are a
Ray Lee wrote:
Michael Buesch wrote:
On Wednesday 15 November 2006 20:01, Ray Lee wrote:
Suggestions? Requests for 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 trigger, if the
-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 immediatel
On Wed, Nov 15, 2006 at 08:16:37PM -0600, Larry Finger wrote:
> NOTE to maintainers: This problem affects BOTH wireless-2.6 and
> 2.6.19-rcX-mmY. At present, the
> "Move IV/ICV" patch has not been incorporated into 2.6.19-rcX and it is OK.
This patch is available in the 'upstream' branch pull re
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.
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: http://service.chelsio.com/kerne
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: ht
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 d
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 f
On Wed, Nov 15, 2006 at 02:39:01PM -0500, Pavel Roskin wrote:
> 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:
>
> I said it before, and it's worth repeating. Dissolving HAL in the
> sources is easy. It's just a matt
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
On Wed, 15 Nov 2006 18:36:43 +0100
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> 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
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 ins
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 i
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 b
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 b
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 man
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 becau
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 dr
On Wednesday 15 November 2006 20:21, 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. ;
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
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. ;)
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 resou
Michael Buesch wrote:
> On Wednesday 15 November 2006 20:01, Ray Lee wrote:
>> Suggestions? Requests for 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 trigger, if the pattern ho
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
On Wednesday 15 November 2006 20:01, Ray Lee wrote:
> Suggestions? Requests for even more info?
Yeah, enable bcm43xx debugging.
--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://
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
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 s
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
Jiri Benc wrote:
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 suppo
Please test if this fixes hwcrypto.
Note that we will require v4 firmware with this patch.
I will remove v3 firmware support, because it's _really_
a huge pain to support both firmware versions.
If someone wants to have v3 support, please fork my tree.
Or alternatively simply install v4 firmware, w
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 b/drivers/net
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 environme
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.
Lon
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 mes
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 H
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 d
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, dev_to_
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 ugl
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
#include
#include
#include
+#include
#include
#include
#include
@@
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 d80
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 s
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?
t
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 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
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
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
> 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 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 "
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. Ch
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 PROTE
* 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
John wrote:
-0009 : System RAM
000a-000b : Video RAM area
000f-000f : System ROM
0010-0ffe : System RAM
0010-00296a1a : Kernel code
00296a1b-0031bbe7 : Kernel data
0fff-0fff2fff : ACPI Non-volatile Storage
0fff3000-0fff : ACPI Tables
2000-2
| > [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 udp_push_pending_fram
72 matches
Mail list logo
