Re: TCP send/ack lockstep problem

2006-09-02 Thread Herbert Xu
Matthias Urlichs [EMAIL PROTECTED] wrote: The stuff I see in there doesn't look stupid to me. accept(...) = 216 setsockopt(216, SOL_IP, IP_TOS, [8], 4) = 0 setsockopt(216, SOL_TCP, TCP_NODELAY, [1], 4) = 0 setsockopt(216, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0 followed by a bunch of

Re: TCP send/ack lockstep problem

2006-09-02 Thread Stephen Hemminger
Matthias Urlichs wrote: Hi, Herbert Xu: Matthias Urlichs [EMAIL PROTECTED] wrote: Any ideas? Is the sending program doing something stupid? If so, what? Probably. Since you're on the sender's side (192.109.x.x I presume) why don't you do a strace on the sending process and

Re: Linux UDP Implementation

2006-09-02 Thread Gary Chan
Dear Rick, Thank you for your reply. I am sorry that I don't quite understand your point. As far as I know, the function call udp_flush_pending_frames() in net/ipv4/udp.c is invoked regardless of whether the socket is set to either a blocking mode or a non-blocking mode. Do you mean that the

Re: [PATCH] tcp: turn ABC off

2006-09-02 Thread Evgeniy Polyakov
On Fri, Sep 01, 2006 at 01:55:15PM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 111ff39..159fa3f 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -89,7 +89,7 @@ int sysctl_tcp_frto; int

Re: [PATCH] tcp: turn ABC off

2006-09-02 Thread Herbert Xu
Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Fri, Sep 01, 2006 at 01:55:15PM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 111ff39..159fa3f 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -89,7 +89,7 @@

Re: TCP send/ack lockstep problem

2006-09-02 Thread netdev-owner
Hi, found it. This is the tcpdump, for your edification. Note that many packets have push set for no good reason, which generally indicates dropped packets if we're doing a bulk transfer. But all packets that are visible in the dump reached their destination..! The culprit turns out to be the

Re: Linux UDP Implementation

2006-09-02 Thread Andi Kleen
It seems that the implementation (at code level) does not match with the actual behaviour. I would like to seek expertise on clarifying my understanding in UDP implementation so that this phenomenon can be explained. How about you just add some printks or use a tool like systemtap to

Re: [PATCH] change netfilter tunables to __read_mostly

2006-09-02 Thread Patrick McHardy
Brian Haley wrote: Sorry, next time I'll send them to you, or [EMAIL PROTECTED] netfilter-devel is better, that way other people working on netfilter get a chance to see it as well. I think only a handful of people on netfilter-devel also follow netdev. I'll cook-up another patch for the

[IPSEC]: searching SAD without assumming L3 details

2006-09-02 Thread jamal
Against net-2.6.19 signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED] cheers, jamal Allow for searching the SAD from external data path points without assumming L3 details. The only customer of this exposure currently is pktgen. --- commit 33d3060784e6aa55e30ae7d5efc491180e7f955d tree

e1000 Detected Tx Unit Hang

2006-09-02 Thread Paul Aviles
I am getting e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang using stock 2.6.17.11, 2.6.17.5 or 2.6.17.4 kernels on centos 4.3. The server is a Tyan GS12 ( 82541GI/PI and 82547GI) and is connected to a Netgear GS724T Gig switch. I can easily reproduce the problem by trying to do a

[XFRM]: Fix wildcard as tunnel source

2006-09-02 Thread Patrick McHardy
[XFRM]: Fix wildcard as tunnel source Hashing SAs by source address breaks templates with wildcards as tunnel source. Remove saddr from the hash key. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] --- commit 19f7b6f33c0e9fbdf23a33506c2dfc0706b0c731 tree

Re: [IPSEC]: searching SAD without assumming L3 details

2006-09-02 Thread James Morris
On Sat, 2 Sep 2006, jamal wrote: Against net-2.6.19 signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED] +xfrm_stateonly_find(xfrm_address_t *daddr, xfrm_address_t *saddr, + unsigned short family, u32 reqid, u8 mode, u8 proto) +{ + unsigned int h = xfrm_dst_hash(daddr,

Re: [IPSEC]: searching SAD without assumming L3 details

2006-09-02 Thread jamal
On Sat, 2006-02-09 at 11:04 -0400, James Morris wrote: On Sat, 2 Sep 2006, jamal wrote: + + spin_lock(xfrm_state_lock); Shouldn't this be spin_lock_bh()? + spin_unlock(xfrm_state_lock); + the call is made at the moment only by pktgen (kernel threads on dev_queue_xmit

Re: ProxyARP and IPSec

2006-09-02 Thread H. Peter Anvin
Stephen J. Bevan wrote: H. Peter Anvin writes: Fair enough. However, that does beg a question: is there any sane way to create the pseudo-device model on top of the current model, as a convenience layer? That way you could get the best of both. I assume you were using tunnel-mode

Re: [IPSEC]: searching SAD without assumming L3 details

2006-09-02 Thread jamal
On Sat, 2006-02-09 at 13:16 -0400, jamal wrote: the call is made at the moment only by pktgen (kernel threads on dev_queue_xmit level contending with softirqs essentially). I think (although havent tried) the spin_{un}lock_bh() wont work. Thoughts? Obviously the easy thing for me to do is

Re: [IPSEC]: searching SAD without assumming L3 details

2006-09-02 Thread James Morris
On Sat, 2 Sep 2006, jamal wrote: On Sat, 2006-02-09 at 11:04 -0400, James Morris wrote: On Sat, 2 Sep 2006, jamal wrote: + + spin_lock(xfrm_state_lock); Shouldn't this be spin_lock_bh()? + spin_unlock(xfrm_state_lock); + the call is made at the moment

2.6.18-rc5 + pata-drivers on MSI K9N Ultra report, AMD64

2006-09-02 Thread Krzysztof Halasa
Hi, Keywords: nForce PCIe, forcedeth, nForce PATA, Radeon DRM, ALC883 HDA sound FYI: running 2.6.18-rc5 + pata-drivers on MSI mb K9N Ultra (NVidia MCP55, PCIe, Athlon64, x86_64, no SMP, no preempt) gives the following (all details available on request, of course): Nvidia board detected.

2.6.18-rc5 with GRE, iptables and Speedtouch ADSL, PPP over ATM

2006-09-02 Thread Krzysztof Halasa
Hi, FYI: Just enabled kernel lock testers on my old laptop machine doing internet services. 2.6.18-rc5, i686. All details available on request, of course. There is IP GRE tunnel here running over ADSL connection (USB Thomson/Alcatel Speedtouch 330, PPP over ATM, in-kernel drivers). Ethernet is

Re: ProxyARP and IPSec

2006-09-02 Thread Stephen J. Bevan
sarcasm What I great idea. Now I just have to get every host I want to interoperate with to support a nonstandard configuration. The scary part is that if I motivate it with Linux is too stupid to handle standard tunnel-mode IPsec I might actually get away with it. /sarcasm

Re: 2.6.18-rc5 + pata-drivers on MSI K9N Ultra report, AMD64

2006-09-02 Thread Alan Cox
Ar Sad, 2006-09-02 am 22:14 +0200, ysgrifennodd Krzysztof Halasa: ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14 ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 There is no secondary IDE connector on this motherboard, I think it's just disabled by BIOS. Its

Re: 2.6.18-rc5 with GRE, iptables and Speedtouch ADSL, PPP over ATM

2006-09-02 Thread Francois Romieu
Krzysztof Halasa [EMAIL PROTECTED] : [...] === [ INFO: possible circular locking dependency detected ] --- swapper/0 is trying to acquire lock: (dev-queue_lock){-+..}, at: [c02c8c46]

neigh_lookup lockdep warning

2006-09-02 Thread Dave Jones
Seen during boot of a 2.6.18rc5-git1 based kernel. Dave === [ INFO: possible circular locking dependency detected ] 2.6.17-1.2608.fc6 #1 --- swapper/0 is trying to acquire

BUG in bcm32xx-d80211: sleeping function called with irq's disabled

2006-09-02 Thread Larry Finger
The latest git pull from wireless-dev (g7844a579) is calling a sleeping function with irq's disabled. The kernel is a UP version with preemption disabled. The dump is as follows: kernel: bcm43xx_d80211: Virtual interface added (type: 0x0002, ID: 4, MAC: 00:06:25:40:6f:03) kernel: