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
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
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
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
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 @@
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
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
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
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
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
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
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,
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
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
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
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
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.
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
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
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
Krzysztof Halasa [EMAIL PROTECTED] :
[...]
===
[ INFO: possible circular locking dependency detected ]
---
swapper/0 is trying to acquire lock:
(dev-queue_lock){-+..}, at: [c02c8c46]
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
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:
23 matches
Mail list logo