Hello
This is a repost, there seems to have a misunderstanding before.
I hope this is the right place to ask this. Does any know if there is a
substantial difference in the performance of the traffic controller
between kernel 2.4 and 2.6. We tested it using 1 iperf server and use
250 and 500 clien
On Tue, Oct 02, 2007 at 05:29:11PM +0200, Patrick McHardy wrote:
>
> I think this doesn't completely fix it, when dev_unicast_add is
> interrupted by dev_mc_add before the unicast changes are performed,
> they will get committed in the dev_mc_add context, so we might still
> call change_flags with
On Tue, 02 Oct 2007, jamal wrote:
> On Tue, 2007-02-10 at 00:25 -0400, Bill Fink wrote:
>
> > One reason I ask, is that on an earlier set of alternative batching
> > xmit patches by Krishna Kumar, his performance testing showed a 30 %
> > performance hit for TCP for a single process and a size of
On Wed, 03 Oct 2007 03:34:34 +0200
Ian Kumlien <[EMAIL PROTECTED]> wrote:
> On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote:
> > Remove unneeded check that caused problems with jumbo frame sizes.
> > The check was recently added and is wrong.
> > When using jumbo frames the sky2 driver
Stephen Hemminger wrote:
On Tue, 02 Oct 2007 21:07:22 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Stephen Hemminger wrote:
Remove unneeded check that caused problems with jumbo frame sizes.
The check was recently added and is wrong.
When using jumbo frames the sky2 driver does fragmentation,
On Tue, 02 Oct 2007 21:07:22 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > Remove unneeded check that caused problems with jumbo frame sizes.
> > The check was recently added and is wrong.
> > When using jumbo frames the sky2 driver does fragmentation, so
> > rx_data_
Of course, these are intended for 2.6.24. Also, I forgot to mention
that the individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-davem/
I also preserved the net-2.6.24 commit I based from as 'master-davem'
in case you need
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Tue, 2 Oct 2007 21:25:52 -0400
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
> upstream-davem
This doesn't pull cleanly.
Probably you used a recently cloned Linus tree, pulled
net-2.6.24 into that (and resolved the
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 2 Oct 2007 17:41:03 -0700
> Update baycom epp driver for new header ops in net-2.6.24
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied, thanks Stephen.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
th
The following changes since commit 3146b39c185f8a436d430132457e84fa1d8f8208:
Linus Torvalds (1):
Linux 2.6.23-rc9
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
fixes-jgarzik
Joe Perches (1):
bcm43xx: Correct pri
The following changes since commit d3adbde754a9ae7a6f87612055cb20db856f0721:
Ilpo Järvinen (1):
[TCP]: Wrap-safed reordering detection FRTO check
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-davem
Daniel Dra
On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote:
> Remove unneeded check that caused problems with jumbo frame sizes.
> The check was recently added and is wrong.
> When using jumbo frames the sky2 driver does fragmentation, so
> rx_data_size is less than mtu.
Confirmed working.
Now ru
Stephen Hemminger wrote:
Remove unneeded check that caused problems with jumbo frame sizes.
The check was recently added and is wrong.
When using jumbo frames the sky2 driver does fragmentation, so
rx_data_size is less than mtu.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers
Remove unneeded check that caused problems with jumbo frame sizes.
The check was recently added and is wrong.
When using jumbo frames the sky2 driver does fragmentation, so
rx_data_size is less than mtu.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-10-
Update baycom epp driver for new header ops in net-2.6.24
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/hamradio/baycom_epp.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hamradio/baycom_epp.c
b/drivers/net/hamradio/baycom_epp.c
in
Hello
I hope this is the right place to ask this.Does any know if there is a
substantial difference in the performance of the traffic controller
between kernel 2.4 and 2.6. We tested it using 1 iperf server and use
250 and 500 clients, altering the burst. We use the top command to
check the idle ti
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tue, 2 Oct 2007 13:41:50 -0400
> Please pull from the 'upstream' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream
Pulled and pushed back out to net-2.6.24, thanks Jeff!
-
To unsubscribe from this list: send the lin
Michael Chan wrote:
[BNX2]: Update version to 1.6.6.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
ACK patches 1-3
-
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/majordomo-info
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 02 Oct 2007 17:24:06 -0700
> [BNX2]: Update version to 1.6.6.
>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
Also applied to net-2.6.24, thanks!
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message t
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 02 Oct 2007 17:23:43 -0700
> [BNX2]: Optimize firmware loading.
>
> This is a follow up to the patches from Denys Vlasenkos
> <[EMAIL PROTECTED]> to further optimize firmware loading.
>
> 1. In bnx2_init_cpus(), we allocate memory for decompres
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 02 Oct 2007 17:23:09 -0700
> [BNX2]: Add missing napi_disable() in bnx2_close().
>
> bnx2_close() -> bnx2_netif_stop() will not call napi_disable() because
> the netif_state is not running in bnx2_close(). To avoid confusion,
> we change it to
[BNX2]: Update version to 1.6.6.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index c50e4c8..db14f35 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -56,8 +56,8 @@
#define DRV_MODULE_NAME"bnx2"
#define PFX DRV
[BNX2]: Optimize firmware loading.
This is a follow up to the patches from Denys Vlasenkos
<[EMAIL PROTECTED]> to further optimize firmware loading.
1. In bnx2_init_cpus(), we allocate memory for decompression once
and use it repeatedly instead of doing this for every firmware image.
2. We elimi
[BNX2]: Add missing napi_disable() in bnx2_close().
bnx2_close() -> bnx2_netif_stop() will not call napi_disable() because
the netif_state is not running in bnx2_close(). To avoid confusion,
we change it to disable interrupt and napi directly in bnx2_close().
Signed-off-by: Michael Chan <[EMAIL
Larry McVoy wrote:
On Tue, Oct 02, 2007 at 03:32:16PM -0700, David Miller wrote:
I'm starting to have a theory about what the bad case might
be.
A strong sender going to an even stronger receiver which can
pull out packets into the process as fast as they arrive.
This might be part of what kee
Brian,
I don't think a few instructions is a performance issue in the
redirect
paths (it'd be pretty broken if you're getting or generating lots of
them), but I
know there are lots of other checks similar to that that will break with
new
attributes, so doing that as a general clean-up se
On Tue, Oct 02, 2007 at 03:32:16PM -0700, David Miller wrote:
> I'm starting to have a theory about what the bad case might
> be.
>
> A strong sender going to an even stronger receiver which can
> pull out packets into the process as fast as they arrive.
> This might be part of what keeps the rece
On Tue, 2007-10-02 at 08:37 -0400, jamal wrote:
> The simplest solution seems to me to modify the definition of
> TG3_SKB_CB
> as i did for e1000 from:
> (struct tg3_tx_cbdata *)&((__skb)->cb[0])
> to:
> (struct tg3_tx_cbdata *)&((__skb)->cb[8])
>
> that way the vlan tags are always present and no
From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 02 Oct 2007 15:17:35 -0700
> Stranger still, with a mix of a 2.6.23-rc5ish kernel and a net-2.6.24 one
> (pulled oh middle of last week?) I get link-rate and I see no asymmetry
> between
> TCP_STREAM and TCP_MAERTS over an "e1000" link with no swi
David Miller wrote:
From: [EMAIL PROTECTED] (Larry McVoy)
Date: Tue, 2 Oct 2007 14:26:08 -0700
And note that sky2 doesn't have this problem. Does the broadcom do TSO?
And sky2 not? I noticed a much higher CPU load for sky2.
Yes the broadcoms (the revisions I have) do TSO and it is enabled
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 2 Oct 2007 14:52:36 -0700
> Please consider using netif_msg_xxx() and module parameter to set
> default message level, like other real network drivers already do.
I keep seeing this recommendation, but the two supposedly most mature
and activ
On Tue, 02 Oct 2007 23:02:53 +0200
Oliver Hartkopp <[EMAIL PROTECTED]> wrote:
> Arnaldo Carvalho de Melo wrote:
> > Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
> >
> >> +
> >> +#ifdef CONFIG_CAN_DEBUG_DEVICES
> >> +static int debug;
> >> +module_param(debug, int, S_IRUGO);
On Tue, 2 Oct 2007, Wayne Scott wrote:
>
> The slow set was done like this:
>
> on ia64: netcat -l -p > /dev/null
> on work: netcat ia64 < /dev/zero
That sounds wrong. Larry claims the slow case is when the side that did
"accept()" does the sending, the above has the listener jus
Stephen Hemminger wrote:
On Tue, 02 Oct 2007 14:11:38 -0700
[EMAIL PROTECTED] wrote:
From: Mariusz Kozlowski <[EMAIL PROTECTED]>
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
Cc: Stephen Hemminger <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMA
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Tue, 2 Oct 2007 18:43:25 -0300
> I think that helping ctags to find the definition for the debug variable
> to see, for instance, if it is a bitmask or a boolean without having to
> chose from tons of 'debug' variables is a good thing.
I co
On Tue, 02 Oct 2007 14:11:41 -0700
[EMAIL PROTECTED] wrote:
> From: "Ed Swierk" <[EMAIL PROTECTED]>
>
> Log "no link during initialization" at KERN_INFO as it's not an error, and
> occurs every time the interface comes up (when the forcedeth-phy-power-down
> patch is applied).
>
> Signed-off-by:
> On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
>
> > I'm currently out of ideas where it could come from...
Hmm, there seems to be off-by-one in tcp_retrans_try_collapse after
all, or in fact, two of them. I'll post patch for this tomorrow...
--
i.
From: [EMAIL PROTECTED] (Larry McVoy)
Date: Tue, 2 Oct 2007 14:26:08 -0700
> And note that sky2 doesn't have this problem. Does the broadcom do TSO?
> And sky2 not? I noticed a much higher CPU load for sky2.
Yes the broadcoms (the revisions I have) do TSO and it is enabled
on both sides.
Which
On Tue, 02 Oct 2007 14:11:38 -0700
[EMAIL PROTECTED] wrote:
> From: Mariusz Kozlowski <[EMAIL PROTECTED]>
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
> Cc: Stephen Hemminger <[EMAIL PROTECTED]>
> Cc: Jeff Garzik <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
>
Em Tue, Oct 02, 2007 at 11:02:53PM +0200, Oliver Hartkopp escreveu:
> Arnaldo Carvalho de Melo wrote:
>> Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
>>
>>> +
>>> +#ifdef CONFIG_CAN_DEBUG_DEVICES
>>> +static int debug;
>>> +module_param(debug, int, S_IRUGO);
>>> +#endif
>>>
From: [EMAIL PROTECTED] (Larry McVoy)
Date: Tue, 2 Oct 2007 11:40:32 -0700
> I doubt it, the same test works fine in one direction and poorly in the other.
> Wouldn't the flow control squelch either way?
HW controls for these things are typically:
1) Generates flow control flames
2) Listens for
On Tue, Oct 02, 2007 at 02:16:56PM -0700, David Miller wrote:
> We absolutely depend upon people like you to report when there are
> anomalies like this. It's the only thing that scales.
Well cool, finally doing something useful :)
Is this issue no test setup? Because this does seem like someth
pasemi_mac: use buffer index pointer in clean_rx()
Use the new features in B0 for buffer ring index on the receive side. This
means we no longer have to search in the ring for where the buffer
came from.
Also cleanup the RX cleaning side a little, while I was at it.
Note: Pre-B0 hardware is no l
pasemi_mac: use buffer index pointer in clean_rx()
Use the new features in B0 for buffer ring index on the receive side. This
means we no longer have to search in the ring for where the buffer
came from.
Also cleanup the RX cleaning side a little, while I was at it.
Note: Pre-B0 hardware is no l
pasemi_mac: update todo list
Remove some stale todo items that have been taken care of. Add a couple
of upcoming ones.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: 2.6.23/drivers/net/pasemi_mac.c
===
--- 2.6.23.orig/driv
pasemi_mac: clear out old errors on interface open
Clear out any pending errors when an interface is brought up. Since the bits
are sticky, they might be from interface shutdown time after firmware has
used it, etc.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: k.org/drivers/net/pasem
pasemi_mac: add local skb alignment
Add local SKB alignment to pasemi_mac, since ppc64 in general has it at 0
because of design flaws in some of the IBM server bridge chips. However,
for PWRficient doing the unaligned copies is more expensive than doing
unaligned DMA so make sure the data is align
pasemi_mac: further performance tweaks
Misc driver tweaks for pasemi_mac:
* Increase ring size (really needed mostly on 10G)
* Take out an unneeded barrier
* Move around a few prefetches and reorder a few calls
* Don't try to clean on full tx buffer, just let things
pasemi_mac: implement sg support
Implement SG support for pasemi_mac
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: k.org/drivers/net/pasemi_mac.c
===
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/drivers/net/pasemi_ma
pasemi_mac: workaround for erratum 5971
Implement workarounds for erratum 5971, where L2 hints aren't considered
properly unless the way hint is enabled on the interface. Since L2 isn't
setup to dedicate a way to headers, we need to reset the packet count
by hand so it won't run out of credits.
S
From: Magnus Damm <[EMAIL PROTECTED]>
Hook up the 93cx6 eeprom code to the ax88796 driver and modify the ax88796
driver to read out the mac address from the eeprom. We need this for the
ax88796 on certain SuperH boards. The pin configuration used to connect
the eeprom to the ax88796 on these boa
From: "Maciej W. Rozycki" <[EMAIL PROTECTED]>
Ensure the PHY_HALTED state is not entered with the IRQ asserted as it
could lead to an interrupt loop.
There is a small window in phy_stop(), where the state of the PHY machine
indicates it has been halted, but its interrupt output might still be
unm
pasemi_mac: rework ring management
Rework ring management, switching to an opaque ring format instead of
the struct-based descriptor+pointer setup, since it will be needed for
SG support.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: k.org/drivers/net/pasemi_mac.c
pasemi_mac: fix bug in receive buffer dma mapping
skb->len isn't actually set to the size of the allocated skb, so don't
try to use it when figuring out how much to map.
(This hasn't surfaced as a real bug because we effectively disable
translation for the interface, but it still needs fixing for
From: Roy Zang <[EMAIL PROTECTED]>
Clean up redundant PHY write line for ULi526x Ethernet Driver.
Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Acked-by: Grant Grundler <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/tulip/u
> We fixed a lot of bugs in TSO last year.
>
> It would be really great to see numbers with a more recent kernel
> than 2.6.18
More data, sky2 works fine (really really fine, like 79MB/sec) between
Linux dylan.bitmover.com 2.6.18.1 #5 SMP Mon Oct 23 17:36:00 PDT 2006 i686
Linux steele 2.6.20-16-g
pasemi_mac: basic error checking
Add some rudimentary error checking to pasemi_mac.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: k.org/drivers/net/pasemi_mac.c
===
--- k.org.orig/drivers/net/pasemi_mac.c
+++ k.org/driver
On Tue, Oct 02, 2007 at 02:11:38PM -0700, [EMAIL PROTECTED] wrote:
> From: Micah Gruber <[EMAIL PROTECTED]>
>
> This patch fixes an apparent potential null dereference bug where we
> dereference dev before a null check. This patch simply remvoes the
> can't-happen test for a null pointer.
>
> Si
Hi,
This series of patches go on top of the previous fixes that were sent
out and picked up.
It's a series of mostly feature-related changes, but also a couple
of bugfixes:
[1/11] pasemi_mac: basic error checking
[2/11] pasemi_mac: fix bug in receive buffer dma mapping
[3/11] pasemi_mac: rework
From: [EMAIL PROTECTED] (Larry McVoy)
Date: Tue, 2 Oct 2007 09:48:58 -0700
> Isn't this something so straightforward that you would have tests for it?
> This is the basic FTP server loop, doesn't someone have a big machine with
> 10gig cards and test that sending/recving data doesn't regress?
Nob
On Tue, Oct 02, 2007 at 03:02:56PM -0700, Michael Chan wrote:
> On Tue, 2007-10-02 at 16:16 -0400, Andy Gospodarek wrote:
> > Adding that flag in tg3_set_settings seemed like the most logical
> > place
> > since the driver works fine on boot. This is just an issue when
> > re-enabling autonegotiat
From: "Maciej W. Rozycki" <[EMAIL PROTECTED]>
Keep track of disable_irq_nosync() invocations and call enable_irq() the
right number of times if work has been cancelled that would include them.
Now that the call to flush_work_keventd() (problematic because of
rtnl_mutex being held) has been replac
From: "Maciej W. Rozycki" <[EMAIL PROTECTED]>
Use spin_lock_bh()/spin_unlock_bh() for the phydev lock throughout as it
is used in phy_timer() that is called as a softirq and all the other
operations may happen in the user context.
There has been a change recently that did such a conversion for so
From: Micah Gruber <[EMAIL PROTECTED]>
This patch fixes an apparent potential null dereference bug where we
dereference dev before a null check. This patch simply remvoes the
can't-happen test for a null pointer.
Signed-off-by: Micah Gruber <[EMAIL PROTECTED]>
Cc: Grant Grundler <[EMAIL PROTECTE
From: Adrian Bunk <[EMAIL PROTECTED]>
This patch removes dead code ("tx_xcnt" can never be != 0 at this place)
spotted by the Coverity checker.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/xgmac.c |5 +
1 file chan
From: "Peter Oruba" <[EMAIL PROTECTED]>
These driver changes incorporate the proposed PCI-X / PCI-Express read byte
count interface. Reading and setting those valuse doesn't take place
"manually", instead wrapping functions are called to allow quirks for some
PCI bridges.
[EMAIL PROTECTED]: e100
From: "Ed Swierk" <[EMAIL PROTECTED]>
Bring the physical link down when the interface is down, by placing the PHY in
power-down state. This mirrors the behavior of other drivers including e1000
and tg3.
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
Cc: Ayaz Abdulla <[EMAIL PROTECTED]>
Cc: Jeff Ga
From: "Ed Swierk" <[EMAIL PROTECTED]>
Log "no link during initialization" at KERN_INFO as it's not an error, and
occurs every time the interface comes up (when the forcedeth-phy-power-down
patch is applied).
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
Cc: Ayaz Abdulla <[EMAIL PROTECTED]>
Cc: Jef
From: Mariusz Kozlowski <[EMAIL PROTECTED]>
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
Cc: Stephen Hemminger <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/skge.h |2 --
1 file changed, 2 deletions(-)
diff -
From: Vitaly Bordug <[EMAIL PROTECTED]>
device_bind_driver() error code returning has been fixed. release()
function has been written, so that to free resources in correct way; the
release path is now clean.
Before the rework, it used to cause
Device '[EMAIL PROTECTED]:1' does not have a releas
From: Jesper Juhl <[EMAIL PROTECTED]>
In xl_freemem(), if dev_if is NULL, the line
struct xl_private *xl_priv =(struct xl_private *)dev->priv;
will cause a NULL pointer dereference.
(akpm: don't try to fix it: just delete the pointless test-for-null)
Signed-off-by: Jesper Juhl <[EMAIL PROTEC
From: Andrew Morton <[EMAIL PROTECTED]>
net/sctp/sm_statetable.c:551: error: 'sctp_sf_tabort_8_4_8' undeclared here
(not in a function)
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
net/sctp/sm_statetable.c |2 --
1 file changed, 2 deletions(-)
diff -puN net/sctp/sm_statetable.c~g
From: trem <[EMAIL PROTECTED]>
I've tried to compile 2.6.23-rc8-mm2, but it fails on ipg.c with the
error : ERROR: "__udivdi3" [drivers/net/ipg.ko] undefined!
I've instigated a bit, and I've found this code in ipg.c :
static void ipg_nic_txfree(struct net_device *dev)
{
struct ipg_nic_pri
Hi David,
David Stevens wrote:
ipv6_addr_type() returns a mask, so checking for equality will
fail to
match if any other (irrelevant) attributes are set. How about using
bitwise
operators for that?
ipv6_addr_type() does return a mask, but there's a lot of code that just
checks for
From: Andrew Morton <[EMAIL PROTECTED]>
drivers/net/hamradio/baycom_epp.c: In function 'baycom_probe':
drivers/net/hamradio/baycom_epp.c:1162: error: 'struct net_device' has no
member named 'hard_header'
drivers/net/hamradio/baycom_epp.c:1163: error: 'struct net_device' has no
member named 'rebu
On Tue, 2007-10-02 at 16:16 -0400, Andy Gospodarek wrote:
> Adding that flag in tg3_set_settings seemed like the most logical
> place
> since the driver works fine on boot. This is just an issue when
> re-enabling autonegotiation, so we should probably nip it there.
>
> Signed-off-by: Andy Gospod
Arnaldo Carvalho de Melo wrote:
Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
+
+#ifdef CONFIG_CAN_DEBUG_DEVICES
+static int debug;
+module_param(debug, int, S_IRUGO);
+#endif
Can debug be a boolean? Like its counterpart on DCCP:
net/dccp/proto.c:
module_param(dcc
> It would be really great to see numbers with a more recent kernel
> than 2.6.18
FWIW Debian has binaries for 2.6.21 in testing and for 2.6.22 in
unstable so it should be very easy for Larry to try at least those.
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
Alternatively, take your favorite test programs, such as John's,
and make a second pair that reverses the direction the data is
sent. So one pair is server sends, the other is server receives,
try both. That's where we started, BitKeeper, my stripped down test,
and John's test all exhibit the
Brian,
ipv6_addr_type() returns a mask, so checking for equality will
fail to
match if any other (irrelevant) attributes are set. How about using
bitwise
operators for that? Also, the error message is no longer descriptive of
the
failure if it's a link-local multicast, but you could mak
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 2 Oct 2007 12:27:53 -0700 (PDT)
> We see a single packet containing 16060 bytes, which seems to be because
> of TSO on the sending side (you did your tcpdump on the sender, no?), so
> it will actually be broken up into 11 1460-byte regular fram
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Tue, 2 Oct 2007 12:29:50 -0700 (PDT)
> On Tue, 2 Oct 2007, Larry McVoy wrote:
> >
> > No HP in the mix. It's got nothing to do with hp, nor to do with rsh, it
> > has everything to do with the direction the data is flowing.
>
> Can you tcpdump b
I recently noticed that when calling:
# ethtool -s eth0 autoneg on
on a 5722 (though I'm sure it's not specific to that card) that
subsequent checks of the cards status looked like this:
# ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes: 10baseT/H
> I think I'm still missing some basic data here (probably because this
> thread did not originate on netdev). Let me try to nail down some of
> the basics. You have a linux ia64 box (running 2.6.12 or 2.6.18?) that
> sends slowly, and receives faster, but not quite a 1 Gbps? And this is
> t
Ayaz Abdulla wrote:
I am trying to track down a forcedeth driver issue described by bug
9047 in bugzilla (2.6.23-rc7-git1 forcedeth w/ MCP55 oops under heavy
load). I added a patch to synchronize the timer handlers so that one
handler doesn't accidently enable the IRQ while another timer handle
On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
> I'm currently out of ideas where it could come from... so lets try
> brute-force checking as your test case is not very high-speed... This
> could hide it though... :-(
>
> Please put the patch below on top of clean rc8-mm2 (it includes the patch
> I g
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index d6d9413..6acfdc4 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -444,7 +444,7 @@ stati
Larry McVoy wrote:
More data, we've conclusively eliminated the card / cpu from the mix.
We've got 2 ia64 boxes with e1000 interfaces. One box is running
linux 2.6.12 and the other is running hpux 11.
I made sure the linux one was running at gigabit and reran the tests
from the linux/ia64 <=> h
I also would have expected more ACK's from the HP box. It's been a long
time since I did TCP, but I thought the rule was still that you were
supposed to ACK at least every other full frame - but the HP box is acking
roughly every 16K (and it's *not* always at TSO boundaries: the earlier
ACK's i
Larry McVoy wrote:
On Tue, Oct 02, 2007 at 11:01:47AM -0700, Rick Jones wrote:
has anyone already asked whether link-layer flow-control is enabled?
I doubt it, the same test works fine in one direction and poorly in the other.
Wouldn't the flow control squelch either way?
While I am often
More data, we've conclusively eliminated the card / cpu from the mix.
We've got 2 ia64 boxes with e1000 interfaces. One box is running
linux 2.6.12 and the other is running hpux 11.
I made sure the linux one was running at gigabit and reran the tests
from the linux/ia64 <=> hp/ia64. Same results
On Tue, 2 Oct 2007, Larry McVoy wrote:
>
> No HP in the mix. It's got nothing to do with hp, nor to do with rsh, it
> has everything to do with the direction the data is flowing.
Can you tcpdump both cases and send snippets (both of steady-state, and
the initial connect)?
On Tue, 2 Oct 2007, Larry McVoy wrote:
>
> tcpdump is a good idea, take a look at this. The window starts out
> at 46 and never opens up in my test case, but in the rsh case it
> starts out the same but does open up. Ideas?
I don't think that's an issue, since you only send one way. The wind
When the ICMPv6 Target address is multicast, Linux processes the
redirect instead of dropping it. The problem is in this code in
ndisc_redirect_rcv():
if (ipv6_addr_equal(dest, target)) {
on_link = 1;
} else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
> Looks like you have TSO enabled. Does it behave differently if it's
> disabled?
It cranks the interrupts/sec up to 8K instead of 5K. No difference in
performance other than that.
> I think Rick Jones is on to something with the HP ack avoidance.
I sincerely doubt it. I'm only using the
>Umm... this is a difficult situation for me to merge the changes then.
>We're changing the CM retry behavior blind here. How do we know that
>the MRA changes don't make the scalability issue worse?
What's currently upstream doesn't work for Intel MPI on our larger clusters.
The connection reques
On Tue, Oct 02, 2007 at 11:01:47AM -0700, Rick Jones wrote:
> has anyone already asked whether link-layer flow-control is enabled?
I doubt it, the same test works fine in one direction and poorly in the other.
Wouldn't the flow control squelch either way?
--
---
Larry McVoylm at b
> Make sure you don't have slab debugging turned on. It kills performance.
It's a stock debian kernel, so unless they turn it on it's off.
--
---
Larry McVoylm at bitmover.com http://www.bitkeeper.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
Larry McVoy wrote:
On Tue, Oct 02, 2007 at 06:52:54PM +0800, Herbert Xu wrote:
One of my clients also has gigabit so I played around with just that
one and it (itanium running hpux w/ broadcom gigabit) can push the load
as well. One weird thing is that it is dependent on the direction the
data
> >OK -- just to make sure I'm understanding what you're saying: have you
> >confirmed that your proposed [CM MRA] patches actually fix the issue?
>
> Not directly. I cannot easily test kernel patches on our larger, production
> clusters. We've seen the issue with specific applications on 5
1 - 100 of 182 matches
Mail list logo
