* Re: [PATCH stable 3.11+] can: use private sk reference to detect originating socket
From: Oliver Hartkopp @ 2014-01-29 21:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Linux Netdev List, Andre Naujoks,
linux-can@vger.kernel.org
In-Reply-To: <52E9675A.4070201@hartkopp.net>
So here we are:
Introduced can_create_echo_skb() which creates a skb which is properly
owned to be send back (echo'ed) into the network stack.
Regards,
Oliver
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 13a9098..fc59bc6 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -323,19 +323,10 @@ void can_put_echo_skb(struct sk_buff *skb, struct net_device *dev,
}
if (!priv->echo_skb[idx]) {
- struct sock *srcsk = skb->sk;
- if (atomic_read(&skb->users) != 1) {
- struct sk_buff *old_skb = skb;
-
- skb = skb_clone(old_skb, GFP_ATOMIC);
- kfree_skb(old_skb);
- if (!skb)
- return;
- } else
- skb_orphan(skb);
-
- skb->sk = srcsk;
+ skb = can_create_echo_skb(skb);
+ if (!skb)
+ return;
/* make settings for echo to reduce code in irq context */
skb->protocol = htons(ETH_P_CAN);
diff --git a/drivers/net/can/janz-ican3.c b/drivers/net/can/janz-ican3.c
index e24e669..2124c679 100644
--- a/drivers/net/can/janz-ican3.c
+++ b/drivers/net/can/janz-ican3.c
@@ -18,6 +18,7 @@
#include <linux/netdevice.h>
#include <linux/can.h>
#include <linux/can/dev.h>
+#include <linux/can/skb.h>
#include <linux/can/error.h>
#include <linux/mfd/janz.h>
@@ -1133,20 +1134,9 @@ static void ican3_handle_message(struct ican3_dev *mod, struct ican3_msg *msg)
*/
static void ican3_put_echo_skb(struct ican3_dev *mod, struct sk_buff *skb)
{
- struct sock *srcsk = skb->sk;
-
- if (atomic_read(&skb->users) != 1) {
- struct sk_buff *old_skb = skb;
-
- skb = skb_clone(old_skb, GFP_ATOMIC);
- kfree_skb(old_skb);
- if (!skb)
- return;
- } else {
- skb_orphan(skb);
- }
-
- skb->sk = srcsk;
+ skb = can_create_echo_skb(skb);
+ if (!skb)
+ return;
/* save this skb for tx interrupt echo handling */
skb_queue_tail(&mod->echoq, skb);
diff --git a/drivers/net/can/vcan.c b/drivers/net/can/vcan.c
index 0a2a5ee..4e94057 100644
--- a/drivers/net/can/vcan.c
+++ b/drivers/net/can/vcan.c
@@ -46,6 +46,7 @@
#include <linux/if_ether.h>
#include <linux/can.h>
#include <linux/can/dev.h>
+#include <linux/can/skb.h>
#include <linux/slab.h>
#include <net/rtnetlink.h>
@@ -109,25 +110,23 @@ static netdev_tx_t vcan_tx(struct sk_buff *skb, struct net_device *dev)
stats->rx_packets++;
stats->rx_bytes += cfd->len;
}
- kfree_skb(skb);
+ consume_skb(skb);
return NETDEV_TX_OK;
}
/* perform standard echo handling for CAN network interfaces */
if (loop) {
- struct sock *srcsk = skb->sk;
- skb = skb_share_check(skb, GFP_ATOMIC);
+ skb = can_create_echo_skb(skb);
if (!skb)
return NETDEV_TX_OK;
/* receive with packet counting */
- skb->sk = srcsk;
vcan_rx(skb, dev);
} else {
/* no looped packets => no counting */
- kfree_skb(skb);
+ consume_skb(skb);
}
return NETDEV_TX_OK;
}
diff --git a/include/linux/can/skb.h b/include/linux/can/skb.h
index 2f0543f..f9bbbb4 100644
--- a/include/linux/can/skb.h
+++ b/include/linux/can/skb.h
@@ -11,7 +11,9 @@
#define CAN_SKB_H
#include <linux/types.h>
+#include <linux/skbuff.h>
#include <linux/can.h>
+#include <net/sock.h>
/*
* The struct can_skb_priv is used to transport additional information along
@@ -42,4 +44,40 @@ static inline void can_skb_reserve(struct sk_buff *skb)
skb_reserve(skb, sizeof(struct can_skb_priv));
}
+static inline void can_skb_destructor(struct sk_buff *skb)
+{
+ sock_put(skb->sk);
+}
+
+static inline void can_skb_set_owner(struct sk_buff *skb, struct sock *sk)
+{
+ if (sk) {
+ sock_hold(sk);
+ skb->destructor = can_skb_destructor;
+ skb->sk = sk;
+ }
+}
+
+/*
+ * returns an unshared skb owned by the original sock to be echo'ed back
+ */
+static inline struct sk_buff *can_create_echo_skb(struct sk_buff *skb)
+{
+ if (skb_shared(skb)) {
+ struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
+
+ if (likely(nskb)) {
+ can_skb_set_owner(nskb, skb->sk);
+ consume_skb(skb);
+ return nskb;
+ } else {
+ kfree_skb(skb);
+ return NULL;
+ }
+ }
+
+ /* we can assume to have an unshared skb with proper owner */
+ return skb;
+}
+
#endif /* CAN_SKB_H */
diff --git a/net/can/af_can.c b/net/can/af_can.c
index d249874..a27f8aa 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -57,6 +57,7 @@
#include <linux/skbuff.h>
#include <linux/can.h>
#include <linux/can/core.h>
+#include <linux/can/skb.h>
#include <linux/ratelimit.h>
#include <net/net_namespace.h>
#include <net/sock.h>
@@ -290,7 +291,7 @@ int can_send(struct sk_buff *skb, int loop)
return -ENOMEM;
}
- newskb->sk = skb->sk;
+ can_skb_set_owner(newskb, skb->sk);
newskb->ip_summed = CHECKSUM_UNNECESSARY;
newskb->pkt_type = PACKET_BROADCAST;
}
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 3fc737b..dcb75c0 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -268,7 +268,7 @@ static void bcm_can_tx(struct bcm_op *op)
/* send with loopback */
skb->dev = dev;
- skb->sk = op->sk;
+ can_skb_set_owner(skb, op->sk);
can_send(skb, 1);
/* update statistics */
@@ -1223,7 +1223,7 @@ static int bcm_tx_send(struct msghdr *msg, int ifindex, struct sock *sk)
can_skb_prv(skb)->ifindex = dev->ifindex;
skb->dev = dev;
- skb->sk = sk;
+ can_skb_set_owner(skb, sk);
err = can_send(skb, 1); /* send with loopback */
dev_put(dev);
On 29.01.2014 21:40, Oliver Hartkopp wrote:
> On 29.01.2014 20:55, Eric Dumazet wrote:
>
>>> 2. The check for sk and the additional skb_orphan() is not needed as the
>>> can_skb_set_owner() is invoked only after 'fresh' skb allocation or after
>>> clone/skb_orphan() - so we know the skb state very good.
>>
>> Yep, but then you added skb_orphan() calls. when skb is not shared.
>
> I did that e.g. in the sources placed in driver/net/can because I assume that
> I can not be sure that I always get skbs created by AF_CAN.
>
> E.g. one could also use AF_PACKET to send CAN frames to the CAN interfaces.
>
> Btw. assuming AF_PACKET does it correct too with the destructor I will omit
> the skb_orphan() / can_skb_set_owner() sequence in drivers/net/can in the next
> attempt.
>
> Tnx
> Oliver
>
>>
>> I think you really should have a helper instead of copying this 3 times.
>>
>
> ok
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" 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 related
* Re: [PATCH stable 3.11+] can: use private sk reference to detect originating socket
From: Eric Dumazet @ 2014-01-29 21:06 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: David Miller, Linux Netdev List, Andre Naujoks,
linux-can@vger.kernel.org
In-Reply-To: <52E96BDC.9070209@hartkopp.net>
On Wed, 2014-01-29 at 22:00 +0100, Oliver Hartkopp wrote:
> So here we are:
>
> Introduced can_create_echo_skb() which creates a skb which is properly
> owned to be send back (echo'ed) into the network stack.
>
> Regards,
> Oliver
This seems much better ;)
^ permalink raw reply
* [PATCH 3/3] can: janz-ican3: fix uninitialized variable warnings
From: Marc Kleine-Budde @ 2014-01-29 21:11 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel, Ira W. Snyder, Marc Kleine-Budde
In-Reply-To: <1391029863-23099-1-git-send-email-mkl@pengutronix.de>
From: "Ira W. Snyder" <iws@ovro.caltech.edu>
Analysis of the code shows that the struct ican3_msg variable cannot be
used uninitialized. Error conditions are checked and the loop terminates
before calling the ican3_handle_message() function with an uninitialized
value.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/janz-ican3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/janz-ican3.c b/drivers/net/can/janz-ican3.c
index e24e669..07f0ba0 100644
--- a/drivers/net/can/janz-ican3.c
+++ b/drivers/net/can/janz-ican3.c
@@ -1322,7 +1322,7 @@ static int ican3_napi(struct napi_struct *napi, int budget)
/* process all communication messages */
while (true) {
- struct ican3_msg msg;
+ struct ican3_msg uninitialized_var(msg);
ret = ican3_recv_msg(mod, &msg);
if (ret)
break;
--
1.8.5.3
^ permalink raw reply related
* pull-request: can 2014-01-29
From: Marc Kleine-Budde @ 2014-01-29 21:11 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel
Hello David,
this is a pull request with three fixes for net/master, for the current release
cycle.
Arnd Bergmann provides a fix for the flexcan driver, enabling compilation on
all combinations of big and little endian on ARM and PowerPc. A patch by Ira W.
Snyder fixes uninitialized variable warnings in the janz-ican3 driver.
Rostislav Lisovy contributes a patch to propagate the SO_PRIORITY of raw
sockets to skbs.
Marc
---
The following changes since commit c044dc2132d19d8c643cdd340f21afcec177c046:
qeth: fix build of s390 allmodconfig (2014-01-29 00:43:33 -0800)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can.git tags/linux-can-fixes-for-3.14-20140129
for you to fetch changes up to 73615c8669ef1c497c942cae0d5079b95824332a:
can: janz-ican3: fix uninitialized variable warnings (2014-01-29 20:23:23 +0100)
----------------------------------------------------------------
linux-can-fixes-for-3.14-20140129
----------------------------------------------------------------
Arnd Bergmann (1):
can: flexcan: fix flexcan driver build for big endian on ARM and little endian on PowerPc
Ira W. Snyder (1):
can: janz-ican3: fix uninitialized variable warnings
Rostislav Lisovy (1):
can: Propagate SO_PRIORITY of raw sockets to skbs
drivers/net/can/Kconfig | 2 +-
drivers/net/can/flexcan.c | 7 +++++--
drivers/net/can/janz-ican3.c | 2 +-
net/can/raw.c | 1 +
4 files changed, 8 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 1/3] can: flexcan: fix flexcan driver build for big endian on ARM and little endian on PowerPc
From: Marc Kleine-Budde @ 2014-01-29 21:11 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Arnd Bergmann, Guenter Roeck,
Lothar Waßmann, Marc Kleine-Budde
In-Reply-To: <1391029863-23099-1-git-send-email-mkl@pengutronix.de>
From: Arnd Bergmann <arnd@arndb.de>
There is no reason to disallow building the driver on big-endian ARM kernels.
Furthermore, the current behavior is actually broken on little-endian PowerPC
as well.
The choice of register accessor functions must purely depend on the CPU
architecture, not which endianess the CPU is running on. Note that we nowadays
allow both big-endian ARM and little-endian PowerPC kernels.
With this patch applied, we will do the right thing in all four combinations.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/Kconfig | 2 +-
drivers/net/can/flexcan.c | 7 +++++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index d447b88..9e7d95d 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -104,7 +104,7 @@ config CAN_JANZ_ICAN3
config CAN_FLEXCAN
tristate "Support for Freescale FLEXCAN based chips"
- depends on (ARM && CPU_LITTLE_ENDIAN) || PPC
+ depends on ARM || PPC
---help---
Say Y here if you want to support for Freescale FlexCAN.
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index aaed97b..320bef2 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -235,9 +235,12 @@ static const struct can_bittiming_const flexcan_bittiming_const = {
};
/*
- * Abstract off the read/write for arm versus ppc.
+ * Abstract off the read/write for arm versus ppc. This
+ * assumes that PPC uses big-endian registers and everything
+ * else uses little-endian registers, independent of CPU
+ * endianess.
*/
-#if defined(__BIG_ENDIAN)
+#if defined(CONFIG_PPC)
static inline u32 flexcan_read(void __iomem *addr)
{
return in_be32(addr);
--
1.8.5.3
^ permalink raw reply related
* [PATCH 2/3] can: Propagate SO_PRIORITY of raw sockets to skbs
From: Marc Kleine-Budde @ 2014-01-29 21:11 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Rostislav Lisovy, Michal Sojka,
Marc Kleine-Budde
In-Reply-To: <1391029863-23099-1-git-send-email-mkl@pengutronix.de>
From: Rostislav Lisovy <lisovy@gmail.com>
This allows controlling certain queueing disciplines by setting the
socket's SO_PRIORITY option.
For example, with the default pfifo_fast queueing discipline, which
provides three priorities, socket priority TC_PRIO_CONTROL means
higher than default and TC_PRIO_BULK means lower than default.
Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
net/can/raw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/can/raw.c b/net/can/raw.c
index 07d72d8..8be757c 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -715,6 +715,7 @@ static int raw_sendmsg(struct kiocb *iocb, struct socket *sock,
skb->dev = dev;
skb->sk = sk;
+ skb->priority = sk->sk_priority;
err = can_send(skb, ro->loopback);
--
1.8.5.3
^ permalink raw reply related
* Re: Help testing for USB ethernet/xHCI regression
From: Sarah Sharp @ 2014-01-29 21:18 UTC (permalink / raw)
To: Mark Lord; +Cc: Greg Kroah-Hartman, linux-usb, netdev, David Laight
In-Reply-To: <52E883FB.7010704@pobox.com>
On Tue, Jan 28, 2014 at 11:30:51PM -0500, Mark Lord wrote:
> On 14-01-28 03:30 PM, Sarah Sharp wrote:
> ..
> > Can you please pull this branch, which contains a 3.13 kernel with
> > David's patch reverted, and test whether your USB ethernet device works
> > or fails?
>
> Fails. dmesg log attached.
It's funny, because there's certainly data transferred over endpoint
0x82, even though there were link TRBs in the middle of transfers. Did
the "untransferred" messages stop when the device stopped working, or
did they continue?
> All I do is something akin to this:
>
> mount /server/ /x
> mount --bind / /t
> mirrordir -v --strict-mtimes /t /x/backups/empress
>
> "mirrordir" is similar to "rsync", but less cryptic.
> The sequence above maintains a clone of the root filesystem
> of my ultrabook ("empress") on an NFS server over GigE.
Please send me the output of `sudo lsusb -t` and `sudo lsusb -v` with
the USB device attached. I'd like to know whether you and David have
the same device and driver. Perhaps the link TRB issue only impacts
that device, and we can limit scatter-gather under xHCI for that device.
If not, we'll have to look at bigger fixes.
Sarah Sharp
^ permalink raw reply
* Re: [Patch resend nf] ipvs: fix AF assignment in ip_vs_conn_new()
From: Julian Anastasov @ 2014-01-29 21:24 UTC (permalink / raw)
To: Michal Kubecek
Cc: netfilter-devel, netdev, lvs-devel, Wensong Zhang, Simon Horman,
Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller
In-Reply-To: <20140129145437.69F56E916F@unicorn.suse.cz>
Hello,
On Wed, 29 Jan 2014, Michal Kubecek wrote:
> If a fwmark is passed to ip_vs_conn_new(), it is passed in
> vaddr, not daddr. Therefore we should set AF to AF_UNSPEC in
> vaddr assignment (like we do in ip_vs_ct_in_get()).
>
> Signed-off-by: Bogdano Arendartchuk <barendartchuk@suse.com>
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
> ---
> (first time it didn't reach all recipients due to a malformed header)
> ---
> net/netfilter/ipvs/ip_vs_conn.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
> index 59a1a85..282b39b 100644
> --- a/net/netfilter/ipvs/ip_vs_conn.c
> +++ b/net/netfilter/ipvs/ip_vs_conn.c
> @@ -871,11 +871,11 @@ ip_vs_conn_new(const struct ip_vs_conn_param *p,
> cp->protocol = p->protocol;
> ip_vs_addr_set(p->af, &cp->caddr, p->caddr);
> cp->cport = p->cport;
> - ip_vs_addr_set(p->af, &cp->vaddr, p->vaddr);
> - cp->vport = p->vport;
> - /* proto should only be IPPROTO_IP if d_addr is a fwmark */
> + /* proto should only be IPPROTO_IP if p->vaddr is a fwmark */
> ip_vs_addr_set(p->protocol == IPPROTO_IP ? AF_UNSPEC : p->af,
> - &cp->daddr, daddr);
> + &cp->vaddr, vaddr);
Patch does not compile due to vaddr and p->daddr
usage but you are in the right direction. Such change should
fix a problem where connection templates don't get full
IPv6 address for the real server, only the first 4 bytes
are copied and as result it works only for IPv4.
> + cp->vport = p->vport;
> + ip_vs_addr_set(p->af, &cp->daddr, p->daddr);
> cp->dport = dport;
> cp->flags = flags;
> cp->fwmark = fwmark;
> --
> 1.8.1.4
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH stable 3.11+] can: use private sk reference to detect originating socket
From: Oliver Hartkopp @ 2014-01-29 21:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Linux Netdev List, Andre Naujoks,
linux-can@vger.kernel.org
In-Reply-To: <1391029578.28432.64.camel@edumazet-glaptop2.roam.corp.google.com>
On 29.01.2014 22:06, Eric Dumazet wrote:
> On Wed, 2014-01-29 at 22:00 +0100, Oliver Hartkopp wrote:
>> So here we are:
>>
>> Introduced can_create_echo_skb() which creates a skb which is properly
>> owned to be send back (echo'ed) into the network stack.
>>
>> Regards,
>> Oliver
>
> This seems much better ;)
>
Great!
I'll give it some more testing on my Laptop and will send the patch with a
proper description tomorrow morning.
Thanks for your support fixing this issue!
Regards,
Oliver
^ permalink raw reply
* Re: Help testing for USB ethernet/xHCI regression
From: Sarah Sharp @ 2014-01-29 21:54 UTC (permalink / raw)
To: renevant; +Cc: linux-usb, Mark Lord, Greg Kroah-Hartman, netdev, David Laight
In-Reply-To: <22081260.RNay0J72dY@athas>
On Wed, Jan 29, 2014 at 04:21:00PM +1100, renevant@internode.on.net wrote:
> Hello,
>
> I am someone who has been struggling to get an ax88179 net adapter working
> reliably.
>
> I have an integrated Asmedia 1042 xhci controller that is reportedly version
> 0.96 on an ASUS M5A99FX PRO R2.0, BIOS 2201 motherboard based on the AMD 990FX
> chipset.
>
> The big issue I am currently facing is that I cannot get the device to work at
> all with 3.13 and current 3.14 mainline. This does not occur with 3.12.
With the working kernel, were you using vanilla 3.12, or a later 3.12
stable release, like 3.12.5?
> Current issue is when plugging in the ax88179 there is lag when bringing the
> interface up and a bunch of kernel messages:
With which kernel?
> [ 63.389440] ax88179_178a 2-1:1.0 eth0: register 'ax88179_178a' at
> usb-0000:07:00.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 80:3f:5d:08:0c:65
> [ 63.389500] usbcore: registered new interface driver ax88179_178a
> [ 63.423942] systemd-udevd[560]: renamed network interface eth0 to enp7s0u1
> [ 79.481028] IPv6: ADDRCONF(NETDEV_UP): enp7s0u1: link is not ready
> [ 82.210721] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1
> [ 82.338947] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1
> [ 82.467148] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped
> [ 82.470028] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1
> [ 82.595364] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped
> [ 82.598312] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1
> [ 82.723580] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped
> [ 82.726487] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1
> [ 82.851796] ax88179_178a 2-1:1.0 enp7s0u1: kevent 4 may have been dropped
> [ 82.854642] ax88179_178a 2-1:1.0 enp7s0u1: ax88179 - Link status is: 1
> [snip]
> [ 87.218379] ax88179_178a 2-1:1.0 enp7s0u1: Failed to write reg index
> 0x0002: -110
Can you enable xHCI debugging as well, and send dmesg? You'll need to
have CONFIG_USB_DEBUG turned on, and also run this command as root:
echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
> Any traffic sent to the nic isn't seen by Linux.
>
>
> I can confirm the following problems for me with 3.14:
>
> reverting the writeq patch made USB 3 work for me again.
>
> http://marc.info/?t=139093294600002&r=1&w=2
So what was the issue that caused you to revert that patch? The traffic
not going to the device, or the device not being enumerated at all?
> and
>
> http://marc.info/?l=linux-usb&m=139092084714232&w=2
>
> got rid of transiever errors
>
>
>
>
> I cannot really test stability for the ax88179 until I can get it to work when
> plugging it in as above. I've tried the frag reversion and it's made no
> difference to this issue.
What about also reverting the writeq patch, on top of the other patches
I asked Mark to try?
Sarah Sharp
^ permalink raw reply
* Re: [PATCH 0/2] DT: net: davinci_emac: couple more properties actually optional
From: Sergei Shtylyov @ 2014-01-29 22:42 UTC (permalink / raw)
To: David Miller
Cc: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree, linux-doc, davinci-linux-open-source
In-Reply-To: <20140128.234315.2164810932256158473.davem@davemloft.net>
Hello.
On 01/29/2014 10:43 AM, David Miller wrote:
>> Though described as required, couple more properties in the DaVinci EMAC
>> binding are actually optional, as the driver will happily function without them.
>> The patchset is against DaveM's 'net.git' tree this time.
>> [1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
>> [2/2] DT: net: davinci_emac: "ti,davinci-no-bd-ram" property is actually optional
> Series applied with the "has/have" thing fixed.
> Thanks.
Thank you!
Unfortunately, this driver presents a bad example of DT bindings overall
(caused in its turn by a misuse of the platform data for the EMAC type
differing instead of the platform device IDs).
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] DT: net: document Ethernet bindings in one place
From: Sergei Shtylyov @ 2014-01-29 23:04 UTC (permalink / raw)
To: Florian Fainelli, Rob Herring
Cc: netdev, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, devicetree@vger.kernel.org, Rob Landley,
linux-doc@vger.kernel.org, Grant Likely
In-Reply-To: <52DEE465.9000202@cogentembedded.com>
Hello.
On 01/22/2014 12:19 AM, Sergei Shtylyov wrote:
>>>>> I'm afraid that's too late, it has spread very far, so that
>>>>> of_get_phy_mode() handles that property, not "phy-connection-type".
>>>> Uggg, I guess this is a case of a defacto standard then if the kernel
>>>> doesn't even support it.
>>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a
>>> while ago for of_get_phy_mode() to look for both "phy-mode" and
>>> "phy-connection-type" since the former has been a Linux invention, but
>>> the latter is ePAPR specified.
>> Here is a link to the actual patch in question, not sure which tree
>> Grant applied it to though:
>> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html
> It's not the patch mail, it's Grant's "applied" reply, patch is mangled in
> this reply, and I couldn't follow the thread. Here's the actual patch mail:
> http://marc.info/?l=devicetree&m=138449662807254
Florian, I didn't find this patch in Grant's official tree, so maybe you
should ask him where is the patch already?
WBR, Sergei
^ permalink raw reply
* [Patch iproute2] pedit: do not print debugging information by default
From: Cong Wang @ 2014-01-29 23:12 UTC (permalink / raw)
To: netdev; +Cc: Jamal Hadi Salim, Stephen Hemminger, Cong Wang
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
diff --git a/tc/m_pedit.c b/tc/m_pedit.c
index 452d96f..16dd277 100644
--- a/tc/m_pedit.c
+++ b/tc/m_pedit.c
@@ -30,7 +30,7 @@
#include "m_pedit.h"
static struct m_pedit_util *pedit_list;
-int pedit_debug = 1;
+static int pedit_debug;
static void
explain(void)
^ permalink raw reply related
* Re: IPv6 multiple routing tables - all routes were added to main table
From: Ben Greear @ 2014-01-29 23:17 UTC (permalink / raw)
To: Asi Lichtenstein; +Cc: netdev
In-Reply-To: <CAMBtn_0S0K6eydjTLJAsVqbKVuJ+tc7k30OUWRxscm+gP6y2EQ@mail.gmail.com>
On 01/28/2014 01:38 AM, Asi Lichtenstein wrote:
> Hi there,
>
> I'm using an old kernel 2.6.16 where i applied this patchset:
> http://thread.gmane.org/gmane.linux.network/41149/focus=41150
>
> i was able to create new table but all routes I've added to specific
> table were added to main table.
No idea if your patches will work on that ancient kernel. Did you update
your ip tool as well?
try: ip route show table X
and show us what commands you used to try to add the routes to a specific
table?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [Patch net] net: allow setting mac address of loopback device
From: Cong Wang @ 2014-01-29 23:38 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, Eric Dumazet, David S. Miller, Cong Wang
We are trying to mirror the local traffic from lo to eth0,
allowing setting mac address of lo to eth0 would make
the ether addresses in these packets correct, so that
we don't have to modify the ether header again.
Since usually no one cares about its mac address (all-zero),
it is safe to allow those who care to set its mac address.
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index c5011e0..a0ee030 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -160,6 +160,7 @@ static const struct net_device_ops loopback_ops = {
.ndo_init = loopback_dev_init,
.ndo_start_xmit= loopback_xmit,
.ndo_get_stats64 = loopback_get_stats64,
+ .ndo_set_mac_address = eth_mac_addr,
};
/*
^ permalink raw reply related
* Re: [PATCH v2 3/4] net: ethoc: set up MII management bus clock
From: Max Filippov @ 2014-01-30 0:14 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-xtensa@linux-xtensa.org, netdev, LKML, Chris Zankel,
Marc Gauthier, David S. Miller, Ben Hutchings
In-Reply-To: <52E8A74F.9060603@gmail.com>
On Wed, Jan 29, 2014 at 11:01 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Le 28/01/2014 22:00, Max Filippov a écrit :
>
>> MII management bus clock is derived from the MAC clock by dividing it by
>> MIIMODER register CLKDIV field value. This value may need to be set up
>> in case it is undefined or its default value is too high (and
>> communication with PHY is too slow) or too low (and communication with
>> PHY is impossible). The value of CLKDIV is not specified directly, but
>> is derived from the MAC clock for the default MII management bus frequency
>> of 2.5MHz. The MAC clock may be specified in the platform data, or as
>> either 'clock-frequency' or 'clocks' device tree attribute.
>>
>> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>> ---
>> Changes v1->v2:
>> - drop MDIO bus frequency configurability, always configure for standard
>> 2.5MHz;
>> - allow using common clock framework to provide ethoc clock.
>>
>> drivers/net/ethernet/ethoc.c | 37 +++++++++++++++++++++++++++++++++++--
>> include/net/ethoc.h | 1 +
>> 2 files changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
>> index 5643b2d..5854d41 100644
>> --- a/drivers/net/ethernet/ethoc.c
>> +++ b/drivers/net/ethernet/ethoc.c
>> @@ -13,6 +13,7 @@
>>
>> #include <linux/dma-mapping.h>
>> #include <linux/etherdevice.h>
>> +#include <linux/clk.h>
>> #include <linux/crc32.h>
>> #include <linux/interrupt.h>
>> #include <linux/io.h>
>> @@ -216,6 +217,7 @@ struct ethoc {
>>
>> struct phy_device *phy;
>> struct mii_bus *mdio;
>> + struct clk *clk;
>> s8 phy_id;
>> };
>>
>> @@ -925,6 +927,8 @@ static int ethoc_probe(struct platform_device *pdev)
>> int num_bd;
>> int ret = 0;
>> bool random_mac = false;
>> + u32 eth_clkfreq = 0;
>> + struct ethoc_platform_data *pdata = dev_get_platdata(&pdev->dev);
>>
>> /* allocate networking device */
>> netdev = alloc_etherdev(sizeof(struct ethoc));
>> @@ -1038,8 +1042,7 @@ static int ethoc_probe(struct platform_device *pdev)
>> }
>>
>> /* Allow the platform setup code to pass in a MAC address. */
>> - if (dev_get_platdata(&pdev->dev)) {
>> - struct ethoc_platform_data *pdata =
>> dev_get_platdata(&pdev->dev);
>> + if (pdata) {
>> memcpy(netdev->dev_addr, pdata->hwaddr, IFHWADDRLEN);
>> priv->phy_id = pdata->phy_id;
>> } else {
>> @@ -1077,6 +1080,32 @@ static int ethoc_probe(struct platform_device
>> *pdev)
>> if (random_mac)
>> netdev->addr_assign_type = NET_ADDR_RANDOM;
>>
>> + /* Allow the platform setup code to adjust MII management bus
>> clock. */
>> + if (pdata)
>> + eth_clkfreq = pdata->eth_clkfreq;
>
> Since this is a new member, why not make it a struct clk pointer directly so
> you could simplify the code path?
Basically this is to provide flexibility for the user: it may be more
appropriate to
specify frequency if it's known and fixed, otherwise clk_get below
would find the
clock registered for this device/generic clock.
>> + else
>> + of_property_read_u32(pdev->dev.of_node,
>> + "clock-frequency", ð_clkfreq);
>> + if (!eth_clkfreq) {
>> + struct clk *clk = clk_get(&pdev->dev, NULL);
This should have been devm_clk_get.
>> +
>> + if (!IS_ERR(clk)) {
>> + priv->clk = clk;
>> + clk_prepare_enable(clk);
>> + eth_clkfreq = clk_get_rate(clk);
>> + }
>> + }
>> + if (eth_clkfreq) {
>> + u32 clkdiv = MIIMODER_CLKDIV(eth_clkfreq / 2500000 + 1);
>> +
>> + if (!clkdiv)
>> + clkdiv = 2;
>> + dev_dbg(&pdev->dev, "setting MII clkdiv to %u\n", clkdiv);
>> + ethoc_write(priv, MIIMODER,
>> + (ethoc_read(priv, MIIMODER) & MIIMODER_NOPRE)
>> |
>> + clkdiv);
>> + }
>
>
> This does look a bit convoluted, and it looks like the clk_get() or getting
> the clock-frequency property should boil down to being the same thing with
> of_clk_get() as it should resolve all clocks phandles and fetch their
> frequencies appropriately.
I can drop clock-frequency property checking to encourage usage of common
clock framework. I don't quite understand the rest of the objection, could you
please rephrase it? clk_get calls of_clk_get internally.
>> +
>> /* register MII bus */
>> priv->mdio = mdiobus_alloc();
>> if (!priv->mdio) {
>> @@ -1141,6 +1170,8 @@ free_mdio:
>> kfree(priv->mdio->irq);
>> mdiobus_free(priv->mdio);
>> free:
>> + if (priv->clk)
>> + clk_disable_unprepare(priv->clk);
>
>
> This should probbaly be if (!IS_ERR(priv-clk)).
No, I haven't changed priv->clk when get_clk returned error.
>> free_netdev(netdev);
>> out:
>> return ret;
>> @@ -1165,6 +1196,8 @@ static int ethoc_remove(struct platform_device
>> *pdev)
>> kfree(priv->mdio->irq);
>> mdiobus_free(priv->mdio);
>> }
>> + if (priv->clk)
>> + clk_disable_unprepare(priv->clk);
>
>
> Same here
Ditto.
>> unregister_netdev(netdev);
>> free_netdev(netdev);
>> }
>> diff --git a/include/net/ethoc.h b/include/net/ethoc.h
>> index 96f3789..2a2d6bb 100644
>> --- a/include/net/ethoc.h
>> +++ b/include/net/ethoc.h
>> @@ -16,6 +16,7 @@
>> struct ethoc_platform_data {
>> u8 hwaddr[IFHWADDRLEN];
>> s8 phy_id;
>> + u32 eth_clkfreq;
>> };
>>
>> #endif /* !LINUX_NET_ETHOC_H */
>>
--
Thanks.
-- Max
^ permalink raw reply
* Re: [PATCH v2 4/4] net: ethoc: implement ethtool operations
From: Ben Hutchings @ 2014-01-30 1:59 UTC (permalink / raw)
To: Max Filippov
Cc: linux-xtensa, netdev, linux-kernel, Chris Zankel, Marc Gauthier,
David S. Miller, Florian Fainelli
In-Reply-To: <1390975218-13863-5-git-send-email-jcmvbkbc@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]
On Wed, 2014-01-29 at 10:00 +0400, Max Filippov wrote:
> The following methods are implemented:
> - get/set settings;
> - get registers length/registers;
> - get link state (standard implementation);
> - get/set ring parameters;
> - get timestamping info (standard implementation).
[...]
> --- a/drivers/net/ethernet/ethoc.c
> +++ b/drivers/net/ethernet/ethoc.c
> [...]
> +static int ethoc_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> + struct phy_device *phydev = priv->phy;
> +
> + if (!phydev)
> + return -ENODEV;
> +
> + return phy_ethtool_gset(phydev, cmd);
> +}
> +
> +static int ethoc_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> + struct phy_device *phydev = priv->phy;
> +
> + if (!phydev)
> + return -ENODEV;
> +
> + return phy_ethtool_sset(phydev, cmd);
> +}
I think these should return -EOPNOTSUPP in the PHY-less case, just as if
the set_settings pointer was not set.
[...]
> +static void ethoc_get_ringparam(struct net_device *dev,
> + struct ethtool_ringparam *ring)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> +
> + ring->rx_max_pending = priv->num_bd;
> + ring->rx_mini_max_pending = 0;
> + ring->rx_jumbo_max_pending = 0;
> + ring->tx_max_pending = priv->num_bd;
> +
> + ring->rx_pending = priv->num_rx;
> + ring->rx_mini_pending = 0;
> + ring->rx_jumbo_pending = 0;
> + ring->tx_pending = priv->num_tx;
> +}
> +
> +static int ethoc_set_ringparam(struct net_device *dev,
> + struct ethtool_ringparam *ring)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> +
> + if (netif_running(dev))
> + return -EBUSY;
This is unhelpful. Most implementations of this operation will restart
the interface if it's running.
> + priv->num_tx = rounddown_pow_of_two(ring->tx_pending);
Range check?
> + priv->num_rx = priv->num_bd - priv->num_tx;
> + if (priv->num_rx > ring->rx_pending)
> + priv->num_rx = ring->rx_pending;
So the RX ring may only ever be shrunk?! Did you mean to compare with
priv->num_bd instead?
> + return 0;
> +}
> +
> +const struct ethtool_ops ethoc_ethtool_ops = {
static
> + .get_settings = ethoc_get_settings,
> + .set_settings = ethoc_set_settings,
> + .get_regs_len = ethoc_get_regs_len,
> + .get_regs = ethoc_get_regs,
> + .get_link = ethtool_op_get_link,
> + .get_ringparam = ethoc_get_ringparam,
> + .set_ringparam = ethoc_set_ringparam,
> + .get_ts_info = ethtool_op_get_ts_info,
> +};
[...]
--
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert Einstein
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/4] net: ethoc: implement ethtool operations
From: Max Filippov @ 2014-01-30 3:04 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-xtensa@linux-xtensa.org, netdev, LKML, Chris Zankel,
Marc Gauthier, David S. Miller, Florian Fainelli
In-Reply-To: <1391047176.4405.43.camel@deadeye.wl.decadent.org.uk>
On Thu, Jan 30, 2014 at 5:59 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Wed, 2014-01-29 at 10:00 +0400, Max Filippov wrote:
>> The following methods are implemented:
>> - get/set settings;
>> - get registers length/registers;
>> - get link state (standard implementation);
>> - get/set ring parameters;
>> - get timestamping info (standard implementation).
> [...]
>> --- a/drivers/net/ethernet/ethoc.c
>> +++ b/drivers/net/ethernet/ethoc.c
>> [...]
>> +static int ethoc_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
>> +{
>> + struct ethoc *priv = netdev_priv(dev);
>> + struct phy_device *phydev = priv->phy;
>> +
>> + if (!phydev)
>> + return -ENODEV;
>> +
>> + return phy_ethtool_gset(phydev, cmd);
>> +}
>> +
>> +static int ethoc_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
>> +{
>> + struct ethoc *priv = netdev_priv(dev);
>> + struct phy_device *phydev = priv->phy;
>> +
>> + if (!phydev)
>> + return -ENODEV;
>> +
>> + return phy_ethtool_sset(phydev, cmd);
>> +}
>
> I think these should return -EOPNOTSUPP in the PHY-less case, just as if
> the set_settings pointer was not set.
Ok
> [...]
>> +static void ethoc_get_ringparam(struct net_device *dev,
>> + struct ethtool_ringparam *ring)
>> +{
>> + struct ethoc *priv = netdev_priv(dev);
>> +
>> + ring->rx_max_pending = priv->num_bd;
>> + ring->rx_mini_max_pending = 0;
>> + ring->rx_jumbo_max_pending = 0;
>> + ring->tx_max_pending = priv->num_bd;
>> +
>> + ring->rx_pending = priv->num_rx;
>> + ring->rx_mini_pending = 0;
>> + ring->rx_jumbo_pending = 0;
>> + ring->tx_pending = priv->num_tx;
>> +}
>> +
>> +static int ethoc_set_ringparam(struct net_device *dev,
>> + struct ethtool_ringparam *ring)
>> +{
>> + struct ethoc *priv = netdev_priv(dev);
>> +
>> + if (netif_running(dev))
>> + return -EBUSY;
>
> This is unhelpful. Most implementations of this operation will restart
> the interface if it's running.
Ok
>> + priv->num_tx = rounddown_pow_of_two(ring->tx_pending);
>
> Range check?
May there be requested more than ring->tx_max_pending that we
indicated in the get_ringparam?
>> + priv->num_rx = priv->num_bd - priv->num_tx;
>> + if (priv->num_rx > ring->rx_pending)
>> + priv->num_rx = ring->rx_pending;
>
> So the RX ring may only ever be shrunk?! Did you mean to compare with
> priv->num_bd instead?
First all non-TX descriptors are made RX, and if that's more than user
requested I trim it.
>> + return 0;
>> +}
>> +
>> +const struct ethtool_ops ethoc_ethtool_ops = {
>
> static
Ok
--
Thanks.
-- Max
^ permalink raw reply
* [PATCH] rtl8192ce is disabling the irqs for too long
From: Olivier Langlois @ 2014-01-30 6:22 UTC (permalink / raw)
To: Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ,
linville-2XuSBdqkA4R54TAoqtyWWQ,
chaoming_li-kXabqFNEczNtrwSWzY7KCg
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
mlang45-KttuZimePZJWk0Htik3J/w, Olivier Langlois
rtl8192ce is disabling for too long the local interrupts during hw initiatialisation when performing scans
The observable symptoms in dmesg can be:
- underruns from ALSA playback
- clock freezes (tstamps do not change for several dmesg entries until irqs are finaly reenabled):
[ 250.817669] rtlwifi:rtl_op_config():<0-0-0> 0x100
[ 250.817685] rtl8192ce:_rtl92ce_phy_set_rf_power_state():<0-1-0> IPS Set eRf nic enable
[ 250.817732] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.817796] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.817910] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818024] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818139] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818253] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818367] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
[ 250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:98053f15:10
[ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
[ 250.818472] rtl8192c_common:rtl92c_download_fw():<0-1-0> Firmware Version(49), Signature(0x88c1),Size(32)
[ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> PairwiseEncAlgorithm = 0 GroupEncAlgorithm = 0
[ 250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> The SECR-value cc
[ 250.818472] rtl8192c_common:rtl92c_dm_check_txpower_tracking_thermal_meter():<0-1-0> Schedule TxPowerTracking direct call!!
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> rtl92c_dm_txpower_tracking_callback_thermalmeter
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial pathA ele_d reg0xc80 = 0x40000000, ofdm_index=0xc
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial reg0xa24 = 0x90e1317, cck_index=0xc, ch14 0
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf delta 0x1 delta_lck 0x0 delta_iqk 0x0
[ 250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> <===
[ 250.818472] rtl8192c_common:rtl92c_dm_initialize_txpower_tracking_thermalmeter():<0-1-0> pMgntInfo->txpower_tracking = 1
[ 250.818472] rtl8192ce:rtl92ce_led_control():<0-1-0> ledaction 3
[ 250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
[ 250.818472] rtlwifi:rtl_ips_nic_on():<0-1-0> before spin_unlock_irqrestore
[ 251.154656] PCM: Lost interrupts? [Q]-0 (stream=0, delta=15903, new_hw_ptr=293408, old_hw_ptr=277505)
The exact code flow that causes that is:
1. wpa_supplicant send a start_scan request to the nl80211 driver
2. mac80211 module call rtl_op_config with IEEE80211_CONF_CHANGE_IDLE
3. rtl_ips_nic_on is called which disable local irqs
4. rtl92c_phy_set_rf_power_state() is called
5. rtl_ps_enable_nic() is called and hw_init()is executed and interrupts on the device
A good solution could be to refactor the code to avoid calling rtl92ce_hw_init() with the irqs disabled
but a quick and dirty solution that has proven to work is
to reenable the irqs during the function rtl92ce_hw_init().
I think that it is safe doing so since the device interrupt will only be enabled after the init function succeed.
Signed-off-by: Olivier Langlois <olivier-VxAV575H0jR+kJTeVDPgHg@public.gmane.org>
---
drivers/net/wireless/rtlwifi/ps.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192ce/hw.c | 18 ++++++++++++++++--
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/ps.c b/drivers/net/wireless/rtlwifi/ps.c
index 0d81f76..a56e9b3 100644
--- a/drivers/net/wireless/rtlwifi/ps.c
+++ b/drivers/net/wireless/rtlwifi/ps.c
@@ -48,7 +48,7 @@ bool rtl_ps_enable_nic(struct ieee80211_hw *hw)
/*<2> Enable Adapter */
if (rtlpriv->cfg->ops->hw_init(hw))
- return 1;
+ return false;
RT_CLEAR_PS_LEVEL(ppsc, RT_RF_OFF_LEVL_HALT_NIC);
/*<3> Enable Interrupt */
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
index a82b30a..2eb0b38 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
@@ -937,14 +937,26 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
bool is92c;
int err;
u8 tmp_u1b;
+ unsigned long flags;
rtlpci->being_init_adapter = true;
+
+ /* Since this function can take a very long time (up to 350 ms)
+ * and can be called with irqs disabled, reenable the irqs
+ * to let the other devices continue being serviced.
+ *
+ * It is safe doing so since our own interrupts will only be enabled
+ * in a subsequent step.
+ */
+ local_save_flags(flags);
+ local_irq_enable();
+
rtlpriv->intf_ops->disable_aspm(hw);
rtstatus = _rtl92ce_init_mac(hw);
if (!rtstatus) {
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG, "Init MAC failed\n");
err = 1;
- return err;
+ goto exit;
}
err = rtl92c_download_fw(hw);
@@ -952,7 +964,7 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
RT_TRACE(rtlpriv, COMP_ERR, DBG_WARNING,
"Failed to download FW. Init HW without FW now..\n");
err = 1;
- return err;
+ goto exit;
}
rtlhal->last_hmeboxnum = 0;
@@ -1032,6 +1044,8 @@ int rtl92ce_hw_init(struct ieee80211_hw *hw)
RT_TRACE(rtlpriv, COMP_INIT, DBG_TRACE, "under 1.5V\n");
}
rtl92c_dm_init(hw);
+exit:
+ local_irq_restore(flags);
rtlpci->being_init_adapter = false;
return err;
}
--
1.8.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] ath9k: Fix uninitialized variable in ath9k_has_tx_pending()
From: Felix Fietkau @ 2014-01-30 6:55 UTC (permalink / raw)
To: Geert Uytterhoeven, John W. Linville, QCA ath9k Development
Cc: linux-wireless, ath9k-devel, netdev, linux-kernel
In-Reply-To: <1390733601-11244-1-git-send-email-geert@linux-m68k.org>
On 2014-01-26 11:53, Geert Uytterhoeven wrote:
> drivers/net/wireless/ath/ath9k/main.c: In function ‘ath9k_has_tx_pending’:
> drivers/net/wireless/ath/ath9k/main.c:1869: warning: ‘npend’ may be used uninitialized in this function
>
> Introduced by commit 10e2318103f5941aa70c318afe34bc41f1b98529 ("ath9k:
> optimize ath9k_flush").
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Felix Fietkau <nbd@openwrt.org>
^ permalink raw reply
* Re: kmem_cache_alloc panic in 3.10+
From: dormando @ 2014-01-30 7:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-kernel, Alexei Starovoitov
In-Reply-To: <alpine.DEB.2.02.1401181101220.579@dtop>
> > On Sat, 2014-01-18 at 00:44 -0800, dormando wrote:
> > > Hello again!
> > >
> > > We've had a rare crash that's existed between 3.10.0 and 3.10.15 at least
> > > (trying newer stables now, but I can't tell if it was fixed, and it takes
> > > weeks to reproduce).
> > >
> > > Unfortunately I can only get 8k back from pstore. The panic looks a bit
> > > longer than that is caught in the log, but the bottom part is almost
> > > always this same trace as this one:
> > >
> > > Panic#6 Part1
> > > <4>[1197485.199166] [<ffffffff81611e8c>] tcp_push+0x6c/0x90
> > > <4>[1197485.199171] [<ffffffff816160a9>] tcp_sendmsg+0x109/0xd40
> > > <4>[1197485.199179] [<ffffffff81114b65>] ? put_page+0x35/0x40
> > > <4>[1197485.199185] [<ffffffff8163bf75>] inet_sendmsg+0x45/0xb0
> > > <4>[1197485.199191] [<ffffffff8159da7e>] sock_aio_write+0x11e/0x130
> > > <4>[1197485.199196] [<ffffffff8163b83f>] ? inet_recvmsg+0x4f/0x80
> > > <4>[1197485.199203] [<ffffffff811558ad>] do_sync_readv_writev+0x6d/0xa0
> > > <4>[1197485.199209] [<ffffffff8115722b>] do_readv_writev+0xfb/0x2f0
> > > <4>[1197485.199215] [<ffffffff8110fda5>] ? __free_pages+0x35/0x40
> > > <4>[1197485.199220] [<ffffffff8110fe56>] ? free_pages+0x46/0x50
> > > <4>[1197485.199226] [<ffffffff8112f9e2>] ? SyS_mincore+0x152/0x690
> > > <4>[1197485.199231] [<ffffffff81157468>] vfs_writev+0x48/0x60
> > > <4>[1197485.199236] [<ffffffff811575af>] SyS_writev+0x5f/0xd0
> > > <4>[1197485.199243] [<ffffffff816cf942>] system_call_fastpath+0x16/0x1b
> > > <4>[1197485.199247] Code: 65 4c 03 04 25 c8 cb 00 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 0f 84 84 00 00 00 48 85 c0 74 7f 49 63 44 24 20 49 8b 3c 24 <49> 8b 5c 05 00 48 8d 4a 01 4c 89 e8 65 48 0f c7 0f 0f 94 c0 3c
> > > <1>[1197485.199290] RIP [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
> > > <4>[1197485.199296] RSP <ffff883171211868>
> > > <4>[1197485.199299] CR2: 0000000100000000
> > > <4>[1197485.199343] ---[ end trace 90fee06aa40b7304 ]---
> > > <1>[1197485.263911] BUG: unable to handle kernel paging request at 0000000100000000
> > > <1>[1197485.263923] IP: [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
> > > <4>[1197485.263932] PGD 3f43e5c067 PUD 0
> > > <4>[1197485.263937] Oops: 0000 [#5] SMP
> > > <4>[1197485.263941] Modules linked in: ntfs vfat msdos fat macvlan bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich microcode sb_edac edac_core lpc_ich mfd_core ixgbe igb i2c_algo_bit mdio ptp pps_core
> > > <4>[1197485.263966] CPU: 0 PID: 233846 Comm: cache-worker Tainted: G D 3.10.15 #1
> > > <4>[1197485.263972] Hardware name: Supermicro X9DR3-F/X9DR3-F, BIOS 2.0a 03/07/2013
> > > <4>[1197485.263976] task: ffff883427f9dc00 ti: ffff8830d4312000 task.ti: ffff8830d4312000
> > > <4>[1197485.263982] RIP: 0010:[<ffffffff811476da>] [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
> > > <4>[1197485.263990] RSP: 0018:ffff881fffc038c8 EFLAGS: 00010286
> > > <4>[1197485.263994] RAX: 0000000000000000 RBX: ffffffff81c8c740 RCX: 00000000ffffffff
> > > <4>[1197485.263999] RDX: 0000000029273024 RSI: 0000000000000020 RDI: 0000000000015680
> > > <4>[1197485.264004] RBP: ffff881fffc03908 R08: ffff881fffc15680 R09: ffffffff815bdd4b
> > > <4>[1197485.264009] R10: ffff881c65d21800 R11: 0000000000000000 R12: ffff881fff803800
> > > <4>[1197485.264014] R13: 0000000100000000 R14: 00000000ffffffff R15: 0000000000000000
> > > <4>[1197485.264019] FS: 00007f8d855eb700(0000) GS:ffff881fffc00000(0000) knlGS:0000000000000000
> > > <4>[1197485.264024] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > <4>[1197485.264028] CR2: 0000000100000000 CR3: 000000308f258000 CR4: 00000000000407f0
> > > <4>[1197485.264032] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > <4>[1197485.264037] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > <4>[1197485.264041] Stack:
> > > <4>[1197485.264044] ffff881fffc03928 00000020815d0d95 ffff881fffc03938 ffffffff81c8c740
> > > <4>[1197485.264050] ffff881fce210000 0000000000000001 00000000ffffffff 0000000000000000
> > > <4>[1197485.264056] ffff881fffc03958 ffffffff815bdd4b ffff881fffc039a8 0000000000000000
> > > <4>[1197485.264063] Call Trace:
> > > <4>[1197485.264066] <IRQ>
> > > <4>[1197485.264069] [<ffffffff815bdd4b>] dst_alloc+0x5b/0x190
> > > <4>[1197485.264080] [<ffffffff8160068c>] rt_dst_alloc+0x4c/0x50
> > > <4>[1197485.264085] [<ffffffff81602a30>] __ip_route_output_key+0x270/0x880
> > > <4>[1197485.264092] [<ffffffff8107ee7e>] ? try_to_wake_up+0x23e/0x2b0
> > > <4>[1197485.264097] [<ffffffff81603067>] ip_route_output_flow+0x27/0x60
> > > <4>[1197485.264102] [<ffffffff8160ab8a>] ip_queue_xmit+0x36a/0x390
> > > <4>[1197485.264108] [<ffffffff816207c5>] tcp_transmit_skb+0x485/0x890
> > > <4>[1197485.264113] [<ffffffff81621aa1>] tcp_send_ack+0xf1/0x130
> > > <4>[1197485.264118] [<ffffffff81618d7e>] __tcp_ack_snd_check+0x5e/0xa0
> > > <4>[1197485.264123] [<ffffffff8161f2c2>] tcp_rcv_state_process+0x8b2/0xb20
> > > <4>[1197485.264128] [<ffffffff81627e61>] tcp_v4_do_rcv+0x191/0x4f0
> > > <4>[1197485.264133] [<ffffffff8162984c>] tcp_v4_rcv+0x5fc/0x750
> > > <4>[1197485.264138] [<ffffffff81604c80>] ? ip_rcv+0x350/0x350
> > > <4>[1197485.264143] [<ffffffff815e45cd>] ? nf_hook_slow+0x7d/0x160
> > > <4>[1197485.264147] [<ffffffff81604c80>] ? ip_rcv+0x350/0x350
> > > <4>[1197485.264152] [<ffffffff81604d4e>] ip_local_deliver_finish+0xce/0x250
> > > <4>[1197485.264156] [<ffffffff81604f1c>] ip_local_deliver+0x4c/0x80
> > > <4>[1197485.264161] [<ffffffff816045a9>] ip_rcv_finish+0x119/0x360
> > > <4>[1197485.264165] [<ffffffff81604b60>] ip_rcv+0x230/0x350
> > > <4>[1197485.264170] [<ffffffff815b89f7>] __netif_receive_skb_core+0x477/0x600
> > > <4>[1197485.264175] [<ffffffff815b8ba7>] __netif_receive_skb+0x27/0x70
> > > <4>[1197485.264180] [<ffffffff815b8ce4>] process_backlog+0xf4/0x1e0
> > > <4>[1197485.264184] [<ffffffff815b94e5>] net_rx_action+0xf5/0x250
> > > <4>[1197485.264190] [<ffffffff81053b7f>] __do_softirq+0xef/0x270
> > > <4>[1197485.264196] [<ffffffff816d0b7c>] call_softirq+0x1c/0x30
> > > <4>[1197485.264199] <EOI>
> > > <4>[1197485.264201] [<ffffffff81004495>] do_softirq+0x55/0x90
> > > <4>[1197485.264209] [<ffffffff81053a84>] local_bh_enable+0x94/0xa0
> > > <4>[1197485.264215] [<ffffffff8165567a>] ipt_do_table+0x22a/0x680
> > > <4>[1197485.264221] [<ffffffff815d39c1>] ? skb_clone_tx_timestamp+0x31/0x110
> > > <4>[1197485.264231] [<ffffffffa00ae840>] ? ixgbe_xmit_frame_ring+0x4c0/0xd40 [ixgbe]
> > > <4>[1197485.264239] [<ffffffffa00af103>] ? ixgbe_xmit_frame+0x43/0x90 [ixgbe]
> > > <4>[1197485.264245] [<ffffffff81657a23>] iptable_raw_hook+0x33/0x70
> > > <4>[1197485.264252] [<ffffffff815e43a7>] nf_iterate+0x87/0xb0
> > > <4>[1197485.264256] [<ffffffff81607e20>] ? ip_options_echo+0x420/0x420
> > > <4>[1197485.264261] [<ffffffff815e45cd>] nf_hook_slow+0x7d/0x160
> > > <4>[1197485.264266] [<ffffffff81607e20>] ? ip_options_echo+0x420/0x420
> > > <4>[1197485.264270] [<ffffffff8160a430>] __ip_local_out+0xa0/0xb0
> > > <4>[1197485.264275] [<ffffffff8160a456>] ip_local_out+0x16/0x30
> > > <4>[1197485.264280] [<ffffffff8160a97a>] ip_queue_xmit+0x15a/0x390
> > > <4>[1197485.264286] [<ffffffff81625e73>] ? tcp_v4_md5_lookup+0x13/0x20
> > > <4>[1197485.264290] [<ffffffff816207c5>] tcp_transmit_skb+0x485/0x890
> > > <4>[1197485.264295] [<ffffffff81622e08>] tcp_write_xmit+0x1b8/0xa50
> > > <4>[1197485.264300] [<ffffffff815a7e28>] ? __alloc_skb+0xa8/0x1f0
> > > <4>[1197485.264304] [<ffffffff816236d0>] tcp_push_one+0x30/0x40
> > > <4>[1197485.264309] [<ffffffff81616b84>] tcp_sendmsg+0xbe4/0xd40
> > > <4>[1197485.264315] [<ffffffff81114b65>] ? put_page+0x35/0x40
> > > <4>[1197485.264321] [<ffffffff8163bf75>] inet_sendmsg+0x45/0xb0
> > > <4>[1197485.264326] [<ffffffff8159da7e>] sock_aio_write+0x11e/0x130
> > > <4>[1197485.264331] [<ffffffff8163b83f>] ? inet_recvmsg+0x4f/0x80
> > > <4>[1197485.264337] [<ffffffff811558ad>] do_sync_readv_writev+0x6d/0xa0
> > > <4>[1197485.264343] [<ffffffff8115722b>] do_readv_writev+0xfb/0x2f0
> > > <4>[1197485.264347] [<ffffffff8110fda5>] ? __free_pages+0x35/0x40
> > > <4>[1197485.264352] [<ffffffff8110fe56>] ? free_pages+0x46/0x50
> > > <4>[1197485.264357] [<ffffffff8112f9e2>] ? SyS_mincore+0x152/0x690
> > > <4>[1197485.264363] [<ffffffff81157468>] vfs_writev+0x48/0x60
> > > <4>[1197485.264367] [<ffffffff811575af>] SyS_writev+0x5f/0xd0
> > > <4>[1197485.264373] [<ffffffff816cf942>] system_call_fastpath+0x16/0x1b
> > > <4>[1197485.264377] Code: 65 4c 03 04 25 c8 cb 00 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 0f 84 84 00 00 00 48 85 c0 74 7f 49 63 44 24 20 49 8b 3c 24 <49> 8b 5c 05 00 48 8d 4a 01 4c 89 e8 65 48 0f c7 0f 0f 94 c0 3c
> > > <1>[1197485.264417] RIP [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
> > > <4>[1197485.264424] RSP <ffff881fffc038c8>
> > > <4>[1197485.264427] CR2: 0000000100000000
> > > <4>[1197485.264431] ---[ end trace 90fee06aa40b7305 ]---
> > > <0>[1197485.325141] Kernel panic - not syncing: Fatal exception in interrupt
> > >
> > > ... way down in the tcp code.
> > >
> > > Any help would be appreciated :) I'll do what I can to help, but iterating
> > > this particular crash is very hard due to the amount of time it takes to
> > > reproduce. Since we have a large number of machines they're always
> > > crashing here and there, but once they do it's not going to happen again
> > > for a while.
> > >
> > > Thanks!
> > > -Dormando
> > > --
> >
>
> Forgot to note: This crash appeared after 3.9 (and not in any of 3.9's
> -stable updates). We had to abandon 3.9 in a hurry due to a bizarre tcp
> corruption bug. Otherwise 3.9 never crashed on us :) 3.10 lacks the
> corruption bug, adds this rare panic.
>
Two fresh traces:
Panic#2 Part1
<1>[6707639.294029] BUG: unable to handle kernel paging request at 0000000100000000
<1>[6707639.294039] IP: [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
<4>[6707639.294050] PGD 618c91a067 PUD 0
<4>[6707639.294053] Oops: 0000 [#1] SMP
<4>[6707639.294057] Modules linked in: xt_TEE xt_dscp xt_DSCP macvlan ntfs vfat msdos fat bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich ipmi_watchdog ipmi_devintf microcode sb_edac edac_core isci igb lpc_ich i2c_algo_bit mfd_core libsas ixgbe tpm_tis ptp pps_core tpm mdio tpm_bios ipmi_si ipmi_msghandler
<4>[6707639.294085] CPU: 11 PID: 107657 Comm: sed Tainted: G W 3.10.15 #1
<4>[6707639.294089] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
<4>[6707639.294093] task: ffff88bd4fa5ae00 ti: ffff88614bb7c000 task.ti: ffff88614bb7c000
<4>[6707639.294096] RIP: 0010:[<ffffffff811476da>] [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
<4>[6707639.294101] RSP: 0000:ffff88c07fc63b68 EFLAGS: 00010286
<4>[6707639.294103] RAX: 0000000000000000 RBX: ffffffff81c8c740 RCX: 00000000ffffffff
<4>[6707639.294106] RDX: 0000000266ceed70 RSI: 0000000000000020 RDI: 0000000000015680
<4>[6707639.294110] RBP: ffff88c07fc63ba8 R08: ffff88c07fc75680 R09: ffffffff815bdd4b
<4>[6707639.294113] R10: ffff8801d167de00 R11: 0000000000000000 R12: ffff885eff803800
<4>[6707639.294116] R13: 0000000100000000 R14: 00000000ffffffff R15: 0000000000000000
<4>[6707639.294119] FS: 00007f65232637c0(0000) GS:ffff88c07fc60000(0000) knlGS:0000000000000000
<4>[6707639.294122] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[6707639.294125] CR2: 0000000100000000 CR3: 000000618cce7000 CR4: 00000000000407e0
<4>[6707639.294128] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[6707639.294131] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[6707639.294133] Stack:
<4>[6707639.294135] ffff88c07fc63bc8 00000020815d0d95 ffff88c07fc63bd8 ffffffff81c8c740
<4>[6707639.294139] ffff88be6b380000 0000000000000001 00000000ffffffff 0000000000000000
<4>[6707639.294143] ffff88c07fc63bf8 ffffffff815bdd4b ffff88c07fc63c48 ffff886100000000
<4>[6707639.294147] Call Trace:
<4>[6707639.294149] <IRQ>
<4>[6707639.294151] [<ffffffff815bdd4b>] dst_alloc+0x5b/0x190
<4>[6707639.294161] [<ffffffff8160068c>] rt_dst_alloc+0x4c/0x50
<4>[6707639.294165] [<ffffffff81602a30>] __ip_route_output_key+0x270/0x880
<4>[6707639.294168] [<ffffffff81603067>] ip_route_output_flow+0x27/0x60
<4>[6707639.294174] [<ffffffff8163cf29>] inet_sk_rebuild_header+0x139/0x320
<4>[6707639.294179] [<ffffffff81622690>] __tcp_retransmit_skb+0xa0/0x550
<4>[6707639.294186] [<ffffffff810919c6>] ? ktime_get_real+0x16/0x50
<4>[6707639.294191] [<ffffffff8165f5ad>] ? bictcp_state+0xad/0x110
<4>[6707639.294195] [<ffffffff81622b6b>] tcp_retransmit_skb+0x2b/0x110
<4>[6707639.294198] [<ffffffff81625581>] tcp_retransmit_timer+0x261/0x680
<4>[6707639.294201] [<ffffffff81625b70>] ? tcp_write_timer_handler+0x1d0/0x1d0
<4>[6707639.294205] [<ffffffff81625a50>] tcp_write_timer_handler+0xb0/0x1d0
<4>[6707639.294208] [<ffffffff81625b70>] ? tcp_write_timer_handler+0x1d0/0x1d0
<4>[6707639.294211] [<ffffffff81625bd8>] tcp_write_timer+0x68/0x70
<4>[6707639.294217] [<ffffffff8105afa9>] call_timer_fn+0x49/0x120
<4>[6707639.294220] [<ffffffff8105b594>] run_timer_softirq+0x224/0x290
<4>[6707639.294223] [<ffffffff81625b70>] ? tcp_write_timer_handler+0x1d0/0x1d0
<4>[6707639.294227] [<ffffffff81053b7f>] __do_softirq+0xef/0x270
<4>[6707639.294230] [<ffffffff81053dd5>] irq_exit+0x95/0xa0
<4>[6707639.294236] [<ffffffff816d12ee>] smp_apic_timer_interrupt+0x6e/0x99
<4>[6707639.294242] [<ffffffff816d050a>] apic_timer_interrupt+0x6a/0x70
<4>[6707639.294244] <EOI>
<4>[6707639.294246] Code: 65 4c 03 04 25 c8 cb 00 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 0f 84 84 00 00 00 48 85 c0 74 7f 49 63 44 24 20 49 8b 3c 24 <49> 8b 5c 05 00 48 8d 4a 01 4c 89 e8 65 48 0f c7 0f 0f 94 c0 3c
<1>[6707639.294272] RIP [<ffffffff811476da>] kmem_cache_alloc+0x5a/0x130
<4>[6707639.294275] RSP <ffff88c07fc63b68>
<4>[6707639.294277] CR2: 0000000100000000
<4>[6707639.294284] ---[ end trace 566552bed9fa5ac5 ]---
<0>[6707639.355743] Kernel panic - not syncing: Fatal exception in interrupt
.. and...
Panic#3 Part1
<4>[7359072.926954] CPU: 11 PID: 234126 Comm: gmond Tainted: G W 3.10.15 #1
<4>[7359072.926969] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
<4>[7359072.926988] task: ffff8803f0c0c500 ti: ffff88017f40a000 task.ti: ffff88017f40a000
<4>[7359072.927002] RIP: 0010:[<ffffffff8114106b>] [<ffffffff8114106b>] kmem_cache_alloc_trace+0x5b/0x140
<4>[7359072.927024] RSP: 0018:ffff88017f40be38 EFLAGS: 00010282
<4>[7359072.927034] RAX: 0000000000000000 RBX: ffff88b7aabd8230 RCX: 000000016c1d572d
<4>[7359072.927049] RDX: 000000016c1d572c RSI: 00000000000080d0 RDI: 00000000000156c0
<4>[7359072.927079] RBP: ffff88017f40be88 R08: ffff88c07fc756c0 R09: ffffffff81159904
<4>[7359072.927122] R10: 00007fe2ae0f9300 R11: 0000000000000206 R12: ffff885eff803800
<4>[7359072.927165] R13: 0000000100000000 R14: 0000000000000000 R15: 00007fe2b0e8e0e0
<4>[7359072.927208] FS: 00007fe2b0f02740(0000) GS:ffff88c07fc60000(0000) knlGS:0000000000000000
<4>[7359072.927253] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[7359072.927280] CR2: 0000000100000000 CR3: 00000001c1860000 CR4: 00000000000407e0
<4>[7359072.927323] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[7359072.927367] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[7359072.927410] Stack:
<4>[7359072.927432] ffffffff81169052 0000000000000088 ffff88be6df50000 000080d0aabd8230
<4>[7359072.927483] ffff88be6df50000 ffff88b7aabd8230 ffff88017f40bf40 00000000ffffffe9
<4>[7359072.927535] 0000000000000000 00007fe2b0e8e0e0 ffff88017f40bea8 ffffffff81159904
<4>[7359072.927586] Call Trace:
<4>[7359072.927613] [<ffffffff81169052>] ? inode_init_always+0xf2/0x1b0
<4>[7359072.927643] [<ffffffff81159904>] alloc_pipe_info+0x24/0xb0
<4>[7359072.927671] [<ffffffff81159e8c>] create_pipe_files+0x4c/0x200
<4>[7359072.927699] [<ffffffff8115a082>] __do_pipe_flags+0x42/0xf0
<4>[7359072.927726] [<ffffffff8115a1a0>] SyS_pipe2+0x20/0xa0
<4>[7359072.927757] [<ffffffff816c7f4e>] ? do_page_fault+0xe/0x10
<4>[7359072.927787] [<ffffffff816c46b2>] ? page_fault+0x22/0x30
<4>[7359072.927814] [<ffffffff8115a230>] SyS_pipe+0x10/0x20
<4>[7359072.927842] [<ffffffff816cc702>] system_call_fastpath+0x16/0x1b
<4>[7359072.927869] Code: 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 0f 84 d3 00 00 00 48 85 c0 0f 84 ca 00 00 00 49 63 44 24 20 48 8d 4a 01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b5 49
<1>[7359072.928084] RIP [<ffffffff8114106b>] kmem_cache_alloc_trace+0x5b/0x140
<4>[7359072.928115] RSP <ffff88017f40be38>
<4>[7359072.928138] CR2: 0000000100000000
<4>[7359072.928477] ---[ end trace 83220393c4cb24ac ]---
<1>[7359072.999784] BUG: unable to handle kernel paging request at 0000000100000000
<1>[7359072.999928] IP: [<ffffffff811421e7>] kmem_cache_alloc+0x57/0x150
<4>[7359073.000032] PGD be41868067 PUD 0
<4>[7359073.000167] Oops: 0000 [#2] SMP
<4>[7359073.000301] Modules linked in: nls_cp437 isofs xt_TEE xt_dscp xt_DSCP macvlan bridge coretemp crc32_pclmul ghash_clmulni_intel gpio_ich ipmi_watchdog ipmi_devintf ixgbe microcode igb sb_edac edac_core lpc_ich i2c_algo_bit mfd_core ptp tpm_tis pps_core tpm mdio tpm_bios ipmi_si ipmi_msghandler
<4>[7359073.001557] CPU: 11 PID: 72986 Comm: cache-worker Tainted: G D W 3.10.15 #1
<4>[7359073.001637] Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.0 07/05/2013
<4>[7359073.001718] task: ffff8801c07a5c00 ti: ffff88016e9b8000 task.ti: ffff88016e9b8000
<4>[7359073.001797] RIP: 0010:[<ffffffff811421e7>] [<ffffffff811421e7>] kmem_cache_alloc+0x57/0x150
<4>[7359073.001916] RSP: 0018:ffff88c07fc638f8 EFLAGS: 00010282
<4>[7359073.001977] RAX: 0000000000000000 RBX: ffffffff81c8c1c0 RCX: 000000016c1d572d
<4>[7359073.002055] RDX: 000000016c1d572c RSI: 0000000000000020 RDI: 00000000000156c0
<4>[7359073.002133] RBP: ffff88c07fc63948 R08: ffff88c07fc756c0 R09: ffffffff815b672a
<4>[7359073.002211] R10: ffff88bc97207000 R11: 00000000a2d52a83 R12: ffff885eff803800
<4>[7359073.002289] R13: 0000000100000000 R14: 00000000ffffffff R15: 0000000000000000
<4>[7359073.002367] FS: 00007f0d36755700(0000) GS:ffff88c07fc60000(0000) knlGS:0000000000000000
<4>[7359073.002447] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[7359073.002508] CR2: 0000000100000000 CR3: 000000bc22187000 CR4: 00000000000407e0
<4>[7359073.002586] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[7359073.002664] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[7359073.002741] Stack:
<4>[7359073.002796] ffff885e6e67ee40 ffff88c07fc63ac8 ffff88c07fc63968 00000020815c9145
<4>[7359073.003020] c71b4c1400000001 ffffffff81c8c1c0 ffff885e6c890000 0000000000000001
<4>[7359073.003243] 00000000ffffffff 0000000000000000 ffff88c07fc63998 ffffffff815b672a
<4>[7359073.003466] Call Trace:
<4>[7359073.003522] <IRQ>
<4>[7359073.003563] [<ffffffff815b672a>] dst_alloc+0x5a/0x180
<4>[7359073.003720] [<ffffffff815f78bc>] rt_dst_alloc+0x4c/0x50
<4>[7359073.003783] [<ffffffff815f8861>] __ip_route_output_key+0x281/0x860
<4>[7359073.003846] [<ffffffff815f8e67>] ip_route_output_flow+0x27/0x70
<4>[7359073.003910] [<ffffffff81606fee>] inet_csk_route_req+0xce/0x130
<4>[7359073.003974] [<ffffffff8161fda3>] tcp_v4_conn_request+0x463/0xb10
<4>[7359073.004038] [<ffffffff81616144>] tcp_rcv_state_process+0x1c4/0xd10
<4>[7359073.004101] [<ffffffff8161f457>] tcp_v4_do_rcv+0x257/0x4a0
<4>[7359073.004163] [<ffffffff816215d6>] tcp_v4_rcv+0x6f6/0x870
<4>[7359073.004226] [<ffffffff815fbff0>] ? ip_rcv_finish+0x360/0x360
<4>[7359073.004289] [<ffffffff815fc0be>] ip_local_deliver_finish+0xce/0x250
<4>[7359073.004352] [<ffffffff815fc3ca>] ip_local_deliver+0x4a/0x90
<4>[7359073.004415] [<ffffffff815fbda9>] ip_rcv_finish+0x119/0x360
<4>[7359073.004477] [<ffffffff815fc63b>] ip_rcv+0x22b/0x340
<4>[7359073.004539] [<ffffffff815af002>] __netif_receive_skb_core+0x512/0x640
<4>[7359073.004603] [<ffffffff815af151>] __netif_receive_skb+0x21/0x70
<4>[7359073.004666] [<ffffffff815af23b>] process_backlog+0x9b/0x170
<4>[7359073.004729] [<ffffffff815afa49>] net_rx_action+0x119/0x220
<4>[7359073.004794] [<ffffffff81080f0b>] ? check_preempt_wakeup+0x14b/0x230
<4>[7359073.004860] [<ffffffff81051970>] __do_softirq+0xd0/0x270
<4>[7359073.004921] [<ffffffff81051c25>] irq_exit+0x55/0x60
<4>[7359073.004983] [<ffffffff8107a5b5>] scheduler_ipi+0x35/0x40
<4>[7359073.005049] [<ffffffff81023bda>] smp_reschedule_interrupt+0x2a/0x30
<4>[7359073.005115] [<ffffffff816cd5da>] reschedule_interrupt+0x6a/0x70
<4>[7359073.005176] <EOI>
<4>[7359073.005217] [<ffffffff816c41f5>] ? _raw_spin_lock+0x25/0x30
<4>[7359073.005370] [<ffffffff81098629>] futex_wait_setup+0x69/0xf0
<4>[7359073.005433] [<ffffffff81098836>] futex_wait+0x186/0x2c0
<4>[7359073.005495] [<ffffffff810508c6>] ? current_fs_time+0x16/0x60
<4>[7359073.005559] [<ffffffff81159123>] ? pipe_write+0x2f3/0x590
<4>[7359073.005625] [<ffffffff8118e8c2>] ? fsnotify+0x1d2/0x2b0
<4>[7359073.005687] [<ffffffff81099e04>] do_futex+0x334/0xb20
<4>[7359073.005751] [<ffffffff8115021a>] ? do_sync_write+0x7a/0xb0
<4>[7359073.005813] [<ffffffff8118e8c2>] ? fsnotify+0x1d2/0x2b0
<4>[7359073.005875] [<ffffffff8109a732>] SyS_futex+0x142/0x1a0
<4>[7359073.005939] [<ffffffff8115148b>] ? SyS_write+0x6b/0xa0
<4>[7359073.006001] [<ffffffff816cc702>] system_call_fastpath+0x16/0x1b
<4>[7359073.006063] Code: 00 49 8b 50 08 4d 8b 28 49 8b 40 10 4d 85 ed 0f 84 e7 00 00 00 48 85 c0 0f 84 de 00 00 00 49 63 44 24 20 48 8d 4a 01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b5 49
<1>[7359073.008543] RIP [<ffffffff811421e7>] kmem_cache_alloc+0x57/0x150
<4>[7359073.008642] RSP <ffff88c07fc638f8>
<4>[7359073.008700] CR2: 0000000100000000
<4>[7359073.008767] ---[ end trace 83220393c4cb24ad ]---
<0>[7359073.072455] Kernel panic - not syncing: Fatal exception in interrupt
We hit the routing code fairly hard. Any hints for what to look at or how
to instrument it? Or if it's fixed already? It's a real pain to iterate
since it takes ~30 days to crash, usually. Sometimes.
Thanks!
^ permalink raw reply
* Re: [Patch resend nf] ipvs: fix AF assignment in ip_vs_conn_new()
From: Michal Kubecek @ 2014-01-30 7:39 UTC (permalink / raw)
To: Julian Anastasov
Cc: netfilter-devel, netdev, lvs-devel, Wensong Zhang, Simon Horman,
Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller
In-Reply-To: <alpine.LFD.2.11.1401292319030.1844@ja.home.ssi.bg>
On Wed, Jan 29, 2014 at 11:24:17PM +0200, Julian Anastasov wrote:
> > diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
> > index 59a1a85..282b39b 100644
> > --- a/net/netfilter/ipvs/ip_vs_conn.c
> > +++ b/net/netfilter/ipvs/ip_vs_conn.c
> > @@ -871,11 +871,11 @@ ip_vs_conn_new(const struct ip_vs_conn_param *p,
> > cp->protocol = p->protocol;
> > ip_vs_addr_set(p->af, &cp->caddr, p->caddr);
> > cp->cport = p->cport;
> > - ip_vs_addr_set(p->af, &cp->vaddr, p->vaddr);
> > - cp->vport = p->vport;
> > - /* proto should only be IPPROTO_IP if d_addr is a fwmark */
> > + /* proto should only be IPPROTO_IP if p->vaddr is a fwmark */
> > ip_vs_addr_set(p->protocol == IPPROTO_IP ? AF_UNSPEC : p->af,
> > - &cp->daddr, daddr);
> > + &cp->vaddr, vaddr);
>
> Patch does not compile due to vaddr and p->daddr
> usage but you are in the right direction. Such change should
> fix a problem where connection templates don't get full
> IPv6 address for the real server, only the first 4 bytes
> are copied and as result it works only for IPv4.
Sorry for that, looks like I ran the test build after adapting to
current code with a config which didn't actually compile this file.
I'll send a v2 after testing a fixed version and I'll also extend the
commit message to describe the outcome.
Michal Kubecek
^ permalink raw reply
* [PATCH nf v2] ipvs: fix AF assignment in ip_vs_conn_new()
From: Michal Kubecek @ 2014-01-30 7:50 UTC (permalink / raw)
To: netfilter-devel
Cc: netdev, lvs-devel, Wensong Zhang, Simon Horman, Julian Anastasov,
Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller
In-Reply-To: <alpine.LFD.2.11.1401292319030.1844@ja.home.ssi.bg>
If a fwmark is passed to ip_vs_conn_new(), it is passed in
vaddr, not daddr. Therefore we should set AF to AF_UNSPEC in
vaddr assignment (like we do in ip_vs_ct_in_get()), otherwise we
may copy only first 4 bytes of an IPv6 address into cp->daddr.
v2: fix messed up {d,v}addr and p->{d,v}addr, add info about the
outcome (thanks to Julian Anastasov)
Signed-off-by: Bogdano Arendartchuk <barendartchuk@suse.com>
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
net/netfilter/ipvs/ip_vs_conn.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index 59a1a85..a8eb0a8 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -871,11 +871,11 @@ ip_vs_conn_new(const struct ip_vs_conn_param *p,
cp->protocol = p->protocol;
ip_vs_addr_set(p->af, &cp->caddr, p->caddr);
cp->cport = p->cport;
- ip_vs_addr_set(p->af, &cp->vaddr, p->vaddr);
- cp->vport = p->vport;
- /* proto should only be IPPROTO_IP if d_addr is a fwmark */
+ /* proto should only be IPPROTO_IP if p->vaddr is a fwmark */
ip_vs_addr_set(p->protocol == IPPROTO_IP ? AF_UNSPEC : p->af,
- &cp->daddr, daddr);
+ &cp->vaddr, p->vaddr);
+ cp->vport = p->vport;
+ ip_vs_addr_set(p->af, &cp->daddr, daddr);
cp->dport = dport;
cp->flags = flags;
cp->fwmark = fwmark;
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH nf v2] ipvs: fix AF assignment in ip_vs_conn_new()
From: Julian Anastasov @ 2014-01-30 8:29 UTC (permalink / raw)
To: Michal Kubecek
Cc: netfilter-devel, netdev, lvs-devel, Wensong Zhang, Simon Horman,
Pablo Neira Ayuso, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller
In-Reply-To: <20140130075020.7A903E916F@unicorn.suse.cz>
Hello,
On Thu, 30 Jan 2014, Michal Kubecek wrote:
> If a fwmark is passed to ip_vs_conn_new(), it is passed in
> vaddr, not daddr. Therefore we should set AF to AF_UNSPEC in
> vaddr assignment (like we do in ip_vs_ct_in_get()), otherwise we
> may copy only first 4 bytes of an IPv6 address into cp->daddr.
>
> v2: fix messed up {d,v}addr and p->{d,v}addr, add info about the
> outcome (thanks to Julian Anastasov)
>
> Signed-off-by: Bogdano Arendartchuk <barendartchuk@suse.com>
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Acked-by: Julian Anastasov <ja@ssi.bg>
Looks like problem comes from
commit be8be9eccbf2d908a7e56b3f7a71105cd88da06b
"ipvs: Fix IPv4 FWMARK virtual services" (2.6.30).
> ---
> net/netfilter/ipvs/ip_vs_conn.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
> index 59a1a85..a8eb0a8 100644
> --- a/net/netfilter/ipvs/ip_vs_conn.c
> +++ b/net/netfilter/ipvs/ip_vs_conn.c
> @@ -871,11 +871,11 @@ ip_vs_conn_new(const struct ip_vs_conn_param *p,
> cp->protocol = p->protocol;
> ip_vs_addr_set(p->af, &cp->caddr, p->caddr);
> cp->cport = p->cport;
> - ip_vs_addr_set(p->af, &cp->vaddr, p->vaddr);
> - cp->vport = p->vport;
> - /* proto should only be IPPROTO_IP if d_addr is a fwmark */
> + /* proto should only be IPPROTO_IP if p->vaddr is a fwmark */
> ip_vs_addr_set(p->protocol == IPPROTO_IP ? AF_UNSPEC : p->af,
> - &cp->daddr, daddr);
> + &cp->vaddr, p->vaddr);
> + cp->vport = p->vport;
> + ip_vs_addr_set(p->af, &cp->daddr, daddr);
> cp->dport = dport;
> cp->flags = flags;
> cp->fwmark = fwmark;
> --
> 1.8.1.4
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH stable 3.11+] can: use private sk reference to detect originating socket
From: Andre Naujoks @ 2014-01-30 8:32 UTC (permalink / raw)
To: Oliver Hartkopp, Eric Dumazet
Cc: David Miller, Linux Netdev List, linux-can@vger.kernel.org
In-Reply-To: <52E96BDC.9070209@hartkopp.net>
On 29.01.2014 22:00, schrieb Oliver Hartkopp:
> So here we are:
>
> Introduced can_create_echo_skb() which creates a skb which is properly
> owned to be send back (echo'ed) into the network stack.
I see no crashes with this and it works as expected.
You can add my:
Tested-by: Andre Naujoks <nautsch2@gmail.com>
Regards
Andre
>
> Regards,
> Oliver
>
^ 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