On Friday 11 January 2008, H. Peter Anvin wrote:
> Mike Frysinger wrote:
> > oh, sorry, i see what you mean. i was thinking in terms of crap removed
> > (as that's what i'm after), not crap added (which is what Peter is
> > after). i hadnt noticed that. i dont know if it'll break glibc (and
> >
H. Peter Anvin wrote:
Right now, glibc is special-cased. glibc also tends to be very
deliberate about its kernel header inclusions. It wants a subset of the
available defines, so it can include a subset header.
The reverse is definitely possible too -- all other users (kernel,
newlib, die
This patch changes spidernet interrupt masks.
- unmask GDAINVAINT. There is an operation to do by spidernet
interrupt handler.
- mask some interrupts. There are no operations in the interrupt handler.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
---
Index: linux-powerpc-git/drivers/net/s
Mike Frysinger wrote:
oh, sorry, i see what you mean. i was thinking in terms of crap removed (as
that's what i'm after), not crap added (which is what Peter is after). i
hadnt noticed that. i dont know if it'll break glibc (and really, any other
sane libc). if that is the case, then i thin
On Friday 11 January 2008, David Miller wrote:
> From: Mike Frysinger <[EMAIL PROTECTED]>
> Date: Fri, 11 Jan 2008 01:23:37 -0500
>
> > On Friday 11 January 2008, David Miller wrote:
> > > From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> > >
> > > > Seems the most logical thing to do would be to break
David Miller wrote:
Hmmm...
Doesn't glibc include linux/socket.h? If so, before it wouldn't get
the sa_family_t et al. defines (because __GLIBC__ will be defined and
it will be >= 2), but with your change it get those things.
Correct me if I'm wrong.
At the moment, yes, it does.
-
In addition to the value of GHIINT0STS, spidernet interrupt handler
should check the values of GHIINT1STS/GHIINT2STS registers at the
beginning of spider_net_interrupt() so as not to drop error
interrupts.
GHIINT1STS/GHIINT2STS registers indicates some of erroneous conditions
in spidernet, and a f
This patch fixes initialization of "aneg_count" and "medium" fields in
spider_net_card to make spidernet driver correctly sets "link status".
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
---
Index: linux-powerpc-git/drivers/net/spider_net.c
=
This patch revises the logging for link informations of spidernet.
- The link down message is too verbose because auto-negotiation timeout
occurs periodically while an ethernet cable is not connected.
- We want to see the link result, and we think it should be displayed.
Signed-off-by:
This patch extends the timeout for spidernet auto-negotiation.
Auto-negotiation often fails to finish in 2 seconds.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
---
Index: linux-powerpc-git/drivers/net/spider_net.h
===
--- linux-p
From: Mike Frysinger <[EMAIL PROTECTED]>
Date: Fri, 11 Jan 2008 01:23:37 -0500
> On Friday 11 January 2008, David Miller wrote:
> > From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> > > Seems the most logical thing to do would be to break out the small
> > > portion that everyone wants into or somesuc
Mike Frysinger wrote:
On Friday 11 January 2008, David Miller wrote:
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Seems the most logical thing to do would be to break out the small
portion that everyone wants into or somesuch, and
then remove those ifdefs entirely.
Proposed patch (still being t
From: Daniel Lezcano <[EMAIL PROTECTED]>
Date: Thu, 10 Jan 2008 19:02:40 +0100
> The inet6_addr_lst hash table contains the configured addresses
> for the ipv6 protocol on the system.
>
> With the network namespace, we have 2 solutions:
> * make this hash table per namespace
> * keep a global
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 10 Jan 2008 16:32:38 +0100
> [MACVLAN]: Prevent nesting macvlan devices
>
> Don't allow to nest macvlan devices since it will cause lockdep warnings and
> isn't really useful for anything.
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 10 Jan 2008 16:32:35 +0100
> [VLAN]: nested VLAN: fix lockdep's recursive locking warning
>
> Allow vlans nesting other vlans without lockdep's warnings (max. 2 levels
> i.e. parent + child). Thanks to Patrick McHardy for pointing a bug in the
From: Pavel Emelyanov <[EMAIL PROTECTED]>
Date: Thu, 10 Jan 2008 18:05:25 +0300
> When I studied the neighbor code I puzzled over what
> the NUD can mean for quite a long time.
>
> Finally I asked Alexey and he said that this was smth
> like "neighbor unreachability detection".
>
> Does it worth
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Thu, 10 Jan 2008 15:06:10 +0100
> [DECNET] ROUTE: fix rcu_dereference() uses in /proc/net/decnet_cache
...
> Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
Applied, thanks Eric.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
From: Vince Fuller <[EMAIL PROTECTED]>
Date: Mon, 7 Jan 2008 17:10:57 -0800
> from Vince Fuller <[EMAIL PROTECTED]>
>
> This set of diffs modify the 2.6.20 kernel to enable use of the 240/4
> (aka "class-E") address space as consistent with the Internet Draft
> draft-fuller-240space-00.txt.
>
>
On Friday 11 January 2008, David Miller wrote:
> From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> > Seems the most logical thing to do would be to break out the small
> > portion that everyone wants into or somesuch, and
> > then remove those ifdefs entirely.
> >
> > Proposed patch (still being tested
From: Dave Young <[EMAIL PROTECTED]>
Date: Mon, 7 Jan 2008 13:41:22 +0800
> 1) In tty.c the BUG_ON at line 115 will never be called, because the the
> before list_del_init in this same function.
> 115 BUG_ON(!list_empty(&dev->list));
> So move the list_del_init to rfcomm_dev_del
>
> 2
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Date: Wed, 02 Jan 2008 10:09:56 -0800
> Seems the most logical thing to do would be to break out the small
> portion that everyone wants into or somesuch, and
> then remove those ifdefs entirely.
>
> Proposed patch (still being tested) attached...
I
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Mon, 31 Dec 2007 15:42:42 +0100
> Maybe we need to introduce some mechanism to let sk_forward between 0 and
> SK_MEM_QUANTUM (inclusive).
>
> static inline void sk_mem_reclaim_overpage(struct sock *sk)
> {
> if (sk->sk_forward_alloc > SK_MEM_
From: Jarek Poplawski <[EMAIL PROTECTED]>
Date: Sun, 30 Dec 2007 15:13:23 +0100
> On Sat, Dec 29, 2007 at 07:14:43PM -0800, David Miller wrote:
> ...
> > You can't just drop this linked list lock and expect it to stay
> > consistent like that.
> >
> > Once you drop it, any thread of control can g
Jay Vosburgh <[EMAIL PROTECTED]> wrote:
>
>For the case of the bond_set_multicast_list function, changing
> the existing write_lock to a read_lock_bh doesn't affect any calls to
Right that should also resolve the lockdep issue. So as long as you
guys are sure that this is safe with respec
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Fri, 04 Jan 2008 14:05:29 -0800
> Any objection to merging the following for 2.6.25?
The ipv4/ipv6 bits look fine to me.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo
Hello All
I am waiting for more feedback on the patches.
If there are no objections please consider them for 2.6.25.
With Regards
Poonam
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Aggrwal Poonam
Sent: Monday, December 10, 2007 5:23 PM
To: [
Hello All
I am waiting for more feedback on the patches.
If there are no objections please consider them for 2.6.25.
With Regards
Poonam
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Aggrwal Poonam
Sent: Monday, December 10, 2007 5:23 PM
To: [EM
From: Jay Cliburn <[EMAIL PROTECTED]>
Date: Thu, 10 Jan 2008 19:44:21 -0600
> On Tue, 08 Jan 2008 15:08:48 -0800 (PST)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> >
> > Can people do me a favor and do more constructive things like test
> > that my patches really do fix the "device down during
Update driver version reflects new hardware support.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
Please add to staging tree for 2.6.25.
--- a/drivers/net/sky2.c2008-01-10 15:49:27.0 -0800
+++ b/drivers/net/sky2.c2008-01-10 15:49:29.0 -0800
@@ -51,7 +5
This patch might fix problems with 4G or more of memory.
It stops the driver from doing a small optimization for Tx and Rx,
and instead always sets the high-page on tx/rx descriptors.
Fixes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=9725
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Set of sky2 patches:
1) bug fix for 4G mem
2) low priority fix for WOL default
--- cut line for 2.6.24 ---
3) new hardware support
4) verson 1.21
--
Stephen Hemminger <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EM
The driver checks status of PCI power management to mark
default setting of Wake On Lan. On some systems this works, but often
it reports a that WOL is disabled when it isn't.
This patch gets rid of that check and just reports the wake on
lan status based on the hardware capablity.
Signed-off-by
Add support from sk98lin vendor driver 10.50.1.3 for 88E8055 and
88E8075 chips. I don't have this hardware to test, so this changes
are untested.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
Please add to staging tree for 2.6.25.
--- a/drivers/net/sky2.c2008-01-10 15:49:20.0
2008/1/11, Zhu Yi <[EMAIL PROTECTED]>:
>
> The version doesn't work on a .24-rc kernel. Can you compile it
> with .23?
>
Thank you for your help, I built it.
Thanks,
Joonwoo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More maj
On Fri, 2008-01-11 at 10:38 +0900, Joonwoo Park wrote:
> I should have checked code base, it's my fault.
> it's seems very similar, but I could not made build unfortunately.
> Can you introduce to me how to build it please?
>
> my build error is here:
> [EMAIL PROTECTED] ~/SRC/DRIVERS/iwlwifi $
>
Thank you very much, this appears to work.
> The driver is still a POMS but it seems better now.
I notice that the vendor-supplied driver doesn't have these bugs.
Now, it does have a bug in that it doesn't have an "is this
interrupt for me?" test at all (and always returns "I handled it"),
but th
From: Pavel Emelyanov <[EMAIL PROTECTED]>
Date: Thu, 10 Jan 2008 16:55:12 +0300
> The ipv6_devconf_(all) and ipv6_devconf_dflt are currently
> global, but should be per-namespace.
>
> This set moves them on the struct net. Or, more precisely,
> on the struct netns_ipv6, which is already added.
>
On Tue, 08 Jan 2008 15:08:48 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
>
> Can people do me a favor and do more constructive things like test
> that my patches really do fix the "device down during packet flood"
> bug
Hi Dave,
Your patches seem to work for the atl1 NAPI implementatio
2008/1/11, Zhu Yi <[EMAIL PROTECTED]>:
> Hi Joonwoo,
>
> We already did something similiar in our code base. Could you please
> take a look at this patch?
>
> http://intellinuxwireless.org/repos/?p=iwlwifi.git;a=commitdiff;h=57aa02255e9d7be5e2494683fc2793bd1d0707e2
>
> Thanks,
> -yi
Ooops :-)
I sh
From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
Date: Thu, 10 Jan 2008 12:52:15 -0800
> I hope this explanation makes sense, but what it comes down to is that
> combining hardware round robin balancing with NAPI is a BAD IDEA.
Absolutely agreed on all counts.
No IRQ balancing should be done at all
Hello Reinette,
2008/1/11, Chatre, Reinette <[EMAIL PROTECTED]>:
>
> Could synchronize_irq() be moved into iwl_disable_interrupts() ? I am
At this time, iwl_disable_interrupts() can be called with irq
disabled, so for do that I think additional modification would be
needed.
> also wondering if w
From: "Chris Friesen" <[EMAIL PROTECTED]>
Date: Thu, 10 Jan 2008 11:24:19 -0600
> I've got an issue that's popped up with a deployed system running
> 2.6.10.
...
> So...anyone have any ideas/suggestions?
You have to be kidding, coming here for help with a nearly
4 year old kernel.
The networki
Herbert Xu <[EMAIL PROTECTED]> wrote:
>On Thu, Jan 10, 2008 at 04:03:53PM -0500, Andy Gospodarek wrote:
>>
>> > >Sure, but where do you call that function while holding the bond lock?
>> >
>> >If I recall correctly, the problem was that tg3, et al, did
>> > things that might sleep, and bondin
Hi Joonwoo,
We already did something similiar in our code base. Could you please
take a look at this patch?
http://intellinuxwireless.org/repos/?p=iwlwifi.git;a=commitdiff;h=57aa02255e9d7be5e2494683fc2793bd1d0707e2
Thanks,
-yi
On Wed, 2008-01-09 at 20:02 +0900, Joonwoo Park wrote:
> Eleminiate t
Jeff Garzik wrote:
> Kok, Auke wrote:
>> All,
>>
>> here is the third version of the igb (82575) ethernet controller
>> driver. This
>> driver was previously posted 2007-07-13 and 2007-12-11. Many comments
>> received
>> were addressed:
>>
>> - removed indirection wrappers in the same way as e1000e
Kok, Auke wrote:
All,
here is the third version of the igb (82575) ethernet controller driver. This
driver was previously posted 2007-07-13 and 2007-12-11. Many comments received
were addressed:
- removed indirection wrappers in the same way as e1000e and ixgbe.
- cleaned up largely against spa
On Fri, Jan 11, 2008 at 12:10:42AM +0100, Jarek Poplawski wrote:
>
> It seems this optimization could've a side effect: if during such a
> loop updates are done, and r is seen !NULL during while() check, but
> NULL after rcu_dereference(), the listing/counting could stop too
> soon. So, IMHO, proba
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
drivers/net/ipg.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index 9752902..b234b29 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/ipg.c
@@ -1994,7 +1994,7 @@ static int ip
The current logic will only request an ack for the first pending
packet. No irq is triggered as soon as the CPU submits a few
packets a bit quickly. Let's request an irq for every packet
instead.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
drivers/net/ipg.c |5 +
1 files chang
On Fri, Jan 11, 2008 at 12:10:42AM +0100, Jarek Poplawski wrote:
> Eric Dumazet wrote, On 01/09/2008 11:37 AM:
> ...
> > [NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
> ...
> > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > index d337706..28484f3 100644
> > --- a/net/ipv4/rout
The Tx skb release could not free more than one skb per call.
Add it to the fact that the xmit handler does not check for
a queue full condition and you have a recipe to leak quickly.
Let's release every pending Tx descriptor which has been given
back to the host CPU by the network controller. The
Please pull from branch 'ipg-fixes' in repository
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git ipg-fixes
to get the changes below.
I have tested the driver with a PIV HT based motherboard. The network
controller is connected to a fast ethernet switch (yeah, I'm cheap).
A s
Spotted-by: <[EMAIL PROTECTED]>
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
drivers/net/ipg.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
index dbd23bb..cd1650e 100644
--- a/drivers/net/ipg.c
+++ b/drivers/net/i
Eric Dumazet wrote, On 01/09/2008 11:37 AM:
...
> [NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
...
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index d337706..28484f3 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -283,12 +283,12 @@ static struct rtable *rt_c
I try arp monitoring but it doesn't work! Test an ip, the interface must have
an address, and the dhcpcd is launch by ifplugd if bond0 is linked ... so it
goes around in circles.
So i return to miimon, and i figured out that bond detect when wlan0 is
associated and set it active interface. But w
> and the parallel portions/comments in unix_dgram_recvmsg(),
> it looks like there's been a lot of uncertainty as to how
> file descriptor passing should be handled durning MSG_PEEK
> operations. To quote:
The specs basically don't answer the question. What is critical is that
the behaviour does
Here's what I think is a better patch. Or maybe just simpler.
However, I'm still unsure what the effect of this patch on
file descriptor passing might be. Reading the prior code,
and the parallel portions/comments in unix_dgram_recvmsg(),
it looks like there's been a lot of uncertainty as to how
[2nd try -- turns-out the Mattis Nissler patch needed an extra tweak.
It will probably also cause build breakage when you rebase since
rt2x00lib_txdone(...) becomes rt2x00pci_txdone(rt2x00dev,...) in 2.6.25,
so FYI... :-)
This also includes another patch (the "4 byte boundary" one) which
is alread
On Thu, 2008-10-01 at 17:05 -0200, Dzianis Kahanovich wrote:
> To "classid x:y" = "mark=mark&x|y" ("classid :y" = "-j MARK --set-mark y",
> etc).
>
> --- linux-2.6.23-gentoo-r2/net/sched/Kconfig
> +++ linux-2.6.23-gentoo-r2.fixed/net/sched/Kconfig
> @@ -222,6 +222,16 @@
[..]
>
James Chapman wrote:
What's changed in your application? Any real-time threads in there?
From the top output below, looks like SigtranServices is consuming all
your CPU...
There are two cpus, and SigtranServices is multithreaded with many
threads. Most of these threads are affined to cpu0
On Thu, Jan 10, 2008 at 10:08:16PM +0100, Jarek Poplawski wrote:
...
> But still some 'quirks' are possible there: removing and adding
> devices 'properly' would often require resetting of many subclasses,
...Hmm, probably they are always removed from/with the children, then no
problem! (I know, I
On Thu, Jan 10, 2008 at 02:49:22PM -0500, John W. Linville wrote:
> Jeff,
>
> A couple more fixes for 2.6.24. The one from Mattias Nissler is already
> in your upstream tree...FYI.
>
> Let me know if there are problems!
Please disregard this request. The 'upstream-jgarzik-2' request is still v
Breno Leitao wrote:
> When I run netperf in just one interface, I get 940.95 * 10^6 bits/sec
> of transfer rate. If I run 4 netperf against 4 different interfaces, I
> get around 720 * 10^6 bits/sec.
This is actually a known issue that we have worked with your company
before on. It comes down to
On Thu, Jan 10, 2008 at 04:31:22PM +0100, Patrick McHardy wrote:
...
> No, this seems fine, thanks. Even better would be a way to get
> the last lockdep subclass through lockdep somehow, but I couldn't
> find a clean way for this. So I've applied your patch and also
> fixed macvlan.
As a matter of
On Thu, Jan 10, 2008 at 12:50:46PM -0800, Jay Vosburgh wrote:
> Herbert Xu <[EMAIL PROTECTED]> wrote:
>
> >On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
> >>
> >> That wasn't the only purpose, Herbert. Making sure that calls to
> >> dev_set_mac_address were called from process
On Thu, Jan 10, 2008 at 04:03:53PM -0500, Andy Gospodarek wrote:
>
> > >Sure, but where do you call that function while holding the bond lock?
> >
> > If I recall correctly, the problem was that tg3, et al, did
> > things that might sleep, and bonding was calling from a timer context,
> > whic
[EMAIL PROTECTED] wrote:
>Yes it's what i'm looking for. I don't understand how to change the
>arp_ip_target with the gateway, arp_ip_target is a module option.
If you're running a relatively recent bonding driver (version
3.0.0 or later), the arp_ip_targets can be changed on the fly via
Herbert Xu <[EMAIL PROTECTED]> wrote:
>On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
>>
>> That wasn't the only purpose, Herbert. Making sure that calls to
>> dev_set_mac_address were called from process context was important at
>> the time of the coding as well since at least
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
[...]
>That wasn't the only purpose, Herbert. Making sure that calls to
>dev_set_mac_address were called from process context was important at
>the time of the coding as well since at least the tg3 driver took locks
>that could not be taken reliably in so
On Thu, Jan 10, 2008 at 09:51:44AM -0500, Andy Gospodarek wrote:
>
> That wasn't the only purpose, Herbert. Making sure that calls to
> dev_set_mac_address were called from process context was important at
> the time of the coding as well since at least the tg3 driver took locks
> that could not b
On tor, 2008-01-10 at 20:54 +0100, Andreas Henriksson wrote:
> An additional patch will be provided in a followup mail (not available in
> Debian) that was created by request from Patrick McHardy. This one makes max
> rounds configurable (and 0 means try to infinity, so you can restore old
> behav
Jeff,
This is additive on top of the pull request posted on Tuesday evening:
http://marc.info/?l=linux-wireless&m=119985065704687&w=2
If you pull this one, you will get that one as well.
Please let me know if there are any problems!
Thanks,
John
---
Individual patches are available
Jeff,
A couple more fixes for 2.6.24. The one from Mattias Nissler is already
in your upstream tree...FYI.
Let me know if there are problems!
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
---
Hello Stephen!
I've rebased the patches branch we carry in debian on top of the new
080108 release of iproute2.
See patches branch of git://git.debian.org/git/collab-maint/pkg-iproute
I've dropped one of the patches you picked up[1], so there's now one of the
old ones left and a new manpage for
Jeff Garzik wrote:
> Looks pretty decent. Main comments (style mostly, driver operation path
> seems sound):
thanks again for the comments. I am about to send an updated patch just before
my
vacation and before I do let me just quickly touch on your comments below:
> * kill the bitfields and un
Benjamin Thery <[EMAIL PROTECTED]> writes:
> Hi Eric,
>
> While testing the current network namespace stuff merged in net-2.6.25,
> I bumped into the following problem with the /proc/net/ entries.
> It doesn't always display the actual data of the current namespace,
> but sometime displays data fr
Stephen Hemminger schrieb:
On Wed, 9 Jan 2008 16:03:00 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 9 Jan 2008 13:05:34 -0800 (PST)
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.
On , Joonwoo Park wrote:
> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> @@ -6262,6 +6262,10 @@ static void __iwl_down(struct iwl_priv *priv)
> /* tell the device to stop sending interrupts */
> iwl_disable_interrupts(priv);
>
Rick Jones wrote:
>> 1) Interrupts are being processed on both cpus:
>>
>> [EMAIL PROTECTED]:/root> cat /proc/interrupts
>>CPU0 CPU1
>> 30:17037564530785 U3-MPIC Level eth0
>
> IIRC none of the e1000 driven cards are multi-queue
the pci-express variants are, but th
Chris Friesen wrote:
> Kok, Auke wrote:
>
>> You're using 2.6.10... you can always replace the e1000 module with the
>> out-of-tree version from e1000.sf.net, this might help a bit - the
>> version in the
>> 2.6.10 kernel is very very old.
>
> Do you have any reason to believe this would improve
1) Interrupts are being processed on both cpus:
[EMAIL PROTECTED]:/root> cat /proc/interrupts
CPU0 CPU1
30:17037564530785 U3-MPIC Level eth0
IIRC none of the e1000 driven cards are multi-queue, so while the above
shows that interrupts from eth0 have been processe
Andy,
> -Original Message-
> From: Andy Johnson [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 10, 2008 6:35 AM
> To: netdev@vger.kernel.org
> Subject: ipip tunnel code (IPV4)
>
> Hello,
>
> I am trying to learn the IPV4 ipip tunnel code (net/ipv4/ipip.c)
> and I have two little q
I also tried to increase my interface MTU to 9000, but I am afraid that
netperf only transmits packets with less than 1500. Still investigating.
It may seem like picking a tiny nit, but netperf never transmits
packets. It only provides buffers of specified size to the stack. It is
then the st
This is a resubmission of a new driver for Solarflare network controllers.
The driver supports several types of PHY (10Gbase-T, XFP, CX4) on six
different 10G and 1G boards.
Hardware based on this network controller is now available from SMC as
part numbers SMC10GPCIe-XFP and SMC10GPCIe-10BT.
Th
Breno Leitao wrote:
> On Thu, 2008-01-10 at 16:36 +, Ben Hutchings wrote:
>>> When I run netperf in just one interface, I get 940.95 * 10^6 bits/sec
>>> of transfer rate. If I run 4 netperf against 4 different interfaces, I
>>> get around 720 * 10^6 bits/sec.
>>
>>
>> I take it that's the aver
Arnaldo Carvalho de Melo wrote:
> Em Thu, Jan 10, 2008 at 03:26:59PM +, Jeba Anandhan escreveu:
>> Hi Eric,
>> Thanks for the reply. I have one more doubt. For example, if we have 2
>> processor and 4 ethernet cards. Only CPU0 does all work through 8 cards.
>> If we set the affinity to each eth
Many many things to check when running netperf :)
*) Are the cards on the same or separate PCImumble bus, and what sort of bus
*) is the two interface performance two interfaces on the same four-port
card, or an interface from each of the two four-port cards?
*) is there a dreaded (IMO) irqba
Chris Friesen wrote:
> Hi all,
>
> I've got an issue that's popped up with a deployed system running
> 2.6.10. I'm looking for some help figuring out why incoming network
> packets aren't being processed fast enough.
>
> After a recent userspace app change, we've started seeing packets being
> d
Kok, Auke wrote:
You're using 2.6.10... you can always replace the e1000 module with the
out-of-tree version from e1000.sf.net, this might help a bit - the version in
the
2.6.10 kernel is very very old.
Do you have any reason to believe this would improve things? It seems
like the problem l
Em Thu, Jan 10, 2008 at 03:26:59PM +, Jeba Anandhan escreveu:
> Hi Eric,
> Thanks for the reply. I have one more doubt. For example, if we have 2
> processor and 4 ethernet cards. Only CPU0 does all work through 8 cards.
> If we set the affinity to each ethernet card as CPU number, will it be
>
Chris Friesen wrote:
> Hi all,
>
> I've got an issue that's popped up with a deployed system running
> 2.6.10. I'm looking for some help figuring out why incoming network
> packets aren't being processed fast enough.
>
> After a recent userspace app change, we've started seeing packets being
> d
Dzianis Kahanovich wrote:
--- linux-2.6.23-gentoo-r2/net/sched/sch_ingress.c
+++ linux-2.6.23-gentoo-r2.fixed/net/sched/sch_ingress.c
@@ -161,2 +161,5 @@
skb->tc_index = TC_H_MIN(res.classid);
+#ifdef CONFIG_NET_SCH_INGRESS_TC2MARK
+skb->mark =
(skb->mark&(res.classid>>1
On Thu, 2008-01-10 at 16:36 +, Ben Hutchings wrote:
> > When I run netperf in just one interface, I get 940.95 * 10^6 bits/sec
> > of transfer rate. If I run 4 netperf against 4 different interfaces, I
> > get around 720 * 10^6 bits/sec.
>
>
> I take it that's the average for individual inter
To "classid x:y" = "mark=mark&x|y" ("classid :y" = "-j MARK --set-mark y", etc).
--- linux-2.6.23-gentoo-r2/net/sched/Kconfig
+++ linux-2.6.23-gentoo-r2.fixed/net/sched/Kconfig
@@ -222,6 +222,16 @@
To compile this code as a module, choose M here: the
module will be called sch_
Hi Eric,
While testing the current network namespace stuff merged in net-2.6.25,
I bumped into the following problem with the /proc/net/ entries.
It doesn't always display the actual data of the current namespace,
but sometime displays data from other namespaces.
I bisected the problem to the co
Hi all,
I've got an issue that's popped up with a deployed system running
2.6.10. I'm looking for some help figuring out why incoming network
packets aren't being processed fast enough.
After a recent userspace app change, we've started seeing packets being
dropped by the ethernet hardware
Ben,
I am facing the performance issue when we try to bond the multiple
interfaces with virtual interface. It could be related to this thread.
My questions are,
*) When we use mulitple NICs, will the performance of overall system be
summation of all individual lines XX bits/sec. ?
*) What are th
Breno Leitao wrote:
> Hello,
>
> I've perceived that there is a performance issue when running netperf
> against 4 e1000 links connected end-to-end to another machine with 4
> e1000 interfaces.
>
> I have 2 4-port interfaces on my machine, but the test is just
> considering 2 port for each inte
Hello,
I've perceived that there is a performance issue when running netperf
against 4 e1000 links connected end-to-end to another machine with 4
e1000 interfaces.
I have 2 4-port interfaces on my machine, but the test is just
considering 2 port for each interfaces card.
When I run netperf in
Am Donnerstag, 10. Januar 2008 schrieb Christian Borntraeger:
> Am Donnerstag, 10. Januar 2008 schrieb Christian Borntraeger:
> > Am Dienstag, 18. Dezember 2007 schrieb Rusty Russell:
> > > To me this points to doing interrupt suppression a different way. If
we
> > > have a ->disable_cb() virtio
1 - 100 of 146 matches
Mail list logo
