* Re: [PATCH][XFRM]: Fix statistics.
From: David Miller @ 2008-02-01 1:15 UTC (permalink / raw)
To: nakam; +Cc: herbert, netdev
In-Reply-To: <12017657921885-git-send-email-nakam@linux-ipv6.org>
From: Masahide NAKAMURA <nakam@linux-ipv6.org>
Date: Thu, 31 Jan 2008 16:49:52 +0900
> [PATCH][XFRM]: Fix statistics.
>
> o Outbound sequence number overflow error status
> is counted as XfrmOutStateSeqError.
> o Additionaly, it changes inbound sequence number replay
> error name from XfrmInSeqOutOfWindow to XfrmInStateSeqError
> to apply name scheme above.
> o Inbound IPv4 UDP encapsuling type mismatch error is wrongly
> mapped to XfrmInStateInvalid then this patch fiex the error
> to XfrmInStateMismatch.
>
> Signed-off-by: Masahide NAKAMURA <nakam@linux-ipv6.org>
Applied, thank you.
^ permalink raw reply
* Re: [2.6 patch] net/xfrm/: remove unused exports
From: David Miller @ 2008-02-01 1:10 UTC (permalink / raw)
To: bunk; +Cc: herbert, paul.moore, netdev
In-Reply-To: <20080130200221.GR29368@does.not.exist>
From: Adrian Bunk <bunk@kernel.org>
Date: Wed, 30 Jan 2008 22:02:21 +0200
> This patch removes the following no longer used EXPORT_SYMBOL's:
> - xfrm_input.c: xfrm_parse_spi
> - xfrm_state.c: xfrm_replay_check
> - xfrm_state.c: xfrm_replay_advance
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Applied.
^ permalink raw reply
* Re: [PATCH][net/sched/sch_teql.c] duplicate IFF_BROADCAST in FMASK, remove 2nd
From: David Miller @ 2008-02-01 1:08 UTC (permalink / raw)
To: 12o3l; +Cc: netdev, linux-kernel
In-Reply-To: <47A08B7C.9010205@tiscali.nl>
From: Roel Kluin <12o3l@tiscali.nl>
Date: Wed, 30 Jan 2008 15:36:44 +0100
> Untested patch below, please confirm it's the right fix (should it be some
> other IFF_*?)
> --
> duplicate IFF_BROADCAST, remove 2nd
>
> Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Andy Furniss @ 2008-02-01 1:04 UTC (permalink / raw)
To: Rick Jones; +Cc: Andi Kleen, netdev, davem
In-Reply-To: <47A21E1A.6000006@hp.com>
Rick Jones wrote:
> then the qdisc could/should place a cap on the size of a 'TSO' based on
> the bitrate (and perhaps input as to how much time any one "burst" of
> data should be allowed to consume on the network) and pass that up the
> stack? right now you seem to be proposing what is effectively a cap of
> 1 MSS.
I don't have any gig nics to test, so this is not a rhetorical question.
How does tcp congestion control behave when a tc qdisc drops a big
unsegmented TSO skb?
Andy.
^ permalink raw reply
* Re: [drivers/net/bnx2.c] ADVERTISE_1000XPSE_ASYM
From: David Miller @ 2008-02-01 1:07 UTC (permalink / raw)
To: mchan; +Cc: 12o3l, linux-kernel, netdev
In-Reply-To: <1201719070.7190.4.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 30 Jan 2008 10:51:10 -0800
> [BNX2]: Fix ASYM PAUSE advertisement for remote PHY.
>
> We were checking for the ASYM_PAUSE bit for 1000Base-X twice instead
> checking for both the 1000Base-X bit and the 10/100/1000Base-T bit.
> The purpose of the logic is to tell the firmware that ASYM_PAUSE is
> set on either the Serdes or Copper interface.
>
> Problem was discovered by Roel Kluin <12o3l@tiscali.nl>
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied, thanks Michael.
^ permalink raw reply
* Re: [IPV4] route cache: Introduce rt_genid for smooth cache invalidation
From: David Miller @ 2008-02-01 1:05 UTC (permalink / raw)
To: dada1; +Cc: netdev, Robert.Olsson
In-Reply-To: <47A03098.7060100@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Wed, 30 Jan 2008 09:08:56 +0100
> Current ip route cache implementation is not suited to large caches.
>
> We can consume a lot of CPU when cache must be invalidated, since we
> currently need to evict all cache entries, and this eviction is
> sometimes asynchronous. min_delay & max_delay can somewhat control this
> asynchronism behavior, but whole thing is a kludge, regularly triggering
> infamous soft lockup messages. When entries are still in use, this also
> consumes a lot of ram, filling dst_garbage.list.
>
> A better scheme is to use a generation identifier on each entry,
> so that cache invalidation can be performed by changing the table
> identifier, without having to scan all entries.
> No more delayed flushing, no more stalling when secret_interval expires.
>
> Invalidated entries will then be freed at GC time (controled by
> ip_rt_gc_timeout or stress), or when an invalidated entry is found
> in a chain when an insert is done.
> Thus we keep a normal equilibrium.
>
> This patch :
> - renames rt_hash_rnd to rt_genid (and makes it an atomic_t)
> - Adds a new rt_genid field to 'struct rtable' (filling a hole on 64bit)
> - Checks entry->rt_genid at appropriate places :
> --- Readers have to ignore invalidated entries.
> --- Writers can delete invalidated entries.
> - Removes rt_flush_timer timer
> - Removes unused /proc/sys/net/ipv4/{min_delay,max_delay}
>
> We even reduce size of route.o
>
> # size net/ipv4/route.o
> text data bss dec hex filename
> 20038 1331 160 21529 5419 net/ipv4/route.o.before
> 19991 1203 104 21298 5332 net/ipv4/route.o
>
> Next step will be to audit all rt_cache_flush(0) (aka flushes) users, see
> if they can be converted to "invalidate the cache" users.
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
This looks really nice, applied, thanks Eric.
^ permalink raw reply
* Re: [1/2] POHMELFS - network filesystem with local coherent cache.
From: Jan Engelhardt @ 2008-02-01 1:04 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: linux-kernel, netdev, linux-fsdevel
In-Reply-To: <11972872493911@2ka.mipt.ru>
On Jan 31 2008 22:17, Evgeniy Polyakov wrote:
>
>POHMELFS stands for Parallel Optimized Host Message Exchange
>Layered File System. It allows to mount remote servers to local
>directory via network. This filesystem supports local caching
>and writeback flushing.
>POHMELFS is a brick in a future distributed filesystem.
A brick is usually something that is in the way -
Or you also say "the user has bricked his machine"
when it's quite unusable :)
Hope you did not mean /that/.
>This set includes two patches:
> * network filesystem with write-through cache (slow, but works with
> remote userspace server)
> * hack to show how local cache works and how faster it is compared
> to async NFS (see below). hack disables writeback flush and
> performs local allocation of the objects only.
>
>Now, some vaporware aka food for thoughts and your brains.
>
>A small benchmark of the local cached mode (above hack):
>
>$ time tar -xf /home/zbr/threading.tar
>
> POHMELFS NFS v3 (async)
>real 0m0.043s 0m1.679s
>
>Which is damn 40 times!
Needs a bigger data set to compare. But what is much more
important: does it use a single port for networing, or some
firewall-unfriendly-by-default multiple dynamic-port-allocation
like NFS?
>Next task is to think about how to generically solve the problem with
>syncing local changes with remote server, when remote server maintains inodes with
>completely different numbers.
>This, among others, will allow offline work with automatic syncing after reconnect.
What will happen when both nodes change an inode in disconnected state?
Which inode wins out?
>This is not intended for inclusion, CRFS by Zach Brown is a bit ahead of POHMELFS,
>but it is not generic enough (because of above problem), works only with BTRFS,
>and was closed by Oracle so far :)
btrfs is all we need :p
Where's the parallelism that is advertised by the "POH" in pohmelfs?
^ permalink raw reply
* Re: [PATCH] pktgen: pktgen should not print info that it is spinning
From: David Miller @ 2008-02-01 1:00 UTC (permalink / raw)
To: jesse.brandeburg; +Cc: netdev, auke-jan.h.kok, Robert.Olsson
In-Reply-To: <20080128211635.5907.81831.stgit@jbrandeb-ich9b.jf.intel.com>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Mon, 28 Jan 2008 13:16:35 -0800
> when using pktgen to send delay packets the module prints repeatedly to the
> kernel log:
> sleeping for X
> sleeping for X
> ...
>
> This is probably just a debugging item left in and should not be enabled for
> regular use of the module.
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [NET_SCHED]: sch_ingress: remove netfilter support
From: David Miller @ 2008-02-01 0:57 UTC (permalink / raw)
To: kaber; +Cc: hadi, netdev
In-Reply-To: <479F460B.2060104@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 29 Jan 2008 16:28:11 +0100
> [NET_SCHED]: sch_ingress: remove netfilter support
>
> Since the old policer code is gone, TC actions are needed for policing.
> The ingress qdisc can get packets directly from netif_receive_skb()
> in case TC actions are enabled or through netfilter otherwise, but
> since without TC actions there is no policer the only thing it actually
> does is count packets.
>
> Remove the netfilter support and always require TC actions.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25] [MACVLAN] Setting macvlan_handle_frame_hook to NULL when rtnl_link_register() fails.
From: David Miller @ 2008-02-01 0:56 UTC (permalink / raw)
To: kaber; +Cc: ramirose, netdev
In-Reply-To: <479F43E8.4010107@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 29 Jan 2008 16:19:04 +0100
> Rami Rosen wrote:
> > Hi,
> > In drivers/net/macvlan.c, when rtnl_link_register() fails
> > in macvlan_init_module(), there is no point to set it (second time in this
> > method) to macvlan_handle_frame; macvlan_init_module() will return a negative
> > number, so instead this patch sets macvlan_handle_frame_hook to NULL.
>
>
> Indeed, that seems to be a stupid cut-and-paste error. Thanks for
> catching this.
>
> Dave, please apply.
Done.
^ permalink raw reply
* Re: [VLAN]: set_rx_mode support for unicast address list
From: David Miller @ 2008-02-01 0:54 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <479F41BF.6050004@trash.net>
Applied.
^ permalink raw reply
* Re: [PATCH] TCP:Fix a bug in strategy_allowed_congestion_control
From: David Miller @ 2008-02-01 0:47 UTC (permalink / raw)
To: shanwei; +Cc: shemminger, netdev, sjansen
In-Reply-To: <479D386F.5030805@cn.fujitsu.com>
From: shanwei <shanwei@cn.fujitsu.com>
Date: Mon, 28 Jan 2008 10:05:35 +0800
> Stephen Hemminger 写道:
> > On Fri, 25 Jan 2008 15:10:13 +0800
> > shanwei <shanwei@cn.fujitsu.com> wrote:
> >
> >> hi all:
> >>
> >> In strategy_allowed_congestion_control of the 2.6.24 kernel,
> >> when sysctl_string return 1 on success,it should call
> >> tcp_set_allowed_congestion_control to set the allowed congestion
> >> control.But, it don't.
> >> the sysctl_string return 1 on success, otherwise return negative,
> >> never return 0.The patch fix the problem.
> >>
> >> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
> >>
> >> diff -Nuarp linux-2.6.24/net/ipv4/sysctl_net_ipv4.c linux-2.6.24-new/net/ipv4/sysctl_net_ipv4.c
> >> --- linux-2.6.24/net/ipv4/sysctl_net_ipv4.c 2008-01-25 06:58:37.000000000 +0800
> >> +++ linux-2.6.24-new/net/ipv4/sysctl_net_ipv4.c 2008-01-25 12:23:20.000000000 +0800
> >> @@ -248,7 +248,7 @@ static int strategy_allowed_congestion_c
> >>
> >> tcp_get_available_congestion_control(tbl.data, tbl.maxlen);
> >> ret = sysctl_string(&tbl, name, nlen, oldval, oldlenp, newval, newlen);
> >> - if (ret == 0 && newval && newlen)
> >> + if (ret == 1 && newval && newlen)
> >> ret = tcp_set_allowed_congestion_control(tbl.data);
> >> kfree(tbl.data);
> >>
> >>
> >
> > Acked-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > This parallels previous fix by Sam Jansen.
> >
> >
> >From the link:http://marc.info/?l=linux-netdev&m=119551836927062&w=2,
> he only fix the sysctl_tcp_congestion_control function.
> In the latest kernel, the sysctl_string problem is present.
> Can this patch be applied?
Done.
^ permalink raw reply
* Re: [PATCH] fib_trie: rescan if key is lost during dump
From: David Miller @ 2008-02-01 0:45 UTC (permalink / raw)
To: shemminger; +Cc: kaber, netdev
In-Reply-To: <20080124135112.32b5c1c7@deepthought>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Thu, 24 Jan 2008 13:51:12 -0800
> Normally during a dump the key of the last dumped entry is used for
> continuation, but since lock is dropped it might be lost. In that case
> fallback to the old counter based N^2 behaviour. This means the dump will end up
> skipping some routes which matches what FIB_HASH does.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6.25] [PKTGEN] Remove an unused definition in pktgen.c.
From: David Miller @ 2008-02-01 0:43 UTC (permalink / raw)
To: ramirose; +Cc: netdev
In-Reply-To: <eb3ff54b0801230638j4e0ece76sf0a2592477050fee@mail.gmail.com>
From: "Rami Rosen" <ramirose@gmail.com>
Date: Wed, 23 Jan 2008 16:38:09 +0200
> Hi,
> - Remove an unused definition (LAT_BUCKETS_MAX) in net/core/pktgen.c.
> - Remove the corresponding comment.
> - The LAT_BUCKETS_MAX seems to have to do with a patch from a long
> time ago which was not applied (Ben Greear), which dealt with latency
> counters.
>
> See, for example : http://oss.sgi.com/archives/netdev/2002-09/msg00184.html
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: update MSS even if MTU is unchanged
From: David Miller @ 2008-02-01 0:37 UTC (permalink / raw)
To: jim; +Cc: netdev
In-Reply-To: <20080121220248.GA25284@jim.sh>
From: Jim Paris <jim@jtan.com>
Date: Mon, 21 Jan 2008 17:02:48 -0500
> This is needed because in ndisc.c, we have:
>
> static void ndisc_router_discovery(struct sk_buff *skb)
> {
> // ...
> if (ndopts.nd_opts_mtu) {
> // ...
> if (rt)
> rt->u.dst.metrics[RTAX_MTU-1] = mtu;
>
> rt6_mtu_change(skb->dev, mtu);
> // ...
> }
>
> Since the mtu is set directly here, rt6_mtu_change_route thinks that
> it is unchanged, and so it fails to update the MSS accordingly. This
> patch lets rt6_mtu_change_route still update MSS if old_mtu == new_mtu.
>
> Signed-off-by: Jim Paris <jim@jtan.com>
This seems ok, patch applied, thanks.
^ permalink raw reply
* Re: [PATCH] e1000e: tweak irq allocation messages
From: Kok, Auke @ 2008-01-31 23:54 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, auke-jan.h.kok
In-Reply-To: <20080131230620.GC856@gospo.usersys.redhat.com>
Andy Gospodarek wrote:
> (Reposted with the version I intended -- added ',' so it compiles!)
>
> There's too much noise on systems that don't support MSI. Let's get rid
> of a few and make the real error message more specific.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
thanks Andy, I'll post this to Jeff,
Auke
> ---
>
> netdev.c | 12 +++++-------
> 1 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
> index 0a2cb79..0c8cd1c 100644
> --- a/drivers/net/e1000e/netdev.c
> +++ b/drivers/net/e1000e/netdev.c
> @@ -945,11 +945,7 @@ static int e1000_request_irq(struct e1000_adapter *adapter)
> int irq_flags = IRQF_SHARED;
> int err;
>
> - err = pci_enable_msi(adapter->pdev);
> - if (err) {
> - ndev_warn(netdev,
> - "Unable to allocate MSI interrupt Error: %d\n", err);
> - } else {
> + if (!pci_enable_msi(adapter->pdev)) {
> adapter->flags |= FLAG_MSI_ENABLED;
> handler = e1000_intr_msi;
> irq_flags = 0;
> @@ -958,10 +954,12 @@ static int e1000_request_irq(struct e1000_adapter *adapter)
> err = request_irq(adapter->pdev->irq, handler, irq_flags, netdev->name,
> netdev);
> if (err) {
> + ndev_err(netdev,
> + "Unable to allocate %s interrupt (return: %d)\n",
> + adapter->flags & FLAG_MSI_ENABLED ? "MSI":"INTx",
> + err);
> if (adapter->flags & FLAG_MSI_ENABLED)
> pci_disable_msi(adapter->pdev);
> - ndev_err(netdev,
> - "Unable to allocate interrupt Error: %d\n", err);
> }
>
> return err;
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH] Disable TSO for non standard qdiscs
From: Waskiewicz Jr, Peter P @ 2008-01-31 23:42 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Andi Kleen, Patrick McHardy, Stephen Hemminger, netdev
In-Reply-To: <20080131231045.GA5543@ghostprotocols.net>
> Well, it could be just that when using such qdiscs TSO would be
> disabled, but the user could override this by using ethtool after
> loading the qdiscs.
I still disagree with this. The qdisc should not cause anything to happen to feature flags on the device. It's the scheduling layer and really shouldn't care about what features the device supports or not. If someone has an issue with a feature hurting performance or causing odd behavior when using a qdisc, then they should disable the feature on the device using the appropriate tools provided. If it's the qdisc causing issues, then either the qdisc needs to be fixed, or it should be documented what features are recommended to be on and off with the qdisc. I don't agree that the scheduling layer should affect features on an underlying device.
Cheers,
-PJ Waskiewicz
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Arnaldo Carvalho de Melo @ 2008-01-31 23:10 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P
Cc: Andi Kleen, Patrick McHardy, Stephen Hemminger, netdev
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC32904700F27@orsmsx414.amr.corp.intel.com>
Em Thu, Jan 31, 2008 at 11:39:55AM -0800, Waskiewicz Jr, Peter P escreveu:
> > The philosophical problem I have with this suggestion is that
> > I expect that the large majority of users will be more happy
> > with disabled TSO if they use non standard qdiscs and
> > defaults that do not fit the majority use case are bad.
> >
> > Basically you're suggesting that nearly everyone using tc
> > should learn about another obscure command.
>
> If someone is using tc to load and configure a qdisc, I'd really hope
> knowing or learning ethtool wouldn't be a stretch for them... And I'm
> not arguing the majority of people will want this or not, but taking
> away the ability to use TSO at the kernel level here without allowing a
> tuneable is making that decision for them, which is wrong IMO.
Well, it could be just that when using such qdiscs TSO would be
disabled, but the user could override this by using ethtool after
loading the qdiscs.
- Arnaldo
^ permalink raw reply
* Re: [PATCH] e1000e: tweak irq allocation messages
From: Andy Gospodarek @ 2008-01-31 23:06 UTC (permalink / raw)
To: netdev, auke-jan.h.kok
In-Reply-To: <20080131225639.GB856@gospo.usersys.redhat.com>
On Thu, Jan 31, 2008 at 05:56:39PM -0500, Andy Gospodarek wrote:
>
> There's too much noise on systems that don't support MSI. Let's get rid
> of the unneeded message and make the real error message more specific.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> ---
>
> netdev.c | 12 +++++-------
> 1 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
> index 0a2cb79..0c8cd1c 100644
> --- a/drivers/net/e1000e/netdev.c
> +++ b/drivers/net/e1000e/netdev.c
> @@ -945,11 +945,7 @@ static int e1000_request_irq(struct e1000_adapter *adapter)
> int irq_flags = IRQF_SHARED;
> int err;
>
> - err = pci_enable_msi(adapter->pdev);
> - if (err) {
> - ndev_warn(netdev,
> - "Unable to allocate MSI interrupt Error: %d\n", err);
> - } else {
> + if (!pci_enable_msi(adapter->pdev)) {
> adapter->flags |= FLAG_MSI_ENABLED;
> handler = e1000_intr_msi;
> irq_flags = 0;
> @@ -958,10 +954,12 @@ static int e1000_request_irq(struct e1000_adapter *adapter)
> err = request_irq(adapter->pdev->irq, handler, irq_flags, netdev->name,
> netdev);
> if (err) {
> + ndev_err(netdev,
> + "Unable to allocate %s interrupt (return: %d)\n",
> + adapter->flags & FLAG_MSI_ENABLED ? "MSI":"INTx"
> + err);
> if (adapter->flags & FLAG_MSI_ENABLED)
> pci_disable_msi(adapter->pdev);
> - ndev_err(netdev,
> - "Unable to allocate interrupt Error: %d\n", err);
> }
>
> return err;
(Reposted with the version I intended -- added ',' so it compiles!)
There's too much noise on systems that don't support MSI. Let's get rid
of a few and make the real error message more specific.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
---
netdev.c | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 0a2cb79..0c8cd1c 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -945,11 +945,7 @@ static int e1000_request_irq(struct e1000_adapter *adapter)
int irq_flags = IRQF_SHARED;
int err;
- err = pci_enable_msi(adapter->pdev);
- if (err) {
- ndev_warn(netdev,
- "Unable to allocate MSI interrupt Error: %d\n", err);
- } else {
+ if (!pci_enable_msi(adapter->pdev)) {
adapter->flags |= FLAG_MSI_ENABLED;
handler = e1000_intr_msi;
irq_flags = 0;
@@ -958,10 +954,12 @@ static int e1000_request_irq(struct e1000_adapter *adapter)
err = request_irq(adapter->pdev->irq, handler, irq_flags, netdev->name,
netdev);
if (err) {
+ ndev_err(netdev,
+ "Unable to allocate %s interrupt (return: %d)\n",
+ adapter->flags & FLAG_MSI_ENABLED ? "MSI":"INTx",
+ err);
if (adapter->flags & FLAG_MSI_ENABLED)
pci_disable_msi(adapter->pdev);
- ndev_err(netdev,
- "Unable to allocate interrupt Error: %d\n", err);
}
return err;
^ permalink raw reply related
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Jarek Poplawski @ 2008-01-31 23:04 UTC (permalink / raw)
Cc: Andi Kleen, Waskiewicz Jr, Peter P, Patrick McHardy,
Stephen Hemminger, netdev
In-Reply-To: <47A230A8.7080100@gmail.com>
Jarek Poplawski wrote, On 01/31/2008 09:33 PM:
> Andi Kleen wrote, On 01/31/2008 08:34 PM
...
>> Basically you're suggesting that nearly everyone using tc should learn about
>> another obscure command
...On the other hand, with this DSL argument from the sub-thread you
could be quite right: if this "everyone" wants to use one NIC for
both high speed local network and such a DSL, then learning ethtool
could be not enough...
Jarek P.
^ permalink raw reply
* [PATCH] e1000e: tweak irq allocation messages
From: Andy Gospodarek @ 2008-01-31 22:56 UTC (permalink / raw)
To: netdev; +Cc: auke-jan.h.kok
There's too much noise on systems that don't support MSI. Let's get rid
of the unneeded message and make the real error message more specific.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
---
netdev.c | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 0a2cb79..0c8cd1c 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -945,11 +945,7 @@ static int e1000_request_irq(struct e1000_adapter *adapter)
int irq_flags = IRQF_SHARED;
int err;
- err = pci_enable_msi(adapter->pdev);
- if (err) {
- ndev_warn(netdev,
- "Unable to allocate MSI interrupt Error: %d\n", err);
- } else {
+ if (!pci_enable_msi(adapter->pdev)) {
adapter->flags |= FLAG_MSI_ENABLED;
handler = e1000_intr_msi;
irq_flags = 0;
@@ -958,10 +954,12 @@ static int e1000_request_irq(struct e1000_adapter *adapter)
err = request_irq(adapter->pdev->irq, handler, irq_flags, netdev->name,
netdev);
if (err) {
+ ndev_err(netdev,
+ "Unable to allocate %s interrupt (return: %d)\n",
+ adapter->flags & FLAG_MSI_ENABLED ? "MSI":"INTx"
+ err);
if (adapter->flags & FLAG_MSI_ENABLED)
pci_disable_msi(adapter->pdev);
- ndev_err(netdev,
- "Unable to allocate interrupt Error: %d\n", err);
}
return err;
^ permalink raw reply related
* Re: Null pointer dereference in bonding driver, kernel 2.6.24
From: Jay Vosburgh @ 2008-01-31 22:55 UTC (permalink / raw)
To: Chuck Ebbert; +Cc: Netdev
In-Reply-To: <47A24D65.2000001@redhat.com>
Chuck Ebbert <cebbert@redhat.com> wrote:
>In bond_main.c:
>
>int bond_create(char *name, struct bond_params *params, struct bonding **newbond)
>{
>...
> /* Check to see if the bond already exists. */
> list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list)
> if (strnicmp(bond->dev->name, name, IFNAMSIZ) == 0) {
> printk(KERN_ERR DRV_NAME
> ": cannot add bond %s; it already exists\n",
>
>
>If 'name' is null we get a null dereference in strnicmp()
>
>The code was added in 2.6.24.
This is already fixed in netdev-2.6#upstream.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Null pointer dereference in bonding driver, kernel 2.6.24
From: Chuck Ebbert @ 2008-01-31 22:36 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Netdev
In bond_main.c:
int bond_create(char *name, struct bond_params *params, struct bonding **newbond)
{
...
/* Check to see if the bond already exists. */
list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list)
if (strnicmp(bond->dev->name, name, IFNAMSIZ) == 0) {
printk(KERN_ERR DRV_NAME
": cannot add bond %s; it already exists\n",
If 'name' is null we get a null dereference in strnicmp()
The code was added in 2.6.24.
Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
---
(not even compile tested)
drivers/net/bonding/bond_main.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
--- linux-2.6.24.noarch.orig/drivers/net/bonding/bond_main.c
+++ linux-2.6.24.noarch/drivers/net/bonding/bond_main.c
@@ -4882,15 +4882,17 @@ int bond_create(char *name, struct bond_
rtnl_lock();
down_write(&bonding_rwsem);
- /* Check to see if the bond already exists. */
- list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list)
- if (strnicmp(bond->dev->name, name, IFNAMSIZ) == 0) {
- printk(KERN_ERR DRV_NAME
- ": cannot add bond %s; it already exists\n",
- name);
- res = -EPERM;
- goto out_rtnl;
- }
+ if (name) {
+ /* Check to see if the bond already exists. */
+ list_for_each_entry_safe(bond, nxt, &bond_dev_list, bond_list)
+ if (strnicmp(bond->dev->name, name, IFNAMSIZ) == 0) {
+ printk(KERN_ERR DRV_NAME
+ ": cannot add bond %s; it already exists\n",
+ name);
+ res = -EPERM;
+ goto out_rtnl;
+ }
+ }
bond_dev = alloc_netdev(sizeof(struct bonding), name ? name : "",
ether_setup);
^ permalink raw reply
* Re: [PATCH 6/6] [TCP]: Reorganize struct tcp_sock to save 16 bytes on 64-bit arch
From: Arnaldo Carvalho de Melo @ 2008-01-31 20:33 UTC (permalink / raw)
To: Eric Dumazet, David S. Miller, netdev, dccp
In-Reply-To: <20080131201720.GE11940@ghostprotocols.net>
Em Thu, Jan 31, 2008 at 06:17:20PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Jan 31, 2008 at 08:57:53PM +0100, Eric Dumazet escreveu:
> > Hum... retrans_out should sit close to packets_out (or lost_out/sacked_out
> > ???), please.
> >
> > 'struct tcp_sock' is very large on 64 bits, so I would prefer to make sure
> > most paths dont need to touch all 24 cache lines (or 25 cache lines).
>
> That is perfectly fine, I'll replace my patch with another, that states
> this beyond doubt.
David, I just removed this patch from my net-2.6 tree, if you are ok
with the others, please pull.
- Arnaldo
^ permalink raw reply
* Re: [PATCH] Disable TSO for non standard qdiscs
From: Jarek Poplawski @ 2008-01-31 20:33 UTC (permalink / raw)
To: Andi Kleen
Cc: Waskiewicz Jr, Peter P, Patrick McHardy, Stephen Hemminger,
netdev
In-Reply-To: <20080131193406.GH4671@one.firstfloor.org>
Andi Kleen wrote, On 01/31/2008 08:34 PM:
>> TSO by nature is bursty. But disabling TSO without the option of having
>> it on or off to me seems to aggressive. If someone is using a qdisc
>> that TSO is interfering with the effectiveness of the traffic shaping,
>> then they should turn off TSO via ethtool on the target device. Some
>
> The philosophical problem I have with this suggestion is that I expect
> that the large majority of users will be more happy with disabled TSO
> if they use non standard qdiscs and defaults that do not fit
> the majority use case are bad.
If you mean the large majority of the large minority of users, who use
non standard qdiscs - I agree - this is really the philosophical problem!
> Basically you're suggesting that nearly everyone using tc should learn about
> another obscure command.
...So, it sounds like tc is used by nearly everyone now...
It seems my distro really isn't up to date:
"Package: iproute
...
Description: Professional tools to control the networking in Linux kernels
This is `iproute', the professional set of tools to control the
networking behavior in kernels 2.2.x and later."
And ethtool doesn't have to be learnt at all: "most friendly distros"
could use this in config or add some graphical wrapper.
Regards,
Jarek P.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox