In net poll mode, the current checksum function doesn't consider the
kind of packet which is padded to reach a specific minimum length. I
believe that's the problem causing my test case failed. The following
patch fixed this issue.
Signed-off-by: Aubrey.Li <[EMAIL PROTECTED]>
---
net/core/netpoll
Sebastian Kuzminsky wrote:
> Weird. Why does sending a message from the client make it go again?
The rule that allows packets with an "ESTABLISHED" state only matches
packets for which the connection is in netfilter's conntrack table.
The connection is removed from the table after the 5 days of i
Philip Craig <[EMAIL PROTECTED]> wrote:
> It sounds like it could easily be iptables related, if you have iptables
> rules that only allow new connections in the client to server direction,
> which is quite normal.
Sure I have those standard rules.
iptables -A INPUT -p tcp -m state --state ESTABL
Sebastian Kuzminsky wrote:
> I'm seeing some weird behavior in TCP. The issue is perfectly
> reproducible using netcat and other programs. This is what I do:
>
> 1. Open a TCP connection over the loopback (over IPv4).
>
> 2. Send a couple of bytes of data each way. No problems.
>
>
John Heffner <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > A guess: maybe something related to a PAWS wraparound problem.
> > Does turning off sysctl net.ipv4.tcp_timestamps fix it?
>
> That was my first thought too (aside from netfilter), but a failed PAWS
> check should not result i
Stephen Hemminger wrote:
A guess: maybe something related to a PAWS wraparound problem.
Does turning off sysctl net.ipv4.tcp_timestamps fix it?
That was my first thought too (aside from netfilter), but a failed PAWS
check should not result in a reset..
-John
-
To unsubscribe from this list
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> A guess: maybe something related to a PAWS wraparound problem.
> Does turning off sysctl net.ipv4.tcp_timestamps fix it?
I just started this test, I'll let you know in 5 days. :-/
Any other things I should try, anyone? I'm doing the new tests under
drivers/net/ibmveth.c:96:46: error: marked inline, but without a definition
drivers/net/ibmveth.c:96: warning: 'ibmveth_rxq_harvest_buffer' declared inline
after being called
drivers/net/ibmveth.c:96: warning: previous declaration of
'ibmveth_rxq_harvest_buffer' was here
Just let the compiler de
Dave Jones wrote:
On Mon, Apr 16, 2007 at 05:14:40PM -0700, Brandeburg, Jesse wrote:
> Adrian Bunk wrote:
> > Subject: laptops with e1000: lockups
> > References :
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
> > Submitter : Dave Jones <[EMAIL PROTECTED]>
> > Handl
On Mon, Apr 16, 2007 at 05:14:40PM -0700, Brandeburg, Jesse wrote:
> Adrian Bunk wrote:
> > Subject: laptops with e1000: lockups
> > References :
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
> > Submitter : Dave Jones <[EMAIL PROTECTED]>
> > Handled-By : Jesse Brandeb
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 19:19:02 +0300 (EEST)
> [PATCH] [TCP]: Sed magic converts func(sk, tp, ...) -> func(sk, ...)
I was trying to spread out the net-2.6.22 tree from the tcp-2.6
one so that we could do the experimental TCP stuff in the tcp-2.6
tree and
Adrian Bunk wrote:
> Subject: laptops with e1000: lockups
> References :
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603
> Submitter : Dave Jones <[EMAIL PROTECTED]>
> Handled-By : Jesse Brandeburg <[EMAIL PROTECTED]>
> Status : problem is being debugged
this is being activ
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 06:59:06 +0200
> RTM_DELROUTE + RTM_NEWROUTE seem to be safer, although you're correct
> that it might cause userspace to perform some action upon receiving
> the DELROUTE message since the update is non-atomic. So I really don't
> k
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 09:53:55 +0200
> This patch fixes a few spots for using ingress_lock for the ingress
> qdisc again and switches ing_filter back to use it.
>
> Applies on top of the netlink dump patches.
Applied, thanks a lot for following up on th
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 09:51:57 +0200 (MEST)
> [NET_SCHED]: Eliminate qdisc_tree_lock
>
> Since we're now holding the rtnl during the entire dump operation, we
> can remove qdisc_tree_lock, whose only purpose is to protect dump
> callbacks from concurrent
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 09:51:55 +0200 (MEST)
> [RTNETLINK]: Remove unnecessary locking in dump callbacks
>
> Since we're now holding the rtnl during the entire dump operation, we can
> remove additional locking for rtnl protected data. This patch does tha
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 09:51:54 +0200 (MEST)
> [RTNETLINK]: Hold rtnl_mutex during netlink dump callbacks
>
> Hold rtnl_mutex during the entire netlink dump operation. This allows
> to simplify locking in the dump callbacks, since they can now rely on
> t
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 09:51:53 +0200 (MEST)
> [NETLINK]: Switch cb_lock spinlock to mutex and allow to override it
>
> Switch cb_lock to mutex and allow netlink kernel users to override it
> with a subsystem specific mutex for consistent locking in dump
On Mon, 16 Apr 2007 17:05:42 -0600
Sebastian Kuzminsky <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> > On Mon, 16 Apr 2007 16:28:22 -0600
> > Sebastian Kuzminsky <[EMAIL PROTECTED]> wrote:
> >
> > > I'm seeing some weird behavior in TCP. The issue is perfectly
> > >
On Mon, Apr 16, 2007 at 12:10:51PM -0700, Michael Chan wrote:
> On Sat, 2007-04-14 at 17:20 -0700, Michael Chan wrote:
>
> > I also like Andi's idea of using change_page_attr() to isolate the
> > problem. I'll try to send you a debug patch in the next few days to try
> > that out. Thanks.
>
> H
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Apr 2007 16:28:22 -0600
> Sebastian Kuzminsky <[EMAIL PROTECTED]> wrote:
>
> > I'm seeing some weird behavior in TCP. The issue is perfectly
> > reproducible using netcat and other programs. This is what I do:
> >
> > 1. Open a TCP
On Mon, 16 Apr 2007 16:28:22 -0600
Sebastian Kuzminsky <[EMAIL PROTECTED]> wrote:
> I'm seeing some weird behavior in TCP. The issue is perfectly
> reproducible using netcat and other programs. This is what I do:
>
> 1. Open a TCP connection over the loopback (over IPv4).
>
> 2. Send
I'm seeing some weird behavior in TCP. The issue is perfectly
reproducible using netcat and other programs. This is what I do:
1. Open a TCP connection over the loopback (over IPv4).
2. Send a couple of bytes of data each way. No problems.
3. Wait about 120 hours with no writes
Can you try 2.6.21-rc7 + (either):
- http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.21-rc7/r8169-20070416
-
http://www.fr.zoreil.com/people/francois/misc/20070416-2.6.21-rc7-r8169-test.patch
If it does not work better, please fill an entry for it at bugzilla.kernel.org,
Cc: it to me and attach th
> On Mon, 16 Apr 2007 13:35:47 -0700 [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8338
>
>Summary: NAT of TCP connections broken
> Kernel Version: 2.6.20.7
> Status: NEW
> Severity: high
> Owner: [EMAIL PROTECTED]
>
Greetings!
I have a SuSE 10.2 64-bit installation that uses a Realtek PCI GbE chip in
D-Link disguise (lspci see below).
While this works rather well after a normal boot sequence, I don't get a
gigabit link after resume from standby or suspend-to-disk.
Entering standby, the link speed goes dow
On 4/15/07, Dave Jones <[EMAIL PROTECTED]> wrote:
I booted up 2.6.21rc7 without an ethernet cable plugged in,
and noticed this..
e1000: :02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid
e1000: probe of :02:00.0 failed with error -5
I plugged a cable in, did rmmod e1000;modprobe e1
From: John Heffner <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 15:11:07 -0400
> I don't know if this qualifies as an unconditional bug. The commit
> above was actually a bugfix so that the limits were not higher than
> total memory on some systems, but had the side effect that it made them
> ev
From: "Robert Iakobashvili" <[EMAIL PROTECTED]>
Date: Mon, 16 Apr 2007 20:51:54 +0200
> > Commit: 53cdcc04c1e85d4e423b2822b66149b6f2e52c2c
> > Author: John Heffner <[EMAIL PROTECTED]> Fri, 16 Mar 2007 15:04:03 -0700
> >
> > [TCP]: Fix tcp_mem[] initialization.
> > Change tcp_mem initiali
Robert Iakobashvili wrote:
Kernels 2.6.19 and 2.6.20 series are effectively broken right now.
Don't you wish to patch them?
I don't know if this qualifies as an unconditional bug. The commit
above was actually a bugfix so that the limits were not higher than
total memory on some systems, bu
>> Robert Iakobashvili wrote:
>> > Vanilla 2.6.18.3 works for me perfectly, whereas 2.6.19.5 and
>> > 2.6.20.6 do not.
>> >
>> > Looking into the tcp /proc entries of 2.6.18.3 versus 2.6.19.5
>> > tcp_rmem and tcp_wmem are the same, whereas tcp_mem are
>> > much different:
>> >
>> > kernel
On Sat, 2007-04-14 at 17:20 -0700, Michael Chan wrote:
> I also like Andi's idea of using change_page_attr() to isolate the
> problem. I'll try to send you a debug patch in the next few days to try
> that out. Thanks.
>
Here's the debug patch for x86 only that will change the statistics
memory
[cc:ed to netdev]
On Sun, Apr 15, 2007 at 10:45:37PM -0700, Mike Mattie wrote:
> Hello,
>
> netconsole is hanging my box during IDE init.
>
> I am running 2.6.20.7, config is attached from /proc
>
> Without using netconsole the kernel boots fine. I am writing this message
> from it.
>
> When
Robert Iakobashvili wrote:
Hi John,
On 4/15/07, John Heffner <[EMAIL PROTECTED]> wrote:
Robert Iakobashvili wrote:
> Vanilla 2.6.18.3 works for me perfectly, whereas 2.6.19.5 and
> 2.6.20.6 do not.
>
> Looking into the tcp /proc entries of 2.6.18.3 versus 2.6.19.5
> tcp_rmem and tcp_wmem are th
On Fri, 13 Apr 2007 08:39:31 -0700
Linsys Contractor Mithlesh Thukral <[EMAIL PROTECTED]> wrote:
> NetXen: Fix the multi PCI function for cards with more than 2 ports.
> This patch fixes the working of multi PCI capable driver on cards with
> more than 2 ports by adding the addresses for their ri
Dave Jones wrote:
> I booted up 2.6.21rc7 without an ethernet cable plugged in,
> and noticed this..
>
> e1000: :02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid
> e1000: probe of :02:00.0 failed with error -5
>
> I plugged a cable in, did rmmod e1000;modprobe e1000, and got this..
On Mon, 16 Apr 2007, Patrick McHardy wrote:
> The preferred style is a newline after variable declarations. Some
> (mostly old) code doesn't consistently do that, but in cases where
> you add the first local variable you should really add them.
>
> > ...No newline should be place here, since it's
On Mon, 16 Apr 2007, Patrick McHardy wrote:
> Ilpo Järvinen wrote:
> > On Mon, 16 Apr 2007, Patrick McHardy wrote:
> >
> > [...] It's not clear to me what is really the preferred
> > style considering all the variants... [...]
>
> The preferred style is a newline after variable declarations. So
Ilpo Järvinen wrote:
> On Mon, 16 Apr 2007, Patrick McHardy wrote:
>
>>[...]
>
> ...in the other (original) patch description that is not copied fully here
> I had a sort of disclaimer for these missing ones but in case they should
> all be changed so that if the added tcp_sock is the only loca
On Mon, 16 Apr 2007, Patrick McHardy wrote:
> Ilpo Järvinen wrote:
> > Tweaked newlines manually & fixed four warnings that were
> > introduced.
>
> Not all of them it seems:
>
> > -static inline void tcp_fast_path_check(struct sock *sk, struct tcp_sock
> > *tp)
> > +static inline void tcp_fast
Lennart Sorensen wrote:
Which PCI host controller are you using with the PXA255? We tried using
a PXA255 based system with a PCI controller a couple of years ago and
have to change to a different cpu in the end due to the PCI controller
simply not being valid PCI. The PXA255 wasn't designed for
Ilpo Järvinen wrote:
> Tweaked newlines manually & fixed four warnings that were
> introduced.
Not all of them it seems:
> -static inline void tcp_fast_path_check(struct sock *sk, struct tcp_sock *tp)
> +static inline void tcp_fast_path_check(struct sock *sk)
> {
> + struct tcp_sock *tp = tc
On Mon, 16 Apr 2007, Christoph Hellwig wrote:
> It would be easier if you sent all bits in a single patch, it's
> one logical change after all, and a rather small one aswell.
Here it is the way you requested...
[PATCH] [TCP]: Sed magic converts func(sk, tp, ...) -> func(sk, ...)
This is (mostly
It would be easier if you sent all bits in a single patch, it's
one logical change after all, and a rather small one aswell.
-
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-in
Pavel Emelianov wrote:
> Patrick McHardy wrote:
>
>>>There is a race between netlink_dump_start() and netlink_release()
>>>that can lead to the situation when a netlink socket with non-zero
>>>callback is freed.
>>
>>
>>Can you describe the race in more detail please?
>>
>
> Here it is:
>
> [...
Manual completion to func(sk, tp, ...) -> func(sk, ...)
conversion.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c |1 -
net/ipv4/tcp_output.c |3 ---
2 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
ind
Improves readability a bit here and there (this is likely less
than complete change anyway).
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c | 10 ++
net/ipv4/tcp_output.c |2 ++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_
This is fully automated change using this magic:
sed -e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N'
-e '/struct sock \*sk/ N' -e '/struct sock \*sk/ N'
-e 's|struct sock \*sk,[\n\t ]*struct tcp_sock \*tp\([^{]*\n{\n\)|
struct sock \*sk\1\tstruct tcp_sock *tp = tcp_sk(sk);\n|
Patrick McHardy wrote:
> Pavel Emelianov wrote:
>> From: Denis Lunev <[EMAIL PROTECTED]>
>>
>> There is a race between netlink_dump_start() and netlink_release()
>> that can lead to the situation when a netlink socket with non-zero
>> callback is freed.
>
>
> Can you describe the race in more det
Pavel Emelianov wrote:
> From: Denis Lunev <[EMAIL PROTECTED]>
>
> There is a race between netlink_dump_start() and netlink_release()
> that can lead to the situation when a netlink socket with non-zero
> callback is freed.
Can you describe the race in more detail please?
-
To unsubscribe from
On 4/12/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
Aubrey Li wrote:
> I think we discussed this issue before.
>
> The current checksum function doesn't consider the kind of packet
> which is padded to reach a specific minimum length. I believe that's
> the problem caused my test case failed
> Jerome Borsboom wrote:
> > in4_pton converts a textual representation of an ip4 address into an
> > integer representation. However, when the textual representation is of
> > in the form ip:port, c.f. 192.168.1.1:5060, and 'delim' is set to -1,
> > the function bails out when parsing the colon.
>
Jerome Borsboom wrote:
> in4_pton converts a textual representation of an ip4 address into an
> integer representation. However, when the textual representation is of
> in the form ip:port, c.f. 192.168.1.1:5060, and 'delim' is set to -1,
> the function bails out when parsing the colon.
>
> It mak
in4_pton converts a textual representation of an ip4 address into an
integer representation. However, when the textual representation is of in
the form ip:port, c.f. 192.168.1.1:5060, and 'delim' is set to -1, the
function bails out when parsing the colon.
It makes sense to allow the colon as
On Mon, Apr 16, 2007 at 10:14:17AM +0200, Thomas Graf wrote:
> * Willy Tarreau <[EMAIL PROTECTED]> 2007-04-14 17:48
> > Finally, I think I have the correct fix below. Please someone confirm
> > or tell me I'm nuts.
>
> Looks good, same is needed for DECnet
Thank you Thomas.
The DECnet stuff was a
* Willy Tarreau <[EMAIL PROTECTED]> 2007-04-14 17:48
> Finally, I think I have the correct fix below. Please someone confirm
> or tell me I'm nuts.
Looks good, same is needed for DECnet
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED
This patch fixes a few spots for using ingress_lock for the ingress
qdisc again and switches ing_filter back to use it.
Applies on top of the netlink dump patches.
[NET_SCHED]: ingress: switch back to using ingress_lock
Switch ingress queueing back to use ingress_lock. qdisc_lock_tree now locks
[NET_SCHED]: Eliminate qdisc_tree_lock
Since we're now holding the rtnl during the entire dump operation, we
can remove qdisc_tree_lock, whose only purpose is to protect dump
callbacks from concurrent changes to the qdisc tree.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit cc9651
[RTNETLINK]: Remove unnecessary locking in dump callbacks
Since we're now holding the rtnl during the entire dump operation, we can
remove additional locking for rtnl protected data. This patch does that
for all simple cases (dev_base_lock for dev_base walking, RCU protection
for FIB rule dumping)
[NETLINK]: Switch cb_lock spinlock to mutex and allow to override it
Switch cb_lock to mutex and allow netlink kernel users to override it
with a subsystem specific mutex for consistent locking in dump callbacks.
All netlink_dump_start users have been audited not to rely on any
side-effects of the
[RTNETLINK]: Hold rtnl_mutex during netlink dump callbacks
Hold rtnl_mutex during the entire netlink dump operation. This allows
to simplify locking in the dump callbacks, since they can now rely on
that no concurrent changes happen.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit
These patches change netlink to provide consistent locking in dump callbacks.
Currently the first invocation of the callbacks happens under the queue
processing mutex and ->cb_lock of the dumping socket, further invocations only
under cb_lock. The first patch replaces the cb_lock spinlock by a mute
62 matches
Mail list logo
