Re: [PATCH] forcedeth: suggested cleanups

Ingo Oeser wrote: Hi there, here are some suggested cleanups, which compiled without problems using allyesconfig on the latest net-2.6 git tree from David S. Miller. Please review and apply, if convienient. I think the patch should wait until 0.57 is merged: There are 4 patches on their

Re: bcm43xx symbol clash problems

On Mon, 2006-04-10 at 02:16 +0200, Michael Buesch wrote: Does kbuild perhaps have some magic to handle that? This needs to be solved soon, but I have no idea how. You want to have bcm43xx and bcm43xx-dscape conflict anyway, since there's no point in building both into the kernel, only one can

Re: [PATCH] IrDA: smcinit merged into smsc-ircc driver

On Tue, 11 Apr 2006, Meelis Roos wrote: Detected unconfigured Toshiba Satellite 1800 SMSC IrDA chip, pre-configuring device. SORRY: Toshiba Satellite 1800 has an unsupported bridge controller (ALi): not pre-configured. smsc-ircc2, Preconfiguration failed ! Yep we don't have support for ALi

Re: [PATCH] softmac: don't send out packets while scanning

On Mon, 2006-04-10 at 15:04 +0100, Daniel Drake wrote: I think netif_stop_queue() is only supposed to be used directly from inside a hard_start_xmit function. I think we should be using netif_disable_tx() here. Looks about right to me, since that actually does a spinlock :) I'll send a new

Re: [PATCH] IrDA: smcinit merged into smsc-ircc driver

Detected unconfigured Toshiba Satellite 1800 SMSC IrDA chip, pre-configuring device. SORRY: Toshiba Satellite 1800 has an unsupported bridge controller (ALi): not pre-configured. smsc-ircc2, Preconfiguration failed ! Yep we don't have support for ALi bridges yet, the Toshiba 1800 still needs

Re: [PATCH] deinline a few large functions in vlan code v2

block? For example, typhoon.c: spin_lock(tp-state_lock); +#if defined(CONFIG_VLAN_8021Q) || defined (CONFIG_VLAN_8021Q_MODULE) if(tp-vlgrp != NULL rx-rxStatus TYPHOON_RX_VLAN) vlan_hwaccel_receive_skb(new_skb,

[PATCH] shutting down an interface should remove ipv4 addresses

... but it doesn't, so those addresses are treated as local which is bad. This problem doesn't exist with ipv6 and the patch is based on the solution found there. --- linux-2.4.32.orig/net/ipv4/devinet 2004-08-08 01:26:06.0 +0200 +++ linux-2.4.32/net/ipv4/devinet.c 2006-04-11

Re: [PATCH] shutting down an interface should remove ipv4 addresses

From: Matyas Koszik [EMAIL PROTECTED] Date: Tue, 11 Apr 2006 09:44:55 +0200 (CEST) ... but it doesn't, so those addresses are treated as local which is bad. No, shutting down an interface should not remove ipv4 addresses. The user must explicitly remove them. This behavior has been around

[PATCH 3/3] deinline a few large functions in vlan code - v3

On Tuesday 11 April 2006 10:44, Denis Vlasenko wrote: On Tuesday 11 April 2006 10:43, Denis Vlasenko wrote: These patches exclude VLAN code from netdevice drivers and from bonding module, and even remove vlan-related members of struct netdevice if VLAN is not configured. Compile tested on

[PATCH 1/3] deinline a few large functions in vlan code - v3

Hi, After davem and Dave Dillow comments I realized that a lot of drivers try to do VLAN-related things even on non-VLAN-enabled kernels. These patches exclude VLAN code from netdevice drivers and from bonding module, and even remove vlan-related members of struct netdevice if VLAN is not

[PATCH 2/3] deinline a few large functions in vlan code - v3

On Tuesday 11 April 2006 10:43, Denis Vlasenko wrote: These patches exclude VLAN code from netdevice drivers and from bonding module, and even remove vlan-related members of struct netdevice if VLAN is not configured. Compile tested on allyesconfig kernel with CONFIG_8021Q=y,m,n. This one

Re: [PATCH] shutting down an interface should remove ipv4 addresses

On Tue, 11 Apr 2006, David S. Miller wrote: From: Matyas Koszik [EMAIL PROTECTED] Date: Tue, 11 Apr 2006 09:44:55 +0200 (CEST) ... but it doesn't, so those addresses are treated as local which is bad. No, shutting down an interface should not remove ipv4 addresses. The user must

Re: [PATCH] shutting down an interface should remove ipv4 addresses

From: Matyas Koszik [EMAIL PROTECTED] Date: Tue, 11 Apr 2006 10:08:01 +0200 (CEST) Then it maybe shouldn't affect the flow of packets while the interface is down - or is it also something people depend on? Yes, people probably do depend upon it. Addresses are owned by the host not a

Re: [PATCH 3/3] deinline a few large functions in vlan code - v3

On Tuesday 11 April 2006 10:58, David S. Miller wrote: This is not very nice, there is no way I'm applying these patches. I think the current situation is far better than the large pile of ifdefs these patches are adding to the tree. Let's just leave things the way they are ok? :( Ok,

Re: [PATCH 3/3] deinline a few large functions in vlan code - v3

From: Denis Vlasenko [EMAIL PROTECTED] Date: Tue, 11 Apr 2006 11:11:12 +0300 Ok, one last try. Would you like this smallish patch instead? It takes care of those BIG inlines. You're putting vlan stuff into a net/core/*.c file, that is not correct. If we're not going to do the ifdef mess,

Re: [RFC: 2.6 patch] the overdue removal of ip{,6}_queue

On Sun, Apr 09, 2006 at 08:40:05PM +0200, Patrick McHardy wrote: Adrian Bunk wrote: This patch contains the overdue removal of ip{,6}_queue. I think this is too early, none of the distributions seem to have picked up the compat library already. I believe (not sure, Harald?) that it

Re: [PATCH] forcedeth: suggested cleanups

Hi Manfred, Manfred Spraul wrote: I think the patch should wait until 0.57 is merged: There are 4 patches on their way to Jeff. These patches contain several bugfixes, they should have the higher priority. Fine with me. Will resubmit after next week. Apart from that: looks good. Many

Re: Broadcast ARP packets on link local addresses (Version2).

It seems the discussion has died. How is this to move forward? I'm not sure who is responsible for this part of the kernel. There are a few options: 1. Broadcast ARP by checking the IP range in kernel (current patch) 2. Broadcast ARP if the scope parameter is link 3. Broadcast ARP if a new (to be

Re: [PATCH] deinline a few large functions in vlan code v2

Hi Denis, Denis Vlasenko wrote: +#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) if(vlan_tx_tag_present(skb)) { first_txd-processFlags |= TYPHOON_TX_PF_INSERT_VLAN | TYPHOON_TX_PF_VLAN_PRIORITY; @@ -844,6 +849,7 @@

Re: [e1000 debug] KERNEL: assertion (!sk_forward_alloc) failed...

Maybe it's unrelated to this problem, but it is interesting observation, at least for me. All boxes running for two weeks now and spitting these assert messages have about 1,5GB of slab size allocated, with skbuff_head_cache entry being the largest entry. After rebooting, it is all nice and

linux-source-2.6.16: inconsistent device detetion: eth0=eth1

Subject: linux-source-2.6.16: inconsistent device detetion: eth0=eth1 Package: linux-source-2.6.16 Version: 2.6.16-2 Severity: normal I have two ethernet cards on my box, an onboard SiS 7012 and a pci ne-2k compatible. When I boot the system, sometimes the SiS is detected as eth0 and the pci as

Re: [XFRM] Restore aevent timer

Hi Jamal: On Mon, Apr 10, 2006 at 11:02:06PM -0400, jamal wrote: Ok, if both you can provide feedback on the attached patch (untested but compiles) I will make any necessary changes, test and push this + documentation to Dave. Looks good to me. diff --git a/net/xfrm/xfrm_state.c

Re: [PATCH] net drivers: fix section attributes for gcc

Is this pending in your tree Jeff? It fixes compile regressions with HOTPLUG disabled. Sam On Mon, Apr 03, 2006 at 04:28:46PM -0700, Randy.Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] If CONFIG_HOTPLUG=n, gcc doesn't like some __initdata to be const (rodata) and other

Re: [PATCH 3/3] deinline a few large functions in vlan code - v3

On Tuesday 11 April 2006 11:36, David S. Miller wrote: From: Denis Vlasenko [EMAIL PROTECTED] Date: Tue, 11 Apr 2006 11:11:12 +0300 Ok, one last try. Would you like this smallish patch instead? It takes care of those BIG inlines. You're putting vlan stuff into a net/core/*.c file, that

[patch 3/3] softmac: handle iw_mode properly

Below patch allows using iw_mode auto with softmac. bcm43xx forces managed so this bug wasn't noticed earlier, but this was one of the problems why zd1211 didn't work earlier. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- wireless-2.6.orig/net/ieee80211/softmac/ieee80211softmac_io.c

[patch 1/3] softmac: return -EAGAIN from getscan while scanning

Below patch was developed after discussion with Daniel Drake who mentioned to me that wireless tools expect an EAGAIN return from getscan so that they can wait for the scan to finish before printing out the results. Signed-off-by: Johannes Berg [EMAIL PROTECTED] ---

[patch 0/3] softmac patches

Here are a few patches to softmac for issues that came up in discussions with Daniel and others. - 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.html

Re: [XFRM] Restore aevent timer

Hi, On Tuesday 11 April 2006 05.02, jamal wrote: Ok, if both you can provide feedback on the attached patch (untested but compiles) I will make any necessary changes, test and push this + documentation to Dave. Looks ok, although I only had a quick look at it. -- Regards, Krisztian

Re: linux-source-2.6.16: inconsistent device detetion: eth0=eth1

josh wrote: I have two ethernet cards on my box, an onboard SiS 7012 and a pci ne-2k compatible. When I boot the system, sometimes the SiS is detected as eth0 and the pci as eth1, and sometimes the SiS is eth1 and the pci eth0, *without my changing anything*. I just reboot and it's different.

Re: [PATCH] deinline a few large functions in vlan code v2

Hi Denis, Denis Vlasenko wrote: On Tuesday 11 April 2006 12:49, Ingo Oeser wrote: #if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE) static inline has_vlan_group(...) { /* get VLAN group */ } #else static inline has_vlan_group(...) {return 0;} #endif With

Re: [PATCH] deinline a few large functions in vlan code v2

On Tue, 2006-04-11 at 10:28 +0300, Denis Vlasenko wrote: block? For example, typhoon.c: spin_lock(tp-state_lock); +#if defined(CONFIG_VLAN_8021Q) || defined (CONFIG_VLAN_8021Q_MODULE) if(tp-vlgrp != NULL rx-rxStatus TYPHOON_RX_VLAN)

Re: Broadcast ARP packets on link local addresses (Version2).

Freek Dijkstra wrote: It seems the discussion has died. How is this to move forward? I'm not sure who is responsible for this part of the kernel. There are a few options: 1. Broadcast ARP by checking the IP range in kernel (current patch) 2. Broadcast ARP if the scope parameter is link 3.

Re: [RFC: 2.6 patch] the overdue removal of ip{,6}_queue

Harald Welte wrote: On Sun, Apr 09, 2006 at 08:40:05PM +0200, Patrick McHardy wrote: I think this is too early, none of the distributions seem to have picked up the compat library already. I believe (not sure, Harald?) that it requires at least recompilation of programs using libipq, so the 6

tc actions like pass,drop executed at a given percentage, not every nth

Hi all! Can you give me some guideline about how and where netrand ... influences an action in the tc sources? (I've also tried LARTC mailing list, but did not get any response) When I last checked, iproute2 sources had a tc gact module with 2 statistical netrand methods: - random - determ

Re: Qdisc peek operation

jamal wrote: On Thu, 2006-06-04 at 18:29 +0200, Patrick McHardy wrote: [..] There are basically two possibilities how to implement this. The less intrusive, but IMO more hackish one is to just handle this inside the qdiscs that require this operation by not requeueing the packet to the

Re: [PATCH] bridge: receive link-local on disabled ports.

On Mon, 2006-04-10 at 16:39 -0700, David S. Miller wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Mon, 10 Apr 2006 16:24:29 -0700 This change allows link local packets (like 802.3ad and Spanning Tree Protocol) to be processed even when the bridge is not using the port. It fixes

[RFT] dlink pci cards using wrong driver

This patch fixes the problem of some Dlink cards picking the wrong driver. It looks like these cards use Yukon 1 chipset, not Yukon 2. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- sky2-2.6.17.orig/drivers/net/skge.c 2006-03-24 09:56:05.0 -0800 +++

Re: [RFT] dlink pci cards using wrong driver

Stephen Hemminger wrote: This patch fixes the problem of some Dlink cards picking the wrong driver. It looks like these cards use Yukon 1 chipset, not Yukon 2. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- sky2-2.6.17.orig/drivers/net/skge.c 2006-03-24 09:56:05.0 -0800 +++

[RFC] selective ethtool diagnostic test method

I have searched the netdev archives and have not found any RFC like this. This proposal is to add selective diag/test modes to ethtool with minimal overhead/bloat. Please provide feedback on the proposal. This proposed selective test mode is being requested more and more from our Linux users, so

[PATCH 2/3] eth: indentation and whitespace

Run the ethernet common code through indent, and fix other whitespace issues. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- net-2.6.orig/net/ethernet/eth.c 2006-04-11 10:07:37.0 -0700 +++ net-2.6/net/ethernet/eth.c 2006-04-11 10:18:37.0 -0700 @@ -66,55 +66,46 @@

[PATCH 0/3] eth.c cleanups for 2.6.18

Minor optimizations and cleanups to the common ethernet header routines. -- - 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.html

[PATCH 3/3] eth: dont use __constant_htons

Don't need to use __constant_htons here. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- net-2.6.orig/net/ethernet/eth.c 2006-04-11 10:18:37.0 -0700 +++ net-2.6/net/ethernet/eth.c 2006-04-11 10:21:40.0 -0700 @@ -208,7 +208,7 @@ eth = (struct ethhdr *)

[PATCH 1/3] eth: use constant size address

Change the ethernet support routines to use constant address size. This generates smaller faster code. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- net-2.6.orig/net/ethernet/eth.c 2006-04-11 09:43:40.0 -0700 +++ net-2.6/net/ethernet/eth.c 2006-04-11 10:07:37.0

Re: [RFC: 2.6 patch] the overdue removal of ip{,6}_queue

On Tue, Apr 11, 2006 at 04:42:50PM +0200, Patrick McHardy wrote: Maybe we should add a printk ('app foo is using obsolete ip_queue system'). Good idea, that will probably help speed it up. But I still think we need to give them at least another six month. ok. I'll prepare a patch for both

Re: bcm43xx symbol clash problems

On Tue, 2006-04-11 at 18:35 +0200, Michael Buesch wrote: Sure. I would probably say that both m should conflict, too. Nah, you probably want both m for testing. And one y and the other m, too. Yeah that should conflict too. This can be done with ugly depends statements. I have no idea.

Re: created new q_disc, inserted module, tc tells me unknown qdisc

On Mon, 10 Apr 2006 21:41:39 -0400 (EDT) George P Nychis [EMAIL PROTECTED] wrote: Hi, I am trying to install a proprietary qdisc made for research, it is not publically released yet, however its been used several times so i know it works. The files included are: q_xcp.c: static

2.6.17 regression: Very slow net transfer from some hosts

Hi, Since sometime after 2.6.16, some websites have been very slow to load. Examples include: http://zd1211.ath.cx http://developer.osdl.org/shemminger/blog/ http://www.reactivated.net/weblog On a good kernel, wget http://zd1211.ath.cx; says: 20:23:38 (90.44 KB/s) - `index.html' saved

Re: 2.6.17 regression: Very slow net transfer from some hosts

On Tue, 11 Apr 2006 20:30:46 +0100 Daniel Drake [EMAIL PROTECTED] wrote: Hi, Since sometime after 2.6.16, some websites have been very slow to load. Examples include: http://zd1211.ath.cx http://developer.osdl.org/shemminger/blog/ http://www.reactivated.net/weblog On a good

Re: 2.6.17 regression: Very slow net transfer from some hosts

Daniel Drake wrote: Hi, Since sometime after 2.6.16, some websites have been very slow to load. Examples include: http://zd1211.ath.cx http://developer.osdl.org/shemminger/blog/ http://www.reactivated.net/weblog On a good kernel, wget http://zd1211.ath.cx; says: 20:23:38 (90.44 KB/s) -

Re: 2.6.17 regression: Very slow net transfer from some hosts

John Heffner wrote: I'm not seeing this behavior myself. What are the values of /proc/sys/net/ipv4/tcp_wmem, tcp_rmem, and tcp_mem? How much memory does this system have? (A binary tcpdump might be good, too.) tcp_wmem: 409616384 131072 tcp_rmem: 409687380 174760 tcp_mem: 98304

Re: 2.6.17 regression: Very slow net transfer from some hosts

Daniel Drake wrote: John Heffner wrote: I'm not seeing this behavior myself. What are the values of /proc/sys/net/ipv4/tcp_wmem, tcp_rmem, and tcp_mem? How much memory does this system have? (A binary tcpdump might be good, too.) tcp_wmem: 409616384 131072 tcp_rmem: 409687380

Re: created new q_disc, inserted module, tc tells me unknown qdisc

On Mon, 10 Apr 2006 21:41:39 -0400 (EDT) George P Nychis [EMAIL PROTECTED] wrote: Hi, I am trying to install a proprietary qdisc made for research, it is not publically released yet, however its been used several times so i know it works. The files included are: q_xcp.c: static int

Re: [LARTC] Re: created new q_disc, inserted module, tc tells me unknown qdisc

I am getting closer... I added debugging, and noticed that it looks for: snprintf(buf, sizeof(buf), %s_qdisc_util, str); However in q_xcp.c it had: struct qdisc_util xcp_util = { so I changed that to xcp_qdisc_util, and now i run tc: lanthanum-ini tc # tc qdisc add dev ath0 root

Re: 2.6.17 regression: Very slow net transfer from some hosts

John Heffner wrote: tcp_wmem: 409616384 131072 tcp_rmem: 409687380 174760 tcp_mem: 98304 131072 196608 These are (I assume) with the patch reversed. What are the values with the patch applied? Yes- that was on a good kernel, with the patch reversed. On a bad kernel, with

Re: [RFC/PATCH] remove unneeded check in bcm43xx

I think allowing DMA mask range limiting in the IOMMU layer is going to set a very bad precedence, just don't do it. It's 2006, we should be way past the era of not putting the full 32 PCI DMA address bits in devices. In this day and age it is simply inexscusable. Maybe we could

Re: 2.6.17 regression: Very slow net transfer from some hosts

This is almost certainly due to a buggy firewall that doesn't understand TCP window scaling. I've usually seen this in the past with OpenBSD firewalls. Do you have one of these in your path? Thanks, -John - To unsubscribe from this list: send the line unsubscribe netdev in the body of a

Re: [PATCH] shutting down an interface should remove ipv4 addresses

Addresses are owned by the host not a particular device, even though they are assosciated with a particular interface. Linux defaults to using the host based addressing model instead of the interface based addressing model. It is true for IPv4, but IPv6 addresses are removed when interface

Re: [PATCH] shutting down an interface should remove ipv4 addresses

Addresses are owned by the host not a particular device, even though they are assosciated with a particular interface. Linux defaults to using the host based addressing model instead of the interface based addressing model. It is true for IPv4, but IPv6 addresses are removed when

[PATCH] bcm43 wireless: fix printk format warnings

From: Randy Dunlap [EMAIL PROTECTED] Fix printk format warnings: drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:456: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’ drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c:460: warning: format ‘%08x’ expects type

[PATCH] bcm43: fix config menu alignment

From: Randy Dunlap [EMAIL PROTECTED] Use depends on to make all bcm43 driver options be listed at the same level. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- drivers/net/wireless/bcm43xx/Kconfig |3 +++ 1 files changed, 3 insertions(+) ---

Re: [PATCH] shutting down an interface should remove ipv4 addresses

From: David Stevens [EMAIL PROTECTED] Date: Tue, 11 Apr 2006 14:33:38 -0700 Addresses are owned by the host not a particular device, even though they are assosciated with a particular interface. Linux defaults to using the host based addressing model instead of the interface based

Re: [RFC/PATCH] remove unneeded check in bcm43xx

From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Wed, 12 Apr 2006 06:49:00 +1000 I would tend to agree... except that the broadcom is _the_ wireless card shipped by Apple with all of their machines for the last few years, and thus, the problem will be hit by pretty much any G5 user trying

Re: 2.6.17 regression: Very slow net transfer from some hosts

John Heffner wrote: This is almost certainly due to a buggy firewall that doesn't understand TCP window scaling. I've usually seen this in the past with OpenBSD firewalls. Do you have one of these in your path? At home I'm behind a Linux gateway box currently running 2.6.15-rc6 - I am

Re: [RFC/PATCH] remove unneeded check in bcm43xx

On Tue, 2006-04-11 at 14:34 -0700, David S. Miller wrote: I still think we shouldn't reward shit hardware by complicating up our DMA mappings internals. :-) Heh, it's a good point but in that specific case, it's a bit difficult to tell that to users who don't have a choice of what card to put

Re: [RFC/PATCH] remove unneeded check in bcm43xx

I still think we shouldn't reward shit hardware by complicating up our DMA mappings internals. :-) BTW. In the meantime, can't that driver work in PIO only mode ? Ben. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More

Re: [RFC/PATCH] remove unneeded check in bcm43xx

On Wed, Apr 12, 2006 at 08:21:17AM +1000, Benjamin Herrenschmidt wrote: I still think we shouldn't reward shit hardware by complicating up our DMA mappings internals. :-) BTW. In the meantime, can't that driver work in PIO only mode ? yes, I think you just have to have the

Re: 2.6.17 regression: Very slow net transfer from some hosts

On Tue, 11 Apr 2006 23:20:42 +0100 Daniel Drake [EMAIL PROTECTED] wrote: John Heffner wrote: This is almost certainly due to a buggy firewall that doesn't understand TCP window scaling. I've usually seen this in the past with OpenBSD firewalls. Do you have one of these in your path?

Re: [RFC/PATCH] remove unneeded check in bcm43xx

On Wed, 2006-04-12 at 00:30 +0200, Benoit Boissinot wrote: On Wed, Apr 12, 2006 at 08:21:17AM +1000, Benjamin Herrenschmidt wrote: I still think we shouldn't reward shit hardware by complicating up our DMA mappings internals. :-) BTW. In the meantime, can't that driver work in PIO

Re: 2.6.17 regression: Very slow net transfer from some hosts

Stephen Hemminger wrote: This is very familiar, and I just found the article I was thinking of: http://lwn.net/Articles/92727/ I was also hit by that bug, on the same collection of websites, but that particular problem was fixed for 2.6.8 or so. So I guess it is extremely likely that my ISP

Re: 2.6.17 regression: Very slow net transfer from some hosts

On Wed, 12 Apr 2006 01:06:09 +0100 Daniel Drake [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: This is very familiar, and I just found the article I was thinking of: http://lwn.net/Articles/92727/ I was also hit by that bug, on the same collection of websites, but that particular

Re: [PATCH 1/3] eth: use constant size address

From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 11 Apr 2006 11:10:54 -0700 Change the ethernet support routines to use constant address size. This generates smaller faster code. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Ok, but perhaps rework this to have a:

Re: 2.6.17 regression: Very slow net transfer from some hosts

Daniel Drake wrote: Stephen Hemminger wrote: Turn off TCP window scaling, your performance will be limited but about as good as you can get with a corrupting firewall in between. [snip] For anyone else interested, the ISP is NTL (UK). The fix: echo 409616384 131072

Re: 2.6.17 regression: Very slow net transfer from some hosts

Daniel Drake wrote: Stephen Hemminger wrote: This is very familiar, and I just found the article I was thinking of: http://lwn.net/Articles/92727/ I was also hit by that bug, on the same collection of websites, but that particular problem was fixed for 2.6.8 or so. So I guess it is

[PATCH 1/2] mv643xx_eth: Always free completed tx descs on tx interrupt

From: Brent Cook [EMAIL PROTECTED] Fix the tx interrupt handler to free completed tx descriptors even when NAPI is enabled. Otherwise, the tx queue would fill up resulting in poor performance and NETDEV WATCHDOG: iface: transmit timed out messages. Signed-off-by: Brent Cook [EMAIL PROTECTED]

[PATCH 2/2] mv643xx_eth: Fix tx_timeout to only conditionally wake tx queue

From: Dale Farnsworth [EMAIL PROTECTED] After resetting the hardware on a tx_timeout, call netif_wake_queue() only if we have free tx descriptors. Also, attempt to recover if mv643xx_eth_start_xmit() is called when there are fewer free tx descriptors than expected. The BUG_ON() call we are

Re: [PATCH] shutting down an interface should remove ipv4 addresses

David S. Miller [EMAIL PROTECTED] wrote: I agree, it should behave just like ipv4. AOL That would've made quite a few races that we had to fix non-existant by definition :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED] Home Page: