* [PATCH v2 6/6] sctp: convert sctp_assoc_set_id to use idr_alloc_cyclic
From: Jeff Layton @ 2013-03-27 19:29 UTC (permalink / raw)
To: akpm
Cc: linux-kernel, tj, Vlad Yasevich, Sridhar Samudrala, Neil Horman,
David S. Miller, linux-sctp, netdev
In-Reply-To: <1364412578-7462-1-git-send-email-jlayton@redhat.com>
(Note: compile-tested only)
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Cc: Sridhar Samudrala <sri@us.ibm.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-sctp@vger.kernel.org
Cc: netdev@vger.kernel.org
---
net/sctp/associola.c | 16 ++--------------
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index d2709e2..fa261a3 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -66,13 +66,6 @@ static void sctp_assoc_bh_rcv(struct work_struct *work);
static void sctp_assoc_free_asconf_acks(struct sctp_association *asoc);
static void sctp_assoc_free_asconf_queue(struct sctp_association *asoc);
-/* Keep track of the new idr low so that we don't re-use association id
- * numbers too fast. It is protected by they idr spin lock is in the
- * range of 1 - INT_MAX.
- */
-static u32 idr_low = 1;
-
-
/* 1st Level Abstractions. */
/* Initialize a new association from provided memory. */
@@ -1601,13 +1594,8 @@ int sctp_assoc_set_id(struct sctp_association *asoc, gfp_t gfp)
if (preload)
idr_preload(gfp);
spin_lock_bh(&sctp_assocs_id_lock);
- /* 0 is not a valid id, idr_low is always >= 1 */
- ret = idr_alloc(&sctp_assocs_id, asoc, idr_low, 0, GFP_NOWAIT);
- if (ret >= 0) {
- idr_low = ret + 1;
- if (idr_low == INT_MAX)
- idr_low = 1;
- }
+ /* 0 is not a valid assoc_id, must be >= 1 */
+ ret = idr_alloc_cyclic(&sctp_assocs_id, asoc, 1, 0, GFP_NOWAIT);
spin_unlock_bh(&sctp_assocs_id_lock);
if (preload)
idr_preload_end();
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH -next] GRE: Use strlcat() for size checking
From: Ben Hutchings @ 2013-03-27 20:06 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Pravin B Shelar, David S. Miller, netdev, linux-kernel,
linux-next
In-Reply-To: <1364410111-29418-1-git-send-email-geert@linux-m68k.org>
On Wed, 2013-03-27 at 19:48 +0100, Geert Uytterhoeven wrote:
> On m68k, gcc tries to be smart and turns
>
> strncat(name, "%d", 2);
>
> into a call to strlen() and a 16-bit store, causing a link failure,
> as arch/m68k/include/asm/string.h provides strlen() using a macro:
>
> ERROR: "strlen" [net/ipv4/ip_tunnel.ko] undefined!
Perhaps you should fix the string library for m68k, then!
> Use strlcat() instead to avoid this, which also allows to simplify the
> check for buffer overflows.
It looks like you're also fixing an off-by-one error: the maximum length
of ops->kind will be IFNAMSIZ - 3 (just enough to add "%d" and the null
terminator), rather than IFNAMSIZ - 4.
Ben.
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> --
> Compile-tested only
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/8462108/
> ---
> net/ipv4/ip_tunnel.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index 9d96b68..8dbe672 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -284,12 +284,11 @@ static struct net_device *__ip_tunnel_create(struct net *net,
> if (parms->name[0])
> strlcpy(name, parms->name, IFNAMSIZ);
> else {
> - if (strlen(ops->kind) + 3 >= IFNAMSIZ) {
> + strlcpy(name, ops->kind, IFNAMSIZ);
> + if (strlcat(name, "%d", IFNAMSIZ) >= IFNAMSIZ) {
> err = -E2BIG;
> goto failed;
> }
> - strlcpy(name, ops->kind, IFNAMSIZ);
> - strncat(name, "%d", 2);
> }
>
> ASSERT_RTNL();
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: unmanaged L2TPv3 ethernet pseudowire Cisco <=> Linux
From: Tomas Agartz @ 2013-03-27 20:08 UTC (permalink / raw)
To: James Chapman; +Cc: netdev
In-Reply-To: <CAEwTi7Rbo3dBqhyDJXYvrkMWfrX9xwUr5VovFoW7BfPAZp4XFw@mail.gmail.com>
On Tue, 26 Mar 2013, James Chapman wrote:
> The issue is that Linux and Cisco use a different default for the
> L2SpecificSublayer header setting and neither implementation provides a
> config option to change its setting. :-( The Linux default is to use the
> Default L2SpecificSublayer as defined in the RFC. Unfortunately the
> Cisco default is to use no L2SpecificSublayer.
>
> The kernel already has an API to allow the L2SpecificSublayer setting to
> be configured. The missing piece is an iproute2 l2tp config option to
> configure it. I'll work on an iproute2 patch now to allow this setting
> to be configured.
I patched my iproute2 with your patch and now my tunnel is working. Thank
you! :)
> For unmanaged tunnels, these parameters must be manually configured
> consistently at each side. Both Cisco and Linux default to use no
> cookies and both already have config parameters to set cookie
> parameters, if needed. However, for L2SpecificSublayer this isn't the
> case. We need to add a config option on the Linux side to force the same
> setting as Cisco is using.
Does the API in the kernel allow you to set the cookie? In that
case it seems like a good idea to add that to iproute2 as well?
//tlund
^ permalink raw reply
* Re: [PATCH -next] GRE: Use strlcat() for size checking
From: David Miller @ 2013-03-27 20:10 UTC (permalink / raw)
To: bhutchings; +Cc: geert, pshelar, netdev, linux-kernel, linux-next
In-Reply-To: <1364414776.2922.19.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 27 Mar 2013 20:06:16 +0000
> On Wed, 2013-03-27 at 19:48 +0100, Geert Uytterhoeven wrote:
>> On m68k, gcc tries to be smart and turns
>>
>> strncat(name, "%d", 2);
>>
>> into a call to strlen() and a 16-bit store, causing a link failure,
>> as arch/m68k/include/asm/string.h provides strlen() using a macro:
>>
>> ERROR: "strlen" [net/ipv4/ip_tunnel.ko] undefined!
>
> Perhaps you should fix the string library for m68k, then!
Right, this symbol really must be provided.
You cannot merely provide inlines.
The off-by-one error is seperate, but that should be fixed
differently.
^ permalink raw reply
* Re: [PATCH 2/2] iproute2: update ip-l2tp man page
From: Stephen Hemminger @ 2013-03-27 20:22 UTC (permalink / raw)
To: James Chapman; +Cc: netdev, tlund
In-Reply-To: <1364316563-23303-2-git-send-email-jchapman@katalix.com>
On Tue, 26 Mar 2013 16:49:23 +0000
James Chapman <jchapman@katalix.com> wrote:
> Add documentation about the new l2spec_type parameter for "ip l2tp add
> session".
>
> Signed-off-by: James Chapman <jchapman@katalix.com>
Both applied, thanks
^ permalink raw reply
* [PATCH] tokenring: delete last holdout of CONFIG_TR
From: Paul Bolle @ 2013-03-27 20:52 UTC (permalink / raw)
To: David S. Miller; +Cc: Paul Gortmaker, netdev, linux-kernel
Tokenring support was deleted in v3.5. One last holdout of the macro
CONFIG_TR escaped that fate. Until now.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
Untested.
include/linux/netdevice.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index b3d00fa..05d142f 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -144,8 +144,6 @@ static inline bool dev_xmit_complete(int rc)
# else
# define LL_MAX_HEADER 96
# endif
-#elif IS_ENABLED(CONFIG_TR)
-# define LL_MAX_HEADER 48
#else
# define LL_MAX_HEADER 32
#endif
--
1.7.11.7
^ permalink raw reply related
* Re: unmanaged L2TPv3 ethernet pseudowire Cisco <=> Linux
From: James Chapman @ 2013-03-27 20:56 UTC (permalink / raw)
To: Tomas Agartz; +Cc: netdev
In-Reply-To: <Pine.LNX.4.61.1303272104470.20041@envy.nxs.se>
On 27/03/13 20:08, Tomas Agartz wrote:
> On Tue, 26 Mar 2013, James Chapman wrote:
>
>> The issue is that Linux and Cisco use a different default for the
>> L2SpecificSublayer header setting and neither implementation provides
>> a config option to change its setting. :-( The Linux default is to use
>> the Default L2SpecificSublayer as defined in the RFC. Unfortunately
>> the Cisco default is to use no L2SpecificSublayer.
>>
>> The kernel already has an API to allow the L2SpecificSublayer setting
>> to be configured. The missing piece is an iproute2 l2tp config option
>> to configure it. I'll work on an iproute2 patch now to allow this
>> setting to be configured.
>
> I patched my iproute2 with your patch and now my tunnel is working.
> Thank you! :)
Great. Thanks for reporting back.
>> For unmanaged tunnels, these parameters must be manually configured
>> consistently at each side. Both Cisco and Linux default to use no
>> cookies and both already have config parameters to set cookie
>> parameters, if needed. However, for L2SpecificSublayer this isn't the
>> case. We need to add a config option on the Linux side to force the
>> same setting as Cisco is using.
>
> Does the API in the kernel allow you to set the cookie? In that case it
> seems like a good idea to add that to iproute2 as well?
It is already supported. See the cookie and peer_cookie parameters of ip
l2tp add session.
ip l2tp help
or
man ip-l2tp
James
^ permalink raw reply
* RE: [PATCH net-next] bnx2x: handle spurious interrupts
From: Yuval Mintz @ 2013-03-27 21:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Ariel Elior, Eilon Greenstein
In-Reply-To: <20130327.152716.1731476572805884795.davem@davemloft.net>
> > Since the driver must request the IRQ prior to enabling HW generation of
> > interrupts, it would still need to ignore every interrupt arriving during that
> > interval.
>
> This is the real issue.
>
> request_irq() must not be invoked until you are ready to handle
> interrupts, and this means initializing any and all software
> datastructures that might be accessed in the interrupt handler.
>
> If this requirement is met, seeing NULL pointers is not possible.
I agree we won't be seeing NULL pointers, but that's only the manifestation of the
problem, not the problem itself - if we would have handled those spurious
interrupts in the same manner we do regular ones, we might leave HW in an
unsteady state.
The real issue (well, both are real but this is the one THIS patch tries
solving, while the one you describe is the one I've named `orthogonal') is that
there exists a scenario in which the HW generates an interrupt although it's
configured not to do so, and the bnx2x driver shouldn't ACK but rather discard it.
> I still reject this patch, please fix the fundamental issue instead,
> thanks.
This is of course your prerogative.
We will work on solving both issues.
Thanks,
Yuval
^ permalink raw reply
* Re: ieee802154: Source addr fix for dgram and some small at86rf230 driver enhancements
From: Stefan Schmidt @ 2013-03-27 21:21 UTC (permalink / raw)
To: David Miller
Cc: alan-yzvJWuRpmD1zbRFIqnYvSA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20130327.151037.378525240140621201.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hello.
On Wed, 2013-03-27 at 15:10, David Miller wrote:
> From: Stefan Schmidt <stefan-OrPQZGeq07wqhVmZOOOmNx2eb7JE58TQ@public.gmane.org>
> Date: Wed, 27 Mar 2013 18:52:05 +0000
>
> > On Wed, 2013-03-27 at 00:53, David Miller wrote:
> >> From: Stefan Schmidt <stefan-OrPQZGeq07wqhVmZOOOmNx2eb7JE58TQ@public.gmane.org>
> >> Date: Tue, 26 Mar 2013 22:41:28 +0000
> >>
> >> > Hello.
> >> >
> >> > Second version. Changes since version 1:
> >> > - Obey 80 chars rules
> >> > - Switch logging mode to vdbg to avoid noise
> >> > - Remove uneeded might_sleep()
> >> >
> >> > Thanks Alan, Werner and Alex for the feedback.
> >> >
> >> > I feel these are ready so I added DaveM and netdev to pick them up if they think
> >> > the same.
> >>
> >> All applied.
> >
> > Thanks. That was quick. :)
> >
> > I wonder what happened to the from of two of my commits. Looking at
> > your repo they only show up my email address:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=1486774d69f6e58da16cdae8f17c77ec6569f711
> > https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=028889b0b32064a3a23d6d8d4ef589a42a6d43c7
> >
> > The one from Stephen is fine
> > https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=6364e6ee788ae60f1c2de5c59e39adb157327e6c
> >
> > The later as an explicit from as he was the author and I just the
> > sender. For the two problematic ones git am should have picked up the
> > normal mail from header, no?
>
> I don't understand what the problem is.
>
> The first two patches list you as the author, as that is the sender in
> the From: field.
Yeah, sorry. Should have made that more clear.
> Oh, I see, the name, have a look at:
>
> http://patchwork.ozlabs.org/patch/231579/
>
> That's where I take the patches from, click on Download "mbox" and you'll
> see that it gave me the headers as:
>
> Date: Tue, 26 Mar 2013 12:41:30 -0000
> From: stefan-OrPQZGeq07wqhVmZOOOmNx2eb7JE58TQ@public.gmane.org
Strange, patchwork somehow got the From wrong. Looking through the
headers again it seems all correct to me. The only occurance of my
email without proper name is the return-path which should should not
matter.
Its not a big deal anyway, just strange.
regards
Stefan Schmidt
------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
^ permalink raw reply
* Re: Is there a preferred way to get the VXLAN port number?
From: Jesse Gross @ 2013-03-27 21:30 UTC (permalink / raw)
To: David Stevens
Cc: Alexander Duyck, David Miller, Gasparakis, Joseph, netdev,
netdev-owner, pshelar, Stephen Hemminger
In-Reply-To: <OFAA2F59A9.3D5AC989-ON85257B3B.00666533-85257B3B.00688855@us.ibm.com>
On Wed, Mar 27, 2013 at 12:01 PM, David Stevens <dlstevens@us.ibm.com> wrote:
> netdev-owner@vger.kernel.org wrote on 03/27/2013 02:32:59 PM:
>
>> The main think I want to do is keep this simple since I would prefer to
>> not build up any infrastructure that will just get in the way. My
>> thought for now is to just export a function to allow drivers to fetch
>> the port number of VXLAN. The only downside is that it forces the VXLAN
>> module to load if a driver comes up with offload support, similar to how
>> we have been loading the 8021q module for many of the drivers that
>> support VLAN offloads. Hopefully if the fixed port number approach wins
>> out we can simplify things by replacing the function call with a static
>> define.
>
> I guess you mean you need to find it within the kernel.
>
> I think whether or not it remains a single port for the machine,
> it would be just silly to make it a fixed port, period. Virtually any
> service allows an administrator to specify an alternate port to run a
> service on.
> I think one of the primary reasons is that you may want to run
> more than one instance on the same host (e.g., a sandbox installation
> alongside a production installation) -- a capability not there now,
> even though you can specify an alternate port now.
> But if for whatever reason an adminstrator cares that it uses
> a particular port number, even in a single instance, there is no
> technical reason to disallow it. It'd be bad to assume all VXLAN
> must be on the particular port, and equally bad to assume all traffic
> for that port is VXLAN (esp. on a host that is not using VXLAN at all,
> but very well may want to use a lot of ports, including 8472).
>
> I think it ought to be fully general -- different devices may
> use different ports and one device may use multiple listeners on different
> ports (to split flows for security, load balancing, or whatever).
> I'd make it a per-device function interface that gives you a port
> list
> for that device (e.g., an array and length or count). Right now, all
> devices
> would return the single module parameter value, but in the future those
> ought
> to be capable of being entirely distinct lists of ports.
Agreed, the likelihood of a single port winning in the foreseeable
future seems low and not really consistent with the usage of other L4
ports. Even settling on a single tunneling protocol is unlikely to
happen, so I don't think this problem is specific to VXLAN. From a
layering perspective, it also seems better to have the protocol
implementation tell the driver what to use rather than inferring it
the other way around.
As far as GRO/RPS, we really want to do this as early in the
processing path as possible and not wait until the socket lookup since
the more work we do first, the less the benefit. I think the position
in the stack for both the hardware and software versions are very
analogous.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: handle spurious interrupts
From: David Miller @ 2013-03-27 21:34 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, ariele, eilong
In-Reply-To: <979A8436335E3744ADCD3A9F2A2B68A52ABF944F@SJEXCHMB10.corp.ad.broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Wed, 27 Mar 2013 21:08:17 +0000
> The real issue (well, both are real but this is the one THIS patch
> tries solving, while the one you describe is the one I've named
> `orthogonal') is that there exists a scenario in which the HW
> generates an interrupt although it's configured not to do so, and
> the bnx2x driver shouldn't ACK but rather discard it.
Then I'd rather you test for this situation in a cheap and explicit
manner instead of "pointer is NULL, datastructures not setup yet,
must be spurious."
Actually, in drivers, the handling of spurious interrupts is probably
the domain in which I see the most poorly thought out and implemented
patches.
^ permalink raw reply
* [PATCH net-next] vxlan: Provide means for obtaining port information
From: Alexander Duyck @ 2013-03-27 21:33 UTC (permalink / raw)
To: netdev
Cc: jesse, pshelar, jeffrey.t.kirsher, shemminger, joseph.gasparakis,
davem
This patch provides a very simple means for device drivers to obtain access to
the VXLAN destination port number configuration. This information is needed
in order to provide devices with a means of determining if a given UDP flow is
a VXLAN flow or if it is a standard flow for offload purposes.
The main disadvantage with this approach is that loading a driver that calls
this interface will mean that it will also load the vxlan module and any other
modules it depends on. To that end I really hope at some point the value
becomes static as we could then avoid this extra overhead. The alternative to
this though is significantly more complicated as it would likely require
registering notifiers to capture when the vxlan module is loaded and then
updating the value.
This patch adds a new header, if_vxlan.h which I suspect will slowly be
populated with more details such as the header layout as more devices end up
needing to figure out how to parse VXLAN for various offloads.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
drivers/net/vxlan.c | 7 +++++++
include/linux/if_vxlan.h | 28 ++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 0 deletions(-)
create mode 100644 include/linux/if_vxlan.h
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 62a4438..5b3bb9a 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -898,6 +898,13 @@ static u16 vxlan_src_port(const struct vxlan_dev *vxlan, struct sk_buff *skb)
return (((u64) hash * range) >> 32) + vxlan->port_min;
}
+/* simple accessor function for getting VXLAN destination port number */
+int vxlan_dst_port(void)
+{
+ return vxlan_port;
+}
+EXPORT_SYMBOL_GPL(vxlan_dst_port);
+
static int handle_offloads(struct sk_buff *skb)
{
if (skb_is_gso(skb)) {
diff --git a/include/linux/if_vxlan.h b/include/linux/if_vxlan.h
new file mode 100644
index 0000000..b997eac
--- /dev/null
+++ b/include/linux/if_vxlan.h
@@ -0,0 +1,28 @@
+/*
+ * VXLAN: Virtual eXtensible Local Area Network
+ *
+ * Copyright (c) 2013, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ */
+
+#if IS_ENABLED(CONFIG_VXLAN)
+extern int vxlan_dst_port(void);
+#else
+static inline int vxlan_dst_port(void)
+{
+ return 0;
+}
+#endif
^ permalink raw reply related
* Re: [PATCH net-next] vxlan: Provide means for obtaining port information
From: Stephen Hemminger @ 2013-03-27 21:38 UTC (permalink / raw)
To: Alexander Duyck
Cc: netdev, jesse, pshelar, jeffrey.t.kirsher, shemminger,
joseph.gasparakis, davem
In-Reply-To: <20130327212842.13367.68803.stgit@ahduyck-cp1.jf.intel.com>
On Wed, 27 Mar 2013 14:33:11 -0700
Alexander Duyck <alexander.h.duyck@intel.com> wrote:
> This patch provides a very simple means for device drivers to obtain access to
> the VXLAN destination port number configuration. This information is needed
> in order to provide devices with a means of determining if a given UDP flow is
> a VXLAN flow or if it is a standard flow for offload purposes.
>
> The main disadvantage with this approach is that loading a driver that calls
> this interface will mean that it will also load the vxlan module and any other
> modules it depends on. To that end I really hope at some point the value
> becomes static as we could then avoid this extra overhead. The alternative to
> this though is significantly more complicated as it would likely require
> registering notifiers to capture when the vxlan module is loaded and then
> updating the value.
>
> This patch adds a new header, if_vxlan.h which I suspect will slowly be
> populated with more details such as the header layout as more devices end up
> needing to figure out how to parse VXLAN for various offloads.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
>
> drivers/net/vxlan.c | 7 +++++++
> include/linux/if_vxlan.h | 28 ++++++++++++++++++++++++++++
> 2 files changed, 35 insertions(+), 0 deletions(-)
> create mode 100644 include/linux/if_vxlan.h
>
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index 62a4438..5b3bb9a 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -898,6 +898,13 @@ static u16 vxlan_src_port(const struct vxlan_dev *vxlan, struct sk_buff *skb)
> return (((u64) hash * range) >> 32) + vxlan->port_min;
> }
>
> +/* simple accessor function for getting VXLAN destination port number */
> +int vxlan_dst_port(void)
> +{
> + return vxlan_port;
> +}
> +EXPORT_SYMBOL_GPL(vxlan_dst_port);
> +
> static int handle_offloads(struct sk_buff *skb)
> {
> if (skb_is_gso(skb)) {
> diff --git a/include/linux/if_vxlan.h b/include/linux/if_vxlan.h
> new file mode 100644
> index 0000000..b997eac
> --- /dev/null
> +++ b/include/linux/if_vxlan.h
> @@ -0,0 +1,28 @@
> +/*
> + * VXLAN: Virtual eXtensible Local Area Network
> + *
> + * Copyright (c) 2013, Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
> + * Place - Suite 330, Boston, MA 02111-1307 USA.
> + *
> + */
> +
> +#if IS_ENABLED(CONFIG_VXLAN)
> +extern int vxlan_dst_port(void);
> +#else
> +static inline int vxlan_dst_port(void)
> +{
> + return 0;
> +}
> +#endif
Won't this all break if we what Dave wants and allow listening on multiple ports.
The port should be a property of the vxlan device not global.
^ permalink raw reply
* Re: [PATCH net-next] vxlan: Provide means for obtaining port information
From: Alexander Duyck @ 2013-03-27 21:48 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, jesse, pshelar, jeffrey.t.kirsher, shemminger,
joseph.gasparakis, davem
In-Reply-To: <20130327143849.29afdbdc@nehalam.linuxnetplumber.net>
On 03/27/2013 02:38 PM, Stephen Hemminger wrote:
> On Wed, 27 Mar 2013 14:33:11 -0700
> Alexander Duyck <alexander.h.duyck@intel.com> wrote:
>
>> This patch provides a very simple means for device drivers to obtain access to
>> the VXLAN destination port number configuration. This information is needed
>> in order to provide devices with a means of determining if a given UDP flow is
>> a VXLAN flow or if it is a standard flow for offload purposes.
>>
>> The main disadvantage with this approach is that loading a driver that calls
>> this interface will mean that it will also load the vxlan module and any other
>> modules it depends on. To that end I really hope at some point the value
>> becomes static as we could then avoid this extra overhead. The alternative to
>> this though is significantly more complicated as it would likely require
>> registering notifiers to capture when the vxlan module is loaded and then
>> updating the value.
>>
>> This patch adds a new header, if_vxlan.h which I suspect will slowly be
>> populated with more details such as the header layout as more devices end up
>> needing to figure out how to parse VXLAN for various offloads.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> ---
>>
>> drivers/net/vxlan.c | 7 +++++++
>> include/linux/if_vxlan.h | 28 ++++++++++++++++++++++++++++
>> 2 files changed, 35 insertions(+), 0 deletions(-)
>> create mode 100644 include/linux/if_vxlan.h
>>
>> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
>> index 62a4438..5b3bb9a 100644
>> --- a/drivers/net/vxlan.c
>> +++ b/drivers/net/vxlan.c
>> @@ -898,6 +898,13 @@ static u16 vxlan_src_port(const struct vxlan_dev *vxlan, struct sk_buff *skb)
>> return (((u64) hash * range) >> 32) + vxlan->port_min;
>> }
>>
>> +/* simple accessor function for getting VXLAN destination port number */
>> +int vxlan_dst_port(void)
>> +{
>> + return vxlan_port;
>> +}
>> +EXPORT_SYMBOL_GPL(vxlan_dst_port);
>> +
>> static int handle_offloads(struct sk_buff *skb)
>> {
>> if (skb_is_gso(skb)) {
>> diff --git a/include/linux/if_vxlan.h b/include/linux/if_vxlan.h
>> new file mode 100644
>> index 0000000..b997eac
>> --- /dev/null
>> +++ b/include/linux/if_vxlan.h
>> @@ -0,0 +1,28 @@
>> +/*
>> + * VXLAN: Virtual eXtensible Local Area Network
>> + *
>> + * Copyright (c) 2013, Intel Corporation.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along with
>> + * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
>> + * Place - Suite 330, Boston, MA 02111-1307 USA.
>> + *
>> + */
>> +
>> +#if IS_ENABLED(CONFIG_VXLAN)
>> +extern int vxlan_dst_port(void);
>> +#else
>> +static inline int vxlan_dst_port(void)
>> +{
>> + return 0;
>> +}
>> +#endif
> Won't this all break if we what Dave wants and allow listening on multiple ports.
> The port should be a property of the vxlan device not global.
Yes this will break if we ended up supporting a different port per
VXLAN. The problem is a port per VXLAN is going to be much more
difficult to support for any sort of hardware offload as well. What we
end up having to do is add a significant number of filters just to
identify all of the possible ports that may be used. In addition it
will mean having to add some sort of notifier as I mentioned in the
patch description since we will have VXLANs going into and out of
existence, each one with their own port number..
This was essentially a "good enough for now" fix to address the fact
that I needed the port number for offload testing, but I will sit back
and wait for the port per VXLAN stuff to be pushed in before I take any
steps to try to sort that out.
Thanks,
Alex
^ permalink raw reply
* [net-next PATCH] [RFC] net: add option to enable error queue packets waking select
From: Jacob Keller @ 2013-03-27 22:00 UTC (permalink / raw)
To: netdev; +Cc: Jeffrey Kirsher, Richard Cochran
Currently, when a socket receives something on the error queue it only wakes up
the socket on select if it is in the "read" list, that is the socket has
something to read. It is useful also to wake the socket if it is in the error
list, which would enable software to wait on error queue packets without waking
up for regular data on the socket. The main use case is for receiving
timestamped transmit packets which return the timestamp to the socket via the
error queue. This enables an application to select on the socket for the error
queue only instead of for the regular traffic.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Cc: Jeffrey Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Richard Cochran <richardcochran@gmail.com>
---
include/net/sock.h | 1 +
include/uapi/asm-generic/socket.h | 2 ++
net/core/datagram.c | 5 ++++-
net/core/sock.c | 8 ++++++++
net/unix/af_unix.c | 5 ++++-
5 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 14f6e9d..08f05f9 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -667,6 +667,7 @@ enum sock_flags {
* user-space instead.
*/
SOCK_FILTER_LOCKED, /* Filter cannot be changed anymore */
+ SOCK_SELECT_ERR_QUEUE, /* Wake select on error queue */
};
static inline void sock_copy_flags(struct sock *nsk, struct sock *osk)
diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
index 4ef3acb..c5d2e3a 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -74,4 +74,6 @@
#define SO_LOCK_FILTER 44
+#define SO_SELECT_ERR_QUEUE 45
+
#endif /* __ASM_GENERIC_SOCKET_H */
diff --git a/net/core/datagram.c b/net/core/datagram.c
index 368f9c3..f7d7b64 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -748,8 +748,11 @@ unsigned int datagram_poll(struct file *file, struct socket *sock,
mask = 0;
/* exceptional events? */
- if (sk->sk_err || !skb_queue_empty(&sk->sk_error_queue))
+ if (sk->sk_err || !skb_queue_empty(&sk->sk_error_queue)) {
mask |= POLLERR;
+ if (sock_flag(sk, SOCK_SELECT_ERR_QUEUE))
+ mask |= POLLPRI;
+ }
if (sk->sk_shutdown & RCV_SHUTDOWN)
mask |= POLLRDHUP | POLLIN | POLLRDNORM;
if (sk->sk_shutdown == SHUTDOWN_MASK)
diff --git a/net/core/sock.c b/net/core/sock.c
index a19e728..2ff5f36 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -907,6 +907,10 @@ set_rcvbuf:
sock_valbool_flag(sk, SOCK_NOFCS, valbool);
break;
+ case SO_SELECT_ERR_QUEUE:
+ sock_valbool_flag(sk, SOCK_SELECT_ERR_QUEUE, valbool);
+ break;
+
default:
ret = -ENOPROTOOPT;
break;
@@ -1160,6 +1164,10 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
v.val = sock_flag(sk, SOCK_FILTER_LOCKED);
break;
+ case SO_SELECT_ERR_QUEUE:
+ v.val = sock_flag(sk, SOCK_SELECT_ERR_QUEUE);
+ break;
+
default:
return -ENOPROTOOPT;
}
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 51be64f..f435555 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -2196,8 +2196,11 @@ static unsigned int unix_dgram_poll(struct file *file, struct socket *sock,
mask = 0;
/* exceptional events? */
- if (sk->sk_err || !skb_queue_empty(&sk->sk_error_queue))
+ if (sk->sk_err || !skb_queue_empty(&sk->sk_error_queue)) {
mask |= POLLERR;
+ if (sock_flag(sk, SOCK_SELECT_ERR_QUEUE))
+ mask |= POLLPRI;
+ }
if (sk->sk_shutdown & RCV_SHUTDOWN)
mask |= POLLRDHUP | POLLIN | POLLRDNORM;
if (sk->sk_shutdown == SHUTDOWN_MASK)
^ permalink raw reply related
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Hannes Frederic Sowa @ 2013-03-27 22:02 UTC (permalink / raw)
To: Huang, Xiong; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <157393863283F442885425D2C4542856489E8232@nasanexd02f.na.qualcomm.com>
On Tue, Mar 26, 2013 at 04:44:50AM +0000, Huang, Xiong wrote:
> You can try to get windows register setting by
>
> Pci config space register 0x80/0x84
> For example, to read register 0x1480
> Pci configure write 0x1480 to [0x80] (32bit)
> Pci configure read [0x84]
>
> Only 32 bit read/write is allowed.
Here we go. In Linux we reread the registers with the same method, again.
Perhaps you can see something:
Register Reg-Num Linux Windows XOR
-------------------------------------------------------------------------------
REG_BASE_CPU_NUMBER 0x157c 0x0 0x0 0x0
REG_BIST0_CTRL 0x141c 0x0 0x0 0x0
REG_BIST1_CTRL 0x1420 0x0 0x0 0x0
REG_CMBDISDMA_TIMER 0x140e 0xc3503c01 0xffff1c01 0x3caf2000
REG_DEBUG_DATA0 0x1900 0x1000 0x1f2f 0xf2f
REG_DEBUG_DATA1 0x1904 0x90004800 0x0 0x90004800
REG_DESC_BASE_ADDR_HI 0x1540 0x0 0x0 0x0
REG_DEVICE_CAP 0x5c 0x647f85 0x647f85 0x0
REG_DEVICE_CTRL 0x60 0x1a2000 0x112000 0xb0000
REG_DMA_CTRL 0x15c0 0x247c24 0x247c54 0x70
REG_GPHY_CTRL 0x140c 0xc3503c01 0xffff1c01 0x3caf2000
REG_HOST_RXF0_MB0_LO 0x1820 0xcf981404 0xa72c8510 0x68b49114
REG_HOST_RXF0_MB1_LO 0x1824 0xcf981408 0xa7308c20 0x68a89828
REG_HOST_RXF0_PAGE0_LO 0x1544 0xcf900800 0xa72c8600 0x68bc8e00
REG_HOST_RXF0_PAGE0_VLD 0x15f4 0x1010101 0x1b19 0x1011a18
REG_HOST_RXF0_PAGE1_LO 0x1548 0xcf940e00 0xa7308d00 0x68a48300
REG_HOST_RXF0_PAGE1_VLD 0x15f5 0x1010101 0x1b19 0x1011a18
REG_HOST_RXF0_PAGEOFF 0x1800 0x2e640 0xc01de00 0xc033840
REG_HOST_RXF1_MB0_LO 0x1828 0x0 0x0 0x0
REG_HOST_RXF1_MB1_LO 0x182c 0x0 0x0 0x0
REG_HOST_RXF1_PAGE0_LO 0x15d0 0x0 0x0 0x0
REG_HOST_RXF1_PAGE0_VLD 0x15f6 0x1010101 0x1b19 0x1011a18
REG_HOST_RXF1_PAGE1_LO 0x15d4 0x0 0x0 0x0
REG_HOST_RXF1_PAGE1_VLD 0x15f7 0x1010101 0x1b19 0x1011a18
REG_HOST_RXF1_PAGEOFF 0x1808 0x0 0x0 0x0
REG_HOST_RXF2_MB0_LO 0x1830 0x0 0x0 0x0
REG_HOST_RXF2_MB1_LO 0x1834 0x0 0x0 0x0
REG_HOST_RXF2_PAGE0_LO 0x15d8 0x0 0x0 0x0
REG_HOST_RXF2_PAGE0_VLD 0x15f8 0x1010101 0x0 0x1010101
REG_HOST_RXF2_PAGE1_LO 0x15dc 0x0 0x0 0x0
REG_HOST_RXF2_PAGE1_VLD 0x15f9 0x1010101 0x0 0x1010101
REG_HOST_RXF2_PAGEOFF 0x180c 0x0 0x0 0x0
REG_HOST_RXF3_MB0_LO 0x1838 0x0 0x0 0x0
REG_HOST_RXF3_MB1_LO 0x183c 0x0 0x0 0x0
REG_HOST_RXF3_PAGE0_LO 0x15e0 0x0 0x0 0x0
REG_HOST_RXF3_PAGE0_VLD 0x15fa 0x1010101 0x0 0x1010101
REG_HOST_RXF3_PAGE1_LO 0x15e4 0x0 0x0 0x0
REG_HOST_RXF3_PAGE1_VLD 0x15fb 0x1010101 0x0 0x1010101
REG_HOST_RXF3_PAGEOFF 0x1810 0x0 0x0 0x0
REG_HOST_RXFPAGE_SIZE 0x1558 0x40000 0x40000 0x0
REG_HOST_SMB_ADDR_LO 0x1844 0x0 0x0 0x0
REG_HOST_TX_CMB_LO 0x1840 0xcf981400 0xcff75000 0x6f4400
REG_IDLE_STATUS 0x1410 0x0 0x0 0x0
REG_IDT_TABLE0 0x1560 0x0 0xe4e4e4e4 0xe4e4e4e4
REG_IDT_TABLE1 0x1564 0xe4e4e4e4 0xe4e4e4e4 0x0
REG_IDT_TABLE2 0x1568 0xe4e4e4e4 0xe4e4e4e4 0x0
REG_IDT_TABLE3 0x156c 0xe4e4e4e4 0xe4e4e4e4 0x0
REG_IDT_TABLE4 0x14e0 0xe4e4e4e4 0xe4e4e4e4 0x0
REG_IDT_TABLE5 0x14e4 0xe4e4e4e4 0xe4e4e4e4 0x0
REG_IDT_TABLE6 0x14e8 0xe4e4e4e4 0xe4e4e4e4 0x0
REG_IDT_TABLE7 0x14ec 0xe4e4e4e4 0xe4e4e4e4 0x0
REG_IMR 0x1604 0x10035d1d 0x12035e1d 0x2000300
REG_IRQ_MODU_TIMER2_INIT 0x140a 0x640064 0x640064 0x0
REG_IRQ_MODU_TIMER_INIT 0x1408 0x640064 0x640064 0x0
REG_ISR 0x1600 0x5000000 0x8c00000 0xdc00000
REG_LOAD_PTR 0x1534 0x0 0x0 0x0
REG_LTSSM_TEST_MODE 0x12fc 0x6500 0x6500 0x0
REG_MAC_CTRL 0x1480 0x4105cef 0x4105cef 0x0
REG_MAC_HALF_DUPLX_CTRL 0x1498 0x7a1f037 0x7a1f037 0x0
REG_MAC_IPG_IFG 0x1484 0x60405060 0x60405060 0x0
REG_MAC_RX_STATUS_BIN 0x1700 0x0 0x0 0x0
REG_MAC_RX_STATUS_END 0x175c 0x0 0x0 0x0
REG_MAC_STA_ADDR 0x1488 0x8c5d5ea7 0x8c5d5ea7 0x0
REG_MAC_TX_STATUS_BIN 0x1760 0x0 0x0 0x0
REG_MAC_TX_STATUS_END 0x17c0 0x0 0x0 0x0
REG_MANUAL_TIMER_INIT 0x1404 0x0 0x0 0x0
REG_MASTER_CTRL 0x1400 0xb0020224 0xb0020224 0x0
REG_MB_RXF1_RADDR 0x15b4 0x0 0x0 0x0
REG_MB_RXF2_RADDR 0x15b8 0x0 0x0 0x0
REG_MB_RXF3_RADDR 0x15bc 0x0 0x0 0x0
REG_MB_TPD_PROD_IDX 0x15f0 0xf 0x128 0x127
REG_MDIO_CTRL 0x1414 0x717c1c 0x1e0ba8 0x6f77b4
REG_MTU 0x149c 0x5f2 0x5f2 0x0
REG_PCIE_CAP_LIST 0x58 0x10010 0x10010 0x0
REG_PCIE_DEV_MISC_CTRL 0x21c 0xc00 0xc00 0x0
REG_PCIE_PHYMISC 0x1000 0x78ff2580 0x78ff25a0 0x20
REG_PHY_STATUS 0x1418 0x7c700dd 0x7c700dd 0x0
REG_PM_CTRLSTAT 0x44 0x0 0x100 0x100
REG_RSS_HASH_FLAG 0x1574 0x0 0x0 0x0
REG_RSS_HASH_VALUE 0x1570 0x0 0x0 0x0
REG_RSS_KEY0 0x14b0 0xbeac01fa 0xbeac01fa 0x0
REG_RSS_KEY1 0x14b4 0x6a42b73b 0x6a42b73b 0x0
REG_RSS_KEY2 0x14b8 0x8030f20c 0x8030f20c 0x0
REG_RSS_KEY3 0x14bc 0x77cb2da3 0x77cb2da3 0x0
REG_RSS_KEY4 0x14c0 0xae7b30b4 0xae7b30b4 0x0
REG_RSS_KEY5 0x14c4 0xd0ca2bcb 0xd0ca2bcb 0x0
REG_RSS_KEY6 0x14c8 0x43a38fb0 0x43a38fb0 0x0
REG_RSS_KEY7 0x14cc 0x4167253d 0x4167253d 0x0
REG_RSS_KEY8 0x14d0 0x255b0ec2 0x255b0ec2 0x0
REG_RSS_KEY9 0x14d4 0x6d5a56da 0x6d5a56da 0x0
REG_RXF0_BASE_ADDR_HI 0x1540 0x0 0x0 0x0
REG_RXF1_BASE_ADDR_HI 0x1550 0x0 0x0 0x0
REG_RXF2_BASE_ADDR_HI 0x1554 0x0 0x0 0x0
REG_RXF3_BASE_ADDR_HI 0x153c 0x0 0x0 0x0
REG_RXQ_CTRL 0x15a0 0xc0000080 0xc0001083 0x1003
REG_RXQ_JMBOSZ_RRDTIM 0x15a4 0x8bf 0x8be 0x1
REG_RXQ_RXF_PAUSE_THRESH 0x15a8 0xcc0333 0x400310 0x8c0023
REG_RX_HASH_TABLE 0x1490 0x80100000 0x80028100 0x128100
REG_SERDES_LOCK 0x1424 0xbb23 0xbb23 0x0
REG_SMB_STAT_TIMER 0x15c4 0x30d40 0x30d40 0x0
REG_SRAM_PKTH_ADDR 0x1532 0x40007e0 0x40007e0 0x0
REG_SRAM_RXF_ADDR 0x1520 0x3ff0000 0x3ff0000 0x0
REG_SRAM_RXF_LEN 0x1524 0x400 0x400 0x0
REG_SRAM_TCPH_ADDR 0x1530 0x40007e0 0x40007e0 0x0
REG_SRAM_TRD_ADDR 0x1518 0x7df07c0 0x7df07c0 0x0
REG_SRAM_TRD_LEN 0x151c 0x20 0x20 0x0
REG_SRAM_TXF_ADDR 0x1528 0x7bf0400 0x7bf0400 0x0
REG_SRAM_TXF_LEN 0x152c 0x3c0 0x3c0 0x0
REG_TPD_BASE_ADDR_LO 0x154c 0xcf900000 0xcff75010 0x675010
REG_TPD_CONS_IDX 0x1804 0xf 0x128 0x127
REG_TPD_RING_SIZE 0x155c 0x80 0x400 0x480
REG_TRIG_RRD_THRESH 0x15ca 0x10040 0x40010 0x50050
REG_TRIG_RXTIMER 0x15ce 0x40085 0x40004 0x81
REG_TRIG_TPD_THRESH 0x15c8 0x10040 0x40010 0x50050
REG_TRIG_TXTIMER 0x15cc 0x40085 0x40004 0x81
REG_TXQ_CTRL 0x1580 0x2000065 0x1000065 0x3000000
REG_TX_EARLY_TH 0x1584 0xbf 0xbf 0x0
REG_VPD_CAP 0x6c 0x3 0x3 0x0
REG_VPD_DATA 0x70 0x0 0x0 0x0
REG_WOL_CTRL 0x14a0 0x0 0x0 0x0
REG_WOL_PATTERN_LEN 0x14a4 0x0 0x0 0x0
Thanks,
Hannes
^ permalink raw reply
* RE: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Huang, Xiong @ 2013-03-27 22:28 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <20130327220248.GD23223@order.stressinduktion.org>
Hi Hnnes
What Windows are you using ? XP or Win7 ?
> -----Original Message-----
> From: Hannes Frederic Sowa [mailto:hannes@stressinduktion.org]
> Sent: Thursday, March 28, 2013 6:03 AM
> To: Huang, Xiong
> Cc: Sven Hartge; netdev@vger.kernel.org
> Subject: Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or
> Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba
> (updated) Version 2
>
> On Tue, Mar 26, 2013 at 04:44:50AM +0000, Huang, Xiong wrote:
> > You can try to get windows register setting by
> >
> > Pci config space register 0x80/0x84
> > For example, to read register 0x1480
> > Pci configure write 0x1480 to [0x80] (32bit) Pci configure read [0x84]
> >
> > Only 32 bit read/write is allowed.
>
> Here we go. In Linux we reread the registers with the same method, again.
> Perhaps you can see something:
>
>
> Register Reg-Num Linux Windows XOR
> -------------------------------------------------------------------------------
> REG_BASE_CPU_NUMBER 0x157c 0x0 0x0 0x0
> REG_BIST0_CTRL 0x141c 0x0 0x0 0x0
> REG_BIST1_CTRL 0x1420 0x0 0x0 0x0
> REG_CMBDISDMA_TIMER 0x140e 0xc3503c01 0xffff1c01
> 0x3caf2000
> REG_DEBUG_DATA0 0x1900 0x1000 0x1f2f 0xf2f
> REG_DEBUG_DATA1 0x1904 0x90004800 0x0 0x90004800
> REG_DESC_BASE_ADDR_HI 0x1540 0x0 0x0 0x0
> REG_DEVICE_CAP 0x5c 0x647f85 0x647f85 0x0
> REG_DEVICE_CTRL 0x60 0x1a2000 0x112000 0xb0000
> REG_DMA_CTRL 0x15c0 0x247c24 0x247c54 0x70
> REG_GPHY_CTRL 0x140c 0xc3503c01 0xffff1c01 0x3caf2000
> REG_HOST_RXF0_MB0_LO 0x1820 0xcf981404 0xa72c8510
> 0x68b49114
> REG_HOST_RXF0_MB1_LO 0x1824 0xcf981408 0xa7308c20
> 0x68a89828
> REG_HOST_RXF0_PAGE0_LO 0x1544 0xcf900800 0xa72c8600
> 0x68bc8e00
> REG_HOST_RXF0_PAGE0_VLD 0x15f4 0x1010101 0x1b19
> 0x1011a18
> REG_HOST_RXF0_PAGE1_LO 0x1548 0xcf940e00 0xa7308d00
> 0x68a48300
> REG_HOST_RXF0_PAGE1_VLD 0x15f5 0x1010101 0x1b19
> 0x1011a18
> REG_HOST_RXF0_PAGEOFF 0x1800 0x2e640 0xc01de00 0xc033840
> REG_HOST_RXF1_MB0_LO 0x1828 0x0 0x0 0x0
> REG_HOST_RXF1_MB1_LO 0x182c 0x0 0x0 0x0
> REG_HOST_RXF1_PAGE0_LO 0x15d0 0x0 0x0 0x0
> REG_HOST_RXF1_PAGE0_VLD 0x15f6 0x1010101 0x1b19
> 0x1011a18
> REG_HOST_RXF1_PAGE1_LO 0x15d4 0x0 0x0 0x0
> REG_HOST_RXF1_PAGE1_VLD 0x15f7 0x1010101 0x1b19
> 0x1011a18
> REG_HOST_RXF1_PAGEOFF 0x1808 0x0 0x0 0x0
> REG_HOST_RXF2_MB0_LO 0x1830 0x0 0x0 0x0
> REG_HOST_RXF2_MB1_LO 0x1834 0x0 0x0 0x0
> REG_HOST_RXF2_PAGE0_LO 0x15d8 0x0 0x0 0x0
> REG_HOST_RXF2_PAGE0_VLD 0x15f8 0x1010101 0x0 0x1010101
> REG_HOST_RXF2_PAGE1_LO 0x15dc 0x0 0x0 0x0
> REG_HOST_RXF2_PAGE1_VLD 0x15f9 0x1010101 0x0 0x1010101
> REG_HOST_RXF2_PAGEOFF 0x180c 0x0 0x0 0x0
> REG_HOST_RXF3_MB0_LO 0x1838 0x0 0x0 0x0
> REG_HOST_RXF3_MB1_LO 0x183c 0x0 0x0 0x0
> REG_HOST_RXF3_PAGE0_LO 0x15e0 0x0 0x0 0x0
> REG_HOST_RXF3_PAGE0_VLD 0x15fa 0x1010101 0x0 0x1010101
> REG_HOST_RXF3_PAGE1_LO 0x15e4 0x0 0x0 0x0
> REG_HOST_RXF3_PAGE1_VLD 0x15fb 0x1010101 0x0 0x1010101
> REG_HOST_RXF3_PAGEOFF 0x1810 0x0 0x0 0x0
> REG_HOST_RXFPAGE_SIZE 0x1558 0x40000 0x40000 0x0
> REG_HOST_SMB_ADDR_LO 0x1844 0x0 0x0 0x0
> REG_HOST_TX_CMB_LO 0x1840 0xcf981400 0xcff75000 0x6f4400
> REG_IDLE_STATUS 0x1410 0x0 0x0 0x0
> REG_IDT_TABLE0 0x1560 0x0 0xe4e4e4e4 0xe4e4e4e4
> REG_IDT_TABLE1 0x1564 0xe4e4e4e4 0xe4e4e4e4 0x0
> REG_IDT_TABLE2 0x1568 0xe4e4e4e4 0xe4e4e4e4 0x0
> REG_IDT_TABLE3 0x156c 0xe4e4e4e4 0xe4e4e4e4 0x0
> REG_IDT_TABLE4 0x14e0 0xe4e4e4e4 0xe4e4e4e4 0x0
> REG_IDT_TABLE5 0x14e4 0xe4e4e4e4 0xe4e4e4e4 0x0
> REG_IDT_TABLE6 0x14e8 0xe4e4e4e4 0xe4e4e4e4 0x0
> REG_IDT_TABLE7 0x14ec 0xe4e4e4e4 0xe4e4e4e4 0x0
> REG_IMR 0x1604 0x10035d1d 0x12035e1d 0x2000300
> REG_IRQ_MODU_TIMER2_INIT 0x140a 0x640064 0x640064 0x0
> REG_IRQ_MODU_TIMER_INIT 0x1408 0x640064 0x640064 0x0
> REG_ISR 0x1600 0x5000000 0x8c00000 0xdc00000
> REG_LOAD_PTR 0x1534 0x0 0x0 0x0
> REG_LTSSM_TEST_MODE 0x12fc 0x6500 0x6500 0x0
> REG_MAC_CTRL 0x1480 0x4105cef 0x4105cef 0x0
> REG_MAC_HALF_DUPLX_CTRL 0x1498 0x7a1f037 0x7a1f037 0x0
> REG_MAC_IPG_IFG 0x1484 0x60405060 0x60405060 0x0
> REG_MAC_RX_STATUS_BIN 0x1700 0x0 0x0 0x0
> REG_MAC_RX_STATUS_END 0x175c 0x0 0x0 0x0
> REG_MAC_STA_ADDR 0x1488 0x8c5d5ea7 0x8c5d5ea7 0x0
> REG_MAC_TX_STATUS_BIN 0x1760 0x0 0x0 0x0
> REG_MAC_TX_STATUS_END 0x17c0 0x0 0x0 0x0
> REG_MANUAL_TIMER_INIT 0x1404 0x0 0x0 0x0
> REG_MASTER_CTRL 0x1400 0xb0020224 0xb0020224 0x0
> REG_MB_RXF1_RADDR 0x15b4 0x0 0x0 0x0
> REG_MB_RXF2_RADDR 0x15b8 0x0 0x0 0x0
> REG_MB_RXF3_RADDR 0x15bc 0x0 0x0 0x0
> REG_MB_TPD_PROD_IDX 0x15f0 0xf 0x128 0x127
> REG_MDIO_CTRL 0x1414 0x717c1c 0x1e0ba8 0x6f77b4
> REG_MTU 0x149c 0x5f2 0x5f2 0x0
> REG_PCIE_CAP_LIST 0x58 0x10010 0x10010 0x0
> REG_PCIE_DEV_MISC_CTRL 0x21c 0xc00 0xc00 0x0
> REG_PCIE_PHYMISC 0x1000 0x78ff2580 0x78ff25a0 0x20
> REG_PHY_STATUS 0x1418 0x7c700dd 0x7c700dd 0x0
> REG_PM_CTRLSTAT 0x44 0x0 0x100 0x100
> REG_RSS_HASH_FLAG 0x1574 0x0 0x0 0x0
> REG_RSS_HASH_VALUE 0x1570 0x0 0x0 0x0
> REG_RSS_KEY0 0x14b0 0xbeac01fa 0xbeac01fa 0x0
> REG_RSS_KEY1 0x14b4 0x6a42b73b 0x6a42b73b 0x0
> REG_RSS_KEY2 0x14b8 0x8030f20c 0x8030f20c 0x0
> REG_RSS_KEY3 0x14bc 0x77cb2da3 0x77cb2da3 0x0
> REG_RSS_KEY4 0x14c0 0xae7b30b4 0xae7b30b4 0x0
> REG_RSS_KEY5 0x14c4 0xd0ca2bcb 0xd0ca2bcb 0x0
> REG_RSS_KEY6 0x14c8 0x43a38fb0 0x43a38fb0 0x0
> REG_RSS_KEY7 0x14cc 0x4167253d 0x4167253d 0x0
> REG_RSS_KEY8 0x14d0 0x255b0ec2 0x255b0ec2 0x0
> REG_RSS_KEY9 0x14d4 0x6d5a56da 0x6d5a56da 0x0
> REG_RXF0_BASE_ADDR_HI 0x1540 0x0 0x0 0x0
> REG_RXF1_BASE_ADDR_HI 0x1550 0x0 0x0 0x0
> REG_RXF2_BASE_ADDR_HI 0x1554 0x0 0x0 0x0
> REG_RXF3_BASE_ADDR_HI 0x153c 0x0 0x0 0x0
> REG_RXQ_CTRL 0x15a0 0xc0000080 0xc0001083 0x1003
> REG_RXQ_JMBOSZ_RRDTIM 0x15a4 0x8bf 0x8be 0x1
> REG_RXQ_RXF_PAUSE_THRESH 0x15a8 0xcc0333 0x400310
> 0x8c0023
> REG_RX_HASH_TABLE 0x1490 0x80100000 0x80028100 0x128100
> REG_SERDES_LOCK 0x1424 0xbb23 0xbb23 0x0
> REG_SMB_STAT_TIMER 0x15c4 0x30d40 0x30d40 0x0
> REG_SRAM_PKTH_ADDR 0x1532 0x40007e0 0x40007e0 0x0
> REG_SRAM_RXF_ADDR 0x1520 0x3ff0000 0x3ff0000 0x0
> REG_SRAM_RXF_LEN 0x1524 0x400 0x400 0x0
> REG_SRAM_TCPH_ADDR 0x1530 0x40007e0 0x40007e0 0x0
> REG_SRAM_TRD_ADDR 0x1518 0x7df07c0 0x7df07c0 0x0
> REG_SRAM_TRD_LEN 0x151c 0x20 0x20 0x0
> REG_SRAM_TXF_ADDR 0x1528 0x7bf0400 0x7bf0400 0x0
> REG_SRAM_TXF_LEN 0x152c 0x3c0 0x3c0 0x0
> REG_TPD_BASE_ADDR_LO 0x154c 0xcf900000 0xcff75010 0x675010
> REG_TPD_CONS_IDX 0x1804 0xf 0x128 0x127
> REG_TPD_RING_SIZE 0x155c 0x80 0x400 0x480
> REG_TRIG_RRD_THRESH 0x15ca 0x10040 0x40010 0x50050
> REG_TRIG_RXTIMER 0x15ce 0x40085 0x40004 0x81
> REG_TRIG_TPD_THRESH 0x15c8 0x10040 0x40010 0x50050
> REG_TRIG_TXTIMER 0x15cc 0x40085 0x40004 0x81
> REG_TXQ_CTRL 0x1580 0x2000065 0x1000065 0x3000000
> REG_TX_EARLY_TH 0x1584 0xbf 0xbf 0x0
> REG_VPD_CAP 0x6c 0x3 0x3 0x0
> REG_VPD_DATA 0x70 0x0 0x0 0x0
> REG_WOL_CTRL 0x14a0 0x0 0x0 0x0
> REG_WOL_PATTERN_LEN 0x14a4 0x0 0x0 0x0
>
> Thanks,
>
> Hannes
^ permalink raw reply
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Hannes Frederic Sowa @ 2013-03-27 22:34 UTC (permalink / raw)
To: Huang, Xiong; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <157393863283F442885425D2C45428564F1FDF82@nasanexd02f.na.qualcomm.com>
On Wed, Mar 27, 2013 at 10:28:24PM +0000, Huang, Xiong wrote:
> What Windows are you using ? XP or Win7 ?
It is a Windows 7 x86_64. The version of the windows driver is 1.0.0.45.
Thanks,
Hannes
^ permalink raw reply
* Re: [net-next PATCH] [RFC] net: add option to enable error queue packets waking select
From: Vick, Matthew @ 2013-03-27 23:43 UTC (permalink / raw)
To: Keller, Jacob E, netdev@vger.kernel.org
Cc: Kirsher, Jeffrey T, Richard Cochran
In-Reply-To: <20130327220028.13267.89112.stgit@jekeller-hub.jf.intel.com>
>index 4ef3acb..c5d2e3a 100644
>--- a/include/uapi/asm-generic/socket.h
>+++ b/include/uapi/asm-generic/socket.h
>@@ -74,4 +74,6 @@
>
> #define SO_LOCK_FILTER 44
>
>+#define SO_SELECT_ERR_QUEUE 45
>+
> #endif /* __ASM_GENERIC_SOCKET_H */
Shouldn't this also go in the arch/*/include/uapi/asm/socket.h headers?
^ permalink raw reply
* RE: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Huang, Xiong @ 2013-03-28 0:10 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <20130327223433.GE23223@order.stressinduktion.org>
There is no much difference on those registers :(
But you could try to replace :
static void atl1e_cal_ring_size(struct atl1e_adapter *adapter, u32 *ring_size)
{
*ring_size = ((u32)(adapter->tx_ring.count *
sizeof(struct atl1e_tpd_desc) + 7
/* tx ring, qword align */
+ adapter->rx_ring.real_page_size * AT_PAGE_NUM_PER_QUEUE *
adapter->num_rx_queues + 31
/* rx ring, 32 bytes align */
+ (1 + AT_PAGE_NUM_PER_QUEUE * adapter->num_rx_queues) *
16 + 15));
/* tx, rx cmd, dword align */
}
static int atl1e_setup_ring_resources(struct atl1e_adapter *adapter)
{
.....
/* Init CMB dma address */
offset = roundup(offset, 16);
tx_ring->cmb_dma = adapter->ring_dma + offset;
tx_ring->cmb = adapter->ring_vir_addr + offset;
offset += sizeof(u32);
offset = roundup(offset, 16);
for (i = 0; i < adapter->num_rx_queues; i++) {
for (j = 0; j < AT_PAGE_NUM_PER_QUEUE; j++) {
rx_page_desc[i].rx_page[j].write_offset_dma =
adapter->ring_dma + offset;
rx_page_desc[i].rx_page[j].write_offset_addr =
adapter->ring_vir_addr + offset;
offset += sizeof(u32);
offset = roundup(offset, 16);
}
}
.....
Just guess, no confidence on it ....
BR.
Xiong
> -----Original Message-----
> From: Hannes Frederic Sowa [mailto:hannes@stressinduktion.org]
> Sent: Thursday, March 28, 2013 6:35 AM
> To: Huang, Xiong
> Cc: Sven Hartge; netdev@vger.kernel.org
> Subject: Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or
> Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba
> (updated) Version 2
>
> On Wed, Mar 27, 2013 at 10:28:24PM +0000, Huang, Xiong wrote:
> > What Windows are you using ? XP or Win7 ?
>
> It is a Windows 7 x86_64. The version of the windows driver is 1.0.0.45.
>
> Thanks,
>
> Hannes
^ permalink raw reply
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Hannes Frederic Sowa @ 2013-03-28 0:40 UTC (permalink / raw)
To: Huang, Xiong; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <157393863283F442885425D2C45428564F1FFFCE@nasanexd02f.na.qualcomm.com>
On Thu, Mar 28, 2013 at 12:10:57AM +0000, Huang, Xiong wrote:
> There is no much difference on those registers :(
> But you could try to replace :
>
> static void atl1e_cal_ring_size(struct atl1e_adapter *adapter, u32 *ring_size)
> {
> *ring_size = ((u32)(adapter->tx_ring.count *
> sizeof(struct atl1e_tpd_desc) + 7
> /* tx ring, qword align */
> + adapter->rx_ring.real_page_size * AT_PAGE_NUM_PER_QUEUE *
> adapter->num_rx_queues + 31
> /* rx ring, 32 bytes align */
> + (1 + AT_PAGE_NUM_PER_QUEUE * adapter->num_rx_queues) *
> 16 + 15));
> /* tx, rx cmd, dword align */
> }
>
>
> static int atl1e_setup_ring_resources(struct atl1e_adapter *adapter)
> {
> .....
> /* Init CMB dma address */
> offset = roundup(offset, 16);
> tx_ring->cmb_dma = adapter->ring_dma + offset;
> tx_ring->cmb = adapter->ring_vir_addr + offset;
> offset += sizeof(u32);
> offset = roundup(offset, 16);
>
> for (i = 0; i < adapter->num_rx_queues; i++) {
> for (j = 0; j < AT_PAGE_NUM_PER_QUEUE; j++) {
> rx_page_desc[i].rx_page[j].write_offset_dma =
> adapter->ring_dma + offset;
> rx_page_desc[i].rx_page[j].write_offset_addr =
> adapter->ring_vir_addr + offset;
> offset += sizeof(u32);
> offset = roundup(offset, 16);
> }
> }
> .....
>
>
>
> Just guess, no confidence on it ....
No, problem still persists. :(
Btw, in the meantime I extracted another mmiotrace (this time with a dhcp
exchange) and resolved the symbols:
https://gist.github.com/hannes/5259468/raw/4c22dff854254c46534c1b87e477eff7d3ca2c5d/mmiotrace.txt
Perhaps it helps.
Thanks,
Hannes
^ permalink raw reply
* Re: [RFC][PATCH] iproute: Faster ip link add, set and delete
From: Eric W. Biederman @ 2013-03-28 0:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Benoit Lourdelet, Serge Hallyn, netdev@vger.kernel.org
In-Reply-To: <20130327104746.0ec9dcb5@nehalam.linuxnetplumber.net>
Stephen Hemminger <stephen@networkplumber.org> writes:
> If you need to do lots of operations the --batch mode will be significantly faster.
> One command start and one link map.
The problem in this case as I understand it is lots of independent
operations. Now maybe lxc should not shell out to ip and perform the
work itself.
> I have an updated version of link map hash (index and name). Could you test this patch
> which applies to latest version in git.
This still dumps all of the interfaces in ll_init_map causing things to
slow down noticably.
# with your patch
# time ~/projects/iproute/iproute2/ip/ip link add a4511 type veth peer name b4511
real 0m0.049s
user 0m0.000s
sys 0m0.048s
# With a hack to make ll_map_init a nop.
# time ~/projects/iproute/iproute2/ip/ip link add a4512 type veth peer name b4512
real 0m0.003s
user 0m0.000s
sys 0m0.000s
eric-ThinkPad-X220 6bed4 #
# Without any patches.
# time ~/projects/iproute/iproute2/ip/ip link add a5002 type veth peer name b5002
real 0m0.052s
user 0m0.004s
sys 0m0.044s
So it looks like dumping all of the interfaces is taking 46 miliseconds,
longer than otherwise. Causing ip to take nearly an order of magnitude
longer to run when there are a lot of interfaces, and causing ip to slow
down with each command.
So the ideal situation is probably just to fill in the ll_map on demand
instead of up front.
Eric
^ permalink raw reply
* RE: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Huang, Xiong @ 2013-03-28 1:01 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <20130328004024.GA2176@order.stressinduktion.org>
Please try to use following define in atl1e_hw.h
#define GPHY_CTRL_DEFAULT (\
GPHY_CTRL_SEL_ANA_RST |\
GPHY_CTRL_HIB_PULSE |\
GPHY_CTRL_HIB_EN)
BR
Xiong
> -----Original Message-----
> From: Hannes Frederic Sowa [mailto:hannes@stressinduktion.org]
> Sent: Thursday, March 28, 2013 8:40 AM
> To: Huang, Xiong
> Cc: Sven Hartge; netdev@vger.kernel.org
> Subject: Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or
> Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba
> (updated) Version 2
>
> On Thu, Mar 28, 2013 at 12:10:57AM +0000, Huang, Xiong wrote:
> > There is no much difference on those registers :( But you could try to
> > replace :
> >
> > static void atl1e_cal_ring_size(struct atl1e_adapter *adapter, u32
> > *ring_size) {
> > *ring_size = ((u32)(adapter->tx_ring.count *
> > sizeof(struct atl1e_tpd_desc) + 7
> > /* tx ring, qword align */
> > + adapter->rx_ring.real_page_size *
> AT_PAGE_NUM_PER_QUEUE *
> > adapter->num_rx_queues + 31
> > /* rx ring, 32 bytes align */
> > + (1 + AT_PAGE_NUM_PER_QUEUE * adapter-
> >num_rx_queues) *
> > 16 + 15));
> > /* tx, rx cmd, dword align */
> > }
> >
> >
> > static int atl1e_setup_ring_resources(struct atl1e_adapter *adapter) {
> > .....
> > /* Init CMB dma address */
> > offset = roundup(offset, 16);
> > tx_ring->cmb_dma = adapter->ring_dma + offset;
> > tx_ring->cmb = adapter->ring_vir_addr + offset;
> > offset += sizeof(u32);
> > offset = roundup(offset, 16);
> >
> > for (i = 0; i < adapter->num_rx_queues; i++) {
> > for (j = 0; j < AT_PAGE_NUM_PER_QUEUE; j++) {
> > rx_page_desc[i].rx_page[j].write_offset_dma =
> > adapter->ring_dma + offset;
> > rx_page_desc[i].rx_page[j].write_offset_addr =
> > adapter->ring_vir_addr + offset;
> > offset += sizeof(u32);
> > offset = roundup(offset, 16);
> > }
> > }
> > .....
> >
> >
> >
> > Just guess, no confidence on it ....
>
> No, problem still persists. :(
>
> Btw, in the meantime I extracted another mmiotrace (this time with a dhcp
> exchange) and resolved the symbols:
>
> https://gist.github.com/hannes/5259468/raw/4c22dff854254c46534c1b87e47
> 7eff7d3ca2c5d/mmiotrace.txt
>
> Perhaps it helps.
>
> Thanks,
>
> Hannes
^ permalink raw reply
* Re: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Hannes Frederic Sowa @ 2013-03-28 1:16 UTC (permalink / raw)
To: Huang, Xiong; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <157393863283F442885425D2C45428564F200FE9@nasanexd02f.na.qualcomm.com>
On Thu, Mar 28, 2013 at 01:01:05AM +0000, Huang, Xiong wrote:
> Please try to use following define in atl1e_hw.h
>
> #define GPHY_CTRL_DEFAULT (\
> GPHY_CTRL_SEL_ANA_RST |\
> GPHY_CTRL_HIB_PULSE |\
> GPHY_CTRL_HIB_EN)
No change either.
We will try to go with RXQ_CTRL_PBA_ALIGN_256 in REG_RXQ_CTRL next. Just have
to check the ring resources are initialized correctly.
Thanks,
Hannes
^ permalink raw reply
* RE: Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) 1.0.0.7 md5/sha1 corrupted using NFS and samba (updated) Version 2
From: Huang, Xiong @ 2013-03-28 1:17 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Sven Hartge, netdev@vger.kernel.org
In-Reply-To: <20130328011602.GB2176@order.stressinduktion.org>
>
> We will try to go with RXQ_CTRL_PBA_ALIGN_256 in REG_RXQ_CTRL next.
> Just have to check the ring resources are initialized correctly.
>
> Thanks,
ALIGN_256 require the RXF page 256 byte alignment, you should also revise the memory allocation function.
Thanks
Xiong
^ 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