Hi All,
Looking at the TCP stack code it seems that if the variable snd_cwnd >
snd_ssthresh, TCP would move to congestion avoidance. Is that correct?
Are there any other constraints as far as linux implementation goes?
Will that condition hold even if there has been no packet drop or dup
acks rece
* Herbert Xu wrote:
Does the problem go away if you disable conntrack by unloading its module?
Please try to capture the offending ICMP packet with tcpdump and show us
what it looks like.
Well, there are no problems if SuSEfirewall2 is disabled. But have a look
at the loaded modules:
ipt_M
From: "David S. Miller" <[EMAIL PROTECTED]>
Date: Thu, 01 Dec 2005 18:51:19 -0800 (PST)
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Thu, 1 Dec 2005 10:51:55 -0800
>
> > Detail of issue is old:
> >
> > http://oss.sgi.com/archives/netdev/2004-11/msg00573.html
> >
> > Once accept fails o
From: Robert Olsson <[EMAIL PROTECTED]>
Date: Thu, 22 Dec 2005 10:51:46 +0100
> @@ -219,28 +230,27 @@
> if (rta[RTA_FLOW-1])
> memcpy(&new_r->r_tclassid, RTA_DATA(rta[RTA_FLOW-1]), 4);
> #endif
> -
> - rp = &fib_rules;
> + r = (struct fib_rule *) fib_rules.first;
>
Hi All,
How can i change the size of TCP prequeue? "netstat -s" output
indicates that packets are being dropped from prequeue.
Thanks in advance.
-
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.k
On Wed, Jan 25, 2006 at 08:12:02PM +, Eric W. Biederman wrote:
>
> Unfortunately because we have already call rt6_ifdown() the route is
> not found in the routing table, the dst_free does not decrement the
> count and is therefore unable to free the dst entry because the count
> is still elevat
Stephen Hemminger wrote:
The sky2 driver attempts to clear PCI express errors on boot, but
the PCI subsystem sometimes won't let the sky2 driver write to PCI
express registers. It depends on the phase of the moon
and number of goats sacrificed (actually it probably is ACPI).
Until the PCI subs
Arnaldo Carvalho de Melo wrote:
Hi Jeff,
Please apply:
Make phy 0 actually be read, as it is not being right now as we have:
int mii_status = mdio_read(dev, phy, MII_BMSR);
int phyx = phy & 0x1f;
When we should have instead:
int phyx = p
Simon Barber wrote:
In order to get FCC certification the manufacturer must ensure there is
no easy way for the user to tune to illegal frequencies. Broadcom has
done their job - it was not easy to reverse engineer their driver. Now
the cat is out of the bag. The open source driver is not illegal
John W. Linville wrote:
On Thu, Jan 26, 2006 at 11:58:17AM -0800, Ben Greear wrote:
David Hollis wrote:
I don't know the details of the Atheros chip to
know if it might be possible to generate a firmware that users would
have to install in /lib/firmware and let the driver load it up. If so
Ben Greear wrote:
Michael Buesch wrote:
On Friday 27 January 2006 00:10, you wrote:
No doubt. It also may be illegal (IANAL) to provide an open-source
HAL in the US due to FCC restrictions because it gives users
an easy way to screw up frequencies not legally available to
them. That seems
[1]Summary of the problem:
ip_options_fragment() has no effect on fragmentation
[2]Full description of the problem:
When I send IPv4 packet(contain Record Route Option) which need to be
fragmented to the router, the router can not fragment it correctly.
After fragmented by router, the second frag
On Thu, Jan 26, 2006 at 03:25:17PM +0100, Patrick McHardy wrote:
>
> [IPV4]: Always set fl.proto in ip_route_newports
>
> ip_route_newports uses the struct flowi from the struct rtable returned
> by ip_route_connect for the new route lookup and just replaces the port
> numbers if they have changed
On Friday 27 January 2006 01:04, you wrote:
> In order to get FCC certification the manufacturer must ensure there is
> no easy way for the user to tune to illegal frequencies. Broadcom has
> done their job - it was not easy to reverse engineer their driver. Now
> the cat is out of the bag. The ope
In order to get FCC certification the manufacturer must ensure there is
no easy way for the user to tune to illegal frequencies. Broadcom has
done their job - it was not easy to reverse engineer their driver. Now
the cat is out of the bag. The open source driver is not illegal -
although it may be
Cum 27 Oca 2006 01:45 tarihinde, Michael Buesch şunları yazmıştı:
> On Friday 27 January 2006 00:10, you wrote:
> > Michael Buesch wrote:
> > > On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote:
> > >>If someone has a reverse-engineered HAL that might could
> > >>be used as well.
> > >
> > > Fro
Michael Buesch wrote:
On Friday 27 January 2006 00:10, you wrote:
No doubt. It also may be illegal (IANAL) to provide an open-source
HAL in the US due to FCC restrictions because it gives users
an easy way to screw up frequencies not legally available to
them. That seems to be the primary r
On Friday 27 January 2006 00:10, you wrote:
> Michael Buesch wrote:
> > On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote:
> >
> >>If someone has a reverse-engineered HAL that might could
> >>be used as well.
> >
> >
> > From a quick look at the HAL asm code (mips-le), I think
> > symbol names
On Thu, Jan 26, 2006 at 03:05:54PM -0800, Stephen Hemminger wrote:
> Plan B:
> 1. Use p->br (the back pointer) as the RCU sentinel
> 2. Keep dev->br_port set until after the RCU transition
> 3. Order operations so we don't have to worry about p->br being NULL
>in the case of STP timers.
This s
On Thu, Jan 26, 2006 at 03:01:00PM -0800, Stephen Hemminger wrote:
>
> Well, it was before I changed del_nbp to set dev->br_port to NULL.
> So what br_del_if would get called twice for same port.
Right. I wasn't questioning the zeroing of dev->br_port. I was
just saying that placing a barrier u
Michael Buesch wrote:
On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote:
If someone has a reverse-engineered HAL that might could
be used as well.
From a quick look at the HAL asm code (mips-le), I think
symbol names are obfuscated. So reverse engineering
is Not Easy (tm).
No doubt. It
Plan B:
1. Use p->br (the back pointer) as the RCU sentinel
2. Keep dev->br_port set until after the RCU transition
3. Order operations so we don't have to worry about p->br being NULL
in the case of STP timers.
Untested. Probably excessive use of rcu() macros. Since it is only
needed in cases
> It might be, that arranging a "DEBUG NETLINK socket" to direct to it,
> when enabled, copies of all netlink messages (better to exclude a
> really bulk traffic like netfilter packet log)
That emphasizes the need to know the identity of the source emitting the
packet. I see in RFC3549 :
" Proce
On Fri, 27 Jan 2006 09:29:12 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 27, 2006 at 07:33:24AM +1100, herbert wrote:
> >
> > > That breaks because of the race (found by Xen) where an interface
> > > is being deleted from a bridge and the device is being removed.
> > >
> > > br_de
From: Al Viro <[EMAIL PROTECTED]>
switch to ioremap()
Adrian Bunk:
The order of the hunks in the patch was slightly rearranged due to an
unrelated change in the driver.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/hp-plus.c | 17
From: Al Viro <[EMAIL PROTECTED]>
hp100 has ->mem_ptr_virt set for all memory-mapped cases; removed
rudiment of old version that used ioremap() only when physical
address wasn't an ISA one. These days it's simply a dead code.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk
From: Al Viro <[EMAIL PROTECTED]>
switch to ioremap()
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/lance.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
aadde842b4976445ac101c6ed04986382988d035
diff --git a/driv
From: Al Viro <[EMAIL PROTECTED]>
sanitized probing code, made sure we claim regions before poking into
them (original tried that to some extent, but hadn't got it right),
switched to ioremap() use in probing.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED
On Fri, Jan 27, 2006 at 07:33:24AM +1100, herbert wrote:
>
> > That breaks because of the race (found by Xen) where an interface
> > is being deleted from a bridge and the device is being removed.
> >
> > br_del_if
> > rmmod device
> > netlink ev
On Wed, Jan 11, Jeff Kirsher wrote:
> Added variable to handle return values for pci_enable_* functions
>
> This was to fix compilation warnings. Also added log messages when
> pci_enable_* functions return with an error.
I object to this patch.
Useless error messages for unhandled return val
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global functions:
- name_table.c: tipc_nametbl_print()
- name_table.c: tipc_nametbl_dump()
- net.c: tipc_net_next_node()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote:
> If someone has a reverse-engineered HAL that might could
> be used as well.
From a quick look at the HAL asm code (mips-le), I think
symbol names are obfuscated. So reverse engineering
is Not Easy (tm).
--
Greetings Michael.
pgp14dkWxsSrf.
On Thu, Jan 26, 2006 at 09:41:00AM -0800, Stephen Hemminger wrote:
>
> > > --- br-fix.orig/net/bridge/br_if.c
> > > +++ br-fix/net/bridge/br_if.c
> > > @@ -124,7 +124,7 @@ static void del_nbp(struct net_bridge_po
> > > struct net_bridge *br = p->br;
> > > struct net_device *dev = p->dev;
> > >
John W. Linville wrote:
On Thu, Jan 26, 2006 at 11:58:17AM -0800, Ben Greear wrote:
David Hollis wrote:
I don't know the details of the Atheros chip to
know if it might be possible to generate a firmware that users would
have to install in /lib/firmware and let the driver load it up. If so
Hi,
Sorry for late response, I was trying to find some h/w so as
to retest this before responding. (Which I wasn't able to
find, and so haven't retested yet).
On Thu, Jan 19, 2006 at 05:23:07AM +0100, Andi Kleen was heard to remark:
>
> >
> > +#ifdef XXX_CONFIG_IXGB_EEH_RECOVERY
> > + if(u
On Thu, Jan 26, 2006 at 11:58:17AM -0800, Ben Greear wrote:
> David Hollis wrote:
> >I don't know the details of the Atheros chip to
> >know if it might be possible to generate a firmware that users would
> >have to install in /lib/firmware and let the driver load it up. If so,
> >that would be t
David Hollis wrote:
On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote:
It appears to be the case. It might be technically possible to
hack up madwifi as a module w/out the HAL and force end-users to
download and install the HAL (and taint their kernel) to have a useful
setup. That would go
On Thu, 2006-01-26 at 11:04 -0800, Ben Greear wrote:
>
> It appears to be the case. It might be technically possible to
> hack up madwifi as a module w/out the HAL and force end-users to
> download and install the HAL (and taint their kernel) to have a useful
> setup. That would go against much
On Thu, Jan 26, 2006 at 08:02:37PM +0100, Stefan Seyfried wrote:
> Will be in the next SUSE betas, so if anything breaks, we'll notice
> it.
I doubt it. As Jesse mentioned, e100_hw_init is called from e100_up,
so the call from e100_resume was really superfluous.
Olaf
--
Olaf Kirch | --- o ---
This patch uses alloc_percpu to allocate per-CPU memory for the proto->inuse
field. The inuse field is currently per-CPU as in NR_CPUS * cacheline size --
a big bloat on arches with large cachelines. Also marks some frequently
used protos read mostly.
Signed-off-by: Pravin B. Shelar <[EMAIL PRO
John W. Linville wrote:
On Thu, Jan 26, 2006 at 07:27:08PM +0200, Samuel Ortiz wrote:
On Wed, 25 Jan 2006, ext John W. Linville wrote:
I still have a number of other branches in the wireless-2.6 tree.
I was wondering what's the reason for not having the madwifi stack there
as well. I hav
Add percpu_counter_mod_bh for using these counters safely from
both softirq and process context.
Signed-off by: Pravin B. Shelar <[EMAIL PROTECTED]>
Signed-off by: Ravikiran G Thirumalai <[EMAIL PROTECTED]>
Signed-off by: Shai Fultheim <[EMAIL PROTECTED]>
Index: linux-2.6.16-rc1/include/linux/per
Change struct proto->memory_allocated to a batching per-CPU counter
(percpu_counter) from an atomic_t. A batching counter is better than a
plain per-CPU counter as this field is read often.
Signed-off-by: Pravin B. Shelar <[EMAIL PROTECTED]>
Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED
Change the atomic_t sockets_allocated member of struct proto to a
per-cpu counter.
Signed-off-by: Pravin B. Shelar <[EMAIL PROTECTED]>
Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]>
Signed-off-by: Shai Fultheim <[EMAIL PROTECTED]>
Index: linux-2.6.16-rc1/include/net/sock.h
=
On Wed, Jan 25, 2006 at 04:28:48PM -0800, Jesse Brandeburg wrote:
> Okay I reproduced the issue on 2.6.15.1 (with S1 sleep) and was able
> to show that my patch that just removes e100_init_hw works okay for
> me. Let me know how it goes for you, I think this is a good fix.
worked for me in the
The following patches change struct proto.memory_allocated,
proto.sockets_allocated to use per-cpu counters. This patchset also switches
the proto.inuse percpu varible to use alloc_percpu, instead of NR_CPUS *
cacheline size padding.
We saw 5 % improvement in apache bench requests per second with
On Thu, Jan 26, 2006 at 07:27:08PM +0200, Samuel Ortiz wrote:
> On Wed, 25 Jan 2006, ext John W. Linville wrote:
>
> > I still have a number of other branches in the wireless-2.6 tree.
> I was wondering what's the reason for not having the madwifi stack there
> as well. I haven't seen anyone send
On Thu, 26 Jan 2006 19:45:06 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 23, 2006 at 12:05:26PM -0800, Stephen Hemminger wrote:
> > Use RCU macro's to ensure barrier safety on the bridge
> > receive path.
>
> Thanks for working on this Stephen.
>
> > --- br-fix.orig/net/bridge/br_i
Hi John,
On Wed, 25 Jan 2006, ext John W. Linville wrote:
> I still have a number of other branches in the wireless-2.6 tree.
> I am using those branches to collect out of stream drivers and
> developments such as the softmac code and the alternative 802.11
> stack from Devicescape.
I was wonderi
Probably, the caller should not set RTF_EXPIRES when allocating
new one. Instead, set rt6i_expires and RTF_EXPIRES afterwards
(as your patch does).
It makes sense.
And, please make your patch so that we can apply it by "patch -p1"
at the top directory of the tree; e.g.
% diff -u linux-2.6.1
Marco Berizzi wrote:
>
> Patrick McHardy wrote:
>
>> Marco Berizzi wrote:
>> > I would like to deploy dhcp over ipsec with openswan
>> > 2.4.x running on linux 2.6.15.1. To achieve this
>> > solution I need dhcp relay agent running on the ipsec
>> > gateway box (there will be also the dhcp server
Patrick McHardy wrote:
Marco Berizzi wrote:
> I would like to deploy dhcp over ipsec with openswan
> 2.4.x running on linux 2.6.15.1. To achieve this
> solution I need dhcp relay agent running on the ipsec
> gateway box (there will be also the dhcp server on the
> same box). I'm using the nativ
In article <[EMAIL PROTECTED]> (at Thu, 26 Jan 2006 16:35:08 +0100),
Jean-Mickael Guerin <[EMAIL PROTECTED]> says:
> Following patch drops this flag. As you can see, it requires to set the
> flag back to RTF_EXPIRES in ndisc_router_discovery(), because
> rt6_add_dflt_router() asks a new route w
When adding a route, expiration attribute may be 0. In my understanding,
it means the route never expires and rt6i_expires should be 0, and not
the current time. If right, attached patch should fix the issue.
Well, please drop RTF_EXPIRES also. Thanks.
Following patch drops this flag. As y
On Thu, Jan 26, 2006 at 01:04:37AM +0300, Al Boldi wrote:
> Ed L. Cashin wrote:
> > This patch is a bugfix that follows and depends on the
> > eight aoe driver patches sent January 19th.
>
> Will they also fix this?
> Or is this an md bug?
No, this patch fixes a bug that would cause an AoE device
This fixes the accounting in H-TCP, the ccount variable is also adjusted
a few lines above this one.
This line was not supposed to be there and wasn't there in the patches
originally submitted, the four patches submitted were merged to one and
in that merge the bug was introduced.
Signed-Off-By:
Jesse Brandeburg wrote:
> On Mon, 23 Jan 2006, Ingo Oeser wrote:
> > Jeff Kirsher wrote:
> > > These functions help restore the driver to active configuration when
> > > coming out of resume for
> > power management.
> >
> > Shouldn't this problem be fixed in the PCI layer of Linux?
> >
> > PS:
Patrick McHardy wrote:
> [IPV4]: Always set fl.proto in ip_route_newports
>
> ip_route_newports uses the struct flowi from the struct rtable returned
> by ip_route_connect for the new route lookup and just replaces the port
> numbers if they have changed. If an IPsec policy exists which doesn't ma
Please pull Steve's git repository from
http://git.kernel.org/pub/scm/linux/kernel/git/steve/decnet-2.6.17.git
diffstat:
include/linux/dn.h | 44 -
include/net/dn.h | 105 -
include/net/dn_dev.h | 8
Fix xfrm lookup in ip_route_newports for a very special case.
IPv6 needs a similar fix, it doesn't reroute at all after
selecting new ports, I'll send a patch for that soon.
[IPV4]: Always set fl.proto in ip_route_newports
ip_route_newports uses the struct flowi from the struct rtable returned
by
Hi Mathieu,
>Here is a patch that add a netlink virtual interface.
>Through a hook in af_netlink.c every packets are duplicated and sent to
>that interface. Thus userspace sniffers can capture them.
> >Security people will cry, but sometimes we need good troubleshooting
> >means in userland.
>Ye
On Wed, Jan 25, 2006 at 04:28:44PM -0800, Stephen Hemminger wrote:
> Mostly a collection of bug fixes. The most critical is the pci express
> fix. Also adds Message Signaled Interrupt and entropy support.
Patches seemed to be mangled. Actually having a "version I want
people to test" tarball would
Marco Berizzi wrote:
> I would like to deploy dhcp over ipsec with openswan
> 2.4.x running on linux 2.6.15.1. To achieve this
> solution I need dhcp relay agent running on the ipsec
> gateway box (there will be also the dhcp server on the
> same box). I'm using the native linux 2.6 ipsec (no
> KLI
I would like to deploy dhcp over ipsec with openswan
2.4.x running on linux 2.6.15.1. To achieve this
solution I need dhcp relay agent running on the ipsec
gateway box (there will be also the dhcp server on the
same box). I'm using the native linux 2.6 ipsec (no
KLIPS) so there is no virtual devic
Hi all,
I work with the fec driver (used with embedded linuxes), and I am not very
satisfied of the behaviour regarding link down / link up.
So here are my questions :
1. When/where should netif_carrierr_on/off or another similar routine
be called ?
2. If the above are called properly, will t
On Wednesday 25 January 2006 17:44, Stuffed Crust wrote:
> On Mon, Jan 23, 2006 at 03:32:32PM +0100, Johannes Berg wrote:
> > Shouldn't you BSS-filter management packets too?
>
> Filtering on BSSID is necessary for management frames, especially when
> multicast management frames are thrown into t
On St 25-01-06 16:28:48, Jesse Brandeburg wrote:
> On 1/25/06, Jesse Brandeburg <[EMAIL PROTECTED]> wrote:
> > On 1/25/06, Olaf Kirch <[EMAIL PROTECTED]> wrote:
> > > On Wed, Jan 25, 2006 at 10:02:40AM +0100, Olaf Kirch wrote:
> > > > I'm not sure what the right fix would be. e100_resume would prob
On Mon, Jan 23, 2006 at 12:05:26PM -0800, Stephen Hemminger wrote:
> Use RCU macro's to ensure barrier safety on the bridge
> receive path.
Thanks for working on this Stephen.
> --- br-fix.orig/net/bridge/br_if.c
> +++ br-fix/net/bridge/br_if.c
> @@ -124,7 +124,7 @@ static void del_nbp(struct net
68 matches
Mail list logo
