* Re: [patch net-next v3 04/17] net: introduce generic switch devices support
From: Jamal Hadi Salim @ 2014-11-27 12:35 UTC (permalink / raw)
To: Simon Horman
Cc: Thomas Graf, Jiri Pirko, netdev, davem, nhorman, andy, dborkman,
ogerlitz, jesse, pshelar, azhou, ben, stephen, jeffrey.t.kirsher,
vyasevic, xiyou.wangcong, john.r.fastabend, edumazet, sfeldma,
f.fainelli, roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, alexander.h.duyck, john.ronciak, mleitner,
shrijeet, gospo, bcrl
In-Reply-To: <20141127031315.GD1649@vergenet.net>
On 11/26/14 22:13, Simon Horman wrote:
> On Tue, Nov 25, 2014 at 10:33:36PM -0500, Jamal Hadi Salim wrote:
[..]
> I may be missing the point but I see two problems that are solved by
> the switch abstraction.
>
> - Cases where no ports are configured.
>
> Perhaps no such use cases exist for the API in question.
> But it does seem plausible to me that non-physical ports could
> be added at run-time and that thus a "switch" could initially
> exist with no configured port. Something like how bridges
> initially have no ports (IIRC).
>
> - Discovering the association between ports and "switches".
>
> My recollection from the double round table discussion on the last day of
> the Düsseldorf sessions was that these were reasons that simply accessing
> any port belonging to the "switch" were not entirely satisfactory.
>
So in Du I illustrated in a slide the internals of the Realtek that
Ben had patches on. Ben first exposes the realtek ports and when
you wish you can build a bridge and attach the exposed ports
and then hardware switching functionality is used. What is interesting
about it is infact you didnt need to use the switching on it. You
could attach a filter to any of the exposed ports, then specify an
action to do a redirect to another port for example.
(Scott i know you were not there, but i cant find where those slides
are posted; will send them when i do - or ask Thomas).
This is very easy to map to port/ingress classifier/actions in Linux.
I was hoping i could produce a patch to do this - but waiting on Ben
to complete the reverse engineering.
In any case the realtek is a toy example but there's millions deployed
and producing a patch for tc (if Jiri doesnt beat me to it) is a useful
exercise.
My devices (as would a netronome) would apply the same concept.
Essentially, you take an ingress packet arriving on a port,
you apply a classifier to it, apply actions to i and eventually
ingress it to a port. i.e
Ingress packet-->port->classifier-->...actions..->egress port
I can model the above with tc.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v3 04/17] net: introduce generic switch devices support
From: Jamal Hadi Salim @ 2014-11-27 12:46 UTC (permalink / raw)
To: Scott Feldman
Cc: Thomas Graf, Jiri Pirko, Netdev, David S. Miller,
nhorman@tuxdriver.com, Andy Gospodarek, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Florian Fainelli, Roopa Prabhu,
John Linville
In-Reply-To: <CAE4R7bC2GTOAHm6uN9CboQ8HRFQ0+-7yoK+XF3wUysA9Sbo=gw@mail.gmail.com>
On 11/27/14 00:58, Scott Feldman wrote:
> You have access to the inside scope. We don't. Ok, I don't. We
> (think we) know what the traditional L2/L3 and OVS-style flow stuff
> looks like, but you know more, but you can't show us in code so it's
> frustrating. Not your fault. Just continue to guide us and give some
> disclaimer when we're your close to some proprietary knowledge, but it
> is relevant to the discussion.
>
Scott, I am asking to offload basic functionality that Linux supports.
I may be blind-sided and getting frustrated thinking it is obvious
because i live through this stuff everyday; but I am trying all i can
to share what you call proprietary knowledge whenever i can. If you
think of this as "we need to offload all packet processing linux
supports" you'll see where i am coming from.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] stmmac: platform: Move plat_dat checking earlier
From: Sergei Shtylyov @ 2014-11-27 12:52 UTC (permalink / raw)
To: Huacai Chen, Giuseppe Cavallaro; +Cc: Vince Bridgers, David S. Miller, netdev
In-Reply-To: <1417058072-22527-1-git-send-email-chenhc@lemote.com>
Hello.
On 11/27/2014 6:14 AM, Huacai Chen wrote:
> Original code only check/alloc plat_dat for the CONFIG_OF case, this
> patch check/alloc it earlier and unconditionally to avoid kernel build
> warnings:
> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:275
> stmmac_pltfr_probe() warn: variable dereferenced before check 'plat_dat'
> Signed-off-by: Huacai Chen <chenhc@lemote.com>
> ---
> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 18 +++++++++---------
> 1 files changed, 9 insertions(+), 9 deletions(-)
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 5b0da39..d254950 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -265,6 +265,15 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
>
> plat_dat = dev_get_platdata(&pdev->dev);
>
> + if (!plat_dat)
> + plat_dat = devm_kzalloc(&pdev->dev,
> + sizeof(struct plat_stmmacenet_data),
> + GFP_KERNEL);
Please start the continuation lines exactly under & on the first line.
[...]
WBR, Sergei
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-11-27 12:55 UTC (permalink / raw)
To: Alex Strizhevsky
Cc: Bjørn Mork, ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg,
Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg, Enrico Mioso,
youtux-Re5JQEeQqe8AvxtiuMwx3w, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg
In-Reply-To: <CAPChA0cLuvRpYTYuFoi3bewqASgf_oZHSz5yQQ8JYm96dZ4-TQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3814 bytes --]
On Thu, 27 Nov 2014, Alex Strizhevsky wrote:
==Date: Thu, 27 Nov 2014 13:36:37
==From: Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
==To: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org,
== Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org
==Cc: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
== linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
== Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org
==Subject: Re: Is this 32-bit NCM?
==
==Adding my colleagues - Eli, Kevin & Midge.
==
==Any ideas are welcome ;)
==
==
==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> wrote:
== Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
==
== > Ok - we can arrive to some ocnclusions regarding the E3272.
== > First of all - the modem seems buggy enough to not be able to
== handle requests
== > for different formats. You need to unplug and re-plug it, but
== this is onlyan
== > impression and is reasonable.
== >
== > Then - the modem will accept to ndisdup the connection with
== > at^ndisdup=1,1,"internet"
== > but - if we use huawei_cdc_ncm + cdc_ncm we have no flow
== handling messages and
== > the modem stops here.
== > If we use the cdc_ncm 32-bit driver (modified) we get lotfs of
== > ^dsflorpt
== > that's how it should be.
== > So I think we can say that something is changing.
== > Then there's the alignment problem you mentioned in your
== previous reply. And
== > this is hard to solve.
== > could you try to help me understand where the problem is?
== > I feel like we are very close to the solution but something
== isn't working.
== > Or might be just try to change the 16 bit driver?
==
==If you use a recent version of the driver as a basis, then you get the
==CDC NCM NTB parameters in sysfs (if not, then you need to enable
==debugging and look in the log for these values). For example:
==
==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001
==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360
==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360
==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824
==/sys/class/net/wwan0/cdc_ncm/rx_max:15360
==/sys/class/net/wwan0/cdc_ncm/tx_max:15360
==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1
==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0
==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32
==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0
==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32
==
In kernel 3.16 you have these funcitonalities, so please use a kernel as recent
as 3.16 at least, so that you bill be able to gather an modify some of these
parameters easily.
==
==The possible problem I am thinking of is proper handling of the
==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet Frame
==Alignment" in the spec. Which is confusing as hell, but if I
==understand
==it correctly then we are supposed to align the start of the IP packets
==(the "payload", _not_ the ethernet frame) to a whole wNdp*Divisor
==number
==as long as the wNdp*PayloadRemainder is 0.
So probably the cdc_ncm_frame_fill and *_fixup functions need to be a little
bit modified. Looking at the captures I am not able to understand this fully.
And in general, I would not be able to change alingment. Alessio?
==
==
==Bjørn
==
==
==
==
^ permalink raw reply
* Re: [patch net-next v3 04/17] net: introduce generic switch devices support
From: Thomas Graf @ 2014-11-27 13:03 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Jiri Pirko, Scott Feldman, Netdev, David S. Miller,
nhorman@tuxdriver.com, Andy Gospodarek, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Florian Fainelli, Roopa Prabhu,
John Linville
In-Reply-To: <547662F4.3060408@mojatatu.com>
On 11/26/14 at 06:32pm, Jamal Hadi Salim wrote:
> Jiri/Scott: We'll call this offload thing hanging off a port_ops
> a "switch". It does one or more of L2, L3 and flows.
> Jamal: I am not fond of that name because not everything that offloads
> off a port is a switch (some mention of fitting even with dpdk)
> Jiri: What do you have - an L3 "switch"?
> Jamal: No, it is something that does offloading of packet processing off
> a port with flows and action. Example a netronome would be a good fit (if
> you are to ignore Simon going for OVS).
So what is your name suggestion?
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-11-27 13:05 UTC (permalink / raw)
To: Alex Strizhevsky
Cc: Bjørn Mork, ShaojunMidge.Tan, Mingying.Zhu, youtux,
linux-usb, netdev, Eli.Britstein
In-Reply-To: <CAPChA0cLuvRpYTYuFoi3bewqASgf_oZHSz5yQQ8JYm96dZ4-TQ@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3326 bytes --]
By the chance - a cdc_ncm driver for 32-bit devices tthat might be buggy as
hell and that works but only with my device (that works in both 16 and 32 bit
mode) is:
http://www.gstorm.eu/cdc_ncm.c
On Thu, 27 Nov 2014, Alex Strizhevsky wrote:
==Date: Thu, 27 Nov 2014 13:36:37
==From: Alex Strizhevsky <alexxst@gmail.com>
==To: Bjørn Mork <bjorn@mork.no>, ShaojunMidge.Tan@audiocodes.com,
== Mingying.Zhu@audiocodes.com
==Cc: Enrico Mioso <mrkiko.rs@gmail.com>, youtux@gmail.com,
== linux-usb@vger.kernel.org, netdev@vger.kernel.org,
== Eli.Britstein@audiocodes.com
==Subject: Re: Is this 32-bit NCM?
==
==Adding my colleagues - Eli, Kevin & Midge.
==
==Any ideas are welcome ;)
==
==
==On Thu, Nov 27, 2014 at 12:03 PM, Bjørn Mork <bjorn@mork.no> wrote:
== Enrico Mioso <mrkiko.rs@gmail.com> writes:
==
== > Ok - we can arrive to some ocnclusions regarding the E3272.
== > First of all - the modem seems buggy enough to not be able to
== handle requests
== > for different formats. You need to unplug and re-plug it, but
== this is onlyan
== > impression and is reasonable.
== >
== > Then - the modem will accept to ndisdup the connection with
== > at^ndisdup=1,1,"internet"
== > but - if we use huawei_cdc_ncm + cdc_ncm we have no flow
== handling messages and
== > the modem stops here.
== > If we use the cdc_ncm 32-bit driver (modified) we get lotfs of
== > ^dsflorpt
== > that's how it should be.
== > So I think we can say that something is changing.
== > Then there's the alignment problem you mentioned in your
== previous reply. And
== > this is hard to solve.
== > could you try to help me understand where the problem is?
== > I feel like we are very close to the solution but something
== isn't working.
== > Or might be just try to change the 16 bit driver?
==
==If you use a recent version of the driver as a basis, then you get the
==CDC NCM NTB parameters in sysfs (if not, then you need to enable
==debugging and look in the log for these values). For example:
==
==bjorn@nemi:~$ grep . /sys/class/net/wwan0/cdc_ncm/*
==/sys/class/net/wwan0/cdc_ncm/bmNtbFormatsSupported:0x0001
==/sys/class/net/wwan0/cdc_ncm/dwNtbInMaxSize:15360
==/sys/class/net/wwan0/cdc_ncm/dwNtbOutMaxSize:15360
==/sys/class/net/wwan0/cdc_ncm/min_tx_pkt:13824
==/sys/class/net/wwan0/cdc_ncm/rx_max:15360
==/sys/class/net/wwan0/cdc_ncm/tx_max:15360
==/sys/class/net/wwan0/cdc_ncm/tx_timer_usecs:400
==/sys/class/net/wwan0/cdc_ncm/wNdpInAlignment:4
==/sys/class/net/wwan0/cdc_ncm/wNdpInDivisor:1
==/sys/class/net/wwan0/cdc_ncm/wNdpInPayloadRemainder:0
==/sys/class/net/wwan0/cdc_ncm/wNdpOutAlignment:4
==/sys/class/net/wwan0/cdc_ncm/wNdpOutDivisor:32
==/sys/class/net/wwan0/cdc_ncm/wNdpOutPayloadRemainder:0
==/sys/class/net/wwan0/cdc_ncm/wNtbOutMaxDatagrams:32
==
==
==The possible problem I am thinking of is proper handling of the
==wNdp*PayloadRemainder values. See section 3.3.4 "NCM Ethernet Frame
==Alignment" in the spec. Which is confusing as hell, but if I
==understand
==it correctly then we are supposed to align the start of the IP packets
==(the "payload", _not_ the ethernet frame) to a whole wNdp*Divisor
==number
==as long as the wNdp*PayloadRemainder is 0.
==
==
==Bjørn
==
==
==
==
^ permalink raw reply
* Re: [PATCH] e1000: remove unused variables
From: Sudip Mukherjee @ 2014-11-27 13:07 UTC (permalink / raw)
To: Hisashi T Fujinaka
Cc: Jeff Kirsher, Jesse Brandeburg, Bruce Allan, Carolyn Wyborny,
Don Skidmore, Greg Rose, Matthew Vick, John Ronciak,
Mitch Williams, Linux NICS, e1000-devel, netdev, linux-kernel
In-Reply-To: <alpine.NEB.2.11.1411262157110.1481@chris.i8u.org>
On Wed, Nov 26, 2014 at 09:59:28PM -0800, Hisashi T Fujinaka wrote:
> I'm pretty sure those double reads are there for a reason, so most of
> this I'm going to have to check on Monday. We have a long holiday
> weekend here in the US.
if the double reads are there for some reason, can you please let me know what that reason might be..
>
> I'm not sure why you're bothering with an old driver like this, but if
> you haven't actually tried this on all the hardware it pertains to, I'm
> going want to NAK this.
no it has not been tested on hardware. :(
i am still in the learning process, NAK is also part of learning.
infact there is another part of the code, which, theoretically, will never get executed. but i didnot dare to send that removal patch without testing on the hardware.
thanks
sudip
>
> I should do this from my todd.fujinaka@intel.com account but it's 10PM
> on the first day of a long holiday weekend.
>
> On Thu, 27 Nov 2014, Sudip Mukherjee wrote:
>
> >these variables were only being assigned some values, but were never
> >used.
> >
> >Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> >---
> >drivers/net/ethernet/intel/e1000/e1000_hw.c | 142 ++++++++++++--------------
<snip>
> > case SPEED_100:
> >- txb2b = false;
> > /* maybe add some timeout factor ? */
> > break;
> > }
> >
>
> --
> Hisashi T Fujinaka - htodd@twofifty.com
> BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
^ permalink raw reply
* [PATCH V2] stmmac: platform: Move plat_dat checking earlier
From: Huacai Chen @ 2014-11-27 13:05 UTC (permalink / raw)
To: Giuseppe Cavallaro; +Cc: Vince Bridgers, David S. Miller, netdev, Huacai Chen
Original code only check/alloc plat_dat for the CONFIG_OF case, this
patch check/alloc it earlier and unconditionally to avoid kernel build
warnings:
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:275
stmmac_pltfr_probe() warn: variable dereferenced before check 'plat_dat'
V2: Fix coding style.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 5b0da39..d254950 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -265,6 +265,15 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
plat_dat = dev_get_platdata(&pdev->dev);
+ if (!plat_dat)
+ plat_dat = devm_kzalloc(&pdev->dev,
+ sizeof(struct plat_stmmacenet_data),
+ GFP_KERNEL);
+ if (!plat_dat) {
+ pr_err("%s: ERROR: no memory", __func__);
+ return -ENOMEM;
+ }
+
/* Set default value for multicast hash bins */
plat_dat->multicast_filter_bins = HASH_TABLE_SIZE;
@@ -272,15 +281,6 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
plat_dat->unicast_filter_entries = 1;
if (pdev->dev.of_node) {
- if (!plat_dat)
- plat_dat = devm_kzalloc(&pdev->dev,
- sizeof(struct plat_stmmacenet_data),
- GFP_KERNEL);
- if (!plat_dat) {
- pr_err("%s: ERROR: no memory", __func__);
- return -ENOMEM;
- }
-
ret = stmmac_probe_config_dt(pdev, plat_dat, &mac);
if (ret) {
pr_err("%s: main dt probe failed", __func__);
--
1.7.7.3
^ permalink raw reply related
* [PATCH v3] can: Convert to runtime_pm
From: Kedareswara rao Appana @ 2014-11-27 13:08 UTC (permalink / raw)
To: wg, mkl, michal.simek, soren.brinkmann, grant.likely, robh+dt
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel, devicetree,
Kedareswara rao Appana
Instead of enabling/disabling clocks at several locations in the driver,
use the runtime_pm framework. This consolidates the actions for
runtime PM in the appropriate callbacks and makes the driver more
readable and mantainable.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
---
Changes for v3:
- Converted the driver to use runtime_pm.
Changes for v2:
- Removed the struct platform_device* from suspend/resume
as suggest by Lothar.
drivers/net/can/xilinx_can.c | 119 +++++++++++++++++++++++++----------------
1 files changed, 72 insertions(+), 47 deletions(-)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 8a998e3..1be28ed 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -32,6 +32,7 @@
#include <linux/can/dev.h>
#include <linux/can/error.h>
#include <linux/can/led.h>
+#include <linux/pm_runtime.h>
#define DRIVER_NAME "xilinx_can"
@@ -138,7 +139,7 @@ struct xcan_priv {
u32 (*read_reg)(const struct xcan_priv *priv, enum xcan_reg reg);
void (*write_reg)(const struct xcan_priv *priv, enum xcan_reg reg,
u32 val);
- struct net_device *dev;
+ struct device *dev;
void __iomem *reg_base;
unsigned long irq_flags;
struct clk *bus_clk;
@@ -842,6 +843,13 @@ static int xcan_open(struct net_device *ndev)
struct xcan_priv *priv = netdev_priv(ndev);
int ret;
+ ret = pm_runtime_get_sync(priv->dev);
+ if (ret < 0) {
+ netdev_err(ndev, "%s: runtime CAN resume failed(%d)\n\r",
+ __func__, ret);
+ return ret;
+ }
+
ret = request_irq(ndev->irq, xcan_interrupt, priv->irq_flags,
ndev->name, ndev);
if (ret < 0) {
@@ -849,29 +857,17 @@ static int xcan_open(struct net_device *ndev)
goto err;
}
- ret = clk_prepare_enable(priv->can_clk);
- if (ret) {
- netdev_err(ndev, "unable to enable device clock\n");
- goto err_irq;
- }
-
- ret = clk_prepare_enable(priv->bus_clk);
- if (ret) {
- netdev_err(ndev, "unable to enable bus clock\n");
- goto err_can_clk;
- }
-
/* Set chip into reset mode */
ret = set_reset_mode(ndev);
if (ret < 0) {
netdev_err(ndev, "mode resetting failed!\n");
- goto err_bus_clk;
+ goto err_irq;
}
/* Common open */
ret = open_candev(ndev);
if (ret)
- goto err_bus_clk;
+ goto err_irq;
ret = xcan_chip_start(ndev);
if (ret < 0) {
@@ -887,13 +883,11 @@ static int xcan_open(struct net_device *ndev)
err_candev:
close_candev(ndev);
-err_bus_clk:
- clk_disable_unprepare(priv->bus_clk);
-err_can_clk:
- clk_disable_unprepare(priv->can_clk);
err_irq:
free_irq(ndev->irq, ndev);
err:
+ pm_runtime_put(priv->dev);
+
return ret;
}
@@ -910,12 +904,11 @@ static int xcan_close(struct net_device *ndev)
netif_stop_queue(ndev);
napi_disable(&priv->napi);
xcan_chip_stop(ndev);
- clk_disable_unprepare(priv->bus_clk);
- clk_disable_unprepare(priv->can_clk);
free_irq(ndev->irq, ndev);
close_candev(ndev);
can_led_event(ndev, CAN_LED_EVENT_STOP);
+ pm_runtime_put(priv->dev);
return 0;
}
@@ -934,27 +927,21 @@ static int xcan_get_berr_counter(const struct net_device *ndev,
struct xcan_priv *priv = netdev_priv(ndev);
int ret;
- ret = clk_prepare_enable(priv->can_clk);
- if (ret)
- goto err;
+ ret = pm_runtime_get_sync(priv->dev);
+ if (ret < 0) {
+ netdev_err(ndev, "%s: runtime resume failed(%d)\n\r",
+ __func__, ret);
+ return ret;
+ }
- ret = clk_prepare_enable(priv->bus_clk);
- if (ret)
- goto err_clk;
bec->txerr = priv->read_reg(priv, XCAN_ECR_OFFSET) & XCAN_ECR_TEC_MASK;
bec->rxerr = ((priv->read_reg(priv, XCAN_ECR_OFFSET) &
XCAN_ECR_REC_MASK) >> XCAN_ESR_REC_SHIFT);
- clk_disable_unprepare(priv->bus_clk);
- clk_disable_unprepare(priv->can_clk);
+ pm_runtime_put(priv->dev);
return 0;
-
-err_clk:
- clk_disable_unprepare(priv->can_clk);
-err:
- return ret;
}
@@ -967,15 +954,45 @@ static const struct net_device_ops xcan_netdev_ops = {
/**
* xcan_suspend - Suspend method for the driver
- * @dev: Address of the platform_device structure
+ * @dev: Address of the net_device structure
*
* Put the driver into low power mode.
- * Return: 0 always
+ * Return: 0 on success and failure value on error
*/
static int __maybe_unused xcan_suspend(struct device *dev)
{
- struct platform_device *pdev = dev_get_drvdata(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ if (!device_may_wakeup(dev))
+ return pm_runtime_force_suspend(dev);
+
+ return 0;
+}
+
+/**
+ * xcan_resume - Resume from suspend
+ * @dev: Address of the net_device structure
+ *
+ * Resume operation after suspend.
+ * Return: 0 on success and failure value on error
+ */
+static int __maybe_unused xcan_resume(struct device *dev)
+{
+ if (!device_may_wakeup(dev))
+ return pm_runtime_force_resume(dev);
+
+ return 0;
+
+}
+
+/**
+ * xcan_runtime_suspend - Runtime suspend method for the driver
+ * @dev: Address of the net_device structure
+ *
+ * Put the driver into low power mode.
+ * Return: 0 always
+ */
+static int __maybe_unused xcan_runtime_suspend(struct device *dev)
+{
+ struct net_device *ndev = dev_get_drvdata(dev);
struct xcan_priv *priv = netdev_priv(ndev);
if (netif_running(ndev)) {
@@ -993,16 +1010,15 @@ static int __maybe_unused xcan_suspend(struct device *dev)
}
/**
- * xcan_resume - Resume from suspend
- * @dev: Address of the platformdevice structure
+ * xcan_runtime_resume - Runtime resume from suspend
+ * @dev: Address of the net_device structure
*
* Resume operation after suspend.
* Return: 0 on success and failure value on error
*/
-static int __maybe_unused xcan_resume(struct device *dev)
+static int __maybe_unused xcan_runtime_resume(struct device *dev)
{
- struct platform_device *pdev = dev_get_drvdata(dev);
- struct net_device *ndev = platform_get_drvdata(pdev);
+ struct net_device *ndev = dev_get_drvdata(dev);
struct xcan_priv *priv = netdev_priv(ndev);
int ret;
@@ -1030,7 +1046,10 @@ static int __maybe_unused xcan_resume(struct device *dev)
return 0;
}
-static SIMPLE_DEV_PM_OPS(xcan_dev_pm_ops, xcan_suspend, xcan_resume);
+static const struct dev_pm_ops xcan_dev_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(xcan_suspend, xcan_resume)
+ SET_PM_RUNTIME_PM_OPS(xcan_runtime_suspend, xcan_runtime_resume, NULL)
+};
/**
* xcan_probe - Platform registration call
@@ -1071,7 +1090,7 @@ static int xcan_probe(struct platform_device *pdev)
return -ENOMEM;
priv = netdev_priv(ndev);
- priv->dev = ndev;
+ priv->dev = &pdev->dev;
priv->can.bittiming_const = &xcan_bittiming_const;
priv->can.do_set_mode = xcan_do_set_mode;
priv->can.do_get_berr_counter = xcan_get_berr_counter;
@@ -1137,6 +1156,11 @@ static int xcan_probe(struct platform_device *pdev)
netif_napi_add(ndev, &priv->napi, xcan_rx_poll, rx_max);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_irq_safe(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_get_sync(&pdev->dev);
+
ret = register_candev(ndev);
if (ret) {
dev_err(&pdev->dev, "fail to register failed (err=%d)\n", ret);
@@ -1144,8 +1168,9 @@ static int xcan_probe(struct platform_device *pdev)
}
devm_can_led_init(ndev);
- clk_disable_unprepare(priv->bus_clk);
- clk_disable_unprepare(priv->can_clk);
+
+ pm_runtime_put(&pdev->dev);
+
netdev_dbg(ndev, "reg_base=0x%p irq=%d clock=%d, tx fifo depth:%d\n",
priv->reg_base, ndev->irq, priv->can.clock.freq,
priv->tx_max);
--
1.7.4
^ permalink raw reply related
* Re: [patch net-next v4 09/21] bridge: call netdev_sw_port_stp_update when bridge port STP status changes
From: Jamal Hadi Salim @ 2014-11-27 13:14 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl,
hemal
In-Reply-To: <1417084826-9875-10-git-send-email-jiri@resnulli.us>
On 11/27/14 05:40, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> To notify switch driver of change in STP state of bridge port, add new
> .ndo op and provide switchdev wrapper func to call ndo op. Use it in bridge
> code then.
>
As it stands right now we are going to pollute the ndo ops and grow
it fatter like the skb (its probably as fat).
If i am not mistaken ethtool has some scheme it uses to pass opaque
objects to different functions. Having a generic
set/get_netdev_offload_attr() would be the right thing to do.
An {id, *value} or {id, len, *value} or a void * would do.
So not objecting - but not ACKing either.
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v4 14/21] bridge: add brport flags to dflt bridge_getlink
From: Jamal Hadi Salim @ 2014-11-27 13:17 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl,
hemal
In-Reply-To: <1417084826-9875-15-git-send-email-jiri@resnulli.us>
On 11/27/14 05:40, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> To allow brport device to return current brport flags set on port. Add
> returned flags to nested IFLA_PROTINFO netlink msg built in dflt getlink.
> With this change, netlink msg returned for bridge_getlink contains the port's
> offloaded flag settings (the port's SELF settings).
Am i missing something or we already have this stuff showing up in user
space today?
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v4 14/21] bridge: add brport flags to dflt bridge_getlink
From: Jamal Hadi Salim @ 2014-11-27 13:25 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl,
hemal
In-Reply-To: <5477244C.2030507@mojatatu.com>
On 11/27/14 08:17, Jamal Hadi Salim wrote:
> On 11/27/14 05:40, Jiri Pirko wrote:
>> From: Scott Feldman <sfeldma@gmail.com>
>>
>> To allow brport device to return current brport flags set on port. Add
>> returned flags to nested IFLA_PROTINFO netlink msg built in dflt getlink.
>> With this change, netlink msg returned for bridge_getlink contains the
>> port's
>> offloaded flag settings (the port's SELF settings).
>
> Am i missing something or we already have this stuff showing up in user
> space today?
>
Sorry, in events it does but for some reason not in the GETs
even though trying to trace the code ndo_bridge_getlink()
i couldnt tell off hand why it is not showing up.
look at: br_port_fill_attrs() and its callers.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v7 6/8] net: can: c_can: Disable pins when CAN interface is down
From: Linus Walleij @ 2014-11-27 13:26 UTC (permalink / raw)
To: Roger Quadros
Cc: wg, Marc Kleine-Budde, Wolfram Sang, Tony Lindgren,
Thomas Gleixner, Mugunthan V N, George Cherian, Felipe Balbi,
Sekhar Nori, Nishanth Menon, Sergei Shtylyov, Linux-OMAP,
linux-can, netdev@vger.kernel.org
In-Reply-To: <5466225D.2070202@ti.com>
On Fri, Nov 14, 2014 at 4:40 PM, Roger Quadros <rogerq@ti.com> wrote:
> DRA7 CAN IP suffers from a problem which causes it to be prevented
> from fully turning OFF (i.e. stuck in transition) if the module was
> disabled while there was traffic on the CAN_RX line.
>
> To work around this issue we select the SLEEP pin state by default
> on probe and use the DEFAULT pin state on CAN up and back to the
> SLEEP pin state on CAN down.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
I see you figured it out all by yourselves :D
(Sorry for being absent.)
> +#include <linux/pinctrl/consumer.h>
> + pinctrl_pm_select_default_state(dev->dev.parent);
> + pinctrl_pm_select_sleep_state(dev->dev.parent);
> + pinctrl_pm_select_sleep_state(dev->dev.parent);
NB: in drivers/base/pinctrl.c:
#ifdef CONFIG_PM
/*
* If power management is enabled, we also look for the optional
* sleep and idle pin states, with semantics as defined in
* <linux/pinctrl/pinctrl-state.h>
*/
dev->pins->sleep_state = pinctrl_lookup_state(dev->pins->p,
PINCTRL_STATE_SLEEP);
So if these states are necessary for the driver to work, put
depends on PM or select PM in the Kconfig.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 6/8] net: can: c_can: Disable pins when CAN interface is down
From: Linus Walleij @ 2014-11-27 13:28 UTC (permalink / raw)
To: Roger Quadros
Cc: Marc Kleine-Budde, wg, Wolfram Sang, Tony Lindgren,
Thomas Gleixner, Mugunthan V N, George Cherian, Felipe Balbi,
Sekhar Nori, Nishanth Menon, Sergei Shtylyov, Linux-OMAP,
linux-can, netdev@vger.kernel.org
In-Reply-To: <546606F4.6020102@ti.com>
On Fri, Nov 14, 2014 at 2:43 PM, Roger Quadros <rogerq@ti.com> wrote:
> On 11/13/2014 06:03 PM, Marc Kleine-Budde wrote:
>> On 11/13/2014 04:23 PM, Roger Quadros wrote:
>> I just stumbled over pinctrl_pm_select_sleep_state(), is it possible to
>> integrate this into runtime pm?
>>
>> http://lxr.free-electrons.com/source/drivers/pinctrl/core.c#L1282
>
> I think those functions are there for the same reason but not sure why aren't
> they used in runtime pm core.
>
> Linus W. any hints?
It is not used from PM core because there are cases where
you may want to put pins to sleep for completely PM-core
unrelated things.
Things like turning off a serial port from userspace,
for example. That should put the pins to sleep.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [patch net-next v4 15/21] rocker: introduce rocker switch driver
From: Jamal Hadi Salim @ 2014-11-27 13:31 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, sfeldma, f.fainelli, roopa, linville,
jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a, buytenh,
aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye, simon.horman,
alexander.h.duyck, john.ronciak, mleitner, shrijeet, gospo, bcrl,
hemal
In-Reply-To: <1417084826-9875-16-git-send-email-jiri@resnulli.us>
On 11/27/14 05:40, Jiri Pirko wrote:
> This patch introduces the first driver to benefit from the switchdev
> infrastructure and to implement newly introduced switch ndos. This is a
> driver for emulated switch chip implemented in qemu:
> https://github.com/sfeldma/qemu-rocker/
>
> This patch is a result of joint work with Scott Feldman.
>
I would like to review the rocking rocks rocker later (sorry dont have
time right now but would love to).
cheers,
jamal
^ permalink raw reply
* Re: [patch net-next v4 13/21] bridge: add new hwmode swdev
From: Sergei Shtylyov @ 2014-11-27 13:31 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417084826-9875-14-git-send-email-jiri@resnulli.us>
Hello.
On 11/27/2014 1:40 PM, Jiri Pirko wrote:
> From: Scott Feldman <sfeldma@gmail.com>
> Current hwmode settings are "vepa" or "veb". These are for NIC interfaces
> with basic bridging function offloaded to HW. Add new "swdev" for full
> switch device offloads.
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> ---
> v3->v4:
> -no change
> new in v3
> ---
> include/uapi/linux/if_bridge.h | 1 +
> 1 file changed, 1 insertion(+)
> diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
> index da17e45..60425ca 100644
> --- a/include/uapi/linux/if_bridge.h
> +++ b/include/uapi/linux/if_bridge.h
> @@ -105,6 +105,7 @@ struct __fdb_entry {
>
> #define BRIDGE_MODE_VEB 0 /* Default loopback mode */
> #define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
> +#define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
Please use tabs for indentation.
[...]
WBR, Sergei
^ permalink raw reply
* Re: [patch net-next v3 04/17] net: introduce generic switch devices support
From: Jamal Hadi Salim @ 2014-11-27 13:32 UTC (permalink / raw)
To: Thomas Graf
Cc: Jiri Pirko, Scott Feldman, Netdev, David S. Miller,
nhorman@tuxdriver.com, Andy Gospodarek, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Florian Fainelli, Roopa Prabhu,
John Linville
In-Reply-To: <20141127130345.GB27041@casper.infradead.org>
On 11/27/14 08:03, Thomas Graf wrote:
> So what is your name suggestion?
>
I would have gone for _offload_ either as a prefix or suffix
somewhere.
cheers,
jamal
^ permalink raw reply
* bug in networking code causes GPF
From: Дениска-редиска @ 2014-11-27 13:35 UTC (permalink / raw)
To: linux-net, netdev, linux-kernel
hello,
i run ipvs DR on 2 servers under heavy load - up to 1Gbps of traffic.
Time to time the server where ipvs runs master IP (VIP) get general protection fault. Switching master to another server make no difference - after some time GPF come. So I assume it is not hardware issue.
There are logs from both servers with different kernels (i run kernel with grsecurity patch set from Gentoo hardened portage tree):
[354497.931834] general protection fault: 0000 [#1] SMP
[354497.931903] CPU: 14 PID: 0 Comm: swapper/14 Not tainted 3.13.10-hardened.standart.20140515 #1
[354497.931993] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.5 11/25/2013
[354497.932082] task: ffff88021e4b2ca0 ti: ffff88021e4b3100 task.ti: ffff88021e4b3100
[354497.932167] RIP: 0010:[<ffffffff81653ca2>] [<ffffffff81653ca2>] ffffffff81653ca2
[354497.932278] RSP: 0000:ffff88021fd03b98 EFLAGS: 00010246
[354497.932330] RAX: 0000000000013ba0 RBX: fefefefefefefefe RCX: 000000000001bc30
[354497.932413] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[354497.932497] RBP: ffff88021fd03c40 R08: 00000000cacb7f0b R09: ffff88021fd03c58
[354497.932580] R10: ffffffffffffffff R11: ffff88041de33280 R12: 8000000000000000
[354497.932663] R13: 0000000000003786 R14: ffffffff81a82540 R15: 0000000000000000
[354497.932749] FS: 000003853a8a7740(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
[354497.932836] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[354497.932891] CR2: 000003d8a933b2d0 CR3: 000000000174a000 CR4: 00000000000407f0
[354497.932973] Stack:
[354497.933013] 0000000000000000 ffffffff81a82540 00000000de1b1efe 0000000000000000
[354497.933110] ffff88021fd03c40 ffffffff81653f6d ffffffff81a92cc0 ffffffff81a82540
[354497.933206] ffff88041d70c500 0000000000000000 00000000de1b1efe ffffffff81654f6c
[354497.933304] Call Trace:
[354497.933347] <IRQ>
[354497.933357] [<ffffffff81653f6d>] ? __nf_conntrack_find_get+0x28/0x13b
[354497.933484] [<ffffffff81654f6c>] ? nf_conntrack_in+0x253/0x73e
[354497.933544] [<ffffffff8164eeb6>] ? nf_iterate+0x40/0x7d
[354497.933601] [<ffffffff816a90a4>] ? inet_del_offload+0x39/0x39
[354497.933658] [<ffffffff8164ef5f>] ? nf_hook_slow+0x6c/0x104
[354497.933714] [<ffffffff816a90a4>] ? inet_del_offload+0x39/0x39
[354497.933770] [<ffffffff816a98c8>] ? ip_rcv+0x313/0x35f
[354497.933824] [<ffffffff816a93d1>] ? ip_local_deliver_finish+0xb8/0x11f
[354497.933885] [<ffffffff81627dfd>] ? __netif_receive_skb_core+0x44d/0x4e2
[354497.933944] [<ffffffff8162afba>] ? netif_receive_skb+0x4c/0x81
[354497.934000] [<ffffffff8162b488>] ? napi_gro_receive+0x35/0x7a
[354497.934058] [<ffffffff81515ddc>] ? igb_poll+0xa49/0xd13
[354497.934115] [<ffffffff810ce5b1>] ? __wake_up+0x38/0x49
[354497.934169] [<ffffffff8162b773>] ? net_rx_action+0xa6/0x172
[354497.934225] [<ffffffff810a31cc>] ? __do_softirq+0xb9/0x1ae
[354497.934280] [<ffffffff810a3499>] ? irq_exit+0x37/0x7a
[354497.934335] [<ffffffff81003ce2>] ? do_IRQ+0x96/0xb0
[354497.934389] [<ffffffff81725a97>] ? common_interrupt+0x97/0x97
[354497.934441] <EOI>
[354497.934451] [<ffffffff810e3080>] ? update_ts_time_stats+0x30/0x76
[354497.934548] [<ffffffff81009d20>] ? arch_remove_reservations+0x6a/0x6a
[354497.934607] [<ffffffff81009d23>] ? default_idle+0x3/0x9
[354497.934676] [<ffffffff8100a333>] ? arch_cpu_idle+0x6/0x1e
[354497.934732] [<ffffffff81009d20>] ? arch_remove_reservations+0x6a/0x6a
[354497.934791] [<ffffffff810d434a>] ? cpu_startup_entry+0xe9/0x15b
[354497.934850] [<ffffffff81024ccf>] ? start_secondary+0x2f9/0x32c
[354497.934903] Code: c2 85 d2 49 8b 86 d0 04 00 00 74 14 66 45 85 ff 75 0e 65 ff 40 04 e8 85 f6 a4 ff 48 89 d8 eb 69 65 ff 00 48 8b 1b f6 c3 01 75 0f <8b> 43 10 39 45 00 b8 00 00 00 00 74 83 eb 9d 48 d1 eb 4c 39 eb
[354497.935402] RIP [<ffffffff81653ca2>] ffffffff81653ca2
[354497.935456] RSP <ffff88021fd03b98>
[354497.935965] ---[ end trace 7d6f660245b2d541 ]---
[354497.936080] Kernel panic - not syncing: Fatal exception in interrupt
[354498.016801] Rebooting in 10 seconds.
[674944.621564] general protection fault: 0000 [#1] SMP
[674944.621637] CPU: 12 PID: 17984 Comm: nginx Not tainted 3.15.10-hardened-r1.standart.20140925 #1
[674944.621728] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.5 11/25/2013
[674944.621817] task: ffff88021e1d7700 ti: ffff88021e1d7c68 task.ti: ffff88021e1d7c68
[674944.621903] RIP: 0010:[<ffffffff816f2be8>] [<ffffffff816f2be8>] ffffffff816f2be8
[674944.621990] RSP: 0000:ffff88021fc03ce8 EFLAGS: 00010246
[674944.622057] RAX: ffffc90011901000 RBX: 822098c2102098c2 RCX: 000000005823edca
[674944.622143] RDX: fefefefefefefefe RSI: 000000009e90f1ad RDI: ffffffff81a8ad40
[674944.622226] RBP: 000000000050abb3 R08: 000000000050abb3 R09: 000000000001f106
[674944.622310] R10: ffffea00100cbd80 R11: ffffea00100cbd80 R12: 8000000000000000
[674944.622394] R13: ffffffff81a8ad40 R14: 0000000049c3f106 R15: ffffc900119f9830
[674944.622479] FS: 0000029d6fd04740(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000
[674944.622566] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[674944.622619] CR2: ffffffffff600400 CR3: 0000000001787000 CR4: 00000000000407f0
[674944.622701] Stack:
[674944.622741] ffffffff816e9360 ffffffff00000050 ffffffff822098c2 abb3000280000000
[674944.622839] ffff88006e9c2b00 ffff88011cbd1bce ffff88021e0c0000 0000000000000008
[674944.622935] ffffffff81a955b0 ffffffff8170920a ffff880100000003 0000000000000008
[674944.623031] Call Trace:
[674944.623077] <IRQ>
[674944.623087] [<ffffffff816e9360>] ? inet_del_offload+0x39/0x39
[674944.623192] [<ffffffff8170920a>] ? tcp_v4_early_demux+0x14c/0x1bd
[674944.623250] [<ffffffff816e93b0>] ? ip_rcv_finish+0x50/0x2c1
[674944.623326] [<ffffffff8165ee92>] ? __netif_receive_skb_core+0x3c8/0x456
[674944.623386] [<ffffffff8165f10c>] ? netif_receive_skb_internal+0x4c/0x81
[674944.623447] [<ffffffff816623b3>] ? napi_gro_receive+0x36/0x7c
[674944.623511] [<ffffffff815485a5>] ? igb_poll+0xa8b/0xd5b
[674944.623572] [<ffffffff810f7fda>] ? __note_gp_changes+0x31/0x61
[674944.623630] [<ffffffff816626cf>] ? net_rx_action+0xa6/0x172
[674944.623688] [<ffffffff810bc995>] ? __do_softirq+0xf6/0x1fb
[674944.623744] [<ffffffff810bcbf4>] ? irq_exit+0x38/0x7c
[674944.623798] [<ffffffff81003ce3>] ? do_IRQ+0xb3/0xce
[674944.623853] [<ffffffff81767217>] ? common_interrupt+0x97/0x97
[674944.623906] <EOI>
[674944.623917] Code: 6a d4 75 0e 48 39 5a c8 74 51 eb 06 3b 44 24 50 74 50 4c 89 4c 24 08 e8 e8 fe ff ff 4c 8b 4c 24 08 eb 83 48 8b 12 f6 c2 01 75 0b <44> 39 72 d0 75 f2 e9 75 ff ff ff 48 d1 ea 4c 39 ca 0f 85 64 ff
[674944.624456] RIP [<ffffffff816f2be8>] ffffffff816f2be8
[674944.624536] RSP <ffff88021fc03ce8>
[674944.625020] ---[ end trace 8035e2b5322bab00 ]---
[674944.625126] Kernel panic - not syncing: Fatal exception in interrupt
[674944.706563] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
[674944.706711] Rebooting in 10 seconds.
[7523332.314991] general protection fault: 0000 [#1] SMP
[7523332.315078] CPU: 4 PID: 25432 Comm: nginx Not tainted 3.15.8-hardened.standart.20140901 #1
[7523332.315172] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.0 09/10/2012
[7523332.315266] task: ffff88041eb98000 ti: ffff88041eb98568 task.ti: ffff88041eb98568
[7523332.315355] RIP: 0010:[<ffffffff8168db79>] [<ffffffff8168db79>] ffffffff8168db79
[7523332.315446] RSP: 0018:ffff88021fa03bf8 EFLAGS: 00010246
[7523332.316983] RAX: 00000000000149c0 RBX: ffffffff81a8ac80 RCX: 00000000000011d5
[7523332.317070] RDX: 0000000000000000 RSI: 0000000000008ea8 RDI: ffffffff81a8acfe
[7523332.317187] RBP: ffff88021fa03c5c R08: 00000000b96542ae R09: ffff88021fa03c74
[7523332.317274] R10: 0000000000000002 R11: ffff880238b8ce00 R12: 8000000000000000
[7523332.317360] R13: fefefefefefefefe R14: 0000000000000000 R15: 0000000047567b68
[7523332.317448] FS: 0000031d200c5740(0000) GS:ffff88021fa00000(0000) knlGS:0000000000000000
[7523332.317538] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[7523332.317594] CR2: 000004373dcef000 CR3: 0000000001779000 CR4: 00000000000007f0
[7523332.317679] Stack:
[7523332.317722] 0000000000000000 ffffffff81a8ac80 ffff880003e08200 0000000000000000
[7523332.317824] ffffffff81a9bf60 ffffffff8168ef87 ffffffff81a9bf60 ffffffff81a96970
[7523332.317925] 0000000047567b68 ffffffff81a96970 0000000281a90002 0000000000000014
[7523332.318026] Call Trace:
[7523332.318072] <IRQ>
[7523332.318085] [<ffffffff8168ef87>] ? nf_conntrack_in+0x2c1/0x846
[7523332.318199] [<ffffffff81688956>] ? nf_iterate+0x41/0x81
[7523332.318259] [<ffffffff816ea4b8>] ? inet_del_offload+0x39/0x39
[7523332.318321] [<ffffffff81688a0c>] ? nf_hook_slow+0x76/0x111
[7523332.318393] [<ffffffff816ea4b8>] ? inet_del_offload+0x39/0x39
[7523332.318453] [<ffffffff816eacf2>] ? ip_rcv+0x2f4/0x356
[7523332.318512] [<ffffffff81660173>] ? __netif_receive_skb_core+0x3d9/0x410
[7523332.318575] [<ffffffff8166039c>] ? netif_receive_skb_internal+0x6d/0x77
[7523332.318640] [<ffffffff816634c1>] ? napi_gro_receive+0x36/0x7c
[7523332.318702] [<ffffffff8154a30d>] ? igb_poll+0xa46/0xd09
[7523332.318762] [<ffffffff813bbd0d>] ? __list_add+0x1b/0x37
[7523332.318820] [<ffffffff816637d2>] ? net_rx_action+0xa0/0x171
[7523332.318882] [<ffffffff810bcb7a>] ? __do_softirq+0xf7/0x1fa
[7523332.318943] [<ffffffff8176a29c>] ? do_softirq_own_stack+0x1c/0x30
[7523332.318999] <EOI>
[7523332.319013] [<ffffffff810bcccb>] ? do_softirq+0x24/0x2c
[7523332.319112] [<ffffffff810bcd39>] ? __local_bh_enable_ip+0x66/0x74
[7523332.319174] [<ffffffff8172f029>] ? ipt_do_table+0x5c6/0x5f0
[7523332.319235] [<ffffffff81688956>] ? nf_iterate+0x41/0x81
[7523332.319293] [<ffffffff816ed488>] ? ip_options_rcv_srr+0x1c7/0x1c7
[7523332.319354] [<ffffffff81688a0c>] ? nf_hook_slow+0x76/0x111
[7523332.319412] [<ffffffff816ed488>] ? ip_options_rcv_srr+0x1c7/0x1c7
[7523332.319473] [<ffffffff816ee3a2>] ? __ip_local_out+0x64/0x6e
[7523332.319533] [<ffffffff8164f4a3>] ? __sk_dst_check+0x34/0x63
[7523332.319617] [<ffffffff816ee3be>] ? ip_local_out_sk+0x12/0x39
[7523332.319676] [<ffffffff816eea83>] ? ip_queue_xmit+0x2ab/0x2db
[7523332.319739] [<ffffffff81703a1e>] ? tcp_transmit_skb+0x6eb/0x735
[7523332.319801] [<ffffffff81704323>] ? tcp_write_xmit+0x82e/0x969
[7523332.319861] [<ffffffff816f7278>] ? tcp_sendpage+0x50b/0x5e4
[7523332.319923] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
[7523332.319986] [<ffffffff8171a807>] ? inet_sendpage+0xbc/0xe0
[7523332.320045] [<ffffffff8164eacc>] ? kernel_sendpage+0x49/0x59
[7523332.320104] [<ffffffff8164eb23>] ? sock_sendpage+0x47/0x53
[7523332.320163] [<ffffffff81184658>] ? pipe_to_sendpage+0x6f/0x7c
[7523332.320223] [<ffffffff81185aa8>] ? splice_from_pipe_feed+0x7f/0x10e
[7523332.320285] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
[7523332.320347] [<ffffffff81185c2e>] ? __splice_from_pipe+0x3a/0x6b
[7523332.320408] [<ffffffff81185dff>] ? splice_from_pipe+0x66/0x87
[7523332.320468] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
[7523332.320533] [<ffffffff811845df>] ? direct_splice_actor+0x3f/0x49
[7523332.320599] [<ffffffff811860f5>] ? splice_direct_to_actor+0xd3/0x18d
[7523332.320661] [<ffffffff811845a0>] ? generic_pipe_buf_nosteal+0xc/0xc
[7523332.320723] [<ffffffff81186249>] ? do_splice_direct+0x9a/0xb6
[7523332.320783] [<ffffffff8115e7f2>] ? do_sendfile+0x182/0x32a
[7523332.320856] [<ffffffff811602bd>] ? SyS_sendfile64+0x137/0x1bc
[7523332.320916] [<ffffffff81768f37>] ? system_call_fastpath+0x16/0x1b
[7523332.320972] Code: 00 02 00 00 48 c7 c7 4d db 68 81 65 ff 40 04 e8 71 f1 a2 ff 4d 85 ed 75 58 e9 94 01 00 00 65 ff 00 4d 8b 6d 00 41 f6 c5 01 75 18 <41> 8b 55 10 31 c0 39 55 00 41 8a 7d 37 0f 85 14 ff ff ff e9 e7
[7523332.321522] RIP [<ffffffff8168db79>] ffffffff8168db79
[7523332.321579] RSP <ffff88021fa03bf8>
[7523332.322094] ---[ end trace 0e21b79561002306 ]---
[7523332.322210] Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply
* Re: [patch net-next v4 09/21] bridge: call netdev_sw_port_stp_update when bridge port STP status changes
From: Jiri Pirko @ 2014-11-27 13:43 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev, davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse,
pshelar, azhou, ben, stephen, jeffrey.t.kirsher, vyasevic,
xiyou.wangcong, john.r.fastabend, edumazet, sfeldma, f.fainelli,
roopa, linville, jasowang, ebiederm, nicolas.dichtel,
ryazanov.s.a, buytenh, aviadr, nbd, alexei.starovoitov,
Neil.Jerram, ronye, simon.horman, alexander.h.duyck, john.ronciak,
mleitner, shrijeet, gospo, bcrl, hemal
In-Reply-To: <547723AC.1070907@mojatatu.com>
Thu, Nov 27, 2014 at 02:14:20PM CET, jhs@mojatatu.com wrote:
>On 11/27/14 05:40, Jiri Pirko wrote:
>>From: Scott Feldman <sfeldma@gmail.com>
>>
>>To notify switch driver of change in STP state of bridge port, add new
>>.ndo op and provide switchdev wrapper func to call ndo op. Use it in bridge
>>code then.
>>
>
>As it stands right now we are going to pollute the ndo ops and grow
>it fatter like the skb (its probably as fat).
>If i am not mistaken ethtool has some scheme it uses to pass opaque
>objects to different functions. Having a generic
>set/get_netdev_offload_attr() would be the right thing to do.
>An {id, *value} or {id, len, *value} or a void * would do.
>So not objecting - but not ACKing either.
Yeah, this will be changed in future when more and more info will need
to be passed to offloads.
>
>cheers,
>jamal
>
^ permalink raw reply
* Re: [patch net-next v3 04/17] net: introduce generic switch devices support
From: Jiri Pirko @ 2014-11-27 13:50 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Thomas Graf, Scott Feldman, Netdev, David S. Miller,
nhorman@tuxdriver.com, Andy Gospodarek, dborkman@redhat.com,
ogerlitz@mellanox.com, jesse@nicira.com, pshelar@nicira.com,
azhou@nicira.com, ben@decadent.org.uk, stephen@networkplumber.org,
Kirsher, Jeffrey T, vyasevic@redhat.com, Cong Wang,
Fastabend, John R, Eric Dumazet, Florian Fainelli, Roopa Prabhu,
John Linville
In-Reply-To: <547727F0.7020105@mojatatu.com>
Thu, Nov 27, 2014 at 02:32:32PM CET, jhs@mojatatu.com wrote:
>On 11/27/14 08:03, Thomas Graf wrote:
>
>>So what is your name suggestion?
>>
>
>I would have gone for _offload_ either as a prefix or suffix
>somewhere.
$ git grep offload net
Wouldn't it be confusing to add this another different "offload". That's
just confusing.
I still like "switch" the best. If it passes packets around, it's a
"switch", +-. Everybody understand what's going on if you use "switch".
If you use "offload", everybody is confused...
>
>cheers,
>jamal
^ permalink raw reply
* Re: bug in networking code causes GPF
From: Daniel Borkmann @ 2014-11-27 13:54 UTC (permalink / raw)
To: Дениска-редиска
Cc: linux-net, netdev, linux-kernel, minipli, fw
In-Reply-To: <1417095336.547728a8852ee@mail.inbox.lv>
On 11/27/2014 02:35 PM, Дениска-редиска wrote:
> hello,
>
> i run ipvs DR on 2 servers under heavy load - up to 1Gbps of traffic.
> Time to time the server where ipvs runs master IP (VIP) get general protection fault. Switching master to another server make no difference - after some time GPF come. So I assume it is not hardware issue.
>
> There are logs from both servers with different kernels (i run kernel with grsecurity patch set from Gentoo hardened portage tree):
Hmm, looks pretty much like ...
http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/54903
... which was a bug in the grsec patch set.
Does your grsec kernel have:
commit 0fa213cce614ad25a79acbd06f37f1e9022134d9
Author: Brad Spengler <spender@grsecurity.net>
Date: Fri Oct 31 17:29:20 2014 -0400
From: Mathias Krause <minipli@googlemail.com>
To: PaX Team <pageexec@freemail.hu>
Cc: Brad Spengler <spender@grsecurity.net>, Mathias Krause
<minipli@googlemail.com>
Subject: [PATCH] pax: don't sanitize RCU slab caches
We cannot sanitize SLAB_DESTROY_BY_RCU slab caches in kmem_cache_free()
as there might be readers in this RCU period, wanting to access the
object.
Fix this, for now, by marking those with SLAB_NO_SANITIZE. Hopefully we
can have a real fix later on. But this should fix the RCU stalls and
netfilter conntrack related problems.
This patch should go on top of the previous patch.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
> [354497.931834] general protection fault: 0000 [#1] SMP
> [354497.931903] CPU: 14 PID: 0 Comm: swapper/14 Not tainted 3.13.10-hardened.standart.20140515 #1
> [354497.931993] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.5 11/25/2013
> [354497.932082] task: ffff88021e4b2ca0 ti: ffff88021e4b3100 task.ti: ffff88021e4b3100
> [354497.932167] RIP: 0010:[<ffffffff81653ca2>] [<ffffffff81653ca2>] ffffffff81653ca2
> [354497.932278] RSP: 0000:ffff88021fd03b98 EFLAGS: 00010246
> [354497.932330] RAX: 0000000000013ba0 RBX: fefefefefefefefe RCX: 000000000001bc30
> [354497.932413] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> [354497.932497] RBP: ffff88021fd03c40 R08: 00000000cacb7f0b R09: ffff88021fd03c58
> [354497.932580] R10: ffffffffffffffff R11: ffff88041de33280 R12: 8000000000000000
> [354497.932663] R13: 0000000000003786 R14: ffffffff81a82540 R15: 0000000000000000
> [354497.932749] FS: 000003853a8a7740(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
> [354497.932836] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [354497.932891] CR2: 000003d8a933b2d0 CR3: 000000000174a000 CR4: 00000000000407f0
> [354497.932973] Stack:
> [354497.933013] 0000000000000000 ffffffff81a82540 00000000de1b1efe 0000000000000000
> [354497.933110] ffff88021fd03c40 ffffffff81653f6d ffffffff81a92cc0 ffffffff81a82540
> [354497.933206] ffff88041d70c500 0000000000000000 00000000de1b1efe ffffffff81654f6c
> [354497.933304] Call Trace:
> [354497.933347] <IRQ>
> [354497.933357] [<ffffffff81653f6d>] ? __nf_conntrack_find_get+0x28/0x13b
> [354497.933484] [<ffffffff81654f6c>] ? nf_conntrack_in+0x253/0x73e
> [354497.933544] [<ffffffff8164eeb6>] ? nf_iterate+0x40/0x7d
> [354497.933601] [<ffffffff816a90a4>] ? inet_del_offload+0x39/0x39
> [354497.933658] [<ffffffff8164ef5f>] ? nf_hook_slow+0x6c/0x104
> [354497.933714] [<ffffffff816a90a4>] ? inet_del_offload+0x39/0x39
> [354497.933770] [<ffffffff816a98c8>] ? ip_rcv+0x313/0x35f
> [354497.933824] [<ffffffff816a93d1>] ? ip_local_deliver_finish+0xb8/0x11f
> [354497.933885] [<ffffffff81627dfd>] ? __netif_receive_skb_core+0x44d/0x4e2
> [354497.933944] [<ffffffff8162afba>] ? netif_receive_skb+0x4c/0x81
> [354497.934000] [<ffffffff8162b488>] ? napi_gro_receive+0x35/0x7a
> [354497.934058] [<ffffffff81515ddc>] ? igb_poll+0xa49/0xd13
> [354497.934115] [<ffffffff810ce5b1>] ? __wake_up+0x38/0x49
> [354497.934169] [<ffffffff8162b773>] ? net_rx_action+0xa6/0x172
> [354497.934225] [<ffffffff810a31cc>] ? __do_softirq+0xb9/0x1ae
> [354497.934280] [<ffffffff810a3499>] ? irq_exit+0x37/0x7a
> [354497.934335] [<ffffffff81003ce2>] ? do_IRQ+0x96/0xb0
> [354497.934389] [<ffffffff81725a97>] ? common_interrupt+0x97/0x97
> [354497.934441] <EOI>
> [354497.934451] [<ffffffff810e3080>] ? update_ts_time_stats+0x30/0x76
> [354497.934548] [<ffffffff81009d20>] ? arch_remove_reservations+0x6a/0x6a
> [354497.934607] [<ffffffff81009d23>] ? default_idle+0x3/0x9
> [354497.934676] [<ffffffff8100a333>] ? arch_cpu_idle+0x6/0x1e
> [354497.934732] [<ffffffff81009d20>] ? arch_remove_reservations+0x6a/0x6a
> [354497.934791] [<ffffffff810d434a>] ? cpu_startup_entry+0xe9/0x15b
> [354497.934850] [<ffffffff81024ccf>] ? start_secondary+0x2f9/0x32c
> [354497.934903] Code: c2 85 d2 49 8b 86 d0 04 00 00 74 14 66 45 85 ff 75 0e 65 ff 40 04 e8 85 f6 a4 ff 48 89 d8 eb 69 65 ff 00 48 8b 1b f6 c3 01 75 0f <8b> 43 10 39 45 00 b8 00 00 00 00 74 83 eb 9d 48 d1 eb 4c 39 eb
> [354497.935402] RIP [<ffffffff81653ca2>] ffffffff81653ca2
> [354497.935456] RSP <ffff88021fd03b98>
> [354497.935965] ---[ end trace 7d6f660245b2d541 ]---
> [354497.936080] Kernel panic - not syncing: Fatal exception in interrupt
> [354498.016801] Rebooting in 10 seconds.
>
>
> [674944.621564] general protection fault: 0000 [#1] SMP
> [674944.621637] CPU: 12 PID: 17984 Comm: nginx Not tainted 3.15.10-hardened-r1.standart.20140925 #1
> [674944.621728] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.5 11/25/2013
> [674944.621817] task: ffff88021e1d7700 ti: ffff88021e1d7c68 task.ti: ffff88021e1d7c68
> [674944.621903] RIP: 0010:[<ffffffff816f2be8>] [<ffffffff816f2be8>] ffffffff816f2be8
> [674944.621990] RSP: 0000:ffff88021fc03ce8 EFLAGS: 00010246
> [674944.622057] RAX: ffffc90011901000 RBX: 822098c2102098c2 RCX: 000000005823edca
> [674944.622143] RDX: fefefefefefefefe RSI: 000000009e90f1ad RDI: ffffffff81a8ad40
> [674944.622226] RBP: 000000000050abb3 R08: 000000000050abb3 R09: 000000000001f106
> [674944.622310] R10: ffffea00100cbd80 R11: ffffea00100cbd80 R12: 8000000000000000
> [674944.622394] R13: ffffffff81a8ad40 R14: 0000000049c3f106 R15: ffffc900119f9830
> [674944.622479] FS: 0000029d6fd04740(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000
> [674944.622566] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [674944.622619] CR2: ffffffffff600400 CR3: 0000000001787000 CR4: 00000000000407f0
> [674944.622701] Stack:
> [674944.622741] ffffffff816e9360 ffffffff00000050 ffffffff822098c2 abb3000280000000
> [674944.622839] ffff88006e9c2b00 ffff88011cbd1bce ffff88021e0c0000 0000000000000008
> [674944.622935] ffffffff81a955b0 ffffffff8170920a ffff880100000003 0000000000000008
> [674944.623031] Call Trace:
> [674944.623077] <IRQ>
> [674944.623087] [<ffffffff816e9360>] ? inet_del_offload+0x39/0x39
> [674944.623192] [<ffffffff8170920a>] ? tcp_v4_early_demux+0x14c/0x1bd
> [674944.623250] [<ffffffff816e93b0>] ? ip_rcv_finish+0x50/0x2c1
> [674944.623326] [<ffffffff8165ee92>] ? __netif_receive_skb_core+0x3c8/0x456
> [674944.623386] [<ffffffff8165f10c>] ? netif_receive_skb_internal+0x4c/0x81
> [674944.623447] [<ffffffff816623b3>] ? napi_gro_receive+0x36/0x7c
> [674944.623511] [<ffffffff815485a5>] ? igb_poll+0xa8b/0xd5b
> [674944.623572] [<ffffffff810f7fda>] ? __note_gp_changes+0x31/0x61
> [674944.623630] [<ffffffff816626cf>] ? net_rx_action+0xa6/0x172
> [674944.623688] [<ffffffff810bc995>] ? __do_softirq+0xf6/0x1fb
> [674944.623744] [<ffffffff810bcbf4>] ? irq_exit+0x38/0x7c
> [674944.623798] [<ffffffff81003ce3>] ? do_IRQ+0xb3/0xce
> [674944.623853] [<ffffffff81767217>] ? common_interrupt+0x97/0x97
> [674944.623906] <EOI>
> [674944.623917] Code: 6a d4 75 0e 48 39 5a c8 74 51 eb 06 3b 44 24 50 74 50 4c 89 4c 24 08 e8 e8 fe ff ff 4c 8b 4c 24 08 eb 83 48 8b 12 f6 c2 01 75 0b <44> 39 72 d0 75 f2 e9 75 ff ff ff 48 d1 ea 4c 39 ca 0f 85 64 ff
> [674944.624456] RIP [<ffffffff816f2be8>] ffffffff816f2be8
> [674944.624536] RSP <ffff88021fc03ce8>
> [674944.625020] ---[ end trace 8035e2b5322bab00 ]---
> [674944.625126] Kernel panic - not syncing: Fatal exception in interrupt
> [674944.706563] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
> [674944.706711] Rebooting in 10 seconds.
>
>
> [7523332.314991] general protection fault: 0000 [#1] SMP
> [7523332.315078] CPU: 4 PID: 25432 Comm: nginx Not tainted 3.15.8-hardened.standart.20140901 #1
> [7523332.315172] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 3.0 09/10/2012
> [7523332.315266] task: ffff88041eb98000 ti: ffff88041eb98568 task.ti: ffff88041eb98568
> [7523332.315355] RIP: 0010:[<ffffffff8168db79>] [<ffffffff8168db79>] ffffffff8168db79
> [7523332.315446] RSP: 0018:ffff88021fa03bf8 EFLAGS: 00010246
> [7523332.316983] RAX: 00000000000149c0 RBX: ffffffff81a8ac80 RCX: 00000000000011d5
> [7523332.317070] RDX: 0000000000000000 RSI: 0000000000008ea8 RDI: ffffffff81a8acfe
> [7523332.317187] RBP: ffff88021fa03c5c R08: 00000000b96542ae R09: ffff88021fa03c74
> [7523332.317274] R10: 0000000000000002 R11: ffff880238b8ce00 R12: 8000000000000000
> [7523332.317360] R13: fefefefefefefefe R14: 0000000000000000 R15: 0000000047567b68
> [7523332.317448] FS: 0000031d200c5740(0000) GS:ffff88021fa00000(0000) knlGS:0000000000000000
> [7523332.317538] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [7523332.317594] CR2: 000004373dcef000 CR3: 0000000001779000 CR4: 00000000000007f0
> [7523332.317679] Stack:
> [7523332.317722] 0000000000000000 ffffffff81a8ac80 ffff880003e08200 0000000000000000
> [7523332.317824] ffffffff81a9bf60 ffffffff8168ef87 ffffffff81a9bf60 ffffffff81a96970
> [7523332.317925] 0000000047567b68 ffffffff81a96970 0000000281a90002 0000000000000014
> [7523332.318026] Call Trace:
> [7523332.318072] <IRQ>
> [7523332.318085] [<ffffffff8168ef87>] ? nf_conntrack_in+0x2c1/0x846
> [7523332.318199] [<ffffffff81688956>] ? nf_iterate+0x41/0x81
> [7523332.318259] [<ffffffff816ea4b8>] ? inet_del_offload+0x39/0x39
> [7523332.318321] [<ffffffff81688a0c>] ? nf_hook_slow+0x76/0x111
> [7523332.318393] [<ffffffff816ea4b8>] ? inet_del_offload+0x39/0x39
> [7523332.318453] [<ffffffff816eacf2>] ? ip_rcv+0x2f4/0x356
> [7523332.318512] [<ffffffff81660173>] ? __netif_receive_skb_core+0x3d9/0x410
> [7523332.318575] [<ffffffff8166039c>] ? netif_receive_skb_internal+0x6d/0x77
> [7523332.318640] [<ffffffff816634c1>] ? napi_gro_receive+0x36/0x7c
> [7523332.318702] [<ffffffff8154a30d>] ? igb_poll+0xa46/0xd09
> [7523332.318762] [<ffffffff813bbd0d>] ? __list_add+0x1b/0x37
> [7523332.318820] [<ffffffff816637d2>] ? net_rx_action+0xa0/0x171
> [7523332.318882] [<ffffffff810bcb7a>] ? __do_softirq+0xf7/0x1fa
> [7523332.318943] [<ffffffff8176a29c>] ? do_softirq_own_stack+0x1c/0x30
> [7523332.318999] <EOI>
> [7523332.319013] [<ffffffff810bcccb>] ? do_softirq+0x24/0x2c
> [7523332.319112] [<ffffffff810bcd39>] ? __local_bh_enable_ip+0x66/0x74
> [7523332.319174] [<ffffffff8172f029>] ? ipt_do_table+0x5c6/0x5f0
> [7523332.319235] [<ffffffff81688956>] ? nf_iterate+0x41/0x81
> [7523332.319293] [<ffffffff816ed488>] ? ip_options_rcv_srr+0x1c7/0x1c7
> [7523332.319354] [<ffffffff81688a0c>] ? nf_hook_slow+0x76/0x111
> [7523332.319412] [<ffffffff816ed488>] ? ip_options_rcv_srr+0x1c7/0x1c7
> [7523332.319473] [<ffffffff816ee3a2>] ? __ip_local_out+0x64/0x6e
> [7523332.319533] [<ffffffff8164f4a3>] ? __sk_dst_check+0x34/0x63
> [7523332.319617] [<ffffffff816ee3be>] ? ip_local_out_sk+0x12/0x39
> [7523332.319676] [<ffffffff816eea83>] ? ip_queue_xmit+0x2ab/0x2db
> [7523332.319739] [<ffffffff81703a1e>] ? tcp_transmit_skb+0x6eb/0x735
> [7523332.319801] [<ffffffff81704323>] ? tcp_write_xmit+0x82e/0x969
> [7523332.319861] [<ffffffff816f7278>] ? tcp_sendpage+0x50b/0x5e4
> [7523332.319923] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
> [7523332.319986] [<ffffffff8171a807>] ? inet_sendpage+0xbc/0xe0
> [7523332.320045] [<ffffffff8164eacc>] ? kernel_sendpage+0x49/0x59
> [7523332.320104] [<ffffffff8164eb23>] ? sock_sendpage+0x47/0x53
> [7523332.320163] [<ffffffff81184658>] ? pipe_to_sendpage+0x6f/0x7c
> [7523332.320223] [<ffffffff81185aa8>] ? splice_from_pipe_feed+0x7f/0x10e
> [7523332.320285] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
> [7523332.320347] [<ffffffff81185c2e>] ? __splice_from_pipe+0x3a/0x6b
> [7523332.320408] [<ffffffff81185dff>] ? splice_from_pipe+0x66/0x87
> [7523332.320468] [<ffffffff811845e9>] ? direct_splice_actor+0x49/0x49
> [7523332.320533] [<ffffffff811845df>] ? direct_splice_actor+0x3f/0x49
> [7523332.320599] [<ffffffff811860f5>] ? splice_direct_to_actor+0xd3/0x18d
> [7523332.320661] [<ffffffff811845a0>] ? generic_pipe_buf_nosteal+0xc/0xc
> [7523332.320723] [<ffffffff81186249>] ? do_splice_direct+0x9a/0xb6
> [7523332.320783] [<ffffffff8115e7f2>] ? do_sendfile+0x182/0x32a
> [7523332.320856] [<ffffffff811602bd>] ? SyS_sendfile64+0x137/0x1bc
> [7523332.320916] [<ffffffff81768f37>] ? system_call_fastpath+0x16/0x1b
> [7523332.320972] Code: 00 02 00 00 48 c7 c7 4d db 68 81 65 ff 40 04 e8 71 f1 a2 ff 4d 85 ed 75 58 e9 94 01 00 00 65 ff 00 4d 8b 6d 00 41 f6 c5 01 75 18 <41> 8b 55 10 31 c0 39 55 00 41 8a 7d 37 0f 85 14 ff ff ff e9 e7
> [7523332.321522] RIP [<ffffffff8168db79>] ffffffff8168db79
> [7523332.321579] RSP <ffff88021fa03bf8>
> [7523332.322094] ---[ end trace 0e21b79561002306 ]---
> [7523332.322210] Kernel panic - not syncing: Fatal exception in interrupt
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* wl1251: NVS firmware data
From: Pali Rohár @ 2014-11-27 14:06 UTC (permalink / raw)
To: John W. Linville, Grazvydas Ignotas, linux-wireless, netdev,
linux-kernel, Ming Lei, Greg Kroah-Hartman
Cc: Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Kalle Valo,
Sebastian Reichel, David Gnedt
[-- Attachment #1: Type: Text/Plain, Size: 1673 bytes --]
Hello,
wifi driver wl1251 needs NVS calibration data for working. These
data are loaded by driver via request_firmware from userspace
file: ti-connectivity/wl1251-nvs.bin. In linux-fimrware git tree
there is generic wl1251-nvs.bin file which is used by default.
Driver wl1251 is used on Nokia N900 cellphone for its wifi chip.
This cellphone has one special MTD partition (called CAL) where
are stored some configuration data in special binary (key-value)
format. And there is also stored correct calibration data for
specific device (each device has different data). It is preferred
to use those data instead generic one (provided by linux-firmware
git tree).
Now my question is: How to correctly load calibration data from
special Nokia N900 CAL partition into wl1251 kernel driver?
By default kernel reads ti-connectivity/wl1251-nvs.bin file from
VFS if exists without any userspace support. If it fails then it
fallback to loading via udev.
Reading correct data from CAL partition is not easy (structure is
difficult), but there is open source program which can parse CAL
partition and write NVS data to stdout. So adding this CAL parser
into kernel is not good idea (program is GPLv3+ code --
incompatible with kernel).
So how to solve this problem? How to load correct NVS data from
CAL partition into wl1251 driver?
It is possible to tell kernel to use some helper userspace
program for loading data and if it fails then fallback to direct
loading? E.g first try to use model specific data and if it fails
for some reasons then fallback to reading genetic data.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Ming Lei @ 2014-11-27 14:21 UTC (permalink / raw)
To: Pali Rohár
Cc: John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Greg Kroah-Hartman, Pavel Machek,
Ivaylo Dimitrov, Aaro Koskinen, Kalle Valo, Sebastian Reichel,
David Gnedt
In-Reply-To: <201411271506.20457@pali>
On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> Hello,
>
> wifi driver wl1251 needs NVS calibration data for working. These
> data are loaded by driver via request_firmware from userspace
> file: ti-connectivity/wl1251-nvs.bin. In linux-fimrware git tree
> there is generic wl1251-nvs.bin file which is used by default.
>
> Driver wl1251 is used on Nokia N900 cellphone for its wifi chip.
> This cellphone has one special MTD partition (called CAL) where
> are stored some configuration data in special binary (key-value)
> format. And there is also stored correct calibration data for
> specific device (each device has different data). It is preferred
> to use those data instead generic one (provided by linux-firmware
> git tree).
>
> Now my question is: How to correctly load calibration data from
> special Nokia N900 CAL partition into wl1251 kernel driver?
It is better to let user space script handle the request.
>
> By default kernel reads ti-connectivity/wl1251-nvs.bin file from
> VFS if exists without any userspace support. If it fails then it
> fallback to loading via udev.
You can remove or rename this file so that loading from user space
can be triggered.
>
> Reading correct data from CAL partition is not easy (structure is
> difficult), but there is open source program which can parse CAL
> partition and write NVS data to stdout. So adding this CAL parser
> into kernel is not good idea (program is GPLv3+ code --
> incompatible with kernel).
>
> So how to solve this problem? How to load correct NVS data from
> CAL partition into wl1251 driver?
>
> It is possible to tell kernel to use some helper userspace
> program for loading data and if it fails then fallback to direct
> loading? E.g first try to use model specific data and if it fails
> for some reasons then fallback to reading genetic data.
One solution is to introduce request_firmware_user() and let
this API handle your case, but CONFIG_FW_LOADER_USER_HELPER
has to be enabled.
If request_firmware_user() fails, request_firmware_direct() can be
tried further.
Thanks,
Ming Lei
^ permalink raw reply
* Re: [PATCH] x86: bpf_jit_comp: simplify trivial boolean return
From: Quentin Lambert @ 2014-11-27 14:36 UTC (permalink / raw)
To: David Laight, 'Joe Perches', Alexei Starovoitov
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9FDA63@AcuExch.aculab.com>
On 27/11/2014 13:25, David Laight wrote:
> From: Joe Perches
>> On Wed, 2014-11-26 at 10:34 -0800, Alexei Starovoitov wrote:
>>> On Wed, Nov 26, 2014 at 10:02 AM, Joe Perches <joe@perches.com> wrote:
>>>> On Wed, 2014-11-26 at 09:23 -0800, Alexei Starovoitov wrote:
>>>>> On Wed, Nov 26, 2014 at 8:58 AM, Joe Perches <joe@perches.com> wrote:
>>>>>> Is there any value in reordering these tests for frequency
>>>>>> or maybe using | instead of || to avoid multiple jumps?
>>>>> probably not. It's not a critical path.
>>>>> compiler may fuse conditions depending on values anyway.
>>>>> If it was a critical path, we could have used
>>>>> (1 << reg) & mask trick.
>>>>> I picked explicit 'return true' else 'return false' here,
>>>>> because it felt easier to read. Just a matter of taste.
>>>> There is a size difference though: (allyesconfig)
>>>>
>>>> $ size arch/x86/net/built-in.o*
>>>> text data bss dec hex filename
>>>> 12999 1012 4336 18347 47ab arch/x86/net/built-in.o.new
>>>> 13177 1076 4592 18845 499d arch/x86/net/built-in.o.old
>>> interesting. Compiler obviously thinks that 178 byte increase
>>> with -O2 is the right trade off. Which I agree with :)
>>>
>>> If I think dropping 'inline' and using -Os will give bigger savings...
>> This was allyesconfig which already uses -Os
>>
>> Using -O2, there is no difference using inline
>> or not, but the size delta with the bitmask is
>> much larger
>>
>> $ size arch/x86/net/built-in.o* (allyesconfig, but not -Os)
>> text data bss dec hex filename
>> 13410 820 3624 17854 45be arch/x86/net/built-in.o.new
>> 16130 884 4200 21214 52de arch/x86/net/built-in.o.old
>> 16130 884 4200 21214 52de arch/x86/net/built-in.o.static
> That is quite a big % change in the code size.
> Why the change in data?
>
> David
>
>
>
Do you want me to propose a second version, or should I just
drop it all together ?
I am a new contributor so I have no experience in that sort of thing.
Quentin
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Pali Rohár @ 2014-11-27 14:43 UTC (permalink / raw)
To: Ming Lei
Cc: John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Greg Kroah-Hartman, Pavel Machek,
Ivaylo Dimitrov, Aaro Koskinen, Kalle Valo, Sebastian Reichel,
David Gnedt
In-Reply-To: <CACVXFVMr8jH1ZzyPNG91VDK8DuVjQsHn9ks62sSNjOfUnNsURQ@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 2970 bytes --]
On Thursday 27 November 2014 15:21:44 Ming Lei wrote:
> On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár
<pali.rohar@gmail.com> wrote:
> > Hello,
> >
> > wifi driver wl1251 needs NVS calibration data for working.
> > These data are loaded by driver via request_firmware from
> > userspace file: ti-connectivity/wl1251-nvs.bin. In
> > linux-fimrware git tree there is generic wl1251-nvs.bin
> > file which is used by default.
> >
> > Driver wl1251 is used on Nokia N900 cellphone for its wifi
> > chip. This cellphone has one special MTD partition (called
> > CAL) where are stored some configuration data in special
> > binary (key-value) format. And there is also stored correct
> > calibration data for specific device (each device has
> > different data). It is preferred to use those data instead
> > generic one (provided by linux-firmware git tree).
> >
> > Now my question is: How to correctly load calibration data
> > from special Nokia N900 CAL partition into wl1251 kernel
> > driver?
>
> It is better to let user space script handle the request.
>
Yes, this makes sense. Implementing CAL parser in kernel wl1251
driver would be hard...
> > By default kernel reads ti-connectivity/wl1251-nvs.bin file
> > from VFS if exists without any userspace support. If it
> > fails then it fallback to loading via udev.
>
> You can remove or rename this file so that loading from user
> space can be triggered.
>
It is no so easy... In case when CAL does not contains NVS data
then we want to use this generic NVS file. And telling everybody
to rename this is file is not good solution...
> > Reading correct data from CAL partition is not easy
> > (structure is difficult), but there is open source program
> > which can parse CAL partition and write NVS data to stdout.
> > So adding this CAL parser into kernel is not good idea
> > (program is GPLv3+ code -- incompatible with kernel).
> >
> > So how to solve this problem? How to load correct NVS data
> > from CAL partition into wl1251 driver?
> >
> > It is possible to tell kernel to use some helper userspace
> > program for loading data and if it fails then fallback to
> > direct loading? E.g first try to use model specific data
> > and if it fails for some reasons then fallback to reading
> > genetic data.
>
> One solution is to introduce request_firmware_user() and let
> this API handle your case, but CONFIG_FW_LOADER_USER_HELPER
> has to be enabled.
>
> If request_firmware_user() fails, request_firmware_direct()
> can be tried further.
>
> Thanks,
> Ming Lei
Ok, new kernel function which will change order of loading
firmware should work.
Which userspace helper programs for (automatic) firmware loading
are used? Can be udev configured to use own program for loading
firmware instead that udev integrated which looking for firmware
only in /lib/firmware files?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ 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