From: Michael Buesch <[EMAIL PROTECTED]>
iIf bcm43xx were to process an afterburner (ampdu) status response, Linux would
oops. The
ampdu and intermediate status bits are properly named.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index:
On Thu, 2007-02-01 at 13:12 +0300, Evgeniy Polyakov wrote:
> Generic event handling mechanism.
The patch applied cleanly to 2.6.20 final, but I got a build error:
CC kernel/kevent/kevent.o
CC kernel/kevent/kevent_user.o
CC kernel/kevent/kevent_timer.o
CC kernel/kevent/
On Mon, 05 Feb 2007 18:44:08 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote:
> I bet this rcu_read_lock()-implies-preempt_disable() assumption has
> spread into other areas of the tree as well.
Me too. Although one expects that other holes will cause might_sleep or
lockdep warnings pretty ea
David Miller wrote:
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:31:04 -0800
From: "Joe Jin" <[EMAIL PROTECTED]>
Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls in
the bonding driver.
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Mon, 5 Feb 2007 18:18:10 -0800
> I think the finger was pointed at preemptible rcu, in -mm. iirc,
> the net stats code is assuming that rcu_read_lock() disables
> preemption as a side-effect, which rcu-preempt makes no-longer-true.
>
> Not sure what t
On Mon, 05 Feb 2007 18:10:26 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote:
> From: [EMAIL PROTECTED]
> Date: Mon, 05 Feb 2007 16:31:11 -0800
>
> > From: Andrew Morton <[EMAIL PROTECTED]>
> >
> > "using smp_processor_id() in preemptible code"
> >
> > Cc: Patrick McHardy <[EMAIL PROTECTED]>
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:31:09 -0800
> From: Andrew Morton <[EMAIL PROTECTED]>
>
> sparc64:
>
> net/dccp/ccids/ccid3.c: In function `ccid3_hc_tx_packet_recv':
> net/dccp/ccids/ccid3.c:480: warning: long long unsigned int format, __u64 arg
> (arg 6)
> net/dccp/ccids/ccid
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:31:11 -0800
> From: Andrew Morton <[EMAIL PROTECTED]>
>
> "using smp_processor_id() in preemptible code"
>
> Cc: Patrick McHardy <[EMAIL PROTECTED]>
> Cc: "David S. Miller" <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
W
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:31:06 -0800
> From: "Robert P. J. Day" <[EMAIL PROTECTED]>
>
> Remove the unused kernel config option DLCI_COUNT.
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
> Cc: "David S. Miller" <[EMAIL PROTECTED]>
> Cc: Jeff Garzik <[EMAIL PROTEC
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:31:06 -0800
> From: joe jin <[EMAIL PROTECTED]>
>
> This patch replace kmalloc() + memset() pairs with the appropriate
> kzalloc().
>
> Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Applied, thanks
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:31:05 -0800
> From: Frederik Deweerdt <[EMAIL PROTECTED]>
>
> The tcphdr struct passed to tcp_v4_check is not used, the following
> patch removes it from the parameter list.
>
> Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
> Signed-off-by
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:31:05 -0800
> From: Adrian Bunk <[EMAIL PROTECTED]>
>
> This patch contains the following cleanups:
> - make the following needlessly global functions static:
> - lock_adapter_irq()
> - unlock_adapter_irq()
> - #if 0 the following unused globa
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:31:04 -0800
> From: "Joe Jin" <[EMAIL PROTECTED]>
>
> Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls in
> the bonding driver.
>
> Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:30:56 -0800
> From: Daniel Walker <[EMAIL PROTECTED]>
>
> This was reported by Ingo Molnar here,
>
> http://lkml.org/lkml/2006/12/18/119
>
> The problem is that adummy_init() depends on atm_init() , but adummy_init()
> is called first.
>
> So I
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:30:53 -0800
> From: Adrian Bunk <[EMAIL PROTECTED]>
>
> Add proper prototypes for some functions in include/net/irda/irda.h
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> Acked-by: Samuel Ortiz <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Mo
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:30:52 -0800
> From: Arjan van de Ven <[EMAIL PROTECTED]>
>
> This patch introduces users of the round_jiffies() function in the networking
> code.
>
> These timers all were of the "about once a second" or "about once every X
> seconds" variety an
From: John Heffner <[EMAIL PROTECTED]>
Date: Mon, 05 Feb 2007 19:11:09 -0500
> My first patch was broken anyway (should not have pulled the test from
> tso_should_defer), and the change is not needed to the nagle test since
> it's implicit. This patch just restores the old behavior from before
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Tue, 06 Feb 2007 10:44:08 +0900 (JST)
> Yes, I agree, but I think it is different issue, and
> maybe, we should check and change other places as well,
> in separate patch(es).
I agree.
-
To unsubscribe from this list: send the line "unsubscribe ne
In article <[EMAIL PROTECTED]> (at Mon, 05 Feb 2007 17:32:58 -0800 (PST)),
David Miller <[EMAIL PROTECTED]> says:
> From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
> Date: Tue, 06 Feb 2007 10:24:05 +0900 (JST)
>
> > > @@ -498,7 +500,8 @@ static void ndisc_send_na(struct net_device *dev,
> > > struc
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Tue, 06 Feb 2007 10:24:05 +0900 (JST)
> > @@ -498,7 +500,8 @@ static void ndisc_send_na(struct net_device *dev,
> > struct neighbour *neigh,
> > msg->icmph.icmp6_unused = 0;
> > msg->icmph.icmp6_router= router;
> > m
Hello.
In article <[EMAIL PROTECTED]> (at Mon, 5 Feb 2007 15:56:51 -0500), Neil Horman
<[EMAIL PROTECTED]> says:
> if (ifp == NULL && valid_lft) {
> int max_addresses = in6_dev->cnf.max_addresses;
> + u32 addr_flags = 0;
> +
> +#ifdef CONF
On Mon, 05 Feb 2007 18:35:06 -0600
Robert Hancock <[EMAIL PROTECTED]> wrote:
> Daniel Barkalow wrote:
> > On Sun, 4 Feb 2007, Robert Hancock wrote:
> >
> >> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
> >> 2.6.20-rc6. There's no errors in dmesg, but it seems no packets
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
Documentation/networking/e1000.txt | 785 +---
1 files changed, 542 insertions(+), 243 deletions(-)
diff --git a/Documentation/networking/e1000.txt
b/Documentati
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
MAINTAINERS | 18 ++
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 13759e9..c001147 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@
Willy,
Please pull:
git-pull git://lost.foo-projects.org/~ahkok/git/linux-2.4 e1000
to receive an update for the e1000 driver. This updates the e1000
driver in the 2.4 kernel to version 7.3.20-k4, roughly the equivalent
of what is in 2.6.20 and the latest of our out-of-tree driver.
This adds ne
Daniel Barkalow wrote:
On Sun, 4 Feb 2007, Robert Hancock wrote:
Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get
received and so the machine can't get an IP address. I tried reverting all the
-mm cha
From: Adrian Bunk <[EMAIL PROTECTED]>
This patch contains the following cleanups:
- make the following needlessly global functions static:
- lock_adapter_irq()
- unlock_adapter_irq()
- #if 0 the following unused global functions:
- wanrouter_encapsulate()
- wanrouter_type_trans()
Signed-o
From: Daniel Walker <[EMAIL PROTECTED]>
This was reported by Ingo Molnar here,
http://lkml.org/lkml/2006/12/18/119
The problem is that adummy_init() depends on atm_init() , but adummy_init()
is called first.
So I put atm_init() into subsys_initcall which seems appropriate, and it
will still get
From: Andrew Morton <[EMAIL PROTECTED]>
sparc64:
net/dccp/ccids/ccid3.c: In function `ccid3_hc_tx_packet_recv':
net/dccp/ccids/ccid3.c:480: warning: long long unsigned int format, __u64 arg
(arg 6)
net/dccp/ccids/ccid3.c: In function `ccid3_hc_rx_packet_recv':
net/dccp/ccids/ccid3.c:1007: warnin
From: Adrian Bunk <[EMAIL PROTECTED]>
Add proper prototypes for some functions in include/net/irda/irda.h
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Samuel Ortiz <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/net/irda/irda.h | 15 +++
From: Andrew Morton <[EMAIL PROTECTED]>
"using smp_processor_id() in preemptible code"
Cc: Patrick McHardy <[EMAIL PROTECTED]>
Cc: "David S. Miller" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/net/netfilter/nf_conntrack.h |7 ++-
1 file changed, 6 in
From: "Robert P. J. Day" <[EMAIL PROTECTED]>
Remove the unused kernel config option DLCI_COUNT.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
Cc: "David S. Miller" <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Krzysztof Halasa [EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[
From: joe jin <[EMAIL PROTECTED]>
This patch replace kmalloc() + memset() pairs with the appropriate
kzalloc().
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/slip.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff -
From: Alan Cox <[EMAIL PROTECTED]>
At some point someone added a spin_lock(&dev->lock) to the IRQ handler for
the Z85230 driver. This actually correctly fixes a bug but the necessary
changes to remove the chan->lock calls in the event handlers were not made
(c->lock is the same lock).
Simona Das
From: Frederik Deweerdt <[EMAIL PROTECTED]>
The tcphdr struct passed to tcp_v4_check is not used, the following
patch removes it from the parameter list.
Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/net/tcp.h
From: Arjan van de Ven <[EMAIL PROTECTED]>
This patch introduces users of the round_jiffies() function in the networking
code.
These timers all were of the "about once a second" or "about once every X
seconds" variety and several showed up in the "what wakes the cpu up" profiles
that the tickless
From: "Joe Jin" <[EMAIL PROTECTED]>
Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls in
the bonding driver.
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_alb.c |4 +---
drivers/net/bonding/bon
Rick Jones wrote:
John Heffner wrote:
David Miller wrote:
However, I can't think of any reason why the cwnd test should not
apply.
Care to elaborate here? You can view the FIN special case as an off
by one error in the CWND test, it's not going to melt the internet.
:-)
True, it's not g
John Heffner wrote:
David Miller wrote:
However, I can't think of any reason why the cwnd test should not apply.
Care to elaborate here? You can view the FIN special case as an off
by one error in the CWND test, it's not going to melt the internet.
:-)
True, it's not going to melt the in
David Miller wrote:
However, I can't think of any reason why the cwnd test should not
apply.
Care to elaborate here? You can view the FIN special case as an off
by one error in the CWND test, it's not going to melt the internet.
:-)
True, it's not going to melt the internet, but why stop at
On Monday 05 February 2007 22:37, Jiri Benc wrote:
> On Mon, 5 Feb 2007 16:32:24 +0100, Ivo van Doorn wrote:
> > When a driver requested additional header room
> > through the extra_tx_headroom field, the stack
> > should respect that and make sure that all frames
> > that are being send to the sta
On Monday 05 February 2007 21:28, Jiri Benc wrote:
> On Sat, 3 Feb 2007 17:25:18 +0100, Ivo van Doorn wrote:
> > When rt2500usb and rt73usb will start using beacontemplates,
> > they would also need a control structure to be passed along to
> > correctly set the tx parameters.
>
> Good catch, than
David Miller wrote:
From: John Heffner <[EMAIL PROTECTED]>
Date: Mon, 05 Feb 2007 16:58:18 -0500
This is especially important with TSO enabled. Currently, it will send
a burst of up to 64k at the end of a connection, even when cwnd is much
smaller than 64k. This patch still lets out empty FI
From: John Heffner <[EMAIL PROTECTED]>
Date: Mon, 05 Feb 2007 18:02:19 -0500
> David Miller wrote:
> > From: John Heffner <[EMAIL PROTECTED]>
> > Date: Mon, 05 Feb 2007 16:58:18 -0500
> >
> >> This is especially important with TSO enabled. Currently, it will send
> >> a burst of up to 64k at th
From: John Heffner <[EMAIL PROTECTED]>
Date: Mon, 05 Feb 2007 16:58:18 -0500
> This is especially important with TSO enabled. Currently, it will send
> a burst of up to 64k at the end of a connection, even when cwnd is much
> smaller than 64k. This patch still lets out empty FIN packets, but d
This is especially important with TSO enabled. Currently, it will send
a burst of up to 64k at the end of a connection, even when cwnd is much
smaller than 64k. This patch still lets out empty FIN packets, but does
not apply the special case to FINs carrying data.
-John
Apply cwnd rules t
I just rebased all branches of netdev-2.6.git, against current Linus TOT
(v2.6.20).
New maintainers (hi Jay) for example will want to re-clone rather than
pulling the remote branch 'foo' into local branch 'foo'.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev
From: Joy Latten <[EMAIL PROTECTED]>
Date: Mon, 05 Feb 2007 14:53:39 -0600
> I can run some tests with this patch and report any results...
Please check out the two most recent patches I posted:
1) Updated core patch with ipv6 side added.
2) Fix for thinko noticed by Venkat.
Thanks.
-
To unsub
From: "Venkat Yekkirala" <[EMAIL PROTECTED]>
Date: Mon, 5 Feb 2007 14:49:17 -0600
> > Something like this (untested) on the ipv4 side, for example:
> >
> > diff --git a/include/net/route.h b/include/net/route.h
> > index 486e37a..a8af632 100644
> > --- a/include/net/route.h
> > +++ b/include/net/
I can run some tests with this patch and report any results...
Regards,
Joy
On Sun, 2007-02-04 at 20:53 -0800, David Miller wrote:
> From: James Morris <[EMAIL PROTECTED]>
> Date: Thu, 1 Feb 2007 18:44:48 -0500 (EST)
>
> > A quick & dirty solution, which is what I think the BSD kernels do, is t
From: James Morris <[EMAIL PROTECTED]>
Date: Mon, 5 Feb 2007 15:34:39 -0500 (EST)
> On Mon, 5 Feb 2007, James Morris wrote:
>
> > On Sun, 4 Feb 2007, David Miller wrote:
> >
> > > Something like this (untested) on the ipv4 side, for example:
> >
> > Looks like it should work. Will do some test
On Thu, 2007-02-01 at 18:44 -0500, James Morris wrote:
> On Thu, 1 Feb 2007, Joy Latten wrote:
>
> > IPsec returns EAGAIN when it needs to acquire an SA.
> > There have been a thread or two about this...
> > Has there been any info or progress in how best to fix this?
> >
> > James Morris present
> Something like this (untested) on the ipv4 side, for example:
>
> diff --git a/include/net/route.h b/include/net/route.h
> index 486e37a..a8af632 100644
> --- a/include/net/route.h
> +++ b/include/net/route.h
> @@ -146,7 +146,8 @@ static inline char rt_tos2priority(u8 tos)
>
> static inline i
Hi Steve
would you mind terribly, changing the -d "$net" to the
-i "$net", and run the script with the interface name instead?
The reason is, that I see 2 different behaviors between blocking
by interface and blocking by IP and would like to find out if
you see it too.
When I block at the inter
On Mon, 5 Feb 2007, James Morris wrote:
> On Sun, 4 Feb 2007, David Miller wrote:
>
> > Something like this (untested) on the ipv4 side, for example:
>
> Looks like it should work. Will do some testing.
Appears to work well, with a slight delay on the first packet as expected.
Tested with tc
Alexey Dobriyan wrote:
On Mon, Feb 05, 2007 at 06:59:33PM +0200, Ahmed S. Darwish wrote:
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Remove it and use ARRAY_SIZE instead.
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,7 +245,7 @@ ixgb_validat
On Sat, 3 Feb 2007 17:25:18 +0100, Ivo van Doorn wrote:
> When rt2500usb and rt73usb will start using beacontemplates,
> they would also need a control structure to be passed along to
> correctly set the tx parameters.
Good catch, thanks.
> This patch will add the allocation an initialization of
On Mon, Feb 05, 2007 at 06:59:16PM +0200, Ahmed S. Darwish wrote:
> A patch to use ARRAY_SIZE macro already defined in kernel.h.
OK, but checks you're changing are strange. idx there is signed so
BUG_ON(idx < 0 || idx > ARRAY_SIZE());
should be more appropriate.
> --- a/drivers/net/ibm_
On Mon, Feb 05, 2007 at 06:59:33PM +0200, Ahmed S. Darwish wrote:
> A patch to use ARRAY_SIZE macro already defined in kernel.h.
Remove it and use ARRAY_SIZE instead.
> --- a/drivers/net/ixgb/ixgb_param.c
> +++ b/drivers/net/ixgb/ixgb_param.c
> @@ -245,7 +245,7 @@ ixgb_validate_option(int *value,
On Mon, Feb 05, 2007 at 07:00:44PM +0200, Ahmed S. Darwish wrote:
> A trivial patch to use ARRAY_SIZE macro.
You're supposed to remove it ans use ARRAY_SIZE where old macro is used.
> --- a/drivers/net/wireless/wavelan.p.h
> +++ b/drivers/net/wireless/wavelan.p.h
> @@ -450,7 +450,7 @@ static cons
On Monday 05 February 2007 19:24, Chris Leech wrote:
> It is busy waiting, but only because the TCP socket use initiates the
> DMA copies from the softirq and they have time to complete during the
> switch back to application context.
But to me it looks as if the code in tcp_recvmsg will also init
On Sat, 4 Feb 2007 [EMAIL PROTECTED] wrote:
I noticed in an LCA talk mention that apprently extensible hashing
with RCU access is an unsolved problem. Here's an idea for solving it.
I'm assuming the table is a power of 2 in size with open chaining
for collisions. When the chains get too long,
From: Randy Dunlap <[EMAIL PROTECTED]>
sparse complains about differing types from prototype to
definition, so change the u32 to phy_interface_t:
drivers/net/phy/phy_device.c:140:19: error: symbol 'phy_connect' redeclared
with different type (originally declared at include/linux/phy.h:362) -
in
On Mon, Feb 05, 2007 at 12:33:55PM -0500, Brian Haley wrote:
> >Please, if you think you can find a way for us to do optimistic dad flags
> >as
> >opt-in, rather than masked out, I'm all for it. Thanks!
>
> This patch should apply on-top of yours, if you want I can send the
> whole thing out to
Hi,
> > Did you already send that patchset to the netdev list?
> > Because I haven't seen a patch series about rts for d80211 yet.
>
> No, [EMAIL PROTECTED]
Hmm, wasn't subscribed to that list yet. :(
But now I am. :)
> > The new rt2500usb and rt73usb packet ring handling no longer use a DMA
>
Hi Stephen,
First, thanks for this detailed explanation.
On Mon, Feb 05, 2007 at 09:22:53AM -0800, Stephen Hemminger wrote:
> Here is what I saw.
>
> The transmitter on the Marvell Yukon II (88e8053) hangs when doing transmit
> flow
> control under load. There appears to be a bug or race condi
On Monday 05 February 2007 19:08, Jiri Benc wrote:
> On Mon, 5 Feb 2007 18:43:06 +0100, Michael Buesch wrote:
> > I also think that sending RTS in software is not going to work,
> > as the timing can not be guaranteed. And timing is why we do it in
> > the first place. If the HW is not capable of s
On 2/5/07, Olaf Kirch <[EMAIL PROTECTED]> wrote:
Nowhere in the dma_async_*complete functions can I see any code
that would sleep if the DMA is not yet complete. Am I missing something,
or are we really busy-waiting on the DMA engine? Wouldn't this kind of
defeat the purpose of freeing up the CP
On Monday 05 February 2007 19:07, Ivo van Doorn wrote:
> Hi,
>
> > > > > Not all hardware are capable of generating their own RTS frames.
> > > > > This patch will add support for creating the RTS frame in software,
> > > > > when the driver requests this through the flag
> > > > > IEEE80211_HW_SO
On Thursday 01 February 2007 12:30, Andi Kleen wrote:
> Simon Lodal <[EMAIL PROTECTED]> writes:
> > Memory is generally not an issue, but CPU is, and you can not beat the
> > CPU efficiency of plain array lookup (always faster, and constant time).
>
> Actually that's not true when the array doesn't
On Monday 05 February 2007 19:08, Jiri Benc wrote:
> On Mon, 5 Feb 2007 18:43:06 +0100, Michael Buesch wrote:
> > I also think that sending RTS in software is not going to work,
> > as the timing can not be guaranteed. And timing is why we do it in
> > the first place. If the HW is not capable of s
On Sat, 4 Feb 2007 [EMAIL PROTECTED] wrote:
I noticed in an LCA talk mention that apprently extensible hashing
with RCU access is an unsolved problem. Here's an idea for solving it.
Yes, I have been playing around with the same idea for
doing dynamic resizing of the TCP hashtable.
Did a
On Mon, 5 Feb 2007 18:43:06 +0100, Michael Buesch wrote:
> I also think that sending RTS in software is not going to work,
> as the timing can not be guaranteed. And timing is why we do it in
> the first place. If the HW is not capable of sending RTS frames, we
> should not try to emulate them in S
Hi,
> > > > Not all hardware are capable of generating their own RTS frames.
> > > > This patch will add support for creating the RTS frame in software,
> > > > when the driver requests this through the flag
> > > > IEEE80211_HW_SOFTWARE_RTS
> > >
> > > It seems this is not the ideal solution. Mo
On Monday 05 February 2007 18:37, Jiri Benc wrote:
> On Sat, 3 Feb 2007 12:45:26 +0100, Ivo van Doorn wrote:
> > --- dscape/net/d80211/ieee80211_i.h 2007-01-31 19:41:53.0 +0100
> > +++ dscape_seq/net/d80211/ieee80211_i.h 2007-01-31 20:06:26.0
> > +0100
> > @@ -405,6 +405,7 @@
>
On Mon, Feb 05, 2007 at 11:28:05AM -0600, David M. Lloyd ([EMAIL PROTECTED])
wrote:
> On Thu, 2007-02-01 at 13:12 +0300, Evgeniy Polyakov wrote:
> > Generic event handling mechanism.
>
> The patch applied cleanly to 2.6.20 final, but I got a build error:
>
> CC kernel/kevent/kevent.o
>
On Monday 05 February 2007 18:43, Ivo van Doorn wrote:
> On Monday 05 February 2007 18:28, Jiri Benc wrote:
> > On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote:
> > > Not all hardware are capable of generating their own RTS frames.
> > > This patch will add support for creating the RTS fram
On Monday 05 February 2007 18:28, Jiri Benc wrote:
> On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote:
> > Not all hardware are capable of generating their own RTS frames.
> > This patch will add support for creating the RTS frame in software,
> > when the driver requests this through the fl
On Monday 05 February 2007 18:28, Jiri Benc wrote:
> On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote:
> > Not all hardware are capable of generating their own RTS frames.
> > This patch will add support for creating the RTS frame in software,
> > when the driver requests this through the fl
On Sat, 3 Feb 2007 12:45:26 +0100, Ivo van Doorn wrote:
> --- dscape/net/d80211/ieee80211_i.h 2007-01-31 19:41:53.0 +0100
> +++ dscape_seq/net/d80211/ieee80211_i.h 2007-01-31 20:06:26.0
> +0100
> @@ -405,6 +405,7 @@
> int *supp_rates[NUM_IEEE80211_MODES];
> int
Please, if you think you can find a way for us to do optimistic dad flags as
opt-in, rather than masked out, I'm all for it. Thanks!
This patch should apply on-top of yours, if you want I can send the
whole thing out too. I've only compile-tested it, so don't know if it
behaves the same as y
On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote:
> Not all hardware are capable of generating their own RTS frames.
> This patch will add support for creating the RTS frame in software,
> when the driver requests this through the flag
> IEEE80211_HW_SOFTWARE_RTS
It seems this is not the id
Here is what I saw.
The transmitter on the Marvell Yukon II (88e8053) hangs when doing transmit flow
control under load. There appears to be a bug or race condition that
causes the MAC to stop transmitting data.
There are two drivers for the Yukon II device on Linux. SysKonnect/Marvell
has one
Vlad Yasevich wrote on 05 February 2007 17:08:
> 1. What did you set the sinfo_timetolive to?
I presume you mean the timetolive parameter of sctp_sendmsg()? - this
was set to 1400ms (as previously mentioned, this was in error but it
does appear to have highlighted a problem with the stack itsel
Hi,
I looked into the IOAT code today as I'm trying to find out how to add support
for it to NFS. I ran into this piece of code, which waits for the DMA
operation to complete:
while (dma_async_memcpy_complete(tp->ucopy.dma_chan,
tp
On Monday 05 February 2007 11:16, Jarek Poplawski wrote:
> On 01-02-2007 12:30, Andi Kleen wrote:
> > Simon Lodal <[EMAIL PROTECTED]> writes:
> >> Memory is generally not an issue, but CPU is, and you can not beat the
> >> CPU efficiency of plain array lookup (always faster, and constant time).
>
>
Hi Steve
Steve Hill wrote:
Vlad Yasevich wrote on 05 February 2007 16:39:
Once you start simulating the network failure, how long do you wait?
If you have not changed rto_max and path_max_retrans, you can end up
waiting quite a while for the full path switchover. This will also
severely slow
Hi,
A trivial patch to use ARRAY_SIZE macro.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/wireless/wavelan.p.h b/drivers/net/wireless/wavelan.p.h
index 72b646c..fe12c77 100644
--- a/drivers/net/wireless/wavelan.p.h
+++ b/drivers/net/wireless/wavelan.p.h
@@ -450
Hi,
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c
index b27442a..26031fe 100644
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
Hi,
A patch to use ARRAY_SIZE macro in the Host AP wireless driver.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch is compile tested.
diff --git a/drivers/net/wireless/hostap/hostap.h
b/drivers/net/wireless/hostap/hostap.h
index e89c890..ef37a75 100644
--- a/drivers/net/wireless/
Hi,
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile-tested cause I don't have the needed hardware.
diff --git a/drivers/net/ibm_emac/ibm_emac_debug.c
b/drivers/net/ibm_emac/ibm_emac_debug.c
index 92f970d..1
Hi,
A patch to use ARRAY_SIZE macro already defined in kernel.h for some
miscellaneous wireless drivers with no specific maintaners.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch is compile tested.
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index 44a22
Hi,
A 2.6.20 patch to use ARRAY_SIZE macro already defined in kernel.h for some
miscellaneous network drivers with no specific maintaners.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile-tested due to missing hardware.
diff --git a/drivers/net/apne.c b/drivers/net/apn
Hi all,
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch is compile tested.
diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c
index b85857a..a9d944a 100644
--- a/drivers/net/wireless/ipw2100.c
++
Hi,
A 2.6.20 patch to use ARRAY_SIZE macro already defined in kernel.h for some
miscellaneous network drivers with no specific maintaners.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
[PATCH 01/02] is compile tested.
[PATCH 02/02] isn't compile tested cause of missing hardware.
diff -
Hi,
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch is compile tested.
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index fb96c87..d21706e 100644
--- a/drivers/net/e1000/e1000_ethtoo
Hi all,
Follows is a sereis of patches to use ARRAY_SIZE macro in drivers/net.
Patches are sent separately according to their maintaners as replies to
this thread.
apne.c |2 +-
arm/am79c961a.c|2 +-
atarilance.c |2 +-
cs89x0.c
Vlad Yasevich wrote on 05 February 2007 16:39:
> Once you start simulating the network failure, how long do you wait?
>
> If you have not changed rto_max and path_max_retrans, you can end up
> waiting quite a while for the full path switchover. This will also
> severely slow down your retransmis
Steve Hill wrote:
Vlad Yasevich wrote on 25 January 2007 16:33:
Can you try the attached patch and let me know if the problem is
fixed. You can try reducing rto_max or path_max_retrans to get the
failover to happen a little faster.
Sorry for the delay - I've been on vacation for the past we
On Sun, 4 Feb 2007, David Miller wrote:
> Something like this (untested) on the ipv4 side, for example:
Looks like it should work. Will do some testing.
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL P
1 - 100 of 124 matches
Mail list logo
