Ayaz Abdulla wrote:
if (nv_alloc_rx(dev)) {
- spin_lock(&np->lock);
+ spin_lock_irqsave(&np->lock, flags);
Tiny point:
there is not need for irqsave(): we are in timer context, that guarantees:
- bottom half disabled
- interrupts enabled
Just use spin_loc
Ayaz Abdulla wrote:
+
+ NvRegPowerState2 = 0x600,
+#define NVREG_POWERSTATE2_POWERUP_MASK 0x0F11
+#define NVREG_POWERSTATE2_POWERUP_REV_A3 0x0001
};
If the nic has a register 0x600, then we should
- ioremap enough memory. Right now, the code only remaps 0x270
- report all
Ayaz Abdulla wrote:
This patch adds support for configuration of various parameters. This
includes module parameters and ethtool commands.
+
+ if (netif_running(dev)) {
+ nv_start_rx(dev);
+ nv_start_tx(dev);
+ nv_enable_irq(dev);
+ }
+
Implement proper set_bssid_filter. If filters are not set, firmware receives
management frames only (instead of everything), so this is necessary.
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
---
You know guys, it's very tough to be a moron. All this time I was trying
to set filters in set_ch
Ayaz Abdulla wrote:
This patch adds flow control support for tx and rx pause frames in
forcedeth.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
Signed-Off-By: Manfred Spraul <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
Hi Dave:
This patch removes the *_decap_state structures which were previously
used to share state between input/post_input. This is no longer needed.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTEC
On Fri, Mar 31, 2006 at 09:49:31PM -0500, jamal wrote:
> >
> > The RFC seems to talk about sender IP address instead though...
>
> my understanding: the sender is trying to claim that IP and is setting
> the destination to the IP it is trying to claim and see if someone
> responds.
Are you sure?
jamal wrote:
On Wed, 2006-29-03 at 13:16 -0800, [EMAIL PROTECTED] wrote:
On Wed, 2006-29-03 at 11:14 -0800, Jouni Malinen wrote:
[..]
A digression: One of the problems of the bridge in my opinion is having
STP, a control protocol, inside the kernel. I do hope someone with time
will rip it o
Hi Dave:
This patch removes the decap_state argument from the xfrm input hook.
Previously this function allowed the input hook to share state with the
post_input hook. The latter has since been removed.
The only purpose for it now is to check the encap type. However, it is
easier and better to
From: Mark Butler <[EMAIL PROTECTED]>
Date: Fri, 31 Mar 2006 10:26:05 -0700
> That could be done with separate atomic variables for allocated data and
> allocated overhead, at measurable cost with relatively little gain.
> Overhead would still have be tracked and limited separately to handle
>
On Sat, 2006-01-04 at 13:01 +1100, Herbert Xu wrote:
> David Daney <[EMAIL PROTECTED]> wrote:
> >
> > In any event, yes we should be testing the dest_ip. If the ARP packet
> > is destined for the link local network, it should be broadcast.
>
> The RFC seems to talk about sender IP address inste
Remove Host AP and Prism2 references from IEEE 802.11 crypto code. Clean
up coding style and some comments. Replace couple of kmalloc+memset with
kzalloc.
Signed-off-by: Jouni Malinen <[EMAIL PROTECTED]>
Index: wireless-2.6/include/net/ieee80211_crypt.h
==
David Daney <[EMAIL PROTECTED]> wrote:
>
> In any event, yes we should be testing the dest_ip. If the ARP packet
> is destined for the link local network, it should be broadcast.
The RFC seems to talk about sender IP address instead though...
--
Visit Openswan at http://www.openswan.org/
Email
On Fri, 2006-31-03 at 17:00 -0800, David Daney wrote:
> jamal wrote:
> > On Fri, 2006-31-03 at 15:26 -0800, David Daney wrote:
> >
> > While the patch does seem reasonable - given the link local addresses
> > are well defined, I am curious why is this not being done in the user
> > space apps you
Krzysztof Oledzki <[EMAIL PROTECTED]> wrote:
[...]
>I took this patch from linux-2.6 using git tree and applied to 2.6.16.1
>together with recent "link status" fix. Unfortunately broadcast packet
>duplication still occurs.
I am unable to induce any duplicate packets using the current
netde
Herbert Xu wrote:
David Daney <[EMAIL PROTECTED]> wrote:
+ /* If link local address (169.254.0.0/16) we must broadcast
+ * the ARP packet. See RFC 3927 section 2.5 for details.
+*/
+ lla = (dest_ip & htonl(0xUL)) == htonl(0xA9FEUL);
Is this really mean
David Daney <[EMAIL PROTECTED]> wrote:
>
>>>+ /* If link local address (169.254.0.0/16) we must broadcast
>>>+ * the ARP packet. See RFC 3927 section 2.5 for details.
>>>+*/
>>>+ lla = (dest_ip & htonl(0xUL)) == htonl(0xA9FEUL);
>>
>> Is this really meant t
Herbert Xu wrote:
David Daney <[EMAIL PROTECTED]> wrote:
--- net/ipv4/arp.c.orig 2006-03-31 13:44:50.0 -0800
+++ net/ipv4/arp.c 2006-03-31 13:48:26.0 -0800
@@ -690,8 +691,13 @@ void arp_send(int type, int ptype, u32 d
if (dev->flags&IFF_NOARP)
return;
+
jamal wrote:
On Fri, 2006-31-03 at 15:26 -0800, David Daney wrote:
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in RFC
3927. There are several user space daemons available that imp
David Daney <[EMAIL PROTECTED]> wrote:
>
> --- net/ipv4/arp.c.orig 2006-03-31 13:44:50.0 -0800
> +++ net/ipv4/arp.c 2006-03-31 13:48:26.0 -0800
> @@ -690,8 +691,13 @@ void arp_send(int type, int ptype, u32 d
>if (dev->flags&IFF_NOARP)
>return;
>
> +
On Wed, 2006-29-03 at 13:16 -0800, [EMAIL PROTECTED] wrote:
> > On Wed, 2006-29-03 at 11:14 -0800, Jouni Malinen wrote:
> > [..]
> >
> > A digression: One of the problems of the bridge in my opinion is having
> > STP, a control protocol, inside the kernel. I do hope someone with time
> > will rip i
On Fri, 2006-31-03 at 15:26 -0800, David Daney wrote:
> From: David Daney
>
> Greetings,
>
> When an internet host joins a network where there is no DHCP server,
> it may auto-allocate an IP address by the method described in RFC
> 3927. There are several user space daemons available that implem
Has anyone had a chance to run pktgen between a pair of 82597EX
adapters? I am interested if anyone has pps numbers for 1500 MTU
and perhaps 9000 MTU.
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the li
From: David Daney
Greetings,
When an internet host joins a network where there is no DHCP server,
it may auto-allocate an IP address by the method described in RFC
3927. There are several user space daemons available that implement
most of the protocol (zcip, busybox, ...). The kernel's APR dri
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> If I run 'ping 172.16.1.52 -M do -s 1472' from a 172.25.5.0
> host I got this result:
>
> PING 172.16.1.52 (172.16.1.52) 1472(1500) bytes of data.
> 1480 bytes from 172.16.1.52: icmp_seq=1 ttl=62 time=74.1 ms
> 1480 bytes from 172.16.1.52: icmp_seq=2 tt
> For the else clause wouldn't we be counting fragheaderlen twice if
> the multi page if falls through above despite NETIF_F_SG being true?
Looks like, yeah. I'll fix up and resend. Thanks for the sharp eyes.
- z
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body o
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> Pleiadi is also running another tunnel with an old linux
> 2.4.28/KLIPS FreeS/WAN 2.05 an the MTU is 1444. May anyone
> explain me why ipsec tunnels established with linux 2.6.16
> (linux 2.6<->linux2.6) have an MTU equal to 1428? And why
> tunnels esta
Zach Brown <[EMAIL PROTECTED]> wrote:
>
> Index: 2.6.16-mm2-bigmtu/net/ipv4/ip_output.c
> ===
> --- 2.6.16-mm2-bigmtu.orig/net/ipv4/ip_output.c
> +++ 2.6.16-mm2-bigmtu/net/ipv4/ip_output.c
> @@ -891,13 +891,26 @@ alloc_new_skb:
>
From: Bill Fink <[EMAIL PROTECTED]>
Date: Fri, 31 Mar 2006 10:15:08 -0500
> Another reason the SO_SNDBUF/SO_RCVBUF values shouldn't include
> the kernel overhead. If the user requests 100K of kernel data
> buffering, then they should get 100K. It shouldn't matter to the
> user that the kernel wo
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Fri, 31 Mar 2006 13:11:21 +0200
> For TCP it doesn't apply anymore though because the kernel would
> do a GC of the skbs in this case. So maybe it could be changed for STREAM
> sockets.
TCP does some clever things to determine overhead on the send
side,
Instead of the DEV_OK macro, drivers should use pcmcia_dev_present().
Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
---
drivers/char/pcmcia/cm4000_cs.c |4 ++--
drivers/char/pcmcia/cm4040_cs.c |2 +-
drivers/net/pcmcia/3c574_cs.c |4 ++--
drivers/net
As we do not allow setting Vcc in the pcmcia core, and Vpp1 and
Vpp2 can only be set to the same value, a lot of code can be
streamlined.
Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
---
drivers/bluetooth/bluecard_cs.c |4
drivers/bluetooth/bt3c_cs.c |6
Handle the _modifying_ operation sm91c92_cs requires in
pcmcia_modify_configuration, so that the only remaining users
of pcmcia_release_configuration() are within the pcmcia core
module.
Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
---
drivers/mtd/maps/pcmciamtd.c |3 +--
driver
Remove the unused DEV_RELEASE_PENDING flag, and move the DEV_SUSPEND flag
into the p_dev structure, and make use of it at the core level.
Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
---
drivers/net/wireless/atmel_cs.c |2 +-
drivers/net/wireless/ray_cs.c |2 +-
drivers/ne
Convert the remaining drivers which use pcmcia_release_io or
pcmcia_release_irq, and remove the EXPORT of these symbols.
Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
---
Documentation/pcmcia/driver-changes.txt |4 ++--
drivers/isdn/hardware/avm/avm_cs.c | 10 +-
drive
pcmcia_disable_device(struct pcmcia_device *p_dev) performs the necessary
cleanups upon device or driver removal: it calls the appropriate
pcmcia_release_* functions, and can replace (most) of the current drivers'
_release() functions.
Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
---
Do
In all but one case, the suspend and resume functions of PCMCIA drivers
contain mostly of calls to pcmcia_release_configuration() and
pcmcia_request_configuration(). Therefore, move this code out of the
drivers and into the core.
Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
---
drivers/
On 3/31/06, Kumar Gala <[EMAIL PROTECTED]> wrote:
> > Currently the code updates these variables (kept per cpu) every time a
> > copy is queued. See include/linux/dmaengine.h.
>
> Might it be better to update when the transfer is done incase of an
> error?
The queueing function is really in the be
Send scan completion events to user space when a scan completes.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
--- a/drivers/net/wireless/atmel.c.scan-fixups 2006-03-31 13:31:02.0
-0500
+++ b/drivers/net/wireless/atmel.c 2006-03-31 15:11:13.0 -0500
@@ -3463,6 +3463,7 @@
Airo firmware versions >= 5.30.17 send re-association events to the
driver that are currently unrecognized, causing spurious disassociation
events to be sent to user space. Loss of sync due to scan requests also
results in disassociation events sent to user space. This patch traps
those two event
On Mar 31, 2006, at 2:04 PM, Andrew Grover wrote:
On 3/31/06, Ingo Oeser <[EMAIL PROTECTED]> wrote:
Kumar Gala wrote:
Fair, but wouldn't it be better to have the association per client.
Maybe leave the one as a summary and have a dir per client with
similar stats that are for each client and
On 3/31/06, Ingo Oeser <[EMAIL PROTECTED]> wrote:
> Kumar Gala wrote:
> > Fair, but wouldn't it be better to have the association per client.
> >
> > Maybe leave the one as a summary and have a dir per client with
> > similar stats that are for each client and add a per channel summary
> > at the t
> Could you please describe how struct ioat_dma_chan channels are freed?
Sorry, I got distracted by other issues and never ended up following
up on this. You're right, and it's just sloppiness on my part for
missing it, those structs are being leaked on module unload. I'll fix
it. Thanks.
-Chr
Linas Vepstas wrote:
On Thu, Mar 30, 2006 at 09:14:56PM -0700, Jeffrey V. Merkey wrote:
Yes, we need one. The adapter needs to maintain these stats from the
registers in the kernel structure and not
its own local variables.
Did you read the code to see what the adapter does with thes
2) What's wrong with taking deltas? Typical through-put performance
measurement is done by pre-loading the pipes (i.e. running for
a few minutes wihtout measuring, then starting the measurement).
I'd think that snapshotting the numbers would be easier, and is
trivially doable in user-space. I gue
> What exactly are you trying to do with that "watch out for trailer_len"
> thing where you subtract 2 from datalen?
The danger is in chosing a datalen that just fits in a page but then
finding that it == length and so we want to add on trailer_len, bringing
the alloc back over a page.
The logic
Bill Fink wrote:
Another reason the SO_SNDBUF/SO_RCVBUF values shouldn't include
the kernel overhead. If the user requests 100K of kernel data
buffering, then they should get 100K. It shouldn't matter to the
user that the kernel would actually be using a total of 167K of
memory to satisfy th
On Fri, 31 Mar 2006, Ingo Oeser wrote:
Hi,
Herbert Xu wrote:
On Fri, Mar 31, 2006 at 01:35:40AM -0800, David S. Miller wrote:
He does not have TSO enabled, e1000 disables TSO when on a link speed
slower than gigabit.
dmesg|grep eth0
[4294671.426000] e1000: eth0: e1000_probe: Intel(R) PRO/
Hello, Mark Nipper.
On 31.03.2006 20:01 you said the following:
On 31 Mar 2006, Boris B. Zhmurov wrote:
stream.c (279) -> stream.c (283)
af_inet.c (148) -> af_inet.c (150)
That will be because the patches changed the line numbers
in the source I believe. Nothing helpful unfortunat
On Thu, Mar 30, 2006 at 09:46:54PM -0800, Greg KH wrote:
>
> (hint, use a tab...)
glurg.
[PATCH]: e1000: prevent statistics from getting garbled during reset.
If a PCI bus error/fault triggers a PCI bus reset, attempts to get the
ethernet packet count statistics from the hardware will fail, r
On Thu, Mar 30, 2006 at 09:14:56PM -0700, Jeffrey V. Merkey wrote:
> Yes, we need one. The adapter needs to maintain these stats from the
> registers in the kernel structure and not
> its own local variables.
Did you read the code to see what the adapter does with these stats?
Among other things
On 31 Mar 2006, Boris B. Zhmurov wrote:
> stream.c (279) -> stream.c (283)
> af_inet.c (148) -> af_inet.c (150)
That will be because the patches changed the line numbers
in the source I believe. Nothing helpful unfortunately.
--
Mark Nipper
Hello, Boris B. Zhmurov.
On 31.03.2006 19:08 you said the following:
Hmm... with lastest debug patch I can't see any of debug info:
But wait a minute. Two days ago, without Herbert's patches, assertion's
errors was like this:
Mar 29 20:03:23 msk4 kernel: KERNEL: assertion (!sk->sk_forward_
On Thu, 30 Mar 2006, David S. Miller wrote:
> From: Bill Fink <[EMAIL PROTECTED]>
> Date: Fri, 31 Mar 2006 01:58:35 -0500
>
> > I don't think it makes perfect sense. If there's overhead, fine go
> > ahead and add the overhead, but do it under the covers and invisible
> > to the user.
>
> How in
Hello, Boris B. Zhmurov.
On 31.03.2006 17:30 you said the following:
Herbert, with your second patch still no luck. After an hour of uptime I
have assertion (!sk->sk_forward_alloc) failed at net/core/stream.c (283)
again...
Trying your debug patch.
Hmm... with lastest debug patch I can't
I have done a little test to try to understand how ipsec and
mtu play together.
Here is my simple network schema:
net 172.16.0.0--|2.6.16 box|--internet--|2.4-KLIPS|--net 172.25.5.0
+---ipsec tunnel--+
When I run 'ping 172.25.5.30 -M do -s 1472 -c 3' from a
172.16.
On Tue, 21 Feb 2006, Jay Vosburgh wrote:
Originally submitted by Kenzo Iwami; his original description is:
The current bonding driver receives duplicate packets when broadcast/
multicast packets are sent by other devices or packets are flooded by the
switch. In this patch, new flags
Hello, Christiaan den Besten.
On 31.03.2006 17:12 you said the following:
Hi !
P.S. I have another high-load server as gateway. Same distro, same
kernels, but less memory (512Mb lowmem). eth0 up - e100, eth1 up -
e1000. No errors at all! It kinda looks like assertions happens on
systems, wh
- Original Message -
From: "JaniD++" <[EMAIL PROTECTED]>
To: "BRM" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, March 31, 2006 9:33 AM
Subject: Re: e1000 - packet lost bug in 6.3.9 (old version :NETDEV WATCHDOG:
eth0: transmit timed out)
>
> - Original Message -
> From: "BRM" <[EMAIL
Hello, Boris B. Zhmurov.
On 31.03.2006 16:23 you said the following:
Hello, Mark Nipper.
On 31.03.2006 16:10 you said the following:
This unfortunately is not the case. I have two e1000
interfaces but only eth1 is up and in use. And I still had
assertions.
Can you switch to eth
- Original Message -
From: "Boris B. Zhmurov" <[EMAIL PROTECTED]>
To: "Herbert Xu" <[EMAIL PROTECTED]>
Cc: "David S. Miller" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED
Hello, Herbert Xu.
On 31.03.2006 16:35 you said the following:
On Fri, Mar 31, 2006 at 04:23:02PM +0400, Boris B. Zhmurov wrote:
I'm already using kernel with second Herbert's patch. We'll see...
If it still fails
Not yet. But give it a time :)
--
Boris B. Zhmurov
mailto: [EMAIL PROTEC
On Fri, Mar 31, 2006 at 04:23:02PM +0400, Boris B. Zhmurov wrote:
>
> I'm already using kernel with second Herbert's patch. We'll see...
If it still fails, here is a debugging patch which should tell us
whether we need to look elsewhere.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Ema
Hello, Mark Nipper.
On 31.03.2006 16:10 you said the following:
This unfortunately is not the case. I have two e1000
interfaces but only eth1 is up and in use. And I still had
assertions.
Can you switch to eth0? There is no problem with _eth0_, my friend says.
> And I still had
>
Hi,
Herbert Xu wrote:
> On Fri, Mar 31, 2006 at 01:35:40AM -0800, David S. Miller wrote:
> > He does not have TSO enabled, e1000 disables TSO when on a link speed
> > slower than gigabit.
dmesg|grep eth0
[4294671.426000] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
[4294679.1250
On Friday 31 March 2006 14:07, Boris B. Zhmurov wrote:
> David, Herbert - FYI. One of my colleague confirmed, that idea "bug
> reproducible only if there is more then one e1000 adapter onboard" is
> true. He has a 3 servers with double intel pro 1000 adapters, and that
> bug occurs. Also, he has 4
On Friday 31 March 2006 09:24, David S. Miller wrote:
> For example, if you, for example, receive a lot of tiny UDP packets,
> wherein the "struct sk_buff" overhead far exceeds the amount of data
> in the packet, it still might not work out. You could specify 100K
> and only be able to receive sa
On 31 Mar 2006, Boris B. Zhmurov wrote:
> David, Herbert - FYI. One of my colleague confirmed, that idea "bug
> reproducible only if there is more then one e1000 adapter onboard" is
> true. He has a 3 servers with double intel pro 1000 adapters, and that
> bug occurs. Also, he has 4 servers with
Hello, Herbert Xu.
On 31.03.2006 14:39 you said the following:
On Fri, Mar 31, 2006 at 02:16:38PM +0400, Boris B. Zhmurov wrote:
And xdelta tells, that e1000.ko was modified :)
Thanks for checking again.
Anyway, it didn't take long to find another bug in the same area.
I'm afraid this dri
- Original Message -
From: "Herbert Xu" <[EMAIL PROTECTED]>
To: "David S. Miller" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECT
Hello, Herbert Xu.
On 31.03.2006 14:52 you said the following:
BTW, if you kept the built tree it is possible to apply the patch and
then do a make which should compile just the e1000 driver.
Cheers,
Thank's for the tip, actually I knew that :) First of, I've already
applied some other new
Me again.
I think I have found where the issue is. I have updated the
network schema:
customer private network 10.0.0.0/8
|
|
+ipsec customer gateway (nokia/checkpoint)
|==MTU=1444
|
|
|---ipsec tunnel 10.0.0.0/8<->172.29.128.0/28 (3DES/MD5)
|
|
|+---ipsec gateway (pleiadi)---priv net (172.16
On 31 Mar 2006, David S. Miller wrote:
> He does not have TSO enabled, e1000 disables TSO when on a link speed
> slower than gigabit.
>
> You'll see something like the following in your logs:
>
> e1000: eth0: e1000_watchdog_task: 10/100 speed: disabling TSO
Um...
---
$ uname -a
Linux kin
Hello, David S. Miller.
On 31.03.2006 14:45 you said the following:
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 31 Mar 2006 21:39:56 +1100
Anyway, it didn't take long to find another bug in the same area.
I'm afraid this driver does seem to be full of them :)
Indeed.
Thanks for picki
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 31 Mar 2006 21:39:56 +1100
> Anyway, it didn't take long to find another bug in the same area.
> I'm afraid this driver does seem to be full of them :)
Indeed.
Thanks for picking through this some more Herbert. I hope we got it
this time.
-
To uns
On Fri, Mar 31, 2006 at 02:16:38PM +0400, Boris B. Zhmurov wrote:
>
> And xdelta tells, that e1000.ko was modified :)
Thanks for checking again.
Anyway, it didn't take long to find another bug in the same area.
I'm afraid this driver does seem to be full of them :)
It sets last_tx_tso in betwee
From: Anton Blanchard <[EMAIL PROTECTED]>
Date: Sat, 25 Mar 2006 23:19:29 +1100
> Previously we added NET_IP_ALIGN so an architecture can override the
> padding done to align headers. The next step is to allow the skb
> headroom to be overridden.
>
> We currently always reserve 16 bytes to grow i
On Fri, Mar 31, 2006 at 09:14:45PM +1100, Herbert Xu wrote:
> Hi:
>
> This patches merges the separate calls to le16_to_cpu and ntohl into one
> swab32 call so that it is clear that we're simply changing a little-endian
> value from the hardware to big-endian for the networking stack.
This defeat
From: Zach Brown <[EMAIL PROTECTED]>
Date: Thu, 30 Mar 2006 15:00:30 -0800
> We've had reports from customers of boxes with a week's uptime and 32k MTUs
> getting failed order-3 allocs under:
>
> udp_sendmsg .. ip_append_data .. {sock_wmalloc, sock_alloc_send_skb}
>
> I came up with the fo
Hi:
This patches merges the separate calls to le16_to_cpu and ntohl into one
swab32 call so that it is clear that we're simply changing a little-endian
value from the hardware to big-endian for the networking stack.
Let x be any 16 any 16-bit integer, we have
csum_fold(x << 16) = csum_fold(x).
Hello, David S. Miller.
On 31.03.2006 13:12 you said the following:
From: "Boris B. Zhmurov" <[EMAIL PROTECTED]>
Date: Thu, 30 Mar 2006 17:29:09 +0400
Hello, Herbert Xu.
On 30.03.2006 14:12 you said the following:
On Thu, Mar 30, 2006 at 10:02:01AM +, Boris B. Zhmurov wrote:
[EMAIL
On Fri, Mar 31, 2006 at 01:35:40AM -0800, David S. Miller wrote:
>
> He does not have TSO enabled, e1000 disables TSO when on a link speed
> slower than gigabit.
Indeed. But I think that only happens on PCI Express and I don't think
Ingo is using PCI Express.
Cheers,
--
Visit Openswan at http:
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 31 Mar 2006 20:16:53 +1100
> Ingo Oeser <[EMAIL PROTECTED]> wrote:
> >
> > More datapoints.
> >
> > First of all, I don't see the problem, so this is an exclusion data point.
>
> Great. I think so far all the configurations that have this problem
Hi:
The e1000 xmit routine is lockless and it checks last_tx_tso outside the
locked section. So if a TSO packet wins a race against a non-TSO packet
with last_tx_tso == 0 then we may overwrite an existing buffer_info entry
which would corrupt memory.
The e1000_transfer_dhcp_info call also seems
Ingo Oeser <[EMAIL PROTECTED]> wrote:
>
> More datapoints.
>
> First of all, I don't see the problem, so this is an exclusion data point.
Great. I think so far all the configurations that have this problem
are
e1000 + SMP + TSO
Since your machine is not SMP but has the other two things it wou
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 30 Mar 2006 20:52:45 +1100
> Well I started from the beginning again, and found this. This may be
> the smoking gun that we're after :)
>
> The xmit routine is lockless but checks last_tx_tso outside the locked
> section. So if a TSO packet wins a
From: "Boris B. Zhmurov" <[EMAIL PROTECTED]>
Date: Thu, 30 Mar 2006 17:29:09 +0400
> Hello, Herbert Xu.
>
> On 30.03.2006 14:12 you said the following:
>
> > On Thu, Mar 30, 2006 at 10:02:01AM +, Boris B. Zhmurov wrote:
> >
> >>[EMAIL PROTECTED] linux-2.6.16]$ patch -p1 <
> >>../../../SOUR
From: Ingo Oeser <[EMAIL PROTECTED]>
Date: Fri, 31 Mar 2006 10:57:06 +0200
> Hi Jesse,
>
> More datapoints.
>
> First of all, I don't see the problem, so this is an exclusion data point.
>
> Machine is up 1 day, 19:02
>
> I use 2.6.16 and I'm NBOT running at Gigabit speed.
If you're not runni
Hi Jesse,
More datapoints.
First of all, I don't see the problem, so this is an exclusion data point.
Machine is up 1 day, 19:02
I use 2.6.16 and I'm NBOT running at Gigabit speed.
(just couldn't get e100 cards anymore, they are not sold anymore here)
Version: vendor 00:aa:00, model 56 rev 0
Kumar Gala wrote:
> On Mar 30, 2006, at 12:36 PM, Andrew Grover wrote:
> > Wellit's true they're useful for debugging but I would put them in
> > the category of system statistics that shouldn't go in debugfs. I
> > think they are like /proc/interrupts' interrupt counts or the TX/RX
> > stats r
90 matches
Mail list logo
