During the development of the algorithm, some unnecessary cruft
seems to have crept in that is nowadays unnecessary:
1) LOST edge finder that sets not_marked_skb in the first loop
causes suboptimal performance because the preceeding else branch
already decides that the entry won't be necessary
On Wed, 2007-04-04 at 05:11 +0300, Denys wrote:
I think this highly useful feature given by jamal, difficult to be avoided
from crash, if user not enough experienced in networking(like me). I guess
packet can be even not ipv4/ipv6 packet, maybe it can be cloned IPX or ARP,
so TTL field
On Tue, Apr 03, 2007 at 04:19:46PM +0100, Christian Kujau wrote:
On Tue, 3 Apr 2007, Jarek Poplawski wrote:
Did you try with 8139cp instead of 8139too?
Tried that, 8139cp could not be loaded :(
Sorry for misleading!
(Maybe even try some other card to narrow the problem?)
You could also
DiegoB wrote:
Patrick McHardy wrote:
I've updated my IPsec MTU optimization patch I've posted a couple
of month ago to net-2.6.22 and added the further optimization
suggested by Herbert to account for the space lost due to alignment
in the room reserved for IP options in transport mode.
On Tue, 3 Apr 2007, Francois Romieu wrote:
Christian Kujau [EMAIL PROTECTED] :
If the apic voodoo makes no difference, you can:
1 - leave it enabled
Well, we tried to boot with ACPI compiled in again, but disabled during
boot:
- acpi=off lapic, crashed after 1h (almost exactly) of service
-
On Wed, 4 Apr 2007, Jarek Poplawski wrote:
So, it's a lot sooner than before. (BTW, isn't there anything
in debug log?)
No, nothing. I've set up remote-syslgging to the other node (node1
logging to node2 and vice versa) - nothing :(
I see both CPUs did interrupt handling again.
Yes, when
jamal wrote:
On Wed, 2007-04-04 at 05:11 +0300, Denys wrote:
I think this highly useful feature given by jamal, difficult to be avoided
from crash, if user not enough experienced in networking(like me). I guess
packet can be even not ipv4/ipv6 packet, maybe it can be cloned IPX or ARP,
so
Well, my case is my own mistake, i guess it is just misconfiguration, not
actual bug. And also it is good push for me read doc's and think well before
adding rules.
Maybe it can be in TODO, but it is not N1 priority i guess. There is more
important things, what u want to do. Another thing,
On Wed, 2007-04-04 at 15:36 +0200, Patrick McHardy wrote:
We have a loop counter (RTTL) in tc_verd. For some reason it is reset
after ing_filter though.
Essentially it is valuable just to avoid a lot of stacking (separate
issue) and not to avoid the locking issue he is seeing.
It would
jamal wrote:
On Wed, 2007-04-04 at 15:36 +0200, Patrick McHardy wrote:
It would be interesting to find out what the problem is exactly.
The configuration itself looks harmless, so I'm guessing its
rather a deadlock than a loop.
We know it is a deadlock.
If you redirect the first time
Hello.
Jeff Garzik wrote:
CONFIG_NETPOLL_TRAP causes the TX queue controls to be completely
bypassed in
the netpoll's trapped mode which easily causes overflows in the
drivers with
short TX queues (most notably, in 8139too with its 4-deep queue).
Make this option more sensible by only
On Wed, 2007-04-04 at 16:13 +0200, Patrick McHardy wrote:
This seems to be due to be caused by act_mirred returning TC_ACT_STOLEN,
which is translated to NET_XMIT_SUCCESS within prio, causing HTB to
increase the q.qlen counter and activating the class despite no packet
beeing queued.
I ran into a problem where LKSCTP is reporting a SCTM_COMM_UP indication
to the User application but is giving back a value of zero for the
assoc_id.
Attached are the SCTP debugs for the period in question.
A couple of things that I would like to note about my setup. One is that
I'm running
jamal wrote:
On Wed, 2007-04-04 at 16:07 +0200, Patrick McHardy wrote:
How about adding something like ifb's ri_tasklet to act_mirred?
You mean having a tasklet or the constraint checks?
Have a tasklet to avoid the deadlocks.
-
To unsubscribe from this list: send the line unsubscribe
jamal wrote:
On Wed, 2007-04-04 at 16:13 +0200, Patrick McHardy wrote:
This seems to be due to be caused by act_mirred returning TC_ACT_STOLEN,
which is translated to NET_XMIT_SUCCESS within prio, causing HTB to
increase the q.qlen counter and activating the class despite no packet
beeing
This is an implementation of TCP Illinois invented by Shao Liu
at University of Illinois. It is a another variant of Reno which adapts
the alpha and beta parameters based on RTT. The basic idea is to increase
window less rapidly as delay approaches the maximum. See the papers
and talks to get a
Yes, it is real setup by the way, i just copypaste script here. I tried to
remove some commands to leave only minimum to reproduce the problem.
Right now i dont have another ethernet card on that system, i will add it
today, when i come back home and i will test in different situations. Also it
On Mon, Apr 02, 2007 at 10:47:45PM -0700, Andrew Morton wrote:
...
Changes since 2.6.21-rc5-mm3:
...
git-net.patch
...
git trees.
...
This patch contains the following possible cleanups:
- make the following needlessly global variables static:
- core/rtnetlink.c: struct
Hello,
We are currently using both 1 Gb 10 Gb links, that interconnect
several servers that are very *local* to each other.
Typical RTT times range from 0.2 ms - 0.3 ms.
We are currently using TCP reno - is there a more suitable congestion
control algorithm for our application,
especially
* [EMAIL PROTECTED] [EMAIL PROTECTED] [070404 18:29]:
Hello,
We are currently using both 1 Gb 10 Gb links, that interconnect several
servers that are very *local* to
each other.
Typical RTT times range from 0.2 ms - 0.3 ms.
We are currently using TCP reno - is there a more suitable
[For SCTP questions, please use netdev or lksctp-developers list]
Hi Oscar
Isaula Oscar-QOI000 wrote:
I ran into a problem where LKSCTP is reporting a SCTM_COMM_UP indication
to the User application but is giving back a value of zero for the
assoc_id.
Attached are the SCTP debugs for the
Le Mardi 20 Mars 2007 08:19, Jean Delvare a écrit :
I noticed recently that, in skb_checksum(), offset and start are
essentially the same thing and have the same value throughout the
function, despite being computed differently. Using a single variable
allows some cleanups and makes the
Thanks - so you are suggesting we enable 802.3 flow-control /
pause-frames?
(it's currently disabled)
-Original Message-
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org
Sent: Wed, 4 Apr 2007 8:39 AM
Subject: Re: TCP congestion control for
* [EMAIL PROTECTED] [EMAIL PROTECTED] [070404 19:03]:
Thanks - so you are suggesting we enable 802.3 flow-control / pause-frames?
(it's currently disabled)
I do, but do test it before you bet on it. I've never tested such a
scenario but from my experience the lower the rtt the lesser are the
Adrian,
Sorry about the upper case stuff. The new PHY code was ported from our
firmware guys and the case didn't not get changed. I normally will make
such changes but it didn't get done this time. I will clean it up in
the near future.
Ron
-Original Message-
From: Jeff Garzik
In article [EMAIL PROTECTED] (at Tue, 3 Apr 2007 15:55:51 +0900), Mitsuru
Chinen [EMAIL PROTECTED] says:
Incoming trancated packets are counted as not only InTruncatedPkts but
also InHdrErrors. They should be counted as InTruncatedPkts only.
Signed-off-by: Mitsuru Chinen [EMAIL PROTECTED]
On Wed, 4 Apr 2007 19:11:21 +0300
Baruch Even [EMAIL PROTECTED] wrote:
* [EMAIL PROTECTED] [EMAIL PROTECTED] [070404 19:03]:
Thanks - so you are suggesting we enable 802.3 flow-control / pause-frames?
(it's currently disabled)
I do, but do test it before you bet on it. I've never tested
Christian Kujau [EMAIL PROTECTED] :
[...]
Actually I was thinking about *using* netconsole, since even setting up
remote (userspace-)syslog left nothing on the syslog-server, when the
machine crashed. But if it's b0rked in 8139, I will refrain from doing
so.
Please refrain :o)
No serial
Andi Kleen [EMAIL PROTECTED] :
Aaron Lehmann [EMAIL PROTECTED] writes:
[adding netdev]
[meta-comment: I wish people wouldn't use such unnecessarily broad subjects
-- how is it the x86-64 port's or AMD's fault when you have broken hardware?
Would anybody write Silent corruption on i386 or
Francois Romieu [EMAIL PROTECTED] writes:
[...]
Oh, thanks. I'll try.
Excellent.
That patchset works fine for me. (i386 + smp, i386 + up, x86_64 + smp)
I hope to include those patches to 2.6.21.
Thanks.
--
OGAWA Hirofumi [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
From: Baruch Even [EMAIL PROTECTED]
Date: Wed, 4 Apr 2007 19:11:21 +0300
* [EMAIL PROTECTED] [EMAIL PROTECTED] [070404 19:03]:
Thanks - so you are suggesting we enable 802.3 flow-control / pause-frames?
(it's currently disabled)
I do, but do test it before you bet on it. I've never tested
thanks for your help - I'll investigate turning on 802.3 level flow
control
-Original Message-
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
netdev@vger.kernel.org
Sent: Wed, 4 Apr 2007 12:55 PM
Subject: Re: TCP congestion control for fast,
OGAWA Hirofumi [EMAIL PROTECTED] :
[...]
That patchset works fine for me. (i386 + smp, i386 + up, x86_64 + smp)
Cool.
I hope to include those patches to 2.6.21.
The patchkit is scheduled for the next merge window. It fixes things for
some users but:
1. it missed the merge window of 2.6.21
2.
On Wed, Apr 04, 2007 at 08:45:04PM +0200, Francois Romieu wrote:
[adding netdev]
[meta-comment: I wish people wouldn't use such unnecessarily broad subjects
-- how is it the x86-64 port's or AMD's fault when you have broken
hardware?
Would anybody write Silent corruption on i386 or
Can't this BUG_ON be hit very easily:
static void tg3_irq_quiesce(struct tg3 *tp)
{
BUG_ON(tp-irq_sync);
...
}
tg3_reset_task could easily be racing with another thread, that calls
tg3_full_lock(tp, 1); e.g tg3_change_mtu. Maybe I'm missing something
obvious.
--
Gagan
-
To unsubscribe
Aaron Lehmann [EMAIL PROTECTED] :
[...]
I'll try to get to testing this, but I'm wondering if people may have
misunderstood my original post. I don't get any corruption over
Ethernet; it's just corruption on the filesystem during certain load
patterns that involve the Realtek ethernet card.
On Wed, 2007-04-04 at 13:34 -0700, Gagan Arneja wrote:
Can't this BUG_ON be hit very easily:
static void tg3_irq_quiesce(struct tg3 *tp)
{
BUG_ON(tp-irq_sync);
...
}
tg3_reset_task could easily be racing with another thread, that calls
tg3_full_lock(tp, 1); e.g tg3_change_mtu.
I like the counting semaphore idea.
--
Gagan
Michael Chan wrote:
On Wed, 2007-04-04 at 13:34 -0700, Gagan Arneja wrote:
Can't this BUG_ON be hit very easily:
static void tg3_irq_quiesce(struct tg3 *tp)
{
BUG_ON(tp-irq_sync);
...
}
tg3_reset_task could easily be racing with another
===
[ INFO: possible circular locking dependency detected ]
2.6.20-1.2933.fc6debug #1
---
swapper/0 is trying to acquire lock:
(tbl-lock){-+-+}, at: [c05d5664] neigh_lookup+0x43/0xa2
but task
On Wed, 04 Apr 2007 13:53:47 -0700
Gagan Arneja [EMAIL PROTECTED] wrote:
I like the counting semaphore idea.
--
Gagan
Michael Chan wrote:
On Wed, 2007-04-04 at 13:34 -0700, Gagan Arneja wrote:
Can't this BUG_ON be hit very easily:
static void tg3_irq_quiesce(struct tg3 *tp)
{
Thanks Dave, there is a classic AB BA deadlock here.
We should break the dependency like this.
Could someone who uses proxy ARP test this?
-
Need to drop one of the locks to avoid deadlock between
proxy arp and incoming arp receive.
---
net/core/neighbour.c | 10 +-
1 files
On Wed, 2007-04-04 at 23:21 +0200, Ingo Molnar wrote:
* Anthony Liguori [EMAIL PROTECTED] wrote:
But why is it a good thing to do PV drivers in the kernel? You lose
flexibility and functionality to gain performance. [...]
in Linux a kernel-space network driver can still be tunneled
Francois Romieu wrote:
Your usual dont-flush_scheduled_work-with-RTNL-held stuff.
It is a bit different here since the thread runs permanently
or is only occasionally kicked for recovery depending on the
hardware revision.
It looks like this has not made it into the 2.6.20 stable series
teach ethtool to print 1Mb/s for a 10G NIC and prepare
for 10G NICs where it is possible to run something other than 10G
update the ethtool.8 manpage with info re same and some grammar fixes
Signed-off-by: Rick Jones [EMAIL PROTECTED]
the likely required asbestos at the ready :)
rick jones
Stephen Hemminger [EMAIL PROTECTED] wrote:
Thanks Dave, there is a classic AB BA deadlock here.
We should break the dependency like this.
Could someone who uses proxy ARP test this?
Sorry Stephen, this isn't necessary. The lockdep thing is
simply confused here. It's treating
On Thu, 2007-04-05 at 10:44 +1000, Herbert Xu wrote:
Stephen Hemminger [EMAIL PROTECTED] wrote:
Thanks Dave, there is a classic AB BA deadlock here.
We should break the dependency like this.
Could someone who uses proxy ARP test this?
Sorry Stephen, this isn't necessary. The lockdep
On Wed, 2007-04-04 at 16:50 +0200, Patrick McHardy wrote:
Anyway, we can't return NET_XMIT_SUCCESS, so how about just returning
NET_XMIT_BYPASS in all cases where the packet was stolen/dropped/...
by TC actions?
Ok, I think i get you now. Yes, that would work, but:
for the dropped case, you
ShopInMe.net - Product Updates
Place here your text
4GB Sony memory stick Pro Duo
Product ID: 1164686843542328
£59.95
This looks like a locking bug in the ipv6 changes in davem's devel tree.
There are no relevant changes to drivers/net/sc92031.c in rc5-mm4.
Begin forwarded message:
Date: Thu, 05 Apr 2007 08:56:38 +0800
From: Antonino A. Daplas [EMAIL PROTECTED]
To: Andrew Morton [EMAIL PROTECTED]
Cc:
On Wed, 2007-04-04 at 16:39 +0200, Patrick McHardy wrote:
Have a tasklet to avoid the deadlocks.
sounds like a good idea from the outset. The principle of punishing only
users of mirred is the right one. It will also provide a clean way to
drop all redirect to self.
The dilema is that the cost
On Tue, Apr 03, 2007 at 10:30:46PM -0400, Jeff Garzik wrote:
Sergei Shtylyov wrote:
CONFIG_NETPOLL_TRAP causes the TX queue controls to be completely bypassed
in
the netpoll's trapped mode which easily causes overflows in the drivers
with
short TX queues (most notably, in 8139too with
From: Randy Dunlap [EMAIL PROTECTED]
Check PCI interfaces results in net/ drivers.
Fixes these warnings:
drivers/net/3c59x.c:1499: warning: ignoring return value of
'pci_enable_device', declared with attribute warn_unused_result
drivers/net/ne2k-pci.c:676: warning: ignoring return value of
52 matches
Mail list logo
