On Friday 21 April 2006 07:59, Tom Young wrote:
> On Thu, 2006-04-20 at 22:26 -0700, Piet Delaney wrote:
> > I'm upgrading our 2.6.12 kernel to 2.6.13, which includes significant
> > congestion avoidance code additions and changes. I was wondering if
> > there are any tools folks can recommend for
On Thu, 2006-04-20 at 22:26 -0700, Piet Delaney wrote:
> I'm upgrading our 2.6.12 kernel to 2.6.13, which includes significant
> congestion avoidance code additions and changes. I was wondering if
> there are any tools folks can recommend for testing the kernel to make
> sure the congestion avoidan
Begin forwarded message:
Date: Thu, 20 Apr 2006 23:17:58 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6420] New: iptables is complaining with bogus unknown
error 18446744073709551615
http://bugzilla.kernel.org/show_bug.cgi?id=6420
Summary: iptables
I'm upgrading our 2.6.12 kernel to 2.6.13, which includes significant
congestion avoidance code additions and changes. I was wondering if
there are any tools folks can recommend for testing the kernel to make
sure the congestion avoidance code is operating correctly. For
example the displaying of
On Thu, Apr 20, 2006 at 08:42:00PM -0700, David S. Miller wrote:
> This is basically why none of the performance gains add up to me. I
> am thus very concerned that the current non-cache-warming
> implmentation may fall flat performance wise.
Ok, I buy your arguments. It does seems unlikely that
From: Olof Johansson <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 22:04:26 -0500
> On Thu, Apr 20, 2006 at 05:27:42PM -0700, David S. Miller wrote:
> > Besides the control overhead of the DMA engines, the biggest thing
> > lost in my opinion is the perfect cache warming that a cpu based copy
> > doe
From: Pavel Roskin <[EMAIL PROTECTED]>
This is the right thing to do and it prevents kernel BUG on unload.
Some PCMCIA network drivers use link->dev_node as a flag indicating that
the network device has been successfully registered. Recent code
changes cause this flag to be 0 after PCMCIA resour
On Thu, 2006-04-20 at 19:42 -0700, Shaw Vrana wrote:
> I'll bite! Here's a patch to add a call to flush_scheduled_work() in
> e1000_down. It's against 2.6.16.9.
>
You're not following our discussion. It is not safe to call
flush_scheduled_work() in a driver's close() because it is holding the
On Thu, Apr 20, 2006 at 05:44:38PM -0700, David S. Miller wrote:
> From: Olof Johansson <[EMAIL PROTECTED]>
> Date: Thu, 20 Apr 2006 18:33:43 -0500
>
> > On Thu, Apr 20, 2006 at 03:14:15PM -0700, Andrew Grover wrote:
> > > In
> > > addition, there may be workloads (file serving? backup?) where we
I've replied to this once before, but haven't seen my last two emails on the
list, so I'm sending again with different settings. Sorry for the noise.
On Thursday 20 April 2006 17:10, Michael Chan wrote:
> In tg3_remove_one(), we call flush_scheduled_work() in case the
> reset_task is still pendi
On Thu, Apr 20, 2006 at 05:27:42PM -0700, David S. Miller wrote:
> From: Olof Johansson <[EMAIL PROTECTED]>
> Date: Thu, 20 Apr 2006 16:33:05 -0500
>
> > From the wiki:
> >
> > >3. Data copied by I/OAT is not cached
> >
> > This is a I/OAT device limitation and not a global statement of the
On Fri, 2006-04-21 at 12:40 +1000, Herbert Xu wrote:
> One simple solution is to establish a separate queue for RTNL-holding
> users or vice versa for non-RTNL holding networking users. That
> would allow the drivers to safely flush the non-RTNL queue while
> holding the RTNL.
You mean a separat
Andrew,
> I did not
> think the source IP was relevant to the matching code in linux, since
> there are no source squelching socket options.
>
> There are no firewall rules active on this machine, and the packets are
> definitely visible at the interface (see tcpdump output in my email).
On Fri, Apr 21, 2006 at 12:37:36PM +1000, Herbert Xu wrote:
>
> Rather than dealing with this individually in each driver perhaps we should
> come up with a more centralised solution?
One simple solution is to establish a separate queue for RTNL-holding
users or vice versa for non-RTNL holding ne
On Thursday 20 April 2006 17:10, Michael Chan wrote:
> In tg3_remove_one(), we call flush_scheduled_work() in case the
> reset_task is still pending. Here, it is safe to call
> flush_scheduled_work() because we're not holding the rtnl. Again, when
> it runs, nothing bad will happen because it will
Michael Chan <[EMAIL PROTECTED]> wrote:
>
> In tg3_remove_one(), we call flush_scheduled_work() in case the
> reset_task is still pending. Here, it is safe to call
Great.
> flush_scheduled_work() because we're not holding the rtnl. Again, when
Hmm doing a quick grep seems to indicate that quite
David S. Miller <[EMAIL PROTECTED]> wrote:
>
> For I/O AT you'd really want to get the DMA engine going as soon
> as you had those packets, but I do not see a clean and reliable way
> to determine the target pages before the app gets back to recvmsg().
The vmsplice() system call proposed by Linus
On Fri, 2006-04-21 at 11:33 +1000, Herbert Xu wrote:
> Actually, what if the tg3_close is followed by a tg3_open? That could
> produce a spurious reset which I suppose isn't that bad.
Yes, an extra reset. And yes, it isn't too bad.
> Also if the
> module is unloaded bad things will happen as wel
On Thu, Apr 20, 2006 at 06:55:58PM -0400, Jeff Garzik wrote:
> Also, janitors, there are more NIC specs at
> http://gkernel.sourceforge.net/specs/ than are listed on the wiki. What
> I posted is just a starter list. If someone were to comb through each
> PDF in the /specs/ sub-directories, and ma
On Fri, Apr 21, 2006 at 11:27:01AM +1000, herbert wrote:
> On Thu, Apr 20, 2006 at 03:36:57PM -0700, Michael Chan wrote:
> >
> > If we're in tg3_close() and the reset task isn't running yet, tg3_close
> > () will proceed. However, when the reset task finally runs, it will see
> > that netif_running
Jean Tourrilhes wrote:
The original behaviour was that the event was sent only when a
user did request a scan. At that time, cards did not do background
scanning, so new scan results would be produced only as a result of a
user scan.
After a short discussion we Dan, we agree that
On Thu, Apr 20, 2006 at 03:36:57PM -0700, Michael Chan wrote:
>
> If we're in tg3_close() and the reset task isn't running yet, tg3_close
> () will proceed. However, when the reset task finally runs, it will see
> that netif_running() is zero and will just return.
Yes you're absolutely right.
Tha
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 18:00:37 -0700
> Actually, that brings-up a question - presently, and for reasons that
> are lost to me in the mists of time - netperf will "access" the buffer
> before it calls recv(). I'm wondering if that should be changed to an
>
David S. Miller wrote:
From: "Andrew Grover" <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 15:14:15 -0700
First obviously it's a technology for RX CPU improvement so there's no
benefit on TX workloads. Second it depends on there being buffers to
copy the data into *before* the data arrives. This
Unfortunately, many benchmarks just do raw bandwidth tests sending to
a receiver that just doesn't even look at the data. They just return
from recvmsg() and loop back into it. This is not what applications
using networking actually do, so it's important to make sure we look
intelligently at any
David:
Thank you for taking the time to respond.
The packets are arriving via a switched network composed of Cisco
devices in PIM dense mode. The packets pass through several switch
hops, but no routing hops that have been documented to me. I did not
think the source IP was relevant to the
From: Olof Johansson <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 18:33:43 -0500
> On Thu, Apr 20, 2006 at 03:14:15PM -0700, Andrew Grover wrote:
> > In
> > addition, there may be workloads (file serving? backup?) where we
> > could do a skb->page-in-page-cache copy and avoid cache pollution?
>
> Y
From: "Andrew Grover" <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 15:14:15 -0700
> First obviously it's a technology for RX CPU improvement so there's no
> benefit on TX workloads. Second it depends on there being buffers to
> copy the data into *before* the data arrives. This happens to be the
> c
From: Olof Johansson <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 16:33:05 -0500
> From the wiki:
>
> >3. Data copied by I/OAT is not cached
>
> This is a I/OAT device limitation and not a global statement of the
> DMA infrastructure. Other platforms might be able to prime caches
> with the DM
On Fri, 2006-04-21 at 09:51 +1000, Herbert Xu wrote:
>
> Actually TG3 is buggy too. If the reset task is scheduled but
> isn't running yet there is no synchronisation here to prevent the
> reset task from running after tg3_close releases the tp lock.
>
If we're in tg3_close() and the reset tas
I've run your test program and it receives fine for me.
I note that the source address is not on the same subnet as
(any of) the receiver's addresses. Are the packets being
routed? The default multicasting TTL is 1, though I don't
know if it'll be checked or dropped on the receiver, seeing
as we a
On Fri, Apr 21, 2006 at 09:36:31AM +1000, herbert wrote:
>
> Yes that's definitely buggy. There needs to be some form of
> synchronisation as the TG3 driver does. However, to be frank
> I'm not too fond of what the TG3 driver does either. Is there
> no better way than an msleep loop?
Actually
On Thu, 20 Apr 2006, James Smart wrote:
> Note: We've transitioned off topic. If what this means is "there isn't a
> good
> way except by ioctls (which still isn't easily portable) or system calls",
> then that's ok. Then at least we know the limits and can look at other
> implementation alternat
Andi,
The driver will be polling(listening) to netlink for
any configuration requests. We could release the user
tools but not sure where(in the tree) they would reside.
Thanks,
Ravi
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 19, 2006 5:51 PM
To:
On Thu, Apr 20, 2006 at 05:35:00PM +, [EMAIL PROTECTED] wrote:
>
> If the e1000_tx_timeout_task were running concurrently with e1000_down, it
> seems that they could both attempt to kfree_skb concurrently when running
> e1000_unmap_and_free_tx_resource. I googled around to find mention of
On Thu, Apr 20, 2006 at 03:14:15PM -0700, Andrew Grover wrote:
> Hah, I was just writing an email covering those. I'll incorporate that
> into this reponse.
>
> On 4/20/06, Olof Johansson <[EMAIL PROTECTED]> wrote:
> > I guess the overall question is, how much of this needs to be addressed
> > in
I started a specs section on the linux-net wiki:
http://linux-net.osdl.org/index.php?title=Network-Adapters#Hardware_specifications
If you add to this list, please be SURE of the specification's origin.
We do not want to link to any "fell off the back of a truck" specs of
questionable origin.
On Thu, 20 Apr 2006, Andrew Morton wrote:
> "John W. Linville" <[EMAIL PROTECTED]> wrote:
> >
> > At present, all the branches in wireless-2.6 only pull from linux-2.6.
> > I am still pushing (i.e. requesting Jeff's pull) to netdev-2.6,
> > if that matters.
> >
> > Maybe the current wireless
Hah, I was just writing an email covering those. I'll incorporate that
into this reponse.
On 4/20/06, Olof Johansson <[EMAIL PROTECTED]> wrote:
> I guess the overall question is, how much of this needs to be addressed
> in the implementation before merge, and how much should be done when
> more dr
Andrew Morton wrote:
A bunch of e1000 changes just hit Jeff's tree.
Hopefully things are now fixed in git-netdev-all...
Jeff
-
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.o
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
drivers/net/ne.c |2
drivers/net/wireless/Kconfig |2
drivers/net/wireless/airo.c
The Ethernet bridge code silently drops packets when forwarding a packet
that is too large for the destination interface (as per 802.1d). But it
should allow for VLAN tagged frames.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- bridge.orig/net/bridge/br_forward.c 2006-04-10 16:17:51.00
On Thu, Apr 20, 2006 at 01:49:16PM -0700, Andrew Grover wrote:
> Hi I'm reposting these, originally posted by Chris Leech a few weeks ago.
> However, there is an extra part since I broke up one patch that was too
> big for netdev last time into two (patches 2 and 3).
>
> Of course we're always lo
Hi,
On Thu, Apr 20, 2006 at 01:50:40PM -0700, Andrew Grover wrote:
>
> Any socket recv of less than this ammount will not be offloaded
[...]
> --- a/net/core/user_dma.c
> +++ b/net/core/user_dma.c
> @@ -33,6 +33,10 @@
>
> #ifdef CONFIG_NET_DMA
>
> +#define NET_DMA_DEFAULT_COPYBREAK 1024
> +
Andy Fleming wrote:
This patch fixes several bugs in the gianfar driver, including a major one
where spinlocks were horribly broken:
* Split gianfar locks into two types: TX and RX
* Made it so gfar_start() now clears RHALT
* Fixed a bug where calling gfar_start_xmit() with interrupts off would
John W. Linville wrote:
The following changes since commit 0efd9323f32c137b5cf48bc6582cd08556e7cdfc:
Linus Torvalds:
Merge branch 'splice' of git://brick.kernel.dk/data/git/linux-2.6-block
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wir
Kok, Auke wrote:
Hi,
This patch series implements two e100 fixes for an old and new patch mishap.
[1] fix mispatch for media type detect.
[2] fix mismerge skb_put.
These changes are available through git.
git://63.64.152.142/~ahkok/git/netdev-2.6 e1000-7.0.38-k2-fixes
applied
-
To unsubs
Frank Pavlic wrote:
Hi jeff,
after the first shot I sent to you did not apply I
resend two new patches I've made today to remove tty from ctc network driver.
Please apply
Thank you ...
applied 1-2 to #upstream (queued for 2.6.18, since 2.6.17 is in -rc)
-
To unsubscribe from this list
This patch removes the unused EXPORT_SYMBOL(tr_source_route).
(No, the usage in net/llc/llc_output.c can't be modular.)
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.17-rc1-mm3-full/net/802/tr.c.old 2006-04-20 22:45:07.0
+0200
+++ linux-2.6.17-rc1-mm3-full/net/802/tr.c
Second half of the ioatdma.c diff, split up to make it past netdev size
block -- Andy
Adds a new ioatdma driver, ioatdma.c
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c | 805 +++
diff --git a/drivers/dma/ioatdma.c b/dr
patch 2 got blocked due to size, here is the diff in 2 parts. -- Andy
Adds a new ioatdma driver, ioatdma.c
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c | 805 +++
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdm
Adds an async_wait_queue and some additional fields to tcp_sock, and a
dma_cookie_t to sk_buff.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
include/linux/skbuff.h |4
include/linux/tcp.h|8
include/net/sock.h |2 ++
include/net/tcp.h |7 +++
Provides for pinning user space pages in memory, copying to iovecs,
and copying from sk_buffs including fragmented and chained sk_buffs.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/Makefile |3
drivers/dma/iovlock.c | 301 ++
Hi I'm reposting these, originally posted by Chris Leech a few weeks ago.
However, there is an extra part since I broke up one patch that was too
big for netdev last time into two (patches 2 and 3).
Of course we're always looking for more style improvement comments, but
more importantly we're po
Any socket recv of less than this ammount will not be offloaded
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
include/linux/sysctl.h |1 +
include/net/tcp.h |1 +
net/core/user_dma.c|4
net/ipv4/sysctl_net_ipv4.c | 10 ++
diff --git a/includ
Locks down user pages and sets up for DMA in tcp_recvmsg, then calls
dma_async_try_early_copy in tcp_v4_do_rcv
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
net/ipv4/tcp.c | 101 --
net/ipv4/tcp_input.c | 74
Provides an API for offloading memory copies to DMA devices
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/Kconfig |2
drivers/Makefile |1
drivers/dma/Kconfig | 13 +
drivers/dma/Makefile |1
drivers/dma/dmaengine.c | 405 +
Add an extra argument to sk_eat_skb, and make it move early copied packets
to the async_wait_queue instead of freeing them.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
include/net/sock.h | 13 -
net/dccp/proto.c |4 ++--
net/ipv4/tcp.c |8
net/llc/af_
Attempts to allocate per-CPU DMA channels
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/Kconfig | 12 +
include/linux/netdevice.h |4 ++
include/net/netdma.h | 38
net/core/dev.c| 104
Adds a new ioatdma driver, ioatdma.c
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c | 805 +++
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c
new file mode 100644
index 000..ffe47dd
--- /dev/null
+++ b/dri
Needed to be able to call tcp_cleanup_rbuf in tcp_input.c for I/OAT
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
include/net/tcp.h |2 ++
net/ipv4/tcp.c| 10 +-
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 54e4367..ca5bdaf 100644
--- a/include/net/tcp.h
+++
Mike Christie wrote:
> James Smart wrote:
>> Note: We've transitioned off topic. If what this means is "there isn't a
>> good
>> way except by ioctls (which still isn't easily portable) or system calls",
>> then that's ok. Then at least we know the limits and can look at other
>> implementation alt
James Smart wrote:
> Note: We've transitioned off topic. If what this means is "there isn't a
> good
> way except by ioctls (which still isn't easily portable) or system calls",
> then that's ok. Then at least we know the limits and can look at other
> implementation alternatives.
>
> Mike Christi
Mike Christie wrote:
> James Smart wrote:
>
>>Mike Christie wrote:
>>
>>>For the tasks you want to do for the fc class is performance critical?
>>
>>No, it should not be.
>>
>>
>>>If not, you could do what the iscsi class (for the netdev people this is
>>>drivers/scsi/scsi_transport_iscsi.c) does
Note: We've transitioned off topic. If what this means is "there isn't a good
way except by ioctls (which still isn't easily portable) or system calls",
then that's ok. Then at least we know the limits and can look at other
implementation alternatives.
Mike Christie wrote:
James Smart wrote:
Mi
"John W. Linville" <[EMAIL PROTECTED]> wrote:
>
> At present, all the branches in wireless-2.6 only pull from linux-2.6.
> I am still pushing (i.e. requesting Jeff's pull) to netdev-2.6,
> if that matters.
>
> Maybe the current wireless-2.6 tree fits into your system better?
Works well, thanks
From: Mike Christie <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 14:29:06 -0500
> I was wondering if it is ok to pass sendpage high mem pages. If a piece
> of code does this:
>
> struct socket *sock;
>
> sock->ops->sendpage(pg...)
>
> and pg is a highmem page will the network layer do the right t
From: jamal <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2006 06:58:45 -0400
> On Fri, 2006-14-04 at 15:05 -0700, David S. Miller wrote:
> > From: jamal <[EMAIL PROTECTED]>
> > Date: Thu, 13 Apr 2006 09:00:08 -0400
> >
> > > There is dependency on the previous patch i sent since the issue that
> > > pat
[ Maybe ask questions like this on "netdev" where the networking
developers hang out? Added to CC: ]
Van fell off the face of the planet after giving his presentation and
never published his code, only his slides.
I've started to make a slow attempt at implementing his ideas, nothing
but pure
This patchset fixes more things in softmac, the first patch implements
the SIOCSIWMLME wext, the second fixes the SIOCSIWAP wext and the third
cleans up the event code.
The second is a fairly important fix for wpa_supplicant and should probably
still go to 2.6.17, the others can go in too of cours
This patch adds the SIOCSIWMLME wext to softmac, this functionality
appears to be used by wpa_supplicant and is softmac-specific.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Cc: Jouni Malinen <[EMAIL PROTECTED]>
--- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_priv.h
2006-04
There are some bugs in the current implementation of the SIOCSIWAP wext,
for example that when you do it twice and it fails, it may still try
another access point for some reason. This patch fixes this by introducing
a new flag that tells the association code that the bssid that is in use
was fixed
Mike Christie wrote:
> James Smart wrote:
>> Mike Christie wrote:
>>> For the tasks you want to do for the fc class is performance critical?
>> No, it should not be.
>>
>>> If not, you could do what the iscsi class (for the netdev people this is
>>> drivers/scsi/scsi_transport_iscsi.c) does and jus
Mike Christie wrote:
> James Smart wrote:
>> Mike Christie wrote:
>>> For the tasks you want to do for the fc class is performance critical?
>> No, it should not be.
>>
>>> If not, you could do what the iscsi class (for the netdev people this is
>>> drivers/scsi/scsi_transport_iscsi.c) does and jus
James Smart wrote:
>
> Mike Christie wrote:
>> For the tasks you want to do for the fc class is performance critical?
>
> No, it should not be.
>
>> If not, you could do what the iscsi class (for the netdev people this is
>> drivers/scsi/scsi_transport_iscsi.c) does and just suffer a couple
>> c
On Thu, Apr 20, 2006 at 09:43:54AM -0700, Jean Tourrilhes wrote:
> After we changed to behaviour of ipw, various users reported
> that wpa_supplicant was confused. I particularly trust the report of
> Bill Moss, who has been hacking ipw for a long time :
>
> http://sourceforge.net/mailarchiv
On Thu, Apr 20, 2006 at 10:37:32AM -0400, Dan Williams wrote:
> On Thu, 2006-04-20 at 15:15 +0100, Daniel Drake wrote:
> > Hi Jean,
> >
> > A query regarding wireless events: under which circumstances should a
> > driver/stack send a SIOCGIWSCAN event to userspace?
> >
> > Should it be sent when
On Thu, Apr 20, 2006 at 03:15:59PM +0100, Daniel Drake wrote:
> I think the 'extra' SIOCGIWSCAN event may be confusing wpa_supplicant
> (but have not confirmed that yet).
No, they don't. madwifi-ng is already doing this with background
scanning and as was pointed out, there can be multiple progr
On 4/20/06, Jack Vogel <[EMAIL PROTECTED]> wrote:
> On 4/19/06, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > On Wed, Apr 19, 2006 at 10:28:41AM -0700, John Ronciak wrote:
> > > The hardware is going to generally available in June. There are also
> > > lots of OEMs, OSVs and hardware vendors th
On 4/19/06, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 19, 2006 at 10:28:41AM -0700, John Ronciak wrote:
> > The hardware is going to generally available in June. There are also
> > lots of OEMs, OSVs and hardware vendors that have the system to test
> > on today. The early rollou
On Thu, 2006-04-20 at 15:15 +0100, Daniel Drake wrote:
> Hi Jean,
>
> A query regarding wireless events: under which circumstances should a
> driver/stack send a SIOCGIWSCAN event to userspace?
>
> Should it be sent whenever a driver has new scan results available, or
> only when the user reque
Mike Christie wrote:
For the tasks you want to do for the fc class is performance critical?
No, it should not be.
If not, you could do what the iscsi class (for the netdev people this is
drivers/scsi/scsi_transport_iscsi.c) does and just suffer a couple
copies. For iscsi we do this in usersp
Hi Jean,
A query regarding wireless events: under which circumstances should a
driver/stack send a SIOCGIWSCAN event to userspace?
Should it be sent whenever a driver has new scan results available, or
only when the user requested a scan a short time beforehand (via
SIOCSIWSCAN)?
I ask thi
> > As spinlock debugging still does not work with the qeth driver I
> > want to pick up the discussion.
>
> Does something like the patch below work?
>
> But this all begs the question, what happens if you want to
> dig into the internals of a protocol which is built modular and
> hasn't been lo
On Thu, Apr 20, 2006 at 01:57:52AM -0700, Andrew Morton wrote:
> And I really need to find a way of getting git-wireless into -mm. Problem
> is, it's based off git-netdev-all and when John's tree is synced to a later
> version of Linus's tree than Jeff's tree, all hell breaks loose at my end.
F
On Fri, 2006-14-04 at 15:05 -0700, David S. Miller wrote:
> From: jamal <[EMAIL PROTECTED]>
> Date: Thu, 13 Apr 2006 09:00:08 -0400
>
> > There is dependency on the previous patch i sent since the issue that
> > patch fixes is assumed in this text description. It would be a good
> > idea to apply
On Thursday 20 April 2006 10:57, you wrote:
> Michael Buesch <[EMAIL PROTECTED]> wrote:
> >
> > On Thursday 20 April 2006 03:12, John W. Linville wrote:
> > > bcm43xx: fix dyn tssi2dbm memleak
> > > bcm43xx: fix pctl slowclock limit calculation
> > > bcm43xx: sysfs code cleanup
>
Michael Buesch wrote:
On Thursday 20 April 2006 03:12, John W. Linville wrote:
bcm43xx: fix dyn tssi2dbm memleak
bcm43xx: fix pctl slowclock limit calculation
bcm43xx: sysfs code cleanup
These are already in -mm and on their way into linus's tree.
Is it possible to cause prob
Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> On Thursday 20 April 2006 03:12, John W. Linville wrote:
> > bcm43xx: fix dyn tssi2dbm memleak
> > bcm43xx: fix pctl slowclock limit calculation
> > bcm43xx: sysfs code cleanup
>
> These are already in -mm and on their way into linus'
On Thursday 20 April 2006 03:12, John W. Linville wrote:
> bcm43xx: fix dyn tssi2dbm memleak
> bcm43xx: fix pctl slowclock limit calculation
> bcm43xx: sysfs code cleanup
These are already in -mm and on their way into linus's tree.
Is it possible to cause problems?
If not, fine.
On Wed, Apr 19, 2006 at 04:13:24PM -0700, Andrew Morton wrote:
> "David S. Miller" <[EMAIL PROTECTED]> wrote:
> >
> > From: Andrew Morton <[EMAIL PROTECTED]>
> > Date: Wed, 19 Apr 2006 15:59:25 -0700
> >
> > > "David S. Miller" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > An earlier variant of your
91 matches
Mail list logo
