* Re: [PATCH 4/6 v2] IB: address translation to map IP toIB addresses (GIDs)
From: Roland Dreier @ 2006-03-11 1:14 UTC (permalink / raw)
To: Sean Hefty; +Cc: netdev, linux-kernel, openib-general
In-Reply-To: <ORSMSX401FRaqbC8wSA0000000d@orsmsx401.amr.corp.intel.com>
The ib_addr module depends on CONFIG_INET, because it uses symbols
like arp_tbl, which are only exported if INET is enabled.
I fixed this up by creating a new (non-user-visible) config symbol to
control when ib_addr is built -- I put the following diff on top of
your patch in my tree:
diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
index bdf0891..48c8bb5 100644
--- a/drivers/infiniband/Kconfig
+++ b/drivers/infiniband/Kconfig
@@ -29,6 +29,11 @@ config INFINIBAND_USER_ACCESS
libibverbs, libibcm and a hardware driver library from
<http://www.openib.org>.
+config INFINIBAND_ADDR_TRANS
+ tristate
+ depends on INFINIBAND && INET
+ default y
+
source "drivers/infiniband/hw/mthca/Kconfig"
source "drivers/infiniband/ulp/ipoib/Kconfig"
diff --git a/drivers/infiniband/core/Makefile b/drivers/infiniband/core/Makefile
index 2393e9d..935851d 100644
--- a/drivers/infiniband/core/Makefile
+++ b/drivers/infiniband/core/Makefile
@@ -1,7 +1,8 @@
obj-$(CONFIG_INFINIBAND) += ib_core.o ib_mad.o ib_sa.o \
- ib_cm.o ib_addr.o
+ ib_cm.o
obj-$(CONFIG_INFINIBAND_USER_MAD) += ib_umad.o
obj-$(CONFIG_INFINIBAND_USER_ACCESS) += ib_uverbs.o ib_ucm.o
+obj-$(CONFIG_INFINIBAND_ADDR_TRANS) += ib_addr.o
ib_core-y := packer.o ud_header.o verbs.o sysfs.o \
device.o fmr_pool.o cache.o
^ permalink raw reply related
* Re: [PATCH] orinoco: fix BAP0 offset error after several days of operation
From: Pavel Roskin @ 2006-03-10 23:49 UTC (permalink / raw)
To: Jiri Benc; +Cc: orinoco-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, NetDev
In-Reply-To: <20060309184410.471bfc5e-IhiK2ZEFs2oCVLCxKZUutA@public.gmane.org>
On Thu, 2006-03-09 at 18:44 +0100, Jiri Benc wrote:
> After several days of operation of Netgear MA311 card, the card becomes
> to seek improperly and needs reset. This patch tries to reset the card
> when this situation occurs.
Thanks, applied. I had to move the location closer to the end because
the current sources have more than one place where such failure can be
detected.
The orinoco patch series will be posted as soon as I clean them up and
split some large patches.
--
Regards,
Pavel Roskin
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [2.6 patch] net/decnet/dn_route.c: fix inconsequent NULL checking
From: Adrian Bunk @ 2006-03-10 23:02 UTC (permalink / raw)
To: patrick; +Cc: linux-decnet-user, netdev, linux-kernel
The Coverity checker noted this inconsequent NULL checking in
dnrt_drop().
Since all callers ensure that NULL isn't passed, we can simply remove
the check.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.16-rc5-mm3-full/net/decnet/dn_route.c.old 2006-03-10 23:34:57.000000000 +0100
+++ linux-2.6.16-rc5-mm3-full/net/decnet/dn_route.c 2006-03-10 23:35:08.000000000 +0100
@@ -149,8 +149,7 @@ static inline void dnrt_free(struct dn_r
static inline void dnrt_drop(struct dn_route *rt)
{
- if (rt)
- dst_release(&rt->u.dst);
+ dst_release(&rt->u.dst);
call_rcu_bh(&rt->u.dst.rcu_head, dst_rcu_free);
}
^ permalink raw reply
* Re: [PATCH] IPv6: Cleanups for net/ipv6/addrconf.c (kzalloc, early exit) v2
From: Ingo Oeser @ 2006-03-10 22:34 UTC (permalink / raw)
To: David S. Miller; +Cc: yoshfuji, linux-kernel, netdev
In-Reply-To: <20060310.030258.55767431.davem@davemloft.net>
From: Ingo Oeser <ioe-lkml@rameria.de>
Here are some possible (and trivial) cleanups.
- use kzalloc() where possible
- invert allocation failure test like
if (object) {
/* Rest of function here */
}
to
if (object == NULL)
return NULL;
/* Rest of function here */
Signed-off-by: Ingo Oeser <ioe-lkml@rameria.de>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
Hello Dave,
On Friday, 10. March 2006 12:02, David S. Miller wrote:
> This patch no longer applied cleanly, Ingo can you generate
> a fresh version of your patch against my net-2.6.16 tree?
Done!
I rebased it, but against net-2.6.17, since it did apply cleanly to
net-2.6 and I didn't find the tree for net-2.6.16 as requested.
Hope I got it right :-)
Regards
Ingo Oeser
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 8df9eb9..395b3f8 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -341,84 +341,83 @@ static struct inet6_dev * ipv6_add_dev(s
if (dev->mtu < IPV6_MIN_MTU)
return NULL;
- ndev = kmalloc(sizeof(struct inet6_dev), GFP_KERNEL);
-
- if (ndev) {
- memset(ndev, 0, sizeof(struct inet6_dev));
-
- rwlock_init(&ndev->lock);
- ndev->dev = dev;
- memcpy(&ndev->cnf, &ipv6_devconf_dflt, sizeof(ndev->cnf));
- ndev->cnf.mtu6 = dev->mtu;
- ndev->cnf.sysctl = NULL;
- ndev->nd_parms = neigh_parms_alloc(dev, &nd_tbl);
- if (ndev->nd_parms == NULL) {
- kfree(ndev);
- return NULL;
- }
- /* We refer to the device */
- dev_hold(dev);
+ ndev = kzalloc(sizeof(struct inet6_dev), GFP_KERNEL);
+
+ if (ndev == NULL)
+ return NULL;
+
+ rwlock_init(&ndev->lock);
+ ndev->dev = dev;
+ memcpy(&ndev->cnf, &ipv6_devconf_dflt, sizeof(ndev->cnf));
+ ndev->cnf.mtu6 = dev->mtu;
+ ndev->cnf.sysctl = NULL;
+ ndev->nd_parms = neigh_parms_alloc(dev, &nd_tbl);
+ if (ndev->nd_parms == NULL) {
+ kfree(ndev);
+ return NULL;
+ }
+ /* We refer to the device */
+ dev_hold(dev);
- if (snmp6_alloc_dev(ndev) < 0) {
- ADBG((KERN_WARNING
- "%s(): cannot allocate memory for statistics; dev=%s.\n",
- __FUNCTION__, dev->name));
- neigh_parms_release(&nd_tbl, ndev->nd_parms);
- ndev->dead = 1;
- in6_dev_finish_destroy(ndev);
- return NULL;
- }
+ if (snmp6_alloc_dev(ndev) < 0) {
+ ADBG((KERN_WARNING
+ "%s(): cannot allocate memory for statistics; dev=%s.\n",
+ __FUNCTION__, dev->name));
+ neigh_parms_release(&nd_tbl, ndev->nd_parms);
+ ndev->dead = 1;
+ in6_dev_finish_destroy(ndev);
+ return NULL;
+ }
- if (snmp6_register_dev(ndev) < 0) {
- ADBG((KERN_WARNING
- "%s(): cannot create /proc/net/dev_snmp6/%s\n",
- __FUNCTION__, dev->name));
- neigh_parms_release(&nd_tbl, ndev->nd_parms);
- ndev->dead = 1;
- in6_dev_finish_destroy(ndev);
- return NULL;
- }
+ if (snmp6_register_dev(ndev) < 0) {
+ ADBG((KERN_WARNING
+ "%s(): cannot create /proc/net/dev_snmp6/%s\n",
+ __FUNCTION__, dev->name));
+ neigh_parms_release(&nd_tbl, ndev->nd_parms);
+ ndev->dead = 1;
+ in6_dev_finish_destroy(ndev);
+ return NULL;
+ }
- /* One reference from device. We must do this before
- * we invoke __ipv6_regen_rndid().
- */
- in6_dev_hold(ndev);
+ /* One reference from device. We must do this before
+ * we invoke __ipv6_regen_rndid().
+ */
+ in6_dev_hold(ndev);
#ifdef CONFIG_IPV6_PRIVACY
- init_timer(&ndev->regen_timer);
- ndev->regen_timer.function = ipv6_regen_rndid;
- ndev->regen_timer.data = (unsigned long) ndev;
- if ((dev->flags&IFF_LOOPBACK) ||
- dev->type == ARPHRD_TUNNEL ||
- dev->type == ARPHRD_NONE ||
- dev->type == ARPHRD_SIT) {
- printk(KERN_INFO
- "%s: Disabled Privacy Extensions\n",
- dev->name);
- ndev->cnf.use_tempaddr = -1;
- } else {
- in6_dev_hold(ndev);
- ipv6_regen_rndid((unsigned long) ndev);
- }
+ init_timer(&ndev->regen_timer);
+ ndev->regen_timer.function = ipv6_regen_rndid;
+ ndev->regen_timer.data = (unsigned long) ndev;
+ if ((dev->flags&IFF_LOOPBACK) ||
+ dev->type == ARPHRD_TUNNEL ||
+ dev->type == ARPHRD_NONE ||
+ dev->type == ARPHRD_SIT) {
+ printk(KERN_INFO
+ "%s: Disabled Privacy Extensions\n",
+ dev->name);
+ ndev->cnf.use_tempaddr = -1;
+ } else {
+ in6_dev_hold(ndev);
+ ipv6_regen_rndid((unsigned long) ndev);
+ }
#endif
- if (netif_carrier_ok(dev))
- ndev->if_flags |= IF_READY;
+ if (netif_carrier_ok(dev))
+ ndev->if_flags |= IF_READY;
- write_lock_bh(&addrconf_lock);
- dev->ip6_ptr = ndev;
- write_unlock_bh(&addrconf_lock);
+ write_lock_bh(&addrconf_lock);
+ dev->ip6_ptr = ndev;
+ write_unlock_bh(&addrconf_lock);
- ipv6_mc_init_dev(ndev);
- ndev->tstamp = jiffies;
+ ipv6_mc_init_dev(ndev);
+ ndev->tstamp = jiffies;
#ifdef CONFIG_SYSCTL
- neigh_sysctl_register(dev, ndev->nd_parms, NET_IPV6,
- NET_IPV6_NEIGH, "ipv6",
- &ndisc_ifinfo_sysctl_change,
- NULL);
- addrconf_sysctl_register(ndev, &ndev->cnf);
+ neigh_sysctl_register(dev, ndev->nd_parms, NET_IPV6,
+ NET_IPV6_NEIGH, "ipv6",
+ &ndisc_ifinfo_sysctl_change,
+ NULL);
+ addrconf_sysctl_register(ndev, &ndev->cnf);
#endif
- }
return ndev;
}
@@ -536,7 +535,7 @@ ipv6_add_addr(struct inet6_dev *idev, co
goto out;
}
- ifa = kmalloc(sizeof(struct inet6_ifaddr), GFP_ATOMIC);
+ ifa = kzalloc(sizeof(struct inet6_ifaddr), GFP_ATOMIC);
if (ifa == NULL) {
ADBG(("ipv6_add_addr: malloc failed\n"));
@@ -550,7 +549,6 @@ ipv6_add_addr(struct inet6_dev *idev, co
goto out;
}
- memset(ifa, 0, sizeof(struct inet6_ifaddr));
ipv6_addr_copy(&ifa->addr, addr);
spin_lock_init(&ifa->lock);
@@ -2669,11 +2667,10 @@ static int if6_seq_open(struct inode *in
{
struct seq_file *seq;
int rc = -ENOMEM;
- struct if6_iter_state *s = kmalloc(sizeof(*s), GFP_KERNEL);
+ struct if6_iter_state *s = kzalloc(sizeof(*s), GFP_KERNEL);
if (!s)
goto out;
- memset(s, 0, sizeof(*s));
rc = seq_open(file, &if6_seq_ops);
if (rc)
^ permalink raw reply related
* [2.6 patch] hostap_ap.c:hostap_add_sta(): inconsequent NULL checking
From: Adrian Bunk @ 2006-03-10 19:10 UTC (permalink / raw)
To: jkmaline; +Cc: hostap, netdev, linux-kernel
The Coverity checker spotted this inconsequent NULL checking
(unconditionally dereferencing directly after checking for NULL
isn't a good idea).
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.16-rc5-mm3-full/drivers/net/wireless/hostap/hostap_ap.c.old 2006-03-10 19:30:08.000000000 +0100
+++ linux-2.6.16-rc5-mm3-full/drivers/net/wireless/hostap/hostap_ap.c 2006-03-10 19:30:43.000000000 +0100
@@ -3141,7 +3141,7 @@ int hostap_add_sta(struct ap_data *ap, u
if (ret == 1) {
sta = ap_add_sta(ap, sta_addr);
if (!sta)
- ret = -1;
+ return -1;
sta->flags = WLAN_STA_AUTH | WLAN_STA_ASSOC;
sta->ap = 1;
memset(sta->supported_rates, 0, sizeof(sta->supported_rates));
^ permalink raw reply
* Re: TSO and IPoIB performance degradation
From: Rick Jones @ 2006-03-10 17:44 UTC (permalink / raw)
To: netdev; +Cc: rdreier, linux-kernel, openib-general
In-Reply-To: <20060309.232301.77550306.davem@davemloft.net>
David S. Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Thu, 09 Mar 2006 16:21:05 -0800
>
>
>>well, there are stacks which do "stretch acks" (after a fashion) that
>>make sure when they see packet loss to "do the right thing" wrt sending
>>enough acks to allow cwnds to open again in a timely fashion.
>
>
> Once a loss happens, it's too late to stop doing the stretch ACKs, the
> damage is done already. It is going to take you at least one
> extra RTT to recover from the loss compared to if you were not doing
> stretch ACKs.
I must be dense (entirely possible), but how is that absolute?
If there is no more data in flight after the segment that was lost the
"stretch ACK" stacks with which I'm familiar will generate the
standalone ACK within the deferred ACK interval (50 milliseconds). I
guess that can be the "one extra RTT" However, if there is data in
flight after the point of loss, the immediate ACK upon receipt of out-of
order data kicks in.
> You have to keep giving consistent well spaced ACKs back to the
> receiver in order to recover from loss optimally.
The key there is defining consistent and well spaced. Certainly an ACK
only after a window's-worth of data would not be well spaced, but I
believe that an ACK after more than two full sized frames could indeed
be well-spaced.
> The ACK every 2 full sized frames behavior of TCP is absolutely
> essential.
I don't think it is _quite_ that cut and dried, otherwise, HP-UX and
Solaris, since < 1997 would have had big time problems.
rick jones
^ permalink raw reply
* Re: [UPDATED PATCH] Re: Re: [Patch 7/7] Generic netlink interface (delay accounting)
From: Balbir Singh @ 2006-03-10 16:39 UTC (permalink / raw)
To: jamal; +Cc: Shailabh Nagar, netdev, linux-kernel, lse-tech
In-Reply-To: <1142002433.5298.42.camel@jzny2>
On Fri, Mar 10, 2006 at 09:53:53AM -0500, jamal wrote:
> On Thu, 2006-09-03 at 20:07 +0530, Balbir Singh wrote:
> > Please let us know if we missed something out.
>
> Design still shaky IMO - now that i think i may understand what your end
> goal is.
> Using the principles i described in earlier email, the problem you are
> trying to solve is:
>
> a) shipping of the taskstats from kernel to user-space asynchronously to
> all listeners on multicast channel/group TASKSTATS_LISTEN_GRP
> at the point when some process exits.
> b) responding to queries issued by the user to the kernel for taskstats
> of a particular defined tgid and/or pid combination.
>
> Did i summarize your goals correctly?
Yes, you did.
>
> So lets stat with #b:
> i) the message is multicast; there has to be a user space app registered
> to the multicast group otherwise nothing goes to user space.
> ii) user space issues a GET and it seems to me the appropriate naming
> for the response is a NEW.
>
> Lets go to #a:
> The issued multicast messages are also NEW and no different from the
> ones sent in response to a GET.
>
> Having said that then, you have the following commands:
>
> enum {
> TASKSTATS_CMD_UNSPEC, /* Reserved */
> TASKSTATS_CMD_GET, /* user -> kernel query*/
> TASKSTATS_CMD_NEW, /* kernel -> user update */
> };
>
> You also need the following TLVs
>
> enum {
> TASKSTATS_TYPE_UNSPEC, /* Reserved */
> TASKSTATS_TYPE_TGID, /* The TGID */
> TASKSTATS_TYPE_PID, /* The PID */
> TASKSTATS_TYPE_STATS, /* carries the taskstats */
> TASKSTATS_TYPE_VERS, /* carries the version */
> };
>
> Refer to the doc i passed you and provide feedback if how to use the
> above is not obvious.
>
I will look at the document, just got hold of it.
> The use of TLVs above implies that any of these can be optionally
> appearing.
> So when you are going from user->kernel with a GET a in #a above, then
> you can specify the PID and/or TGID and you dont need to specify the
> STATS and this would be perfectly legal.
>
> On kernel->user (in the case of response to #a or async notifiation as
> in #b) you really dont need to specify the TG/PID since they appear in
> the STATS etc.
I see your point now. I am looking at other users of netlink like
rtnetlink and I see the classical usage.
We can implement TLV's in our code, but for the most part the data we exchange
between the user <-> kernel has all the TLV's listed in the enum above.
The major differnece is the type (pid/tgid). Hence we created a structure
(taskstats) instead of using TLV's.
> I take it you dont want to configure the values of taskstats from user
> space, otherwise user->kernel will send a NEW as well.
Your understanding is correct.
> I also take it dumping doesnt apply to you, so you dont need a dump
> callback in your kernel code.
Yes, this is correct as well.
> >From what i described so far, you dont really need a header for yourself
> either (maybe you need one to just store the VERSION?)
>
True, we do not need a header.
> I didnt understand the point to the err field you had in the reply.
> Netlink already does issue errors which can be read via perror. If this
> is different from what you need, it may be an excuse to have your own
> header.
>
Hmm.. Will look into this.
> I hope this helps.
>
Yes, it does immensely. Thanks for the detailed feedback.
> cheers,
> jamal
>
>
Warm Regards,
Balbir
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: KERNEL: assertion (!sk->sk_forward_alloc) failed
From: Krzysztof Oledzki @ 2006-03-10 15:51 UTC (permalink / raw)
To: David S. Miller
Cc: imcdnzl, bb, jesse.brandeburg, yoseph.basri, linux-kernel, netdev
In-Reply-To: <20060310.025912.107001339.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1036 bytes --]
On Fri, 10 Mar 2006, David S. Miller wrote:
> From: Ian McDonald <imcdnzl@gmail.com>
> Date: Fri, 10 Feb 2006 08:37:48 +1300
>
>> On 2/10/06, Boris B. Zhmurov <bb@kernelpanic.ru> wrote:
>>> Hello, Ian McDonald.
>>>
>>> On 09.02.2006 22:25 you said the following:
>>>
>>>> Is it possible for you to download 2.6.16-rc2 or similar and see if it
>>>> goes away?
>>>
>>> It'll be better, if I get only patch fixs that problem, not all 2.6.16-rc2.
>>
>> Oops I didn't read Jesse's message earlier properly.
>>
>> That patch which probably fixed it is (from his message):
>> I think the commit id that is missing from 2.6.14.X is
>> fb5f5e6e0cebd574be737334671d1aa8f170d5f3
>
> This patch is in the linux-2.6.14 stable tree, I just
> verified this.
So it must be another problem: I had this message with 2.6.15.2:
KERNEL: assertion (!sk->sk_forward_alloc) failed at net/core/stream.c (279)
KERNEL: assertion (!sk->sk_forward_alloc) failed at net/ipv4/af_inet.c (148)
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* Re: [UPDATED PATCH] Re: [Lse-tech] Re: [Patch 7/7] Generic netlink interface (delay accounting)
From: jamal @ 2006-03-10 15:35 UTC (permalink / raw)
To: balbir; +Cc: Shailabh Nagar, netdev, linux-kernel, lse-tech
In-Reply-To: <1142002433.5298.42.camel@jzny2>
On Fri, 2006-10-03 at 09:53 -0500, jamal wrote:
>
> a) shipping of the taskstats from kernel to user-space asynchronously to
> all listeners on multicast channel/group TASKSTATS_LISTEN_GRP
> at the point when some process exits.
> b) responding to queries issued by the user to the kernel for taskstats
> of a particular defined tgid and/or pid combination.
>
> Did i summarize your goals correctly?
>
> So lets stat with #b:
> i) the message is multicast; there has to be a user space app registered
> to the multicast group otherwise nothing goes to user space.
I mispoke:
The above applies to #a.
For #b, the message from/to kernel to user is unicast.
cheers,
jamal
^ permalink raw reply
* Re: [UPDATED PATCH] Re: Re: [Patch 7/7] Generic netlink interface (delay accounting)
From: jamal @ 2006-03-10 14:53 UTC (permalink / raw)
To: balbir; +Cc: Shailabh Nagar, netdev, linux-kernel, lse-tech
In-Reply-To: <20060309143759.GA4653@in.ibm.com>
On Thu, 2006-09-03 at 20:07 +0530, Balbir Singh wrote:
> Please find the latest version of the patch for review. The genetlink
> code has been updated as per your review comments. The changelog is provided
> below
>
> 1. Eliminated TASKSTATS_CMD_LISTEN and TASKSTATS_CMD_IGNORE
> 2. Provide generic functions called genlmsg_data() and genlmsg_len()
> in linux/net/genetlink.h
> 3. Do not multicast all replies, multicast only events generated due
> to task exit.
> 4. The taskstats and taskstats_reply structures are now 64 bit aligned.
> 5. Family id is dynamically generated.
>
> Please let us know if we missed something out.
Design still shaky IMO - now that i think i may understand what your end
goal is.
Using the principles i described in earlier email, the problem you are
trying to solve is:
a) shipping of the taskstats from kernel to user-space asynchronously to
all listeners on multicast channel/group TASKSTATS_LISTEN_GRP
at the point when some process exits.
b) responding to queries issued by the user to the kernel for taskstats
of a particular defined tgid and/or pid combination.
Did i summarize your goals correctly?
So lets stat with #b:
i) the message is multicast; there has to be a user space app registered
to the multicast group otherwise nothing goes to user space.
ii) user space issues a GET and it seems to me the appropriate naming
for the response is a NEW.
Lets go to #a:
The issued multicast messages are also NEW and no different from the
ones sent in response to a GET.
Having said that then, you have the following commands:
enum {
TASKSTATS_CMD_UNSPEC, /* Reserved */
TASKSTATS_CMD_GET, /* user -> kernel query*/
TASKSTATS_CMD_NEW, /* kernel -> user update */
};
You also need the following TLVs
enum {
TASKSTATS_TYPE_UNSPEC, /* Reserved */
TASKSTATS_TYPE_TGID, /* The TGID */
TASKSTATS_TYPE_PID, /* The PID */
TASKSTATS_TYPE_STATS, /* carries the taskstats */
TASKSTATS_TYPE_VERS, /* carries the version */
};
Refer to the doc i passed you and provide feedback if how to use the
above is not obvious.
The use of TLVs above implies that any of these can be optionally
appearing.
So when you are going from user->kernel with a GET a in #a above, then
you can specify the PID and/or TGID and you dont need to specify the
STATS and this would be perfectly legal.
On kernel->user (in the case of response to #a or async notifiation as
in #b) you really dont need to specify the TG/PID since they appear in
the STATS etc.
I take it you dont want to configure the values of taskstats from user
space, otherwise user->kernel will send a NEW as well.
I also take it dumping doesnt apply to you, so you dont need a dump
callback in your kernel code.
>From what i described so far, you dont really need a header for yourself
either (maybe you need one to just store the VERSION?)
I didnt understand the point to the err field you had in the reply.
Netlink already does issue errors which can be read via perror. If this
is different from what you need, it may be an excuse to have your own
header.
I hope this helps.
cheers,
jamal
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [RFC: 2.6 patch] let NET_CLS_ACT no longer depend on EXPERIMENTAL
From: David S. Miller @ 2006-03-10 11:04 UTC (permalink / raw)
To: hadi; +Cc: kaber, bunk, netdev, linux-kernel
In-Reply-To: <1141498341.5185.32.camel@localhost.localdomain>
From: jamal <hadi@cyberus.ca>
Date: Sat, 04 Mar 2006 13:52:21 -0500
> So on Adrian's patch and above reasoning:
>
> ACKed-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied, thanks Adrian.
^ permalink raw reply
* Re: [PATCH] IPv6: Cleanups for net/ipv6/addrconf.c (kzalloc, early exit) v2
From: David S. Miller @ 2006-03-10 11:02 UTC (permalink / raw)
To: yoshfuji; +Cc: ioe-lkml, linux-kernel, netdev
In-Reply-To: <20060212.021103.76157181.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Sun, 12 Feb 2006 02:11:03 +0900 (JST)
> In article <200602111737.20010.ioe-lkml@rameria.de> (at Sat, 11 Feb 2006 17:37:18 +0100), Ingo Oeser <ioe-lkml@rameria.de> says:
>
> > From: Ingo Oeser <ioe-lkml@rameria.de>
> >
> > Here are some possible (and trivial) cleanups.
> > - use kzalloc() where possible
> > - remove unused label
> > - invert allocation failure test like
> :
> > Signed-off-by: Ingo Oeser <ioe-lkml@rameria.de>
> Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
This patch no longer applied cleanly, Ingo can you generate
a fresh version of your patch against my net-2.6.16 tree?
Thanks a lot!
^ permalink raw reply
* Re: KERNEL: assertion (!sk->sk_forward_alloc) failed
From: David S. Miller @ 2006-03-10 10:59 UTC (permalink / raw)
To: jesse.brandeburg; +Cc: yoseph.basri, bb, linux-kernel, netdev
In-Reply-To: <4807377b0602081810l55e4cbdfyeb9102bd50d04641@mail.gmail.com>
From: Jesse Brandeburg <jesse.brandeburg@gmail.com>
Date: Wed, 8 Feb 2006 18:10:21 -0800
> I think the commit id that is missing from 2.6.14.X is
> fb5f5e6e0cebd574be737334671d1aa8f170d5f3
It's in 2.6.14.x I just double checked.
^ permalink raw reply
* Re: KERNEL: assertion (!sk->sk_forward_alloc) failed
From: David S. Miller @ 2006-03-10 10:59 UTC (permalink / raw)
To: imcdnzl; +Cc: bb, jesse.brandeburg, yoseph.basri, linux-kernel, netdev
In-Reply-To: <cbec11ac0602091137p4ee233bdgdcfbf3d6cb62a62f@mail.gmail.com>
From: Ian McDonald <imcdnzl@gmail.com>
Date: Fri, 10 Feb 2006 08:37:48 +1300
> On 2/10/06, Boris B. Zhmurov <bb@kernelpanic.ru> wrote:
> > Hello, Ian McDonald.
> >
> > On 09.02.2006 22:25 you said the following:
> >
> > > Is it possible for you to download 2.6.16-rc2 or similar and see if it
> > > goes away?
> >
> > It'll be better, if I get only patch fixs that problem, not all 2.6.16-rc2.
>
> Oops I didn't read Jesse's message earlier properly.
>
> That patch which probably fixed it is (from his message):
> I think the commit id that is missing from 2.6.14.X is
> fb5f5e6e0cebd574be737334671d1aa8f170d5f3
This patch is in the linux-2.6.14 stable tree, I just
verified this.
^ permalink raw reply
* Re: TSO and IPoIB performance degradation
From: David S. Miller @ 2006-03-10 7:23 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev, rdreier, linux-kernel, openib-general
In-Reply-To: <4410C671.2050300@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Thu, 09 Mar 2006 16:21:05 -0800
> well, there are stacks which do "stretch acks" (after a fashion) that
> make sure when they see packet loss to "do the right thing" wrt sending
> enough acks to allow cwnds to open again in a timely fashion.
Once a loss happens, it's too late to stop doing the stretch ACKs, the
damage is done already. It is going to take you at least one
extra RTT to recover from the loss compared to if you were not doing
stretch ACKs.
You have to keep giving consistent well spaced ACKs back to the
receiver in order to recover from loss optimally.
The ACK every 2 full sized frames behavior of TCP is absolutely
essential.
^ permalink raw reply
* Re: TSO and IPoIB performance degradation
From: David S. Miller @ 2006-03-10 7:18 UTC (permalink / raw)
To: mst; +Cc: netdev, rdreier, linux-kernel, openib-general, shemminger
In-Reply-To: <20060310001031.GA19040@mellanox.co.il>
From: "Michael S. Tsirkin" <mst@mellanox.co.il>
Date: Fri, 10 Mar 2006 02:10:31 +0200
> But with the change we are discussing, could an ack now be sent even
> sooner than we have at least two full sized segments? Or does
> __tcp_ack_snd_check delay until we have at least two full sized
> segments? David, could you explain please?
__tcp_ack_snd_check() delays until we have at least two full
sized segments.
^ permalink raw reply
* Re: TSO and IPoIB performance degradation
From: Michael S. Tsirkin @ 2006-03-10 0:38 UTC (permalink / raw)
To: David S. Miller; +Cc: rdreier, netdev, linux-kernel, openib-general, shemminger
In-Reply-To: <20060310001031.GA19040@mellanox.co.il>
Quoting r. Michael S. Tsirkin <mst@mellanox.co.il>:
> Or does __tcp_ack_snd_check delay until we have at least two full sized
> segments?
What I'm trying to say, since RFC 2525, 2.13 talks about
"every second full-sized segment", so following the code from
__tcp_ack_snd_check, why does it do
/* More than one full frame received... */
if (((tp->rcv_nxt - tp->rcv_wup) > inet_csk(sk)->icsk_ack.rcv_mss
rather than
/* At least two full frames received... */
if (((tp->rcv_nxt - tp->rcv_wup) >= 2 * inet_csk(sk)->icsk_ack.rcv_mss
--
Michael S. Tsirkin
Staff Engineer, Mellanox Technologies
^ permalink raw reply
* Re: TSO and IPoIB performance degradation
From: Rick Jones @ 2006-03-10 0:21 UTC (permalink / raw)
To: netdev; +Cc: rdreier, linux-kernel, openib-general
In-Reply-To: <20060309.154819.104282952.davem@davemloft.net>
David S. Miller wrote:
> From: "Michael S. Tsirkin" <mst@mellanox.co.il>
> Date: Wed, 8 Mar 2006 14:53:11 +0200
>
>
>>What I was trying to figure out was, how can we re-enable the trick
>>without hurting TSO? Could a solution be to simply look at the frame
>>size, and call tcp_send_delayed_ack if the frame size is small?
>
>
> The change is really not related to TSO.
>
> By reverting it, you are reducing the number of ACKs on the wire, and
> the number of context switches at the sender to push out new data.
> That's why it can make things go faster, but it also leads to bursty
> TCP sender behavior, which is bad for congestion on the internet.
naughty naughty Solaris and HP-UX TCP :)
>
> When the receiver has a strong cpu and can keep up with the incoming
> packet rate very well and we are in an environment with no congestion,
> the old code helps a lot. But if the receiver is cpu limited or we
> have congestion of any kind, it does exactly the wrong thing. It will
> delay ACKs a very long time to the point where the pipe is depleted
> and this kills performance in that case. For congested environments,
> due to the decreased ACK feedback, packet loss recovery will be
> extremely poor. This is the first reason behind my change.
well, there are stacks which do "stretch acks" (after a fashion) that
make sure when they see packet loss to "do the right thing" wrt sending
enough acks to allow cwnds to open again in a timely fashion.
that brings-back all that stuff I posted ages ago about the performance
delta when using an HP-UX receiver and altering the number of segmetns
per ACK. should be in the netdev archive somewhere.
might have been around the time of the discussions about MacOS and its
ack avoidance - which wasn't done very well at the time.
>
> The behavior is also specifically frowned upon in the TCP implementor
> community. It is specifically mentioned in the Known TCP
> Implementation Problems RFC2525, in section 2.13 "Stretch ACK
> violation".
>
> The entry, quoted below for reference, is very clear on the reasons
> why stretch ACKs are bad. And although it may help performance for
> your case, in congested environments and also with cpu limited
> receivers it will have a negative impact on performance. So, this was
> the second reason why I made this change.
I would have thought that a receiver "stretching ACK's" would be helpful
when it was CPU limited since it was spending fewer CPU cycles
generating ACKs?
>
> So reverting the change isn't really an option.
>
> Name of Problem
> Stretch ACK violation
>
> Classification
> Congestion Control/Performance
>
> Description
> To improve efficiency (both computer and network) a data receiver
> may refrain from sending an ACK for each incoming segment,
> according to [RFC1122]. However, an ACK should not be delayed an
> inordinate amount of time. Specifically, ACKs SHOULD be sent for
> every second full-sized segment that arrives. If a second full-
> sized segment does not arrive within a given timeout (of no more
> than 0.5 seconds), an ACK should be transmitted, according to
> [RFC1122]. A TCP receiver which does not generate an ACK for
> every second full-sized segment exhibits a "Stretch ACK
> Violation".
How can it be a "violation" of a SHOULD?-)
>
> Significance
> TCP receivers exhibiting this behavior will cause TCP senders to
> generate burstier traffic, which can degrade performance in
> congested environments. In addition, generating fewer ACKs
> increases the amount of time needed by the slow start algorithm to
> open the congestion window to an appropriate point, which
> diminishes performance in environments with large bandwidth-delay
> products. Finally, generating fewer ACKs may cause needless
> retransmission timeouts in lossy environments, as it increases the
> possibility that an entire window of ACKs is lost, forcing a
> retransmission timeout.
Of those three, I think the most meaningful is the second, which can be
dealt with by smarts in the ACK-stretching receiver.
For the first, it will only degrade performance if it triggers packet loss.
I'm not sure I've ever seen the third item happen.
>
> Implications
> When not in loss recovery, every ACK received by a TCP sender
> triggers the transmission of new data segments. The burst size is
> determined by the number of previously unacknowledged segments
> each ACK covers. Therefore, a TCP receiver ack'ing more than 2
> segments at a time causes the sending TCP to generate a larger
> burst of traffic upon receipt of the ACK. This large burst of
> traffic can overwhelm an intervening gateway, leading to higher
> drop rates for both the connection and other connections passing
> through the congested gateway.
Doesn't RED mean that those other connections are rather less likely to
be affected?
>
> In addition, the TCP slow start algorithm increases the congestion
> window by 1 segment for each ACK received. Therefore, increasing
> the ACK interval (thus decreasing the rate at which ACKs are
> transmitted) increases the amount of time it takes slow start to
> increase the congestion window to an appropriate operating point,
> and the connection consequently suffers from reduced performance.
> This is especially true for connections using large windows.
This one is dealt with by ABC isn't it? At least in part since ABC
appears to cap cwnd increase at 2*SMSS (I only know this because I just
read the RFC mentioned in another thread - seems a bit much to have made
that limit a MUST rather than a SHOULD :)
rick jones
^ permalink raw reply
* Re: TSO and IPoIB performance degradation
From: Michael S. Tsirkin @ 2006-03-10 0:10 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, rdreier, linux-kernel, openib-general, shemminger
In-Reply-To: <20060309.154819.104282952.davem@davemloft.net>
Quoting David S. Miller <davem@davemloft.net>:
> Description
> To improve efficiency (both computer and network) a data receiver
> may refrain from sending an ACK for each incoming segment,
> according to [RFC1122]. However, an ACK should not be delayed an
> inordinate amount of time. Specifically, ACKs SHOULD be sent for
> every second full-sized segment that arrives. If a second full-
> sized segment does not arrive within a given timeout (of no more
> than 0.5 seconds), an ACK should be transmitted, according to
> [RFC1122]. A TCP receiver which does not generate an ACK for
> every second full-sized segment exhibits a "Stretch ACK
> Violation".
Thanks very much for the info!
So the longest we can delay, according to this spec, is until we have two full
sized segments.
But with the change we are discussing, could an ack now be sent even sooner than
we have at least two full sized segments? Or does __tcp_ack_snd_check delay
until we have at least two full sized segments? David, could you explain please?
--
Michael S. Tsirkin
Staff Engineer, Mellanox Technologies
^ permalink raw reply
* Re: TSO and IPoIB performance degradation
From: David S. Miller @ 2006-03-09 23:48 UTC (permalink / raw)
To: mst; +Cc: netdev, rdreier, linux-kernel, openib-general, shemminger
In-Reply-To: <20060308125311.GE17618@mellanox.co.il>
From: "Michael S. Tsirkin" <mst@mellanox.co.il>
Date: Wed, 8 Mar 2006 14:53:11 +0200
> What I was trying to figure out was, how can we re-enable the trick
> without hurting TSO? Could a solution be to simply look at the frame
> size, and call tcp_send_delayed_ack if the frame size is small?
The change is really not related to TSO.
By reverting it, you are reducing the number of ACKs on the wire, and
the number of context switches at the sender to push out new data.
That's why it can make things go faster, but it also leads to bursty
TCP sender behavior, which is bad for congestion on the internet.
When the receiver has a strong cpu and can keep up with the incoming
packet rate very well and we are in an environment with no congestion,
the old code helps a lot. But if the receiver is cpu limited or we
have congestion of any kind, it does exactly the wrong thing. It will
delay ACKs a very long time to the point where the pipe is depleted
and this kills performance in that case. For congested environments,
due to the decreased ACK feedback, packet loss recovery will be
extremely poor. This is the first reason behind my change.
The behavior is also specifically frowned upon in the TCP implementor
community. It is specifically mentioned in the Known TCP
Implementation Problems RFC2525, in section 2.13 "Stretch ACK
violation".
The entry, quoted below for reference, is very clear on the reasons
why stretch ACKs are bad. And although it may help performance for
your case, in congested environments and also with cpu limited
receivers it will have a negative impact on performance. So, this was
the second reason why I made this change.
So reverting the change isn't really an option.
Name of Problem
Stretch ACK violation
Classification
Congestion Control/Performance
Description
To improve efficiency (both computer and network) a data receiver
may refrain from sending an ACK for each incoming segment,
according to [RFC1122]. However, an ACK should not be delayed an
inordinate amount of time. Specifically, ACKs SHOULD be sent for
every second full-sized segment that arrives. If a second full-
sized segment does not arrive within a given timeout (of no more
than 0.5 seconds), an ACK should be transmitted, according to
[RFC1122]. A TCP receiver which does not generate an ACK for
every second full-sized segment exhibits a "Stretch ACK
Violation".
Significance
TCP receivers exhibiting this behavior will cause TCP senders to
generate burstier traffic, which can degrade performance in
congested environments. In addition, generating fewer ACKs
increases the amount of time needed by the slow start algorithm to
open the congestion window to an appropriate point, which
diminishes performance in environments with large bandwidth-delay
products. Finally, generating fewer ACKs may cause needless
retransmission timeouts in lossy environments, as it increases the
possibility that an entire window of ACKs is lost, forcing a
retransmission timeout.
Implications
When not in loss recovery, every ACK received by a TCP sender
triggers the transmission of new data segments. The burst size is
determined by the number of previously unacknowledged segments
each ACK covers. Therefore, a TCP receiver ack'ing more than 2
segments at a time causes the sending TCP to generate a larger
burst of traffic upon receipt of the ACK. This large burst of
traffic can overwhelm an intervening gateway, leading to higher
drop rates for both the connection and other connections passing
through the congested gateway.
In addition, the TCP slow start algorithm increases the congestion
window by 1 segment for each ACK received. Therefore, increasing
the ACK interval (thus decreasing the rate at which ACKs are
transmitted) increases the amount of time it takes slow start to
increase the congestion window to an appropriate operating point,
and the connection consequently suffers from reduced performance.
This is especially true for connections using large windows.
Relevant RFCs
RFC 1122 outlines delayed ACKs as a recommended mechanism.
Trace file demonstrating it
Trace file taken using tcpdump at host B, the data receiver (and
ACK originator). The advertised window (which never changed) and
timestamp options have been omitted for clarity, except for the
first packet sent by A:
12:09:24.820187 A.1174 > B.3999: . 2049:3497(1448) ack 1
win 33580 <nop,nop,timestamp 2249877 2249914> [tos 0x8]
12:09:24.824147 A.1174 > B.3999: . 3497:4945(1448) ack 1
12:09:24.832034 A.1174 > B.3999: . 4945:6393(1448) ack 1
12:09:24.832222 B.3999 > A.1174: . ack 6393
12:09:24.934837 A.1174 > B.3999: . 6393:7841(1448) ack 1
12:09:24.942721 A.1174 > B.3999: . 7841:9289(1448) ack 1
12:09:24.950605 A.1174 > B.3999: . 9289:10737(1448) ack 1
12:09:24.950797 B.3999 > A.1174: . ack 10737
12:09:24.958488 A.1174 > B.3999: . 10737:12185(1448) ack 1
12:09:25.052330 A.1174 > B.3999: . 12185:13633(1448) ack 1
12:09:25.060216 A.1174 > B.3999: . 13633:15081(1448) ack 1
12:09:25.060405 B.3999 > A.1174: . ack 15081
This portion of the trace clearly shows that the receiver (host B)
sends an ACK for every third full sized packet received. Further
investigation of this implementation found that the cause of the
increased ACK interval was the TCP options being used. The
implementation sent an ACK after it was holding 2*MSS worth of
unacknowledged data. In the above case, the MSS is 1460 bytes so
the receiver transmits an ACK after it is holding at least 2920
bytes of unacknowledged data. However, the length of the TCP
options being used [RFC1323] took 12 bytes away from the data
portion of each packet. This produced packets containing 1448
bytes of data. But the additional bytes used by the options in
the header were not taken into account when determining when to
trigger an ACK. Therefore, it took 3 data segments before the
data receiver was holding enough unacknowledged data (>= 2*MSS, or
2920 bytes in the above example) to transmit an ACK.
Trace file demonstrating correct behavior
Trace file taken using tcpdump at host B, the data receiver (and
ACK originator), again with window and timestamp information
omitted except for the first packet:
12:06:53.627320 A.1172 > B.3999: . 1449:2897(1448) ack 1
win 33580 <nop,nop,timestamp 2249575 2249612> [tos 0x8]
12:06:53.634773 A.1172 > B.3999: . 2897:4345(1448) ack 1
12:06:53.634961 B.3999 > A.1172: . ack 4345
12:06:53.737326 A.1172 > B.3999: . 4345:5793(1448) ack 1
12:06:53.744401 A.1172 > B.3999: . 5793:7241(1448) ack 1
12:06:53.744592 B.3999 > A.1172: . ack 7241
12:06:53.752287 A.1172 > B.3999: . 7241:8689(1448) ack 1
12:06:53.847332 A.1172 > B.3999: . 8689:10137(1448) ack 1
12:06:53.847525 B.3999 > A.1172: . ack 10137
This trace shows the TCP receiver (host B) ack'ing every second
full-sized packet, according to [RFC1122]. This is the same
implementation shown above, with slight modifications that allow
the receiver to take the length of the options into account when
deciding when to transmit an ACK.
References
This problem is documented in [Allman97] and [Paxson97].
How to detect
Stretch ACK violations show up immediately in receiver-side packet
traces of bulk transfers, as shown above. However, packet traces
made on the sender side of the TCP connection may lead to
ambiguities when diagnosing this problem due to the possibility of
lost ACKs.
^ permalink raw reply
* Re: [RFC: 2.6 patch] chelsio/espi.c:tricn_init(): remove dead code
From: Scott Bardone @ 2006-03-09 23:34 UTC (permalink / raw)
To: Adrian Bunk; +Cc: maintainers, jgarzik, netdev, linux-kernel
In-Reply-To: <20060309230653.GK21864@stusta.de>
This patch is correct, these two variables are unused in this driver. Thanks for
catching this!
Signed-off-by: Scott Bardone <sbardone@chelsio.com>
Adrian Bunk wrote:
> The Coverity checker spotted these two unused variables.
>
> Please check whether this patch is correct or whether they should be
> used.
>
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> ---
>
> drivers/net/chelsio/espi.c | 14 +++-----------
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> --- linux-2.6.16-rc5-mm3-full/drivers/net/chelsio/espi.c.old 2006-03-09 23:19:54.000000000 +0100
> +++ linux-2.6.16-rc5-mm3-full/drivers/net/chelsio/espi.c 2006-03-09 23:20:35.000000000 +0100
> @@ -87,15 +87,9 @@
> static int tricn_init(adapter_t *adapter)
> {
> int i = 0;
> - int sme = 1;
> int stat = 0;
> int timeout = 0;
> int is_ready = 0;
> - int dynamic_deskew = 0;
> -
> - if (dynamic_deskew)
> - sme = 0;
> -
>
> /* 1 */
> timeout=1000;
> @@ -113,11 +107,9 @@
> }
>
> /* 2 */
> - if (sme) {
> - tricn_write(adapter, 0, 0, 0, TRICN_CNFG, 0x81);
> - tricn_write(adapter, 0, 1, 0, TRICN_CNFG, 0x81);
> - tricn_write(adapter, 0, 2, 0, TRICN_CNFG, 0x81);
> - }
> + tricn_write(adapter, 0, 0, 0, TRICN_CNFG, 0x81);
> + tricn_write(adapter, 0, 1, 0, TRICN_CNFG, 0x81);
> + tricn_write(adapter, 0, 2, 0, TRICN_CNFG, 0x81);
> for (i=1; i<= 8; i++) tricn_write(adapter, 0, 0, i, TRICN_CNFG, 0xf1);
> for (i=1; i<= 2; i++) tricn_write(adapter, 0, 1, i, TRICN_CNFG, 0xf1);
> for (i=1; i<= 3; i++) tricn_write(adapter, 0, 2, i, TRICN_CNFG, 0xe1);
>
^ permalink raw reply
* Re: [2.6 patch] tg3.c:tg3_bus_string(): remove dead code
From: David S. Miller @ 2006-03-09 23:09 UTC (permalink / raw)
To: bunk; +Cc: jgarzik, netdev, linux-kernel
In-Reply-To: <20060309230650.GJ21864@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Fri, 10 Mar 2006 00:06:50 +0100
> The Coverity checker spotted this dead code (note that (clock_ctrl == 7)
> is already handled above).
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks Adrian.
^ permalink raw reply
* [RFC: 2.6 patch] chelsio/espi.c:tricn_init(): remove dead code
From: Adrian Bunk @ 2006-03-09 23:06 UTC (permalink / raw)
To: maintainers; +Cc: jgarzik, netdev, linux-kernel
The Coverity checker spotted these two unused variables.
Please check whether this patch is correct or whether they should be
used.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/net/chelsio/espi.c | 14 +++-----------
1 file changed, 3 insertions(+), 11 deletions(-)
--- linux-2.6.16-rc5-mm3-full/drivers/net/chelsio/espi.c.old 2006-03-09 23:19:54.000000000 +0100
+++ linux-2.6.16-rc5-mm3-full/drivers/net/chelsio/espi.c 2006-03-09 23:20:35.000000000 +0100
@@ -87,15 +87,9 @@
static int tricn_init(adapter_t *adapter)
{
int i = 0;
- int sme = 1;
int stat = 0;
int timeout = 0;
int is_ready = 0;
- int dynamic_deskew = 0;
-
- if (dynamic_deskew)
- sme = 0;
-
/* 1 */
timeout=1000;
@@ -113,11 +107,9 @@
}
/* 2 */
- if (sme) {
- tricn_write(adapter, 0, 0, 0, TRICN_CNFG, 0x81);
- tricn_write(adapter, 0, 1, 0, TRICN_CNFG, 0x81);
- tricn_write(adapter, 0, 2, 0, TRICN_CNFG, 0x81);
- }
+ tricn_write(adapter, 0, 0, 0, TRICN_CNFG, 0x81);
+ tricn_write(adapter, 0, 1, 0, TRICN_CNFG, 0x81);
+ tricn_write(adapter, 0, 2, 0, TRICN_CNFG, 0x81);
for (i=1; i<= 8; i++) tricn_write(adapter, 0, 0, i, TRICN_CNFG, 0xf1);
for (i=1; i<= 2; i++) tricn_write(adapter, 0, 1, i, TRICN_CNFG, 0xf1);
for (i=1; i<= 3; i++) tricn_write(adapter, 0, 2, i, TRICN_CNFG, 0xe1);
^ permalink raw reply
* [2.6 patch] tg3.c:tg3_bus_string(): remove dead code
From: Adrian Bunk @ 2006-03-09 23:06 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linux-kernel
The Coverity checker spotted this dead code (note that (clock_ctrl == 7)
is already handled above).
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.16-rc5-mm3-full/drivers/net/tg3.c.old 2006-03-09 23:25:25.000000000 +0100
+++ linux-2.6.16-rc5-mm3-full/drivers/net/tg3.c 2006-03-09 23:25:39.000000000 +0100
@@ -10596,26 +10596,24 @@ static char * __devinit tg3_bus_string(s
if ((clock_ctrl == 7) ||
((tr32(GRC_MISC_CFG) & GRC_MISC_CFG_BOARD_ID_MASK) ==
GRC_MISC_CFG_BOARD_ID_5704CIOBE))
strcat(str, "133MHz");
else if (clock_ctrl == 0)
strcat(str, "33MHz");
else if (clock_ctrl == 2)
strcat(str, "50MHz");
else if (clock_ctrl == 4)
strcat(str, "66MHz");
else if (clock_ctrl == 6)
strcat(str, "100MHz");
- else if (clock_ctrl == 7)
- strcat(str, "133MHz");
} else {
strcpy(str, "PCI:");
if (tp->tg3_flags & TG3_FLAG_PCI_HIGH_SPEED)
strcat(str, "66MHz");
else
strcat(str, "33MHz");
}
if (tp->tg3_flags & TG3_FLAG_PCI_32BIT)
strcat(str, ":32-bit");
else
strcat(str, ":64-bit");
return str;
^ permalink raw reply
* [RFC: 2.6 patch] hostap_hw.c:hfa384x_set_rid(): fix error handling
From: Adrian Bunk @ 2006-03-09 23:06 UTC (permalink / raw)
To: jkmaline; +Cc: hostap, linux-kernel, netdev, linville
The Coverity checker noted that the call to prism2_hw_reset() was dead
code.
Does this patch change the code to what was intended?
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.16-rc5-mm3-full/drivers/net/wireless/hostap/hostap_hw.c.old 2006-03-09 23:28:30.000000000 +0100
+++ linux-2.6.16-rc5-mm3-full/drivers/net/wireless/hostap/hostap_hw.c 2006-03-09 23:30:19.000000000 +0100
@@ -928,16 +928,16 @@ static int hfa384x_set_rid(struct net_de
res = hfa384x_cmd(dev, HFA384X_CMDCODE_ACCESS_WRITE, rid, NULL, NULL);
up(&local->rid_bap_sem);
+
if (res) {
+ if (res == -ETIMEDOUT)
+ prism2_hw_reset(dev);
+
printk(KERN_DEBUG "%s: hfa384x_set_rid: CMDCODE_ACCESS_WRITE "
"failed (res=%d, rid=%04x, len=%d)\n",
dev->name, res, rid, len);
- return res;
}
- if (res == -ETIMEDOUT)
- prism2_hw_reset(dev);
-
return res;
}
^ 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