On Fri, 16 Dec 2005 03:26:31 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 15, 2005 at 08:35:32PM -0500, Bill Fink wrote:
> > On Fri, 16 Dec 2005, Andi Kleen wrote:
> >
> > > > It appears that it is getting CPU starved for some reason (note the
> > > > 43%/40% transmitter CPU usage ve
On Thu, 15 Dec 2005 21:10:03 -0500
"John W. Linville" <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 15, 2005 at 06:54:21PM -0600, Michael Ellerman wrote:
>
> > + /* XXX Why are we checking for 0xff here ? */
> > + return (addr[0] == 0xff) || (!is_multicast_ether_addr(addr)
> > + && !is_z
[revised patch to fix "is_in()" sfcount typo - thanks to Yan Zheng]
Dave,
I tested these together, but let me know if you want me to
split these into a few pieces, though they'll probably conflict with
each other. :-)
The below "jumbo" patch fixes the following problems in MLDv2.
1) Add n
Some more testing shows that even the 2.6.14 driver eventually
causes slab debugging BUGs() like
--- [cut here ] - [please bite here ] -
Kernel BUG at /home/andi/lsrc/linux-2.6.15rc5-git4/mm/slab.c:2307
invalid operand: [1] PREEMPT SMP
CPU 3
Modules linked in:
Pid:
On Thu, 15 Dec 2005, David S. Miller wrote:
> From: Bill Fink <[EMAIL PROTECTED]>
> Date: Thu, 15 Dec 2005 20:35:32 -0500
>
> > chance% nuttcp -w2m 192.168.88.8
> > 6299.0625 MB / 10.01 sec = 5278.6065 Mbps 100 %TX 74 %RX
> > chance% nuttcp -r -w2m 192.168.88.8
> > 6221.3125 MB / 10.01 sec =
On Thu, Dec 15, 2005 at 08:35:32PM -0500, Bill Fink wrote:
> On Fri, 16 Dec 2005, Andi Kleen wrote:
>
> > > It appears that it is getting CPU starved for some reason (note the
> > > 43%/40% transmitter CPU usage versus the 99%/99% CPU usage for the
> > > 2.6.12.6 case).
> >
> > What happens when
From: "David S. Miller" <[EMAIL PROTECTED]>
Date: Thu, 15 Dec 2005 17:52:54 -0800 (PST)
> diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
> index 7cf48aa..25dd8f4 100644
> --- a/net/xfrm/xfrm_state.c
> +++ b/net/xfrm/xfrm_state.c
Sorry, that patch was incomplete, please try this one in
On Thu, Dec 15, 2005 at 06:54:21PM -0600, Michael Ellerman wrote:
> + /* XXX Why are we checking for 0xff here ? */
> + return (addr[0] == 0xff) || (!is_multicast_ether_addr(addr)
> + && !is_zero_ether_addr(addr));
That is a good question...what does a MAC address like
FF:xx:x
On Thu, 2005-12-15 at 00:21 -0800, David S. Miller wrote:
> From: Sridhar Samudrala <[EMAIL PROTECTED]>
> Date: Wed, 14 Dec 2005 23:37:37 -0800 (PST)
>
> > Instead, you seem to be suggesting in_emergency to be set dynamically
> > when we are about to run out of ATOMIC memory. Is this right?
>
> N
The following is an extremely inefficient way to make new
SAs visible immediately. It is just for example purposes.
We just flush out all the cached bundles any time we insert
a new SA state.
Krzysztof, can you at least verify that this makes your
problem go away? Thanks.
diff --git a/net/xfr
From: "David S. Miller" <[EMAIL PROTECTED]>
Date: Thu, 15 Dec 2005 17:04:56 -0800 (PST)
> I'm trying to see if there is a clever way to make existing SA
> entries get invalidated upon insertion of a new SA which "shadows"
> them.
To illustrate why this is a "hard problem", I've drawn an
extensive
From: Bill Fink <[EMAIL PROTECTED]>
Date: Thu, 15 Dec 2005 20:35:32 -0500
> chance% nuttcp -w2m 192.168.88.8
> 6299.0625 MB / 10.01 sec = 5278.6065 Mbps 100 %TX 74 %RX
> chance% nuttcp -r -w2m 192.168.88.8
> 6221.3125 MB / 10.01 sec = 5213.2026 Mbps 100 %TX 71 %RX
>
> And a full test I just d
On Fri, 16 Dec 2005, Andi Kleen wrote:
> > It appears that it is getting CPU starved for some reason (note the
> > 43%/40% transmitter CPU usage versus the 99%/99% CPU usage for the
> > 2.6.12.6 case).
>
> What happens when you turn off tso in ethtool?
Thanks!!! That did the trick.
[EMAIL PROT
From: Krzysztof Oledzki <[EMAIL PROTECTED]>
Date: Fri, 16 Dec 2005 01:04:47 +0100 (CET)
> It looks like XFRM caches that information, so kernel does need to search
> whole SADB for each packet and this is the reason why usage of old SA is
> observed. This is my theory only, someone who wrote XFR
> It appears that it is getting CPU starved for some reason (note the
> 43%/40% transmitter CPU usage versus the 99%/99% CPU usage for the
> 2.6.12.6 case).
What happens when you turn off tso in ethtool?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a me
Fixup callers who're checking for is_multicast || is_broadcast, that's no
longer necessary. Change !is_multicast callers to use is_unicast.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
drivers/net/wireless/ipw2200.c | 15 +--
net/ieee80211/ieee80211_rx.c |5 ++---
Everything I've found on the 'net says that any MAC address with 0x1 in
byte 0 is a multicast address. Which obviously includes the broadcast address.
I think is_multicast_ether_addr() should implement that logic, if not we
should call it something else, otherwise we're asking for confusion.
I've
On Thu, 15 Dec 2005, David S. Miller wrote:
1) I don't understand how a routing cache flush "fixes" the problem.
The routing cache flush only marks non-IPSEC cached routes as
invalid, not IPSEC ones.
New IPsec SA is used for communication between new src/dst (previously
unseend) pair ev
On Fri, 16 Dec 2005 06:21:02 +1100
Anton Blanchard <[EMAIL PROTECTED]> wrote:
>
> Hi Stephen,
>
> > Replace cube root algorithim with a faster version using Newton-Raphson.
> > Surprisingly, doing the scaled div64_64 is faster than a true 64 bit
> > division on 64 bit CPU's.
>
> Interesting, wh
Hi Stephen,
> Replace cube root algorithim with a faster version using Newton-Raphson.
> Surprisingly, doing the scaled div64_64 is faster than a true 64 bit
> division on 64 bit CPU's.
Interesting, what cpu was this on? Was there much difference between the
two methods?
Anton
-
To unsubscribe
On Thu, Dec 15, 2005 at 01:58:41PM -0800, David S. Miller wrote:
> From: "John W. Linville" <[EMAIL PROTECTED]>
> Date: Thu, 15 Dec 2005 15:21:37 -0500
>
> > Interesting... FWIW the FC4.netdev.6 kernel seems to be working fine
> > on (a yet-to-be-released box), which is an x86_64 (AMD) box w/
> >
From: jamal <[EMAIL PROTECTED]>
Date: Thu, 15 Dec 2005 15:56:52 -0500
> Refer to Herberts solution and see if that "solves the problem".
I think the kernel is definitely within it's rights to interpret
section 4.3 of RFC2408 the way that it does.
And I bet that whoever wrote those paragraphs use
Oops. I forgot to attach my 2.6.12.6 kernel config.
-Bill
config-2.6.12.bz2
Description: BZip2 compressed data
Hi,
We use dual 3.06 GHz Xeon PC servers, with 1 GB memory, 133-MHz/64-bit
PCI-X bus, and Intel PRO/10GbE 10-GigE NIC, as 10-GigE network performance
measurement and troubleshooting systems. With the 2.6.12.6 kernel we
get consistently excellent network performance, both TCP and UDP.
Here's a sa
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Thu, 15 Dec 2005 15:21:37 -0500
> Interesting... FWIW the FC4.netdev.6 kernel seems to be working fine
> on (a yet-to-be-released box), which is an x86_64 (AMD) box w/
> forcedeth hardware. The forcedeth.c in the FC4.netdev.6 kernel is
> identic
Hi,
Resending to make sure this doesn't fall through the cracks. The
following patch applies to 2.6 and fixes a memory leak.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
* net/bridge/br_netfilter.c (br_nf_pre_routing, br_nf_pre_routing_ipv6) :
Call nf_bridge_put() before allocating a new n
Given the pretty extensive modifications necessary, do you have any
useful benchmark data to show that this is a win. Previous zero
copy (like page flipping) has not be merged because it did not
prove to be a net gain.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
On Thu, 2005-15-12 at 21:28 +0100, Krzysztof Oledzki wrote:
>
> On Thu, 15 Dec 2005, jamal wrote:
> > It will help 100% of the time _if you know_ you have CISCOs on the other
> > end and you configure racoon with that in mind. In other words it doesnt
> > matter who the initiator/responder is in
> Change "if (pmc->mca_sfcount[MCAST_INCLUDE])" to "if
> (psf->sf_count[MCAST_INCLUDE])" ?
Yes, good catch! I'll re-roll and resubmit.
+-DLS
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EM
On Thu, 15 Dec 2005, jamal wrote:
Agree. It is a _workaround_;-> A good one in my opinion. Given that it
works for CISCOs, a very large piece of the problem is resolved, no?
No, again, it does not help. I explained it in my previous mail.
It will help 100% of the time _if you know_ you have
On Thu, Dec 15, 2005 at 05:50:50PM +0100, Andi Kleen wrote:
> On Thu, Dec 15, 2005 at 11:40:08AM -0500, John W. Linville wrote:
> > On Thu, Dec 15, 2005 at 04:29:04PM +0100, Andi Kleen wrote:
> > >
> > > Hallo,
> > >
> > > When I boot a kernel with iommu=force (this forces all pci_map_sgs
> > > t
Also have to handle out of memory condition on resume.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- skge-2.6.orig/drivers/net/skge.c
+++ skge-2.6/drivers/net/skge.c
@@ -3416,8 +3416,8 @@ static int skge_resume(struct pci_dev *p
struct net_device *dev = hw->dev[i];
On Thu, 2005-15-12 at 17:23 +0100, VANHULLEBUS Yvan wrote:
> On Thu, Dec 15, 2005 at 10:27:02AM -0500, jamal wrote:
> > On Thu, 2005-15-12 at 14:28 +0100, VANHULLEBUS Yvan wrote:
> > > On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote:
> >
> > > > What is not true?;-> CISCO doesnt hardcode 30
On Thu, 2005-15-12 at 17:11 +0100, Krzysztof Oledzki wrote:
>
> On Thu, 15 Dec 2005, jamal wrote:
[..]
> > Thats one interpretation. The other is in the same section and says:
> > "Deletion of the old SA is dependent on local security policy."
>
> Please notice - there are two SA: incomming and
On Thu, Dec 15, 2005 at 11:40:08AM -0500, John W. Linville wrote:
> On Thu, Dec 15, 2005 at 04:29:04PM +0100, Andi Kleen wrote:
> >
> > Hallo,
> >
> > When I boot a kernel with iommu=force (this forces all pci_map_sgs
> > through the K8 aperture) and slab debugging on a Nforce4 x86-64
> > system
On Thu, Dec 15, 2005 at 04:29:04PM +0100, Andi Kleen wrote:
>
> Hallo,
>
> When I boot a kernel with iommu=force (this forces all pci_map_sgs
> through the K8 aperture) and slab debugging on a Nforce4 x86-64
> system the network corrupts data very quickly. Even when just
> sshing somewhere ssh qu
On Thu, Dec 15, 2005 at 10:27:02AM -0500, jamal wrote:
> On Thu, 2005-15-12 at 14:28 +0100, VANHULLEBUS Yvan wrote:
> > On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote:
>
> > > What is not true?;-> CISCO doesnt hardcode 30 secs as the time between
> > > soft and hard expiry? Or what is said
On Thu, 15 Dec 2005, jamal wrote:
On Thu, 2005-15-12 at 14:28 +0100, VANHULLEBUS Yvan wrote:
On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote:
What is not true?;-> CISCO doesnt hardcode 30 secs as the time between
soft and hard expiry? Or what is said with CISCO not sending IKE
delet
Hallo,
When I boot a kernel with iommu=force (this forces all pci_map_sgs
through the K8 aperture) and slab debugging on a Nforce4 x86-64
system the network corrupts data very quickly. Even when just
sshing somewhere ssh quickly aborts with MAC errors etc.
Reverting only forcedeth.c to the one f
On Thu, 2005-15-12 at 14:28 +0100, VANHULLEBUS Yvan wrote:
> On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote:
> > What is not true?;-> CISCO doesnt hardcode 30 secs as the time between
> > soft and hard expiry? Or what is said with CISCO not sending IKE
> > delete? AFAIK, both are true.
>
On Thu, Dec 15, 2005 at 01:47:25PM +0100, Jens Osterkamp wrote:
>
> The driver incorrectly used dma_addr_t to describe
> HW structures and consequently broke when that type
> was changed in 2.6.15-rc.
>
> This changed spidernet to use u32 for 32 bit HW defined
> structure elements.
actually this
On Thu, 2005-15-12 at 14:07 +0100, Arjan van de Ven wrote:
> On Thu, 2005-12-15 at 08:00 -0500, jamal wrote:
> > The big hole punched by DaveM is that of dependencies: a http tcp
> > connection is tied to ICMP or the IPSEC example given; so you need a lot
> > more intelligence than just what your
> Naturally this is all still in the vaporware stage, but I think that
> if implemented the concept might at least improve the OOM/low-memory
> situation considerably. Starting to fail allocations for the cluster
> programs (including their kernel allocations) well before failing
> them fo
On Thu, Dec 15, 2005 at 07:27:58AM -0500, jamal wrote:
> On Thu, 2005-15-12 at 05:57 +0100, Krzysztof Oledzki wrote:
> > Addedd CC: to the [EMAIL PROTECTED] mailing list.
> >
>
> And I added Shoichi Sakane to the CC. He is responsible for bringing
> "use new SA" feature to BSD to begin with and i
On Thu, 2005-12-15 at 08:00 -0500, jamal wrote:
> On Thu, 2005-15-12 at 12:47 +0100, Arjan van de Ven wrote:
> > >
> > > You are using the wrong hammer to crack your nut.
> > > You should instead approach your problem of why the ARP entry gets lost.
> > > For example, you could give as critical pr
On Thu, 2005-15-12 at 12:47 +0100, Arjan van de Ven wrote:
> >
> > You are using the wrong hammer to crack your nut.
> > You should instead approach your problem of why the ARP entry gets lost.
> > For example, you could give as critical priority to your TCP session,
> > but that still won't cure
On Thursday 15 December 2005 23:58, Kyle Moffett wrote:
> On Dec 15, 2005, at 07:45, Con Kolivas wrote:
> > I have some basic process-that-called the memory allocator link in
> > the -ck tree already which alters how aggressively memory is
> > reclaimed according to priority. It does not affect out
On Dec 15, 2005, at 07:45, Con Kolivas wrote:
I have some basic process-that-called the memory allocator link in
the -ck tree already which alters how aggressively memory is
reclaimed according to priority. It does not affect out of memory
management but that could be added to said algorithm
On Dec 15, 2005, at 04:04, Andi Kleen wrote:
When processes request memory through any subsystem, their memory
priority would be passed through the kernel layers to the
allocator, along with any associated information about how to free
the memory in a low-memory condition. As a result, I co
Performance optimizations, changes in these areas:
- RX and TX checksum offload
- correct maximum MTU
- don't use TX interrupts anymore, use a timer instead
- remove some superfluous barriers
- improve RX RAM full handling
From: Utz Bacher <[EMAIL PROTECTED]>
From: Jens Osterkamp <[EMAI
On Thursday 15 December 2005 19:55, Kyle Moffett wrote:
> On Dec 15, 2005, at 03:21, David S. Miller wrote:
> > Not when we run out, but rather when we reach some low water mark,
> > the "critical sockets" would still use GFP_ATOMIC memory but only
> > "critical sockets" would be allowed to do so.
request_firmware() is sometimes problematic, especially
in initramfs, reading the firmware from Open Firmware
is much preferrable.
We still try to get the firmware from the file system
first, in order to support old SLOF releases and to allow
updates of the spidernet firmware without reflashing
t
On Thu, 2005-15-12 at 05:57 +0100, Krzysztof Oledzki wrote:
> Addedd CC: to the [EMAIL PROTECTED] mailing list.
>
And I added Shoichi Sakane to the CC. He is responsible for bringing
"use new SA" feature to BSD to begin with and is one of the original
authors of racoon.
So lets take one more go a
>
> You are using the wrong hammer to crack your nut.
> You should instead approach your problem of why the ARP entry gets lost.
> For example, you could give as critical priority to your TCP session,
> but that still won't cure your ARP problem.
> I would suggest that the best way to cure your
Mitchell Blank Jr wrote:
James Courtier-Dutton wrote:
When I had the conversation with Matt at KS, the problem we were trying
to solve was "Memory pressure with network attached swap space".
s/swap space/writable filesystems/
You can hit these problems even if you have no swap. Too much of
> @@ -1281,7 +1345,18 @@ static int is_in(struct ifmcaddr6 *pmc,
> case MLD2_MODE_IS_EXCLUDE:
> if (gdeleted || sdeleted)
> return 0;
> - return !((pmc->mca_flags & MAF_GSQUERY) &&
> !psf->sf_gsresp);
> + if (!((pmc->mca_fl
"David S. Miller" <[EMAIL PROTECTED]> wrote on 12/15/2005 12:58:05 AM:
> From: David Stevens <[EMAIL PROTECTED]>
> Date: Thu, 15 Dec 2005 00:44:52 -0800
>
> > In our internal discussions
>
> I really wish this hadn't been discussed internally before being
> implemented. Any such internal discus
> When processes request memory through any subsystem, their memory
> priority would be passed through the kernel layers to the allocator,
> along with any associated information about how to free the memory in
> a low-memory condition. As a result, I could configure my database
> to have
On Dec 15, 2005, at 03:21, David S. Miller wrote:
Not when we run out, but rather when we reach some low water mark,
the "critical sockets" would still use GFP_ATOMIC memory but only
"critical sockets" would be allowed to do so.
But even this has faults, consider the IPSEC scenerio I mention
From: David Stevens <[EMAIL PROTECTED]>
Date: Thu, 15 Dec 2005 00:44:52 -0800
> In our internal discussions
I really wish this hadn't been discussed internally before being
implemented. Any such internal discussions are lost completely upon
the community that ends up reviewing such a core and in
On Wed, Dec 14, 2005 at 03:39:50PM -0800, David S. Miller wrote:
> From: Hoerdt Mickael <[EMAIL PROTECTED]>
> Date: Wed, 14 Dec 2005 23:38:56 +0100
>
> > As implemented now, the default memory allocated in net.core.optmem_max
> > permit
> > to join up to 320 (S,G) channels per sockets (for IPv6,
> Also, all this stuff is just a band aid because linux OOM behavior is so
> fucked up.
In our internal discussions, characterizing this as "OOM" came
up a lot, and I don't think of it as that at all. OOM is exactly what the
scheme is trying to avoid!
The actual situation we have in mind is a swa
On Thu, 2005-12-15 at 00:21 -0800, David S. Miller wrote:
> From: Sridhar Samudrala <[EMAIL PROTECTED]>
> Date: Wed, 14 Dec 2005 23:37:37 -0800 (PST)
>
> > Instead, you seem to be suggesting in_emergency to be set dynamically
> > when we are about to run out of ATOMIC memory. Is this right?
>
> N
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Wed, 14 Dec 2005 23:37:37 -0800 (PST)
> Instead, you seem to be suggesting in_emergency to be set dynamically
> when we are about to run out of ATOMIC memory. Is this right?
Not when we run out, but rather when we reach some low water mark, the
"c
64 matches
Mail list logo
