* Re: [RFC] tcp md5 use of alloc_percpu
From: Herbert Xu @ 2014-10-24 9:33 UTC (permalink / raw)
To: Crestez Dan Leonard; +Cc: eric.dumazet, netdev, linux-crypto
In-Reply-To: <5448383A.4090908@gmail.com>
Crestez Dan Leonard <cdleonard@gmail.com> wrote:
>
>> Yep, but the sg stuff does not allow for stack variables. Because of
>> possible offloading and DMA, I dont know...
> A stack buffer is used in tcp_md5_hash_header to add a tcphdr to the
> hash. A quick grep for sg_init_one find a couple of additional instances
> of what looks like doing crypto on small stack buffers:
First of all crypto_hash_update is obsolete, don't use it in any
new code. Thanks for reminding me to get rid of existing users.
You should either use crypto_shash_update for small data, e.g., headers
or crypto_ahash_update for large data such as whole packets.
If you use shash then you may allocate your buffer on the stack. With
ahash stack memory is not allowed.
I hope this clears things up for you.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* RE: [PATCH RFC 1/4] virtio_net: pass vi around
From: David Laight @ 2014-10-24 10:02 UTC (permalink / raw)
To: 'Michael S. Tsirkin', linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org, virtualization@lists.linux-foundation.org
In-Reply-To: <1414099656-28090-1-git-send-email-mst@redhat.com>
From: Michael S. Tsirkin
> Too many places poke at [rs]q->vq->vdev->priv just to get
> the the vi structure. Let's just pass the pointer around: seems
> cleaner, and might even be faster.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/virtio_net.c | 36 +++++++++++++++++++-----------------
> 1 file changed, 19 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 57cbc7d..36f3dfc 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
...
> static struct sk_buff *receive_big(struct net_device *dev,
> + struct virtnet_info *vi,
Do you need to pass 'dev' here?
Looks like it is obtainable from vi->dev (as below).
David
> struct receive_queue *rq,
> void *buf,
> unsigned int len)
> {
> struct page *page = buf;
> - struct sk_buff *skb = page_to_skb(rq, page, 0, len, PAGE_SIZE);
> + struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len, PAGE_SIZE);
...
> -static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
> +static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
> + void *buf, unsigned int len)
> {
> - struct virtnet_info *vi = rq->vq->vdev->priv;
> struct net_device *dev = vi->dev;
...
^ permalink raw reply
* Re: bridge: Do not compile options in br_parse_ip_options
From: Florian Westphal @ 2014-10-24 10:41 UTC (permalink / raw)
To: Herbert Xu
Cc: Florian Westphal, netfilter-devel, bsd, stephen, netdev,
eric.dumazet, davidn, David S. Miller
In-Reply-To: <20141004141802.GA10878@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> bridge: Do not compile options in br_parse_ip_options
>
> Commit 462fb2af9788a82a534f8184abfde31574e1cfa0
>
> bridge : Sanitize skb before it enters the IP stack
>
> broke when IP options are actually used because it mangles the
> skb as if it entered the IP stack which is wrong because the
> bridge is supposed to operate below the IP stack.
>
> Since nobody has actually requested for parsing of IP options
> this patch fixes it by simply reverting to the previous approach
> of ignoring all IP options, i.e., zeroing the IPCB.
>
> If and when somebody who uses IP options and actually needs them
> to be parsed by the bridge complains then we can revisit this.
>
> Reported-by: David Newall <davidn@davidnewall.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Florian Westphal <fw@strlen.de>
Pablo, could you please apply this?
Thanks!
^ permalink raw reply
* Re: [PATCH] ucc_geth: invalid rx checksum error values
From: Jianhua Xie @ 2014-10-24 12:11 UTC (permalink / raw)
To: Kokoris, Ioannis, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Cc: Zhao Qiang, netdev, Timur Tabi
In-Reply-To: <FDB831DFAAC88B42A50BA37D1BC5E13A29C63D1F@MCHP03MSX.global-ad.net>
[-- Attachment #1.1: Type: text/plain, Size: 1828 bytes --]
Hi Ioannis ,
Thank you very much for finding and reporting the issue.
I help to broadcast to netdev mailing-list.
Thanks & Best Regards,
Jianhua
在 2014年10月22日 21:07, Kokoris, Ioannis 写道:
> Hi,
>
> The value in QE UCC ethernet interfaces shows random values:
>
> # ethtool -S eth0
> NIC statistics:
> ...
> rx-ip-checksum-errors: 3933892214
>
> The problem is located in a mismatch between the rx_fw_stat_gstrings fields
> - used in ucc_geth_ethtool - and the ucc_geth_rx_firmware_statistics_pram
> fields - used in ucc_geth.
> Although the QE UCC Ethernet Controller includes the Rx checksum error
> counter in the 'Rx firmware counters', the related field is missing from the
> ucc_geth driver.
> After adding the RxChecksumError field in
> ucc_geth_rx_firmware_statistics_pram structure the counter works fine.
>
>
>
> Signed-off-by: Ioannis Kokkoris <ioannis.kokoris@unify.com>
>
>
> diff -Nru a/drivers/net/ethernet/freescale/ucc_geth.h
> b/drivers/net/ethernet/freescale/ucc_geth.h
> --- a/drivers/net/ethernet/freescale/ucc_geth.h 2014-10-22
> 15:19:16.000000000 +0300
> +++ b/drivers/net/ethernet/freescale/ucc_geth.h 2014-10-22
> 15:24:39.000000000 +0300
> @@ -541,6 +541,8 @@
> replaced */
> u32 insertvlan; /* total frames that had their VLAN tag
> inserted */
> + u32 checksumerr; /* total frames that have IP Checksum Error
> + */
> } __packed;
>
> struct ucc_geth_rx_interrupt_coalescing_entry {
>
>
>
> Best Regards,
> Ioannis
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #1.2: Type: text/html, Size: 2563 bytes --]
[-- Attachment #2: Type: text/plain, Size: 150 bytes --]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH 1/2] staging: lustre: lnet: lnet: do not initialise 0
From: Balavasu @ 2014-10-24 12:15 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
This patch fixes the checkpatch.pl issue
Error: do not initialise statics to 0 or NULL for time
Signed-off-by: Balavasu <kp.balavasu@gmail.com>
---
drivers/staging/lustre/lnet/lnet/router.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/lustre/lnet/lnet/router.c b/drivers/staging/lustre/lnet/lnet/router.c
index b5b8fb5..cdeb246 100644
--- a/drivers/staging/lustre/lnet/lnet/router.c
+++ b/drivers/staging/lustre/lnet/lnet/router.c
@@ -46,7 +46,7 @@ MODULE_PARM_DESC(small_router_buffers, "# of small (1 page) messages to buffer i
static int large_router_buffers;
module_param(large_router_buffers, int, 0444);
MODULE_PARM_DESC(large_router_buffers, "# of large messages to buffer in the router");
-static int peer_buffer_credits = 0;
+static int peer_buffer_credits;
module_param(peer_buffer_credits, int, 0444);
MODULE_PARM_DESC(peer_buffer_credits, "# router buffer credits per peer");
@@ -80,7 +80,7 @@ lnet_peer_buffer_credits(lnet_ni_t *ni)
#endif
-static int check_routers_before_use = 0;
+static int check_routers_before_use;
module_param(check_routers_before_use, int, 0444);
MODULE_PARM_DESC(check_routers_before_use, "Assume routers are down and ping them before use");
@@ -245,7 +245,7 @@ lnet_find_net_locked (__u32 net)
static void lnet_shuffle_seed(void)
{
- static int seeded = 0;
+ static int seeded;
int lnd_type, seed[2];
struct timeval tv;
lnet_ni_t *ni;
@@ -1584,8 +1584,8 @@ lnet_notify (lnet_ni_t *ni, lnet_nid_t nid, int alive, unsigned long when)
void
lnet_router_checker (void)
{
- static time_t last = 0;
- static int running = 0;
+ static time_t last;
+ static int running;
time_t now = get_seconds();
int interval = now - last;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] staging: lustre: lnet: lnet: trailing statement
From: Balavasu @ 2014-10-24 12:16 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
This patch fixes the checkpatch.pl issue
Error: trailing statements should be on next line
Signed-off-by: Balavasu <kp.balavasu@gmail.com>
---
drivers/staging/lustre/lnet/lnet/router.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lnet/lnet/router.c b/drivers/staging/lustre/lnet/lnet/router.c
index cdeb246..0f569a0 100644
--- a/drivers/staging/lustre/lnet/lnet/router.c
+++ b/drivers/staging/lustre/lnet/lnet/router.c
@@ -1670,13 +1670,16 @@ lnet_get_tunables (void)
char *s;
s = getenv("LNET_ROUTER_PING_TIMEOUT");
- if (s != NULL) router_ping_timeout = atoi(s);
+ if (s != NULL)
+ router_ping_timeout = atoi(s);
s = getenv("LNET_LIVE_ROUTER_CHECK_INTERVAL");
- if (s != NULL) live_router_check_interval = atoi(s);
+ if (s != NULL)
+ live_router_check_interval = atoi(s);
s = getenv("LNET_DEAD_ROUTER_CHECK_INTERVAL");
- if (s != NULL) dead_router_check_interval = atoi(s);
+ if (s != NULL)
+ dead_router_check_interval = atoi(s);
/* This replaces old lnd_notify mechanism */
check_routers_before_use = 1;
--
1.9.1
^ permalink raw reply related
* Re: [net-next 8/9] i40e: Moving variable declaration out of the loops
From: Sergei Shtylyov @ 2014-10-24 12:20 UTC (permalink / raw)
To: Jeff Kirsher, davem
Cc: Akeem G Abodunrin, netdev, nhorman, sassmann, jogreene,
Patrick Lu
In-Reply-To: <1414123806-20049-9-git-send-email-jeffrey.t.kirsher@intel.com>
Hello.
On 10/24/2014 8:10 AM, Jeff Kirsher wrote:
> From: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
> Move the three variables out of the loop, so it only declares once.
It's only declared once in either case. I think gcc allocates maximum
local variable space at the start of the function, so declaring variables in
the loop body comes with no extra price.
> Change-ID: I436913777c7da3c16dc0031b59e3ffa61de74718
> Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
> Signed-off-by: Patrick Lu <patrick.lu@intel.com>
> Tested-by: Jim Young <jamesx.m.young@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index 9d36d10..b0c10e0 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -813,7 +813,10 @@ static void i40e_update_vsi_stats(struct i40e_vsi *vsi)
> struct i40e_eth_stats *oes;
> struct i40e_eth_stats *es; /* device's eth stats */
> u32 tx_restart, tx_busy;
> + struct i40e_ring *p;
> u32 rx_page, rx_buf;
> + u64 bytes, packets;
> + unsigned int start;
> u64 rx_p, rx_b;
> u64 tx_p, tx_b;
> u16 q;
> @@ -837,10 +840,6 @@ static void i40e_update_vsi_stats(struct i40e_vsi *vsi)
> rx_buf = 0;
> rcu_read_lock();
> for (q = 0; q < vsi->num_queue_pairs; q++) {
> - struct i40e_ring *p;
> - u64 bytes, packets;
> - unsigned int start;
> -
WBR, Sergei
^ permalink raw reply
* Re: bridge: Do not compile options in br_parse_ip_options
From: Pablo Neira Ayuso @ 2014-10-24 12:28 UTC (permalink / raw)
To: Florian Westphal
Cc: Herbert Xu, netfilter-devel, bsd, stephen, netdev, eric.dumazet,
davidn, David S. Miller
In-Reply-To: <20141024104149.GA7401@breakpoint.cc>
On Fri, Oct 24, 2014 at 12:41:49PM +0200, Florian Westphal wrote:
> Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > bridge: Do not compile options in br_parse_ip_options
> >
> > Commit 462fb2af9788a82a534f8184abfde31574e1cfa0
> >
> > bridge : Sanitize skb before it enters the IP stack
> >
> > broke when IP options are actually used because it mangles the
> > skb as if it entered the IP stack which is wrong because the
> > bridge is supposed to operate below the IP stack.
> >
> > Since nobody has actually requested for parsing of IP options
> > this patch fixes it by simply reverting to the previous approach
> > of ignoring all IP options, i.e., zeroing the IPCB.
> >
> > If and when somebody who uses IP options and actually needs them
> > to be parsed by the bridge complains then we can revisit this.
> >
> > Reported-by: David Newall <davidn@davidnewall.com>
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> Tested-by: Florian Westphal <fw@strlen.de>
Applied, thanks a lot for testing Florian.
^ permalink raw reply
* Re: [PATCH 06/14] net: dsa: Add support for hardware monitoring
From: Florian Fainelli @ 2014-10-24 12:52 UTC (permalink / raw)
To: Guenter Roeck, David Miller; +Cc: netdev, andrew, linux-kernel
In-Reply-To: <5449E66B.6090902@roeck-us.net>
Le 23/10/2014 22:40, Guenter Roeck a écrit :
> On 10/23/2014 10:03 PM, David Miller wrote:
>> From: Guenter Roeck <linux@roeck-us.net>
>> Date: Wed, 22 Oct 2014 22:06:41 -0700
>>
>>> On 10/22/2014 09:37 PM, Florian Fainelli wrote:
>>>> 2014-10-22 21:03 GMT-07:00 Guenter Roeck <linux@roeck-us.net>:
>>>>> Some Marvell switches provide chip temperature data.
>>>>> Add support for reporting it to the dsa infrastructure.
>>>>>
>>>>> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>>>>> ---
>>>> [snip]
>>>>
>>>>> +/* hwmon support
>>>>> ************************************************************/
>>>>> +
>>>>> +#if defined(CONFIG_HWMON) || (defined(MODULE) &&
>>>>> defined(CONFIG_HWMON_MODULE))
>>>>
>>>> IS_ENABLED(CONFIG_HWMON)?
>>>>
>>>
>>> Hi Florian,
>>>
>>> unfortunately, that won't work; I had it initially and got a nice
>>> error message
>>> from Fengguang's build test bot.
>>
>> Then the Kconfig dependencies are broken.
>>
>> Fix Kconfig to only allow legal combinations.
>>
>
> I see two options for that:
>
> - Add
> select HWMON
> to the NET_DSA Kconfig entry.
> Example is Broadcom TIGON3 driver.
>
> - Add a DSA_HWMON Kconfig entry to define the dependencies and
> to let the user select if the functionality should be enabled.
> Example is Intel IGB driver.
>
> Any preference from your side ? If no, I'll go with the latter.
I would prefer DSA_HWMON personaly, though no strong feelings. Since
this is the most debated patch in this patch set, how about you drop it
from your v2 and we sort this one out separately?
--
Florian
^ permalink raw reply
* Payment
From: Finance Department @ 2014-10-24 12:04 UTC (permalink / raw)
Dear Recipient,
You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds.
Gloria Peter
^ permalink raw reply
* RE: [net-next 8/9] i40e: Moving variable declaration out of the loops
From: David Laight @ 2014-10-24 13:10 UTC (permalink / raw)
To: 'Sergei Shtylyov', Jeff Kirsher, davem@davemloft.net
Cc: Akeem G Abodunrin, netdev@vger.kernel.org, nhorman@redhat.com,
sassmann@redhat.com, jogreene@redhat.com, Patrick Lu
In-Reply-To: <544A4403.9090108@cogentembedded.com>
From: Sergei Shtylyov
> Hello.
>
> On 10/24/2014 8:10 AM, Jeff Kirsher wrote:
>
> > From: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
>
> > Move the three variables out of the loop, so it only declares once.
>
> It's only declared once in either case. I think gcc allocates maximum
> local variable space at the start of the function, so declaring variables in
> the loop body comes with no extra price.
It won't make much (if any) difference to the generated code.
However it is generally easier for the human reader to find definitions
if they are at the top of the function.
Personally the only time I declare variables in an inner scope is when
that scope is very small.
David
^ permalink raw reply
* [PATCH 1/1] drivers: net:cpsw: fix probe_dt when only slave 1 is pinned out
From: Mugunthan V N @ 2014-10-24 13:21 UTC (permalink / raw)
To: netdev; +Cc: davem, Mugunthan V N
when slave 0 has no phy and slave 1 connected to phy, driver probe will
fail as there is no phy id present for slave 0 device tree, so continuing
even though no phy-id found, also moving mac-id read later to ensure
mac-id is read from device tree even when phy-id entry in not found.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 952e1e4..d81b84b 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -2006,7 +2006,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
parp = of_get_property(slave_node, "phy_id", &lenp);
if ((parp == NULL) || (lenp != (sizeof(void *) * 2))) {
dev_err(&pdev->dev, "Missing slave[%d] phy_id property\n", i);
- return -EINVAL;
+ goto no_phy_slave;
}
mdio_node = of_find_node_by_phandle(be32_to_cpup(parp));
phyid = be32_to_cpup(parp+1);
@@ -2019,6 +2019,14 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
snprintf(slave_data->phy_id, sizeof(slave_data->phy_id),
PHY_ID_FMT, mdio->name, phyid);
+ slave_data->phy_if = of_get_phy_mode(slave_node);
+ if (slave_data->phy_if < 0) {
+ dev_err(&pdev->dev, "Missing or malformed slave[%d] phy-mode property\n",
+ i);
+ return slave_data->phy_if;
+ }
+
+no_phy_slave:
mac_addr = of_get_mac_address(slave_node);
if (mac_addr) {
memcpy(slave_data->mac_addr, mac_addr, ETH_ALEN);
@@ -2030,14 +2038,6 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
return ret;
}
}
-
- slave_data->phy_if = of_get_phy_mode(slave_node);
- if (slave_data->phy_if < 0) {
- dev_err(&pdev->dev, "Missing or malformed slave[%d] phy-mode property\n",
- i);
- return slave_data->phy_if;
- }
-
if (data->dual_emac) {
if (of_property_read_u32(slave_node, "dual_emac_res_vlan",
&prop)) {
--
2.1.2.484.g13da0fc
^ permalink raw reply related
* Re: [PATCH 06/14] net: dsa: Add support for hardware monitoring
From: Guenter Roeck @ 2014-10-24 13:53 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, netdev, David S. Miller,
linux-kernel@vger.kernel.org
In-Reply-To: <20141023195526.GH25190@lunn.ch>
On 10/23/2014 12:55 PM, Andrew Lunn wrote:
[ ... ]
>
> Does hwmon offer a function to sanitise a string?
>
No, that wasn't necessary so far. The 'name' string is a constant string
provided by the driver.
> The switch index definitely should be used and i would probably
> combine that with a sanitised version of the ethernet device name and
> "dsa".
>
How is this ?
em1dsa0-isa-0000
Adapter: ISA adapter
temp1: +38.0°C (high = +100.0°C)
This is the sanitized network device name + 'dsa' + index.
Guenter
^ permalink raw reply
* Re: [PATCH RFC 1/4] virtio_net: pass vi around
From: Michael S. Tsirkin @ 2014-10-24 14:10 UTC (permalink / raw)
To: David Laight
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9DE6C2@AcuExch.aculab.com>
On Fri, Oct 24, 2014 at 10:02:15AM +0000, David Laight wrote:
> From: Michael S. Tsirkin
>
> > Too many places poke at [rs]q->vq->vdev->priv just to get
> > the the vi structure. Let's just pass the pointer around: seems
> > cleaner, and might even be faster.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > drivers/net/virtio_net.c | 36 +++++++++++++++++++-----------------
> > 1 file changed, 19 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 57cbc7d..36f3dfc 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> ...
> > static struct sk_buff *receive_big(struct net_device *dev,
> > + struct virtnet_info *vi,
>
> Do you need to pass 'dev' here?
> Looks like it is obtainable from vi->dev (as below).
>
> David
>
> > struct receive_queue *rq,
> > void *buf,
> > unsigned int len)
> > {
> > struct page *page = buf;
> > - struct sk_buff *skb = page_to_skb(rq, page, 0, len, PAGE_SIZE);
> > + struct sk_buff *skb = page_to_skb(vi, rq, page, 0, len, PAGE_SIZE);
> ...
> > -static void receive_buf(struct receive_queue *rq, void *buf, unsigned int len)
> > +static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
> > + void *buf, unsigned int len)
> > {
> > - struct virtnet_info *vi = rq->vq->vdev->priv;
> > struct net_device *dev = vi->dev;
> ...
It's a matter of style, isn't it?
We have dev to hand, it seems cleaner to just pass it around.
--
MST
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Paul E. McKenney @ 2014-10-24 14:50 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Yanko Kaneti, Josh Boyer, Eric W. Biederman, Cong Wang,
Kevin Fenzi, netdev, Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <31920.1414126114@famine>
On Thu, Oct 23, 2014 at 09:48:34PM -0700, Jay Vosburgh wrote:
> Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
>
> >On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
> >>
> >> On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
> >> > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
> >> > > On Thu-10/23/14-2014 08:33, Paul E. McKenney wrote:
> >> > > > On Thu, Oct 23, 2014 at 05:27:50AM -0700, Paul E. McKenney wrote:
> >> > > > > On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote:
> >> > > > > > On Wed, 2014-10-22 at 16:24 -0700, Paul E. McKenney wrote:
> >> > > > > > > On Thu, Oct 23, 2014 at 01:40:32AM +0300, Yanko Kaneti
> >> > > > > > > wrote:
> >> > > > > > > > On Wed-10/22/14-2014 15:33, Josh Boyer wrote:
> >> > > > > > > > > On Wed, Oct 22, 2014 at 2:55 PM, Paul E. McKenney
> >> > > > > > > > > <paulmck@linux.vnet.ibm.com> wrote:
> >> > > > > > >
> >> > > > > > > [ . . . ]
> >> > > > > > >
> >> > > > > > > > > > Don't get me wrong -- the fact that this kthread
> >> > > > > > > > > > appears to
> >> > > > > > > > > > have
> >> > > > > > > > > > blocked within rcu_barrier() for 120 seconds means
> >> > > > > > > > > > that
> >> > > > > > > > > > something is
> >> > > > > > > > > > most definitely wrong here. I am surprised that
> >> > > > > > > > > > there are no
> >> > > > > > > > > > RCU CPU
> >> > > > > > > > > > stall warnings, but perhaps the blockage is in the
> >> > > > > > > > > > callback
> >> > > > > > > > > > execution
> >> > > > > > > > > > rather than grace-period completion. Or something is
> >> > > > > > > > > > preventing this
> >> > > > > > > > > > kthread from starting up after the wake-up callback
> >> > > > > > > > > > executes.
> >> > > > > > > > > > Or...
> >> > > > > > > > > >
> >> > > > > > > > > > Is this thing reproducible?
> >> > > > > > > > >
> >> > > > > > > > > I've added Yanko on CC, who reported the backtrace
> >> > > > > > > > > above and can
> >> > > > > > > > > recreate it reliably. Apparently reverting the RCU
> >> > > > > > > > > merge commit
> >> > > > > > > > > (d6dd50e) and rebuilding the latest after that does
> >> > > > > > > > > not show the
> >> > > > > > > > > issue. I'll let Yanko explain more and answer any
> >> > > > > > > > > questions you
> >> > > > > > > > > have.
> >> > > > > > > >
> >> > > > > > > > - It is reproducible
> >> > > > > > > > - I've done another build here to double check and its
> >> > > > > > > > definitely
> >> > > > > > > > the rcu merge
> >> > > > > > > > that's causing it.
> >> > > > > > > >
> >> > > > > > > > Don't think I'll be able to dig deeper, but I can do
> >> > > > > > > > testing if
> >> > > > > > > > needed.
> >> > > > > > >
> >> > > > > > > Please! Does the following patch help?
> >> > > > > >
> >> > > > > > Nope, doesn't seem to make a difference to the modprobe
> >> > > > > > ppp_generic
> >> > > > > > test
> >> > > > >
> >> > > > > Well, I was hoping. I will take a closer look at the RCU
> >> > > > > merge commit
> >> > > > > and see what suggests itself. I am likely to ask you to
> >> > > > > revert specific
> >> > > > > commits, if that works for you.
> >> > > >
> >> > > > Well, rather than reverting commits, could you please try
> >> > > > testing the
> >> > > > following commits?
> >> > > >
> >> > > > 11ed7f934cb8 (rcu: Make nocb leader kthreads process pending
> >> > > > callbacks after spawning)
> >> > > >
> >> > > > 73a860cd58a1 (rcu: Replace flush_signals() with
> >> > > > WARN_ON(signal_pending()))
> >> > > >
> >> > > > c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())
> >> > > >
> >> > > > For whatever it is worth, I am guessing this one.
> >> > >
> >> > > Indeed, c847f14217d5 it is.
> >> > >
> >> > > Much to my embarrasment I just noticed that in addition to the
> >> > > rcu merge, triggering the bug "requires" my specific Fedora
> >> > > rawhide network
> >> > > setup. Booting in single mode and modprobe ppp_generic is fine.
> >> > > The bug
> >> > > appears when starting with my regular fedora network setup, which
> >> > > in my case
> >> > > includes 3 ethernet adapters and a libvirt birdge+nat setup.
> >> > >
> >> > > Hope that helps.
> >> > >
> >> > > I am attaching the config.
> >> >
> >> > It does help a lot, thank you!!!
> >> >
> >> > The following patch is a bit of a shot in the dark, and assumes that
> >> > commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled
> >> > idle
> >> > code) introduced the problem. Does this patch fix things up?
> >>
> >> Unfortunately not, This is linus-tip + patch
> >
> >OK. Can't have everything, I guess.
> >
> >> INFO: task kworker/u16:6:96 blocked for more than 120 seconds.
> >> Not tainted 3.18.0-rc1+ #4
> >> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> >> kworker/u16:6 D ffff8800ca84cec0 11168 96 2 0x00000000
> >> Workqueue: netns cleanup_net
> >> ffff8802218339e8 0000000000000096 ffff8800ca84cec0 00000000001d5f00
> >> ffff880221833fd8 00000000001d5f00 ffff880223264ec0 ffff8800ca84cec0
> >> ffffffff82c52040 7fffffffffffffff ffffffff81ee2658 ffffffff81ee2650
> >> Call Trace:
> >> [<ffffffff8185b8e9>] schedule+0x29/0x70
> >> [<ffffffff81860b0c>] schedule_timeout+0x26c/0x410
> >> [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0
> >> [<ffffffff8110759c>] ? mark_held_locks+0x7c/0xb0
> >> [<ffffffff81861b90>] ? _raw_spin_unlock_irq+0x30/0x50
> >> [<ffffffff8110772d>] ? trace_hardirqs_on_caller+0x15d/0x200
> >> [<ffffffff8185d31c>] wait_for_completion+0x10c/0x150
> >> [<ffffffff810e4ed0>] ? wake_up_state+0x20/0x20
> >> [<ffffffff8112a219>] _rcu_barrier+0x159/0x200
> >> [<ffffffff8112a315>] rcu_barrier+0x15/0x20
> >> [<ffffffff8171657f>] netdev_run_todo+0x6f/0x310
> >> [<ffffffff8170b145>] ? rollback_registered_many+0x265/0x2e0
> >> [<ffffffff817235ee>] rtnl_unlock+0xe/0x10
> >> [<ffffffff8170cfa6>] default_device_exit_batch+0x156/0x180
> >> [<ffffffff810fd390>] ? abort_exclusive_wait+0xb0/0xb0
> >> [<ffffffff81705053>] ops_exit_list.isra.1+0x53/0x60
> >> [<ffffffff81705c00>] cleanup_net+0x100/0x1f0
> >> [<ffffffff810cca98>] process_one_work+0x218/0x850
> >> [<ffffffff810cc9ff>] ? process_one_work+0x17f/0x850
> >> [<ffffffff810cd1b7>] ? worker_thread+0xe7/0x4a0
> >> [<ffffffff810cd13b>] worker_thread+0x6b/0x4a0
> >> [<ffffffff810cd0d0>] ? process_one_work+0x850/0x850
> >> [<ffffffff810d348b>] kthread+0x10b/0x130
> >> [<ffffffff81028c69>] ? sched_clock+0x9/0x10
> >> [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250
> >> [<ffffffff818628bc>] ret_from_fork+0x7c/0xb0
> >> [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250
> >> 4 locks held by kworker/u16:6/96:
> >> #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850
> >> #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850
> >> #2: (net_mutex){+.+.+.}, at: [<ffffffff81705b8c>] cleanup_net+0x8c/0x1f0
> >> #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a0f5>] _rcu_barrier+0x35/0x200
> >> INFO: task modprobe:1045 blocked for more than 120 seconds.
> >> Not tainted 3.18.0-rc1+ #4
> >> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> >> modprobe D ffff880218343480 12920 1045 1044 0x00000080
> >> ffff880218353bf8 0000000000000096 ffff880218343480 00000000001d5f00
> >> ffff880218353fd8 00000000001d5f00 ffffffff81e1b580 ffff880218343480
> >> ffff880218343480 ffffffff81f8f748 0000000000000246 ffff880218343480
> >> Call Trace:
> >> [<ffffffff8185be91>] schedule_preempt_disabled+0x31/0x80
> >> [<ffffffff8185d6e3>] mutex_lock_nested+0x183/0x440
> >> [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50
> >> [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50
> >> [<ffffffffa0673000>] ? 0xffffffffa0673000
> >> [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50
> >> [<ffffffffa0673048>] br_init+0x48/0xd3 [bridge]
> >> [<ffffffff81002148>] do_one_initcall+0xd8/0x210
> >> [<ffffffff81153052>] load_module+0x20c2/0x2870
> >> [<ffffffff8114e030>] ? store_uevent+0x70/0x70
> >> [<ffffffff81278717>] ? kernel_read+0x57/0x90
> >> [<ffffffff811539e6>] SyS_finit_module+0xa6/0xe0
> >> [<ffffffff81862969>] system_call_fastpath+0x12/0x17
> >> 1 lock held by modprobe/1045:
> >> #0: (net_mutex){+.+.+.}, at: [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50
> >
> >Presumably the kworker/u16:6 completed, then modprobe hung?
> >
> >If not, I have some very hard questions about why net_mutex can be
> >held by two tasks concurrently, given that it does not appear to be a
> >reader-writer lock...
> >
> >Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in
> >__call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle
> >NOCB callbacks from irq-disabled idle code) would fail. Is that the case?
> >If not, could you please bisect the commits between 11ed7f934cb8 (rcu:
> >Make nocb leader kthreads process pending callbacks after spawning)
> >and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())?
>
> Just a note to add that I am also reliably inducing what appears
> to be this issue on a current -net tree, when configuring openvswitch
> via script. I am available to test patches or bisect tomorrow (Friday)
> US time if needed.
Thank you, Jay! Could you please check to see if reverting this commit
fixes things for you?
35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
Reverting is not a long-term fix, as this commit is itself a bug fix,
but would be good to check to see if you are seeing the same thing that
Yanko is. ;-)
Thanx, Paul
> The stack is as follows:
>
> [ 1320.492020] INFO: task ovs-vswitchd:1303 blocked for more than 120 seconds.
> [ 1320.498965] Not tainted 3.17.0-testola+ #1
> [ 1320.503570] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1320.511374] ovs-vswitchd D ffff88013fc14600 0 1303 1302 0x00000004
> [ 1320.511378] ffff8801388d77d8 0000000000000002 ffff880031144b00 ffff8801388d7fd8
> [ 1320.511382] 0000000000014600 0000000000014600 ffff8800b092e400 ffff880031144b00
> [ 1320.511385] ffff8800b1126000 ffffffff81c58ad0 ffffffff81c58ad8 7fffffffffffffff
> [ 1320.511389] Call Trace:
> [ 1320.511396] [<ffffffff81739db9>] schedule+0x29/0x70
> [ 1320.511399] [<ffffffff8173cd8c>] schedule_timeout+0x1dc/0x260
> [ 1320.511404] [<ffffffff8109698d>] ? check_preempt_curr+0x8d/0xa0
> [ 1320.511407] [<ffffffff810969bd>] ? ttwu_do_wakeup+0x1d/0xd0
> [ 1320.511410] [<ffffffff8173aab6>] wait_for_completion+0xa6/0x160
> [ 1320.511413] [<ffffffff81099980>] ? wake_up_state+0x20/0x20
> [ 1320.511417] [<ffffffff810cdb57>] _rcu_barrier+0x157/0x200
> [ 1320.511419] [<ffffffff810cdc55>] rcu_barrier+0x15/0x20
> [ 1320.511423] [<ffffffff8163a780>] netdev_run_todo+0x60/0x300
> [ 1320.511427] [<ffffffff8164515e>] rtnl_unlock+0xe/0x10
> [ 1320.511435] [<ffffffffa01aecc5>] internal_dev_destroy+0x55/0x80 [openvswitch]
> [ 1320.511440] [<ffffffffa01ae622>] ovs_vport_del+0x32/0x40 [openvswitch]
> [ 1320.511444] [<ffffffffa01a7dd0>] ovs_dp_detach_port+0x30/0x40 [openvswitch]
> [ 1320.511448] [<ffffffffa01a7ea5>] ovs_vport_cmd_del+0xc5/0x110 [openvswitch]
> [ 1320.511452] [<ffffffff816675b5>] genl_family_rcv_msg+0x1a5/0x3c0
> [ 1320.511455] [<ffffffff816677d0>] ? genl_family_rcv_msg+0x3c0/0x3c0
> [ 1320.511458] [<ffffffff81667861>] genl_rcv_msg+0x91/0xd0
> [ 1320.511461] [<ffffffff816658d1>] netlink_rcv_skb+0xc1/0xe0
> [ 1320.511463] [<ffffffff81665dfc>] genl_rcv+0x2c/0x40
> [ 1320.511466] [<ffffffff81664e66>] netlink_unicast+0xf6/0x200
> [ 1320.511468] [<ffffffff8166528d>] netlink_sendmsg+0x31d/0x780
> [ 1320.511472] [<ffffffff81662274>] ? netlink_rcv_wake+0x44/0x60
> [ 1320.511475] [<ffffffff816632e3>] ? netlink_recvmsg+0x1d3/0x3e0
> [ 1320.511479] [<ffffffff8161c463>] sock_sendmsg+0x93/0xd0
> [ 1320.511484] [<ffffffff81332d00>] ? apparmor_file_alloc_security+0x20/0x40
> [ 1320.511487] [<ffffffff8162a697>] ? verify_iovec+0x47/0xd0
> [ 1320.511491] [<ffffffff8161cc79>] ___sys_sendmsg+0x399/0x3b0
> [ 1320.511495] [<ffffffff81254e02>] ? kernfs_seq_stop_active+0x32/0x40
> [ 1320.511499] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90
> [ 1320.511502] [<ffffffff8101c385>] ? native_sched_clock+0x35/0x90
> [ 1320.511505] [<ffffffff8101c3e9>] ? sched_clock+0x9/0x10
> [ 1320.511509] [<ffffffff81122d5c>] ? acct_account_cputime+0x1c/0x20
> [ 1320.511512] [<ffffffff8109ce6b>] ? account_user_time+0x8b/0xa0
> [ 1320.511516] [<ffffffff811fc135>] ? __fget_light+0x25/0x70
> [ 1320.511519] [<ffffffff8161d372>] __sys_sendmsg+0x42/0x80
> [ 1320.511521] [<ffffffff8161d3c2>] SyS_sendmsg+0x12/0x20
> [ 1320.511525] [<ffffffff8173e6a4>] tracesys_phase2+0xd8/0xdd
>
> -J
>
> ---
> -Jay Vosburgh, jay.vosburgh@canonical.com
>
^ permalink raw reply
* Re: [PATCH net-next] tcp: Add TCP_FREEZE socket option
From: Yuchung Cheng @ 2014-10-24 14:58 UTC (permalink / raw)
To: Kristian Evensen; +Cc: Hagen Paul Pfeifer, David Miller, Network Development
In-Reply-To: <CAKfDRXhJ9c+AqqrD38e7RcUSXn21pNMWskRs38H+PnSEwXac+Q@mail.gmail.com>
On Thu, Oct 23, 2014 at 4:33 AM, Kristian Evensen
<kristian.evensen@gmail.com> wrote:
> Hi,
>
> I am very sorry for not explaining the scenario/use-case properly.
> Freeze-TCP is mostly targeted at TCP connections established through
> mobile broadband networks. One example scenario is that of when a user
> moves outside of an area with LTE coverage. The mobile broadband
> connection will then be downgraded to 2G/3G and this process takes
> 10-15 seconds in the networks I have been able to measure. During this
> handover, the modem/device will in most cases report that it is still
> connected to LTE. So just looking at the state of the link is not good
> enough, as it will appear to be working fine (except for no data
> coming through it). The device does not change IP address, so TCP
> connections will resume normal operation as soon as the network
> connection is re-established and packet is retransmitted. However,
> because of the large "idle" period, this can take another 10-15
> seconds.
>
> On Wed, Oct 22, 2014 at 9:50 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
>> At least better. But what userspace daemon would configure this?
>> Likely NetworkManager and friends. But at what conditions?
>
> Yes, that would be my suggestion for tools too. The conditions would
> depend on the kind of network, available information and so on.
>
>> In a NATed scenario there is no gain because IP addreses change and
>> the connection is lost anyway. For the signal strength thing there
>> might be an advantage but it has costs:
>>
>> a) how long did you freeze the connection? What if NetworkManager
>> stops? The connection hang \infty
>> b) is it not better to inform the upper layer - the application - that
>> something happen with the link?
>>
>> I mean when the application experience disruptions, the application
>> can decide what it do: reconnect, reconnect and resend or inform the
>> user. This possibility is now lost/hidden. Maybe it is no problem -
>> maybe it is for some applications.
>
> This is the main reason why I went with a socket option. While I
> worked on this patch I wrote a small daemon for testing purposes. This
> daemon analyses data exported from a mobile broadband modem (QMI),
> looks at total interface throughput and then multicasts a netlink
> message when it determines that a handover might happen. This message
> is only a hint and then it is up to the application developer to
> decide what to do. Another solution would be a hybrid, the module will
> works as I described and the socket option will be used as an opt-in
> for Freeze-TCP.
>
>>
>> Do you have considered to bring this to the IETF (TCPM WG)?
>>
>
> Yes, I am currently considering it, or if I should look into different
> solutions before bringing it up for discussion. The ideal solution
> would be if there was a way to force a retransmit when the handover
> period is over, but that opens a whole net set of problems, potential
> security problems and changes TCP semantics a bit. An advantage of
Do packets actually get dropped during the handover period? if not
then the sender can detect spurious RTOs and undo the cwnd reductions
with timestamps or DSACKs (Eifel). Eifel did not exist when the
freeze-TCP was published at 2000. Even if the connection does not
support these options as major TCP stacks do, slow-start on a path
with new BDP isn't that bad of an idea.
> Freeze-TCP is that it works fine with what we have today.
>
> Thanks for your detailed comments!
>
> Kristian
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [QA-TCP] How to send tcp small packages immediately?
From: Rick Jones @ 2014-10-24 15:19 UTC (permalink / raw)
To: Zhangjie (HZ), kvm, Jason Wang, Michael S. Tsirkin, linux-kernel,
netdev, liuyongan, qinchuanyu
In-Reply-To: <544A029D.3080508@huawei.com>
On 10/24/2014 12:41 AM, Zhangjie (HZ) wrote:
> Hi,
>
> I use netperf to test the performance of small tcp package, with TCP_NODELAY set :
>
> netperf -H 129.9.7.164 -l 100 -- -m 512 -D
>
> Among the packages I got by tcpdump, there is not only small packages, also lost of
> big ones (skb->len=65160).
>
> IP 129.9.7.186.60840 > 129.9.7.164.34607: tcp 65160
> IP 129.9.7.164.34607 > 129.9.7.186.60840: tcp 0
> IP 129.9.7.164.34607 > 129.9.7.186.60840: tcp 0
> IP 129.9.7.164.34607 > 129.9.7.186.60840: tcp 0
> IP 129.9.7.186.60840 > 129.9.7.164.34607: tcp 65160
> IP 129.9.7.164.34607 > 129.9.7.186.60840: tcp 0
> IP 129.9.7.164.34607 > 129.9.7.186.60840: tcp 0
> IP 129.9.7.164.34607 > 129.9.7.186.60840: tcp 0
> IP 129.9.7.186.60840 > 129.9.7.164.34607: tcp 80
> IP 129.9.7.186.60840 > 129.9.7.164.34607: tcp 512
> IP 129.9.7.186.60840 > 129.9.7.164.34607: tcp 512
>
> SO, how to test small tcp packages? Including TCP_NODELAY, What else should be set?
Well, I don't think there is anything else you can set. Even with
TCP_NODELAY set, segment size with TCP will still be controlled by
factors such as congestion window.
I am ass-u-me-ing your packet trace is at the sender. I suppose if your
sender were fast enough compared to the path that might combine with
congestion window to result in the very large segments.
Not to say there cannot be a bug somewhere with TSO overriding
TCP_NODELAY, but in broad terms, even TCP_NODELAY does not guarantee
small TCP segments. That has been something of a bane on my attempts to
use TCP for aggregate small-packet performance measurements via netperf
for quite some time.
And since you seem to have included a virtualization mailing list I
would also ass-u-me that virtualization is involved somehow. Knuth only
knows how that will affect the timing of events, which will be very much
involved in matters of congestion window and such. I suppose it is even
possible that if the packet trace is on a VM receiver that some delays
in getting the VM running could mean that GRO would end-up making large
segments being pushed up the stack.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Paul E. McKenney @ 2014-10-24 15:40 UTC (permalink / raw)
To: Yanko Kaneti
Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev,
Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos
In-Reply-To: <20141024090857.GA4083@declera.com>
On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote:
> On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote:
> > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
> > >
> > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
> > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
[ . . . ]
> > > > > Indeed, c847f14217d5 it is.
> > > > >
> > > > > Much to my embarrasment I just noticed that in addition to the
> > > > > rcu merge, triggering the bug "requires" my specific Fedora
> > > > > rawhide network
> > > > > setup. Booting in single mode and modprobe ppp_generic is fine.
> > > > > The bug
> > > > > appears when starting with my regular fedora network setup, which
> > > > > in my case
> > > > > includes 3 ethernet adapters and a libvirt birdge+nat setup.
> > > > >
> > > > > Hope that helps.
> > > > >
> > > > > I am attaching the config.
> > > >
> > > > It does help a lot, thank you!!!
> > > >
> > > > The following patch is a bit of a shot in the dark, and assumes that
> > > > commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled
> > > > idle
> > > > code) introduced the problem. Does this patch fix things up?
> > >
> > > Unfortunately not, This is linus-tip + patch
> >
> > OK. Can't have everything, I guess.
> >
> > > INFO: task kworker/u16:6:96 blocked for more than 120 seconds.
> > > Not tainted 3.18.0-rc1+ #4
> > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > kworker/u16:6 D ffff8800ca84cec0 11168 96 2 0x00000000
> > > Workqueue: netns cleanup_net
> > > ffff8802218339e8 0000000000000096 ffff8800ca84cec0 00000000001d5f00
> > > ffff880221833fd8 00000000001d5f00 ffff880223264ec0 ffff8800ca84cec0
> > > ffffffff82c52040 7fffffffffffffff ffffffff81ee2658 ffffffff81ee2650
> > > Call Trace:
> > > [<ffffffff8185b8e9>] schedule+0x29/0x70
> > > [<ffffffff81860b0c>] schedule_timeout+0x26c/0x410
> > > [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0
> > > [<ffffffff8110759c>] ? mark_held_locks+0x7c/0xb0
> > > [<ffffffff81861b90>] ? _raw_spin_unlock_irq+0x30/0x50
> > > [<ffffffff8110772d>] ? trace_hardirqs_on_caller+0x15d/0x200
> > > [<ffffffff8185d31c>] wait_for_completion+0x10c/0x150
> > > [<ffffffff810e4ed0>] ? wake_up_state+0x20/0x20
> > > [<ffffffff8112a219>] _rcu_barrier+0x159/0x200
> > > [<ffffffff8112a315>] rcu_barrier+0x15/0x20
> > > [<ffffffff8171657f>] netdev_run_todo+0x6f/0x310
> > > [<ffffffff8170b145>] ? rollback_registered_many+0x265/0x2e0
> > > [<ffffffff817235ee>] rtnl_unlock+0xe/0x10
> > > [<ffffffff8170cfa6>] default_device_exit_batch+0x156/0x180
> > > [<ffffffff810fd390>] ? abort_exclusive_wait+0xb0/0xb0
> > > [<ffffffff81705053>] ops_exit_list.isra.1+0x53/0x60
> > > [<ffffffff81705c00>] cleanup_net+0x100/0x1f0
> > > [<ffffffff810cca98>] process_one_work+0x218/0x850
> > > [<ffffffff810cc9ff>] ? process_one_work+0x17f/0x850
> > > [<ffffffff810cd1b7>] ? worker_thread+0xe7/0x4a0
> > > [<ffffffff810cd13b>] worker_thread+0x6b/0x4a0
> > > [<ffffffff810cd0d0>] ? process_one_work+0x850/0x850
> > > [<ffffffff810d348b>] kthread+0x10b/0x130
> > > [<ffffffff81028c69>] ? sched_clock+0x9/0x10
> > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250
> > > [<ffffffff818628bc>] ret_from_fork+0x7c/0xb0
> > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250
> > > 4 locks held by kworker/u16:6/96:
> > > #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850
> > > #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850
> > > #2: (net_mutex){+.+.+.}, at: [<ffffffff81705b8c>] cleanup_net+0x8c/0x1f0
> > > #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a0f5>] _rcu_barrier+0x35/0x200
> > > INFO: task modprobe:1045 blocked for more than 120 seconds.
> > > Not tainted 3.18.0-rc1+ #4
> > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > modprobe D ffff880218343480 12920 1045 1044 0x00000080
> > > ffff880218353bf8 0000000000000096 ffff880218343480 00000000001d5f00
> > > ffff880218353fd8 00000000001d5f00 ffffffff81e1b580 ffff880218343480
> > > ffff880218343480 ffffffff81f8f748 0000000000000246 ffff880218343480
> > > Call Trace:
> > > [<ffffffff8185be91>] schedule_preempt_disabled+0x31/0x80
> > > [<ffffffff8185d6e3>] mutex_lock_nested+0x183/0x440
> > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50
> > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50
> > > [<ffffffffa0673000>] ? 0xffffffffa0673000
> > > [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50
> > > [<ffffffffa0673048>] br_init+0x48/0xd3 [bridge]
> > > [<ffffffff81002148>] do_one_initcall+0xd8/0x210
> > > [<ffffffff81153052>] load_module+0x20c2/0x2870
> > > [<ffffffff8114e030>] ? store_uevent+0x70/0x70
> > > [<ffffffff81278717>] ? kernel_read+0x57/0x90
> > > [<ffffffff811539e6>] SyS_finit_module+0xa6/0xe0
> > > [<ffffffff81862969>] system_call_fastpath+0x12/0x17
> > > 1 lock held by modprobe/1045:
> > > #0: (net_mutex){+.+.+.}, at: [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50
> >
> > Presumably the kworker/u16:6 completed, then modprobe hung?
> >
> > If not, I have some very hard questions about why net_mutex can be
> > held by two tasks concurrently, given that it does not appear to be a
> > reader-writer lock...
> >
> > Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in
> > __call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle
> > NOCB callbacks from irq-disabled idle code) would fail. Is that the case?
> > If not, could you please bisect the commits between 11ed7f934cb8 (rcu:
> > Make nocb leader kthreads process pending callbacks after spawning)
> > and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())?
>
> Ok, unless I've messsed up something major, bisecting points to:
>
> 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
>
> Makes any sense ?
Good question. ;-)
Are any of your online CPUs missing rcuo kthreads? There should be
kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU.
> Another thing I noticed is that in failure mode the libvirtd bridge actually
> doesn't show up. So maybe ppp is just the first thing to try that bumps up
> into whatever libvirtd is failing to do to setup those.
>
> Truly hope this is not something with random timing dependency....
Me too. ;-)
Thanx, Paul
> --Yanko
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH 06/14] net: dsa: Add support for hardware monitoring
From: Guenter Roeck @ 2014-10-24 16:19 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, netdev, David S. Miller,
linux-kernel@vger.kernel.org
In-Reply-To: <20141023195526.GH25190@lunn.ch>
On Thu, Oct 23, 2014 at 09:55:26PM +0200, Andrew Lunn wrote:
> On Thu, Oct 23, 2014 at 11:43:22AM -0700, Guenter Roeck wrote:
> > On Thu, Oct 23, 2014 at 08:03:57PM +0200, Andrew Lunn wrote:
> > > > No, I am not saying that. The hwmon device's parent device will tell,
> > > > which is how it works for all other hwmon devices.
> > >
> > > O.K, so parent is important.
> > >
> > > > Not really. Again, the parent device provides that information. libsensors,
> > > > which is the preferred way of accessing sensors information from user space,
> > > > provides the parent device instance as part of the logical sensor device
> > > > name. In this case, the names will end up being dsa-isa-0000, dsa-isa-0001,
> > > > and so on. With your added tags it would be dsa.0.0-isa-0000, dsa.0.1-isa-0001,
> > > > and so on. I don't see how this would add any value.
> > >
> > > isa is the name of the ethernet device? Why is it not eth0? Most
> >
> > isa is just an internal name made up by libsensors, and pretty much just
> > indicates something like "neither i2c nor spi". It is mostly historic,
> > but nowadays almost part of the ABI. It is made up by user space,
> > based on the parent device type, not by the kernel.
>
> So for DSA, since it is not i2c or spi, the parent is actually
> irrelevant, because libsensor ignores it and says "IsSomethingAlien".
> So the name alone needs to identify it.
>
> > You have convinced me that 'dsa' as hwmon attribute name is insufficient,
> > so let's see what we have.
> >
> > - the parent network device in dst->master_netdev
> > - the dsa device in 'parent'
> > - the host device in host_dev
> > - the switch index in 'index'
> >
> > First question is what should be the parent device.
>
> Does it even matter, given the observation above? I would probably go
> for dsa, since as you said, the Ethernet device may have a temperature
> sensor of its own. DSA is a virtual device...
>
> > Second is what to choose for the hwmon device 'name' attribute.
> > 'dsa' is not sufficient, but what to choose instead ? dsa.X or dsa_X,
> > where X is the switch index ? At this point I am open to suggestions.
> > Note that we can not use the name returned from the switch probe
> > functions as it may contain spaces and other invalid characters.
> > Including the ethernet device name (eg as in eth0_dsa_0) may also be
> > problematic if it can contain '-', which is illegal for hwmon devices.
>
> Does hwmon offer a function to sanitise a string?
>
> The switch index definitely should be used and i would probably
> combine that with a sanitised version of the ethernet device name and
> "dsa".
>
Here is another naming option:
em1dsa0-virtual-0
Adapter: Virtual device
temp1: +52.0°C (high = +100.0°C)
I think I'll go with that one. I get it by not specifying
a parent device when registering with the hwmon subsystem.
It is kind of similar to the thermal sensor data reported
through acpi.
acpitz-virtual-0
Adapter: Virtual device
temp1: +52.0°C (crit = +111.0°C)
temp2: +52.0°C (crit = +111.0°C)
Guenter
^ permalink raw reply
* Re: [PATCH net-next] tcp: Add TCP_FREEZE socket option
From: Hagen Paul Pfeifer @ 2014-10-24 16:26 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Kristian Evensen, David Miller, Network Development
In-Reply-To: <CAK6E8=fiHrgicTXy2hBGh0GUcZRWWxpYxw_bNVmRD+ueN9mUdw@mail.gmail.com>
On 24 October 2014 16:58, Yuchung Cheng <ycheng@google.com> wrote:
> Do packets actually get dropped during the handover period? if not
> then the sender can detect spurious RTOs and undo the cwnd reductions
> with timestamps or DSACKs (Eifel). Eifel did not exist when the
> freeze-TCP was published at 2000. Even if the connection does not
> support these options as major TCP stacks do, slow-start on a path
> with new BDP isn't that bad of an idea.
Yes, starting with fresh values for a new links is a good thing to do.
But what I think what Kristian want to address is to reduce larger
idle period due to backoff'ing timeouts followed by larger idle
periods? E.g. like a temporary cork for an exact period of time.
I thought that freeze-TCP was *also* designed to bridge a larger
disconnection? The downside with this approach (compared to SplitTCP)
is that you only send one instance into sleep. The other peer (sender)
may run into timeouts too.
Hagen
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Yanko Kaneti @ 2014-10-24 16:29 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev,
Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos
In-Reply-To: <20141024154006.GP4977@linux.vnet.ibm.com>
On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote:
> On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote:
> > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote:
> > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
> > > >
> > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
> > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
>
> [ . . . ]
>
> > > > > > Indeed, c847f14217d5 it is.
> > > > > >
> > > > > > Much to my embarrasment I just noticed that in addition to the
> > > > > > rcu merge, triggering the bug "requires" my specific Fedora
> > > > > > rawhide network
> > > > > > setup. Booting in single mode and modprobe ppp_generic is fine.
> > > > > > The bug
> > > > > > appears when starting with my regular fedora network setup, which
> > > > > > in my case
> > > > > > includes 3 ethernet adapters and a libvirt birdge+nat setup.
> > > > > >
> > > > > > Hope that helps.
> > > > > >
> > > > > > I am attaching the config.
> > > > >
> > > > > It does help a lot, thank you!!!
> > > > >
> > > > > The following patch is a bit of a shot in the dark, and assumes that
> > > > > commit 1772947bd012 (rcu: Handle NOCB callbacks from irq-disabled
> > > > > idle
> > > > > code) introduced the problem. Does this patch fix things up?
> > > >
> > > > Unfortunately not, This is linus-tip + patch
> > >
> > > OK. Can't have everything, I guess.
> > >
> > > > INFO: task kworker/u16:6:96 blocked for more than 120 seconds.
> > > > Not tainted 3.18.0-rc1+ #4
> > > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > > kworker/u16:6 D ffff8800ca84cec0 11168 96 2 0x00000000
> > > > Workqueue: netns cleanup_net
> > > > ffff8802218339e8 0000000000000096 ffff8800ca84cec0 00000000001d5f00
> > > > ffff880221833fd8 00000000001d5f00 ffff880223264ec0 ffff8800ca84cec0
> > > > ffffffff82c52040 7fffffffffffffff ffffffff81ee2658 ffffffff81ee2650
> > > > Call Trace:
> > > > [<ffffffff8185b8e9>] schedule+0x29/0x70
> > > > [<ffffffff81860b0c>] schedule_timeout+0x26c/0x410
> > > > [<ffffffff81028bea>] ? native_sched_clock+0x2a/0xa0
> > > > [<ffffffff8110759c>] ? mark_held_locks+0x7c/0xb0
> > > > [<ffffffff81861b90>] ? _raw_spin_unlock_irq+0x30/0x50
> > > > [<ffffffff8110772d>] ? trace_hardirqs_on_caller+0x15d/0x200
> > > > [<ffffffff8185d31c>] wait_for_completion+0x10c/0x150
> > > > [<ffffffff810e4ed0>] ? wake_up_state+0x20/0x20
> > > > [<ffffffff8112a219>] _rcu_barrier+0x159/0x200
> > > > [<ffffffff8112a315>] rcu_barrier+0x15/0x20
> > > > [<ffffffff8171657f>] netdev_run_todo+0x6f/0x310
> > > > [<ffffffff8170b145>] ? rollback_registered_many+0x265/0x2e0
> > > > [<ffffffff817235ee>] rtnl_unlock+0xe/0x10
> > > > [<ffffffff8170cfa6>] default_device_exit_batch+0x156/0x180
> > > > [<ffffffff810fd390>] ? abort_exclusive_wait+0xb0/0xb0
> > > > [<ffffffff81705053>] ops_exit_list.isra.1+0x53/0x60
> > > > [<ffffffff81705c00>] cleanup_net+0x100/0x1f0
> > > > [<ffffffff810cca98>] process_one_work+0x218/0x850
> > > > [<ffffffff810cc9ff>] ? process_one_work+0x17f/0x850
> > > > [<ffffffff810cd1b7>] ? worker_thread+0xe7/0x4a0
> > > > [<ffffffff810cd13b>] worker_thread+0x6b/0x4a0
> > > > [<ffffffff810cd0d0>] ? process_one_work+0x850/0x850
> > > > [<ffffffff810d348b>] kthread+0x10b/0x130
> > > > [<ffffffff81028c69>] ? sched_clock+0x9/0x10
> > > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250
> > > > [<ffffffff818628bc>] ret_from_fork+0x7c/0xb0
> > > > [<ffffffff810d3380>] ? kthread_create_on_node+0x250/0x250
> > > > 4 locks held by kworker/u16:6/96:
> > > > #0: ("%s""netns"){.+.+.+}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850
> > > > #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff810cc9ff>] process_one_work+0x17f/0x850
> > > > #2: (net_mutex){+.+.+.}, at: [<ffffffff81705b8c>] cleanup_net+0x8c/0x1f0
> > > > #3: (rcu_sched_state.barrier_mutex){+.+...}, at: [<ffffffff8112a0f5>] _rcu_barrier+0x35/0x200
> > > > INFO: task modprobe:1045 blocked for more than 120 seconds.
> > > > Not tainted 3.18.0-rc1+ #4
> > > > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > > modprobe D ffff880218343480 12920 1045 1044 0x00000080
> > > > ffff880218353bf8 0000000000000096 ffff880218343480 00000000001d5f00
> > > > ffff880218353fd8 00000000001d5f00 ffffffff81e1b580 ffff880218343480
> > > > ffff880218343480 ffffffff81f8f748 0000000000000246 ffff880218343480
> > > > Call Trace:
> > > > [<ffffffff8185be91>] schedule_preempt_disabled+0x31/0x80
> > > > [<ffffffff8185d6e3>] mutex_lock_nested+0x183/0x440
> > > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50
> > > > [<ffffffff81705a1f>] ? register_pernet_subsys+0x1f/0x50
> > > > [<ffffffffa0673000>] ? 0xffffffffa0673000
> > > > [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50
> > > > [<ffffffffa0673048>] br_init+0x48/0xd3 [bridge]
> > > > [<ffffffff81002148>] do_one_initcall+0xd8/0x210
> > > > [<ffffffff81153052>] load_module+0x20c2/0x2870
> > > > [<ffffffff8114e030>] ? store_uevent+0x70/0x70
> > > > [<ffffffff81278717>] ? kernel_read+0x57/0x90
> > > > [<ffffffff811539e6>] SyS_finit_module+0xa6/0xe0
> > > > [<ffffffff81862969>] system_call_fastpath+0x12/0x17
> > > > 1 lock held by modprobe/1045:
> > > > #0: (net_mutex){+.+.+.}, at: [<ffffffff81705a1f>] register_pernet_subsys+0x1f/0x50
> > >
> > > Presumably the kworker/u16:6 completed, then modprobe hung?
> > >
> > > If not, I have some very hard questions about why net_mutex can be
> > > held by two tasks concurrently, given that it does not appear to be a
> > > reader-writer lock...
> > >
> > > Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in
> > > __call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu: Handle
> > > NOCB callbacks from irq-disabled idle code) would fail. Is that the case?
> > > If not, could you please bisect the commits between 11ed7f934cb8 (rcu:
> > > Make nocb leader kthreads process pending callbacks after spawning)
> > > and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())?
> >
> > Ok, unless I've messsed up something major, bisecting points to:
> >
> > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
> >
> > Makes any sense ?
>
> Good question. ;-)
>
> Are any of your online CPUs missing rcuo kthreads? There should be
> kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU.
Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8
and the modprobe ppp_generic testcase reliably works, libvirt also manages
to setup its bridge.
Just with linux-tip , the rcuos are 6 but the failure is as reliable as
before.
Awating instructions: :)
^ permalink raw reply
* Re: [PATCH V3.18] rtlwifi: Add check for get_btc_status callback
From: Larry Finger @ 2014-10-24 16:39 UTC (permalink / raw)
To: Mike Galbraith
Cc: linville, linux-wireless, troy_tan, netdev,
Murilo Opsfelder Araujo, Thadeu Cascardo
In-Reply-To: <1414116580.23080.10.camel@marge.simpson.net>
[-- Attachment #1: Type: text/plain, Size: 16941 bytes --]
On 10/23/2014 09:09 PM, Mike Galbraith wrote:
> On Thu, 2014-10-23 at 13:23 -0500, Larry Finger wrote:
>
>> I know "rtl8192se:rtl92se_get_desc(): ERR rxdesc :4 not process" messages will
>> be fixed by the attached patch. Please send the logs after this is applied.
>
> Both applied.
>
> [ 17.717226] cfg80211: World regulatory domain updated:
> [ 17.719760] cfg80211: DFS Master region: unset
> [ 17.719801] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
> [ 17.724656] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A)
> [ 17.727087] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A)
> [ 17.729422] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm), (N/A)
> [ 17.731592] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A)
> [ 17.733702] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm), (N/A)
> [ 17.858132] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/sound/card0/hdaudioC0D0/input13
> [ 17.861052] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input14
> [ 17.863153] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input15
> [ 17.865356] input: HDA Intel HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input16
> [ 18.259078] toshiba_acpi: Unknown key 401
> [ 18.661507] Adding 2096476k swap on /dev/sda2. Priority:-1 extents:1 across:2096476k FS
> [ 18.984217] rtl8192se 0000:08:00.0: enabling device (0000 -> 0003)
> [ 19.025036] rtl8192se: FW Power Save off (module option)
> [ 19.027195] rtl8192se: Driver for Realtek RTL8192SE/RTL8191SE
> [ 19.027195] Loading firmware rtlwifi/rtl8192sefw.bin
> [ 19.095134] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
> [ 19.152305] ------------[ cut here ]------------
> [ 19.154367] WARNING: CPU: 0 PID: 59 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x68/0x80()
> [ 19.156445] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:1c.5/0000:08:00.0/ieee80211/phy0'
> [ 19.158562] Modules linked in: arc4 rtl8192se rtl_pci rtlwifi mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic uvcvideo btusb videobuf2_core coretemp snd_hda_intel snd_hda_controller snd_hda_codec iTCO_wdt iTCO_vendor_support bluetooth cfg80211 v4l2_common snd_hwdep microcode snd_pcm videodev lpc_ich snd_seq serio_raw snd_timer joydev i2c_i801 videobuf2_vmalloc videobuf2_memops mfd_core snd_seq_device toshiba_acpi sparse_keymap rfkill battery ac snd wmi toshiba_bluetooth toshiba_haps soundcore acpi_cpufreq sg autofs4 i915 drm_kms_helper drm i2c_algo_bit thermal video processor thermal_sys button scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh netconsole atl1c
> [ 19.170633] CPU: 0 PID: 59 Comm: kworker/0:3 Not tainted 3.18.0-master #52
> [ 19.173036] Hardware name: TOSHIBA ��������������������������������/��������������������������������, BIOS V1.70 09/29/2009
> [ 19.175634] Workqueue: events request_firmware_work_func
> [ 19.178247] 0000000000000009 ffff8800379d7a98 ffffffff815878e0 0000000000000001
> [ 19.180947] ffff8800379d7ae8 ffff8800379d7ad8 ffffffff8104c801 00000000000035e0
> [ 19.183573] ffff88003706e000 ffff8800aff86d80 ffff8800b0093d48 ffff88013b027098
> [ 19.186231] Call Trace:
> [ 19.188885] [<ffffffff815878e0>] dump_stack+0x46/0x58
> [ 19.191545] [<ffffffff8104c801>] warn_slowpath_common+0x81/0xa0
> [ 19.194173] [<ffffffff8104c866>] warn_slowpath_fmt+0x46/0x50
> [ 19.196707] [<ffffffff811d06c8>] ? kernfs_path+0x48/0x60
> [ 19.199138] [<ffffffff811d3b48>] sysfs_warn_dup+0x68/0x80
> [ 19.201587] [<ffffffff811d3bee>] sysfs_create_dir_ns+0x8e/0xa0
> [ 19.204057] [<ffffffff81286879>] kobject_add_internal+0xc9/0x400
> [ 19.206495] [<ffffffff81286fe0>] kobject_add+0x60/0xb0
> [ 19.208938] [<ffffffff8158c226>] ? mutex_lock+0x16/0x37
> [ 19.211321] [<ffffffff81380d54>] device_add+0x104/0x600
> [ 19.213692] [<ffffffff8114b98e>] ? lazy_max_pages+0x1e/0x30
> [ 19.216100] [<ffffffffa02e9d0d>] wiphy_register+0x3fd/0x710 [cfg80211]
> [ 19.218504] [<ffffffff8114d352>] ? __vunmap+0xc2/0x110
> [ 19.220957] [<ffffffffa0457cfc>] ? ieee80211_register_hw+0x1ec/0x9a0 [mac80211]
> [ 19.223447] [<ffffffffa0457e78>] ieee80211_register_hw+0x368/0x9a0 [mac80211]
> [ 19.225916] [<ffffffffa050a26b>] rtl92se_fw_cb+0xab/0x1d0 [rtl8192se]
> [ 19.228362] [<ffffffff81393d80>] request_firmware_work_func+0x30/0x60
> [ 19.230779] [<ffffffff8106270d>] process_one_work+0x14d/0x3d0
> [ 19.233167] [<ffffffff81062ab1>] worker_thread+0x121/0x480
> [ 19.235498] [<ffffffff81062990>] ? process_one_work+0x3d0/0x3d0
> [ 19.237861] [<ffffffff81067319>] kthread+0xc9/0xe0
> [ 19.240213] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 19.242534] [<ffffffff8158e26c>] ret_from_fork+0x7c/0xb0
> [ 19.244830] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 19.247125] ---[ end trace 0734244a9269eff8 ]---
> [ 19.249416] ------------[ cut here ]------------
> [ 19.251626] WARNING: CPU: 0 PID: 59 at lib/kobject.c:240 kobject_add_internal+0x294/0x400()
> [ 19.253876] kobject_add_internal failed for phy0 with -EEXIST, don't try to register things with the same name in the same directory.
> [ 19.256197] Modules linked in: arc4 rtl8192se rtl_pci rtlwifi mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic uvcvideo btusb videobuf2_core coretemp snd_hda_intel snd_hda_controller snd_hda_codec iTCO_wdt iTCO_vendor_support bluetooth cfg80211 v4l2_common snd_hwdep microcode snd_pcm videodev lpc_ich snd_seq serio_raw snd_timer joydev i2c_i801 videobuf2_vmalloc videobuf2_memops mfd_core snd_seq_device toshiba_acpi sparse_keymap rfkill battery ac snd wmi toshiba_bluetooth toshiba_haps soundcore acpi_cpufreq sg autofs4 i915 drm_kms_helper drm i2c_algo_bit thermal video processor thermal_sys button scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh netconsole atl1c
> [ 19.269327] CPU: 0 PID: 59 Comm: kworker/0:3 Tainted: G W 3.18.0-master #52
> [ 19.271976] Hardware name: TOSHIBA ��������������������������������/��������������������������������, BIOS V1.70 09/29/2009
> [ 19.274674] Workqueue: events request_firmware_work_func
> [ 19.277301] 0000000000000009 ffff8800379d7af8 ffffffff815878e0 0000000000000001
> [ 19.279875] ffff8800379d7b48 ffff8800379d7b38 ffffffff8104c801 ffff8800379d7b38
> [ 19.282376] ffff880137730350 00000000ffffffef ffff880036a9c940 ffff88013b027098
> [ 19.284844] Call Trace:
> [ 19.287151] [<ffffffff815878e0>] dump_stack+0x46/0x58
> [ 19.289474] [<ffffffff8104c801>] warn_slowpath_common+0x81/0xa0
> [ 19.291751] [<ffffffff8104c866>] warn_slowpath_fmt+0x46/0x50
> [ 19.293979] [<ffffffff81286a44>] kobject_add_internal+0x294/0x400
> [ 19.296192] [<ffffffff81286fe0>] kobject_add+0x60/0xb0
> [ 19.298381] [<ffffffff8158c226>] ? mutex_lock+0x16/0x37
> [ 19.300578] [<ffffffff81380d54>] device_add+0x104/0x600
> [ 19.302734] [<ffffffff8114b98e>] ? lazy_max_pages+0x1e/0x30
> [ 19.304909] [<ffffffffa02e9d0d>] wiphy_register+0x3fd/0x710 [cfg80211]
> [ 19.307110] [<ffffffff8114d352>] ? __vunmap+0xc2/0x110
> [ 19.309305] [<ffffffffa0457cfc>] ? ieee80211_register_hw+0x1ec/0x9a0 [mac80211]
> [ 19.311512] [<ffffffffa0457e78>] ieee80211_register_hw+0x368/0x9a0 [mac80211]
> [ 19.313767] [<ffffffffa050a26b>] rtl92se_fw_cb+0xab/0x1d0 [rtl8192se]
> [ 19.315998] [<ffffffff81393d80>] request_firmware_work_func+0x30/0x60
> [ 19.318260] [<ffffffff8106270d>] process_one_work+0x14d/0x3d0
> [ 19.320501] [<ffffffff81062ab1>] worker_thread+0x121/0x480
> [ 19.322732] [<ffffffff81062990>] ? process_one_work+0x3d0/0x3d0
> [ 19.324987] [<ffffffff81067319>] kthread+0xc9/0xe0
> [ 19.327246] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 19.329517] [<ffffffff8158e26c>] ret_from_fork+0x7c/0xb0
> [ 19.331757] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 19.334039] ---[ end trace 0734244a9269eff9 ]---
> [ 19.336275] rtl8192se:rtl92se_fw_cb():<0-0> Can't register mac80211 hw
> [ 20.108822] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: acl
> [ 24.761182] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 24.762764] IP: [< (null)>] (null)
> [ 24.764106] PGD 0
> [ 24.764106] Oops: 0010 [#1] SMP
> [ 24.764106] Modules linked in: arc4 rtl8192se rtl_pci rtlwifi mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic uvcvideo btusb videobuf2_core coretemp snd_hda_intel snd_hda_controller snd_hda_codec iTCO_wdt iTCO_vendor_support bluetooth cfg80211 v4l2_common snd_hwdep microcode snd_pcm videodev lpc_ich snd_seq serio_raw snd_timer joydev i2c_i801 videobuf2_vmalloc videobuf2_memops mfd_core snd_seq_device toshiba_acpi sparse_keymap rfkill battery ac snd wmi toshiba_bluetooth toshiba_haps soundcore acpi_cpufreq sg autofs4 i915 drm_kms_helper drm i2c_algo_bit thermal video processor thermal_sys button scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh netconsole atl1c
> [ 24.764106] CPU: 1 PID: 54 Comm: kworker/1:2 Tainted: G W 3.18.0-master #52
> [ 24.764106] Hardware name: TOSHIBA ��������������������������������/��������������������������������, BIOS V1.70 09/29/2009
> [ 24.764106] Workqueue: rtl92s_pci rtl_watchdog_wq_callback [rtlwifi]
> [ 24.764106] task: ffff88013614c350 ti: ffff880136150000 task.ti: ffff880136150000
> [ 24.764106] RIP: 0010:[<0000000000000000>] [< (null)>] (null)
> [ 24.764106] RSP: 0018:ffff880136153d80 EFLAGS: 00010293
> [ 24.764106] RAX: ffffffffa05103c0 RBX: ffff8801377319c0 RCX: 0000000000000000
> [ 24.764106] RDX: 0000000000000001 RSI: 000000000000005d RDI: ffff880137730620
> [ 24.764106] RBP: ffff880136153df8 R08: ffff88013fd12380 R09: 0000000000000001
> [ 24.764106] R10: 0000000000000002 R11: 0000000000000293 R12: ffff880137730620
> [ 24.764106] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> [ 24.764106] FS: 0000000000000000(0000) GS:ffff88013fd00000(0000) knlGS:0000000000000000
> [ 24.764106] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 24.764106] CR2: 0000000000000000 CR3: 000000013b249000 CR4: 00000000000407e0
> [ 24.764106] Stack:
> [ 24.764106] ffffffffa051e51e ffff88013fd12b00 0000000000000000 ffff88013fd12b00
> [ 24.764106] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> [ 24.764106] 0000000000000000 ffff880136153e38 ffff880137731be0 ffff880136126b80
> [ 24.764106] Call Trace:
> [ 24.764106] [<ffffffffa051e51e>] ? rtl_watchdog_wq_callback+0xfe/0x420 [rtlwifi]
> [ 24.764106] [<ffffffff8106270d>] process_one_work+0x14d/0x3d0
> [ 24.764106] [<ffffffff81062ab1>] worker_thread+0x121/0x480
> [ 24.764106] [<ffffffff81062990>] ? process_one_work+0x3d0/0x3d0
> [ 24.764106] [<ffffffff81067319>] kthread+0xc9/0xe0
> [ 24.764106] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 24.764106] [<ffffffff8158e26c>] ret_from_fork+0x7c/0xb0
> [ 24.764106] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 24.764106] Code: Bad RIP value.
> [ 24.764106] RIP [< (null)>] (null)
> [ 24.764106] RSP <ffff880136153d80>
> [ 24.764106] CR2: 0000000000000000
> [ 24.764106] ---[ end trace 0734244a9269effa ]---
> [ 24.855146] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 24.857620] BUG: unable to handle kernel paging request at ffffffffffffffd8
> [ 24.859873] IP: [<ffffffff810678f1>] kthread_data+0x11/0x20
> [ 24.861381] PGD 1a16067 PUD 1a18067 PMD 0
> [ 24.861381] Oops: 0000 [#2] SMP
> [ 24.861381] Modules linked in: arc4 rtl8192se rtl_pci rtlwifi mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic uvcvideo btusb videobuf2_core coretemp snd_hda_intel snd_hda_controller snd_hda_codec iTCO_wdt iTCO_vendor_support bluetooth cfg80211 v4l2_common snd_hwdep microcode snd_pcm videodev lpc_ich snd_seq serio_raw snd_timer joydev i2c_i801 videobuf2_vmalloc videobuf2_memops mfd_core snd_seq_device toshiba_acpi sparse_keymap rfkill battery ac snd wmi toshiba_bluetooth toshiba_haps soundcore acpi_cpufreq sg autofs4 i915 drm_kms_helper drm i2c_algo_bit thermal video processor thermal_sys button scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh netconsole atl1c
> [ 24.861381] CPU: 1 PID: 54 Comm: kworker/1:2 Tainted: G D W 3.18.0-master #52
> [ 24.861381] Hardware name: TOSHIBA ��������������������������������/��������������������������������, BIOS V1.70 09/29/2009
> [ 24.861381] task: ffff88013614c350 ti: ffff880136150000 task.ti: ffff880136150000
> [ 24.861381] RIP: 0010:[<ffffffff810678f1>] [<ffffffff810678f1>] kthread_data+0x11/0x20
> [ 24.861381] RSP: 0018:ffff880136153990 EFLAGS: 00010092
> [ 24.861381] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000171a414dc
> [ 24.861381] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff88013614c350
> [ 24.861381] RBP: ffff8801361539a8 R08: ffff88013614fcd0 R09: 00000000000003d9
> [ 24.861381] R10: 000000000000bc00 R11: 0000000000008ddc R12: ffff88013fd12b00
> [ 24.861381] R13: 0000000000000001 R14: 0000000000000000 R15: ffff88013614c350
> [ 24.861381] FS: 0000000000000000(0000) GS:ffff88013fd00000(0000) knlGS:0000000000000000
> [ 24.861381] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 24.861381] CR2: 0000000000000028 CR3: 0000000035eba000 CR4: 00000000000407e0
> [ 24.861381] Stack:
> [ 24.861381] ffffffff81063145 ffff8801361539a8 ffff88013614c350 ffff880136153a18
> [ 24.861381] ffffffff8158a1ae ffff88013614c350 0000000000012b00 ffff880136153fd8
> [ 24.861381] 0000000000012b00 ffff880136153a08 ffff88013614c350 ffff88013614c350
> [ 24.861381] Call Trace:
> [ 24.861381] [<ffffffff81063145>] ? wq_worker_sleeping+0x15/0xa0
> [ 24.861381] [<ffffffff8158a1ae>] __schedule+0x53e/0x810
> [ 24.861381] [<ffffffff8158a4a9>] schedule+0x29/0x70
> [ 24.861381] [<ffffffff8104dfa2>] do_exit+0x6a2/0x9e0
> [ 24.861381] [<ffffffff8100645e>] oops_end+0x8e/0xd0
> [ 24.861381] [<ffffffff815829aa>] no_context+0x248/0x298
> [ 24.861381] [<ffffffff81582a67>] __bad_area_nosemaphore+0x6d/0x1c6
> [ 24.861381] [<ffffffff81582bd3>] bad_area_nosemaphore+0x13/0x15
> [ 24.861381] [<ffffffff8103d67c>] __do_page_fault+0x9c/0x530
> [ 24.861381] [<ffffffff812843c0>] ? cpumask_next_and+0x30/0x50
> [ 24.861381] [<ffffffff8107a24e>] ? load_balance+0x23e/0x830
> [ 24.861381] [<ffffffff8103db1c>] do_page_fault+0xc/0x10
> [ 24.861381] [<ffffffff8158fe22>] page_fault+0x22/0x30
> [ 24.861381] [<ffffffffa051e51e>] ? rtl_watchdog_wq_callback+0xfe/0x420 [rtlwifi]
> [ 24.861381] [<ffffffff8106270d>] process_one_work+0x14d/0x3d0
> [ 24.861381] [<ffffffff81062ab1>] worker_thread+0x121/0x480
> [ 24.861381] [<ffffffff81062990>] ? process_one_work+0x3d0/0x3d0
> [ 24.861381] [<ffffffff81067319>] kthread+0xc9/0xe0
> [ 24.861381] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 24.861381] [<ffffffff8158e26c>] ret_from_fork+0x7c/0xb0
> [ 24.861381] [<ffffffff81067250>] ? kthread_create_on_node+0x180/0x180
> [ 24.861381] Code: 48 89 e5 5d 48 8b 40 c8 48 c1 e8 02 83 e0 01 c3 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 48 8b 87 60 04 00 00 55 48 89 e5 5d <48> 8b 40 d8 c3 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55
> [ 24.861381] RIP [<ffffffff810678f1>] kthread_data+0x11/0x20
> [ 24.861381] RSP <ffff880136153990>
> [ 24.861381] CR2: ffffffffffffffd8
> [ 24.861381] ---[ end trace 0734244a9269effb ]---
> [ 24.861381] Fixing recursive fault but reboot is needed!
> [ 24.861381] Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 1
> [ 24.861381] Shutting down cpus with NMI
> [ 24.861381] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
> [ 24.861381] drm_kms_helper: panic occurred, switching back to text console
> [ 24.861381] Rebooting in 60 seconds..
Please try the attached patch. It replaces the second one I sent you. I will
probably redo it before submitting the final copy, but this should work.
Larry
[-- Attachment #2: fix_missing_desc --]
[-- Type: text/plain, Size: 6864 bytes --]
diff --git a/drivers/net/wireless/rtlwifi/base.c b/drivers/net/wireless/rtlwifi/base.c
index 58ba718..a23ff78 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -1234,7 +1234,8 @@ EXPORT_SYMBOL_GPL(rtl_action_proc);
static void setup_arp_tx(struct rtl_priv *rtlpriv, struct rtl_ps_ctl *ppsc)
{
rtlpriv->ra.is_special_data = true;
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_special_packet_notify(
rtlpriv, 1);
rtlpriv->enter_ps = false;
@@ -1629,7 +1630,8 @@ void rtl_watchdog_wq_callback(void *data)
}
}
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_periodical(rtlpriv);
rtlpriv->link_info.bcn_rx_inperiod = 0;
diff --git a/drivers/net/wireless/rtlwifi/core.c b/drivers/net/wireless/rtlwifi/core.c
index f6179bc..686d256 100644
--- a/drivers/net/wireless/rtlwifi/core.c
+++ b/drivers/net/wireless/rtlwifi/core.c
@@ -1133,7 +1133,8 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw *hw,
ppsc->report_linked = (mstatus == RT_MEDIA_CONNECT) ?
true : false;
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_mediastatus_notify(
rtlpriv, mstatus);
}
@@ -1373,7 +1374,8 @@ static void rtl_op_sw_scan_start(struct ieee80211_hw *hw)
return;
}
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_scan_notify(rtlpriv, 1);
if (rtlpriv->dm.supp_phymode_switch) {
@@ -1425,7 +1427,8 @@ static void rtl_op_sw_scan_complete(struct ieee80211_hw *hw)
}
rtlpriv->cfg->ops->scan_operation_backup(hw, SCAN_OPT_RESTORE);
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_scan_notify(rtlpriv, 0);
}
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index 25daa87..ed3364d 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -1833,7 +1833,8 @@ static void rtl_pci_stop(struct ieee80211_hw *hw)
unsigned long flags;
u8 RFInProgressTimeOut = 0;
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_halt_notify();
/*
diff --git a/drivers/net/wireless/rtlwifi/ps.c b/drivers/net/wireless/rtlwifi/ps.c
index b69321d..2278af9 100644
--- a/drivers/net/wireless/rtlwifi/ps.c
+++ b/drivers/net/wireless/rtlwifi/ps.c
@@ -261,7 +261,8 @@ void rtl_ips_nic_off_wq_callback(void *data)
ppsc->in_powersavemode = true;
/* call before RF off */
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_ips_notify(rtlpriv,
ppsc->inactive_pwrstate);
@@ -306,7 +307,8 @@ void rtl_ips_nic_on(struct ieee80211_hw *hw)
ppsc->in_powersavemode = false;
_rtl_ps_inactive_ps(hw);
/* call after RF on */
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_ips_notify(rtlpriv,
ppsc->inactive_pwrstate);
}
@@ -390,14 +392,16 @@ void rtl_lps_set_psmode(struct ieee80211_hw *hw, u8 rt_psmode)
if (ppsc->p2p_ps_info.opp_ps)
rtl_p2p_ps_cmd(hw , P2P_PS_ENABLE);
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_lps_notify(rtlpriv, rt_psmode);
} else {
if (rtl_get_fwlps_doze(hw)) {
RT_TRACE(rtlpriv, COMP_RF, DBG_DMESG,
"FW LPS enter ps_mode:%x\n",
ppsc->fwctrl_psmode);
- if (rtlpriv->cfg->ops->get_btc_status())
+ if (rtlpriv->cfg->ops->get_btc_status &&
+ rtlpriv->cfg->ops->get_btc_status())
rtlpriv->btcoexist.btc_ops->btc_lps_notify(rtlpriv, rt_psmode);
enter_fwlps = true;
ppsc->pwr_mode = ppsc->fwctrl_psmode;
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/def.h b/drivers/net/wireless/rtlwifi/rtl8192se/def.h
index 83c9867..593646e 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/def.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/def.h
@@ -453,6 +453,9 @@
GET_RX_STATUS_DESC_RX_MCS(_pdesc) == DESC92_RATE5_5M ||\
GET_RX_STATUS_DESC_RX_MCS(_pdesc) == DESC92_RATE11M)
+#define GET_RX_STATUS_DESC_BUFF_ADDR(__pdesc) \
+ SHIFT_AND_MASK_LE(__pdesc + 24, 0, 32)
+
enum rf_optype {
RF_OP_BY_SW_3WIRE = 0,
RF_OP_BY_FW,
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
index 1bff2a0..aa99d97 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/sw.c
@@ -87,11 +87,8 @@ static void rtl92s_init_aspm_vars(struct ieee80211_hw *hw)
static void rtl92se_fw_cb(const struct firmware *firmware, void *context)
{
struct ieee80211_hw *hw = context;
- struct rtl_pci_priv *pcipriv = rtl_pcipriv(hw);
struct rtl_priv *rtlpriv = rtl_priv(hw);
- struct rtl_pci *rtlpci = rtl_pcidev(pcipriv);
struct rt_firmware *pfirmware = NULL;
- int err;
RT_TRACE(rtlpriv, COMP_ERR, DBG_LOUD,
"Firmware callback routine entered!\n");
@@ -112,20 +109,6 @@ static void rtl92se_fw_cb(const struct firmware *firmware, void *context)
memcpy(pfirmware->sz_fw_tmpbuffer, firmware->data, firmware->size);
pfirmware->sz_fw_tmpbufferlen = firmware->size;
release_firmware(firmware);
-
- err = ieee80211_register_hw(hw);
- if (err) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
- "Can't register mac80211 hw\n");
- return;
- } else {
- rtlpriv->mac80211.mac80211_registered = 1;
- }
- rtlpci->irq_alloc = 1;
- set_bit(RTL_STATUS_INTERFACE_START, &rtlpriv->status);
-
- /*init rfkill */
- rtl_init_rfkill(hw);
}
static int rtl92s_init_sw_vars(struct ieee80211_hw *hw)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
index b358ebc..672fd3b 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
@@ -640,6 +640,9 @@ u32 rtl92se_get_desc(u8 *desc, bool istx, u8 desc_name)
case HW_DESC_RXPKT_LEN:
ret = GET_RX_STATUS_DESC_PKT_LEN(desc);
break;
+ case HW_DESC_RXBUFF_ADDR:
+ ret = GET_RX_STATUS_DESC_BUFF_ADDR(desc);
+ break;
default:
RT_ASSERT(false, "ERR rxdesc :%d not process\n",
desc_name);
^ permalink raw reply related
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Paul E. McKenney @ 2014-10-24 16:54 UTC (permalink / raw)
To: Yanko Kaneti
Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev,
Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos
In-Reply-To: <20141024162943.GA16621@declera.com>
On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote:
> On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote:
> > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote:
> > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote:
> > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
> > > > >
> > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
> > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
[ . . . ]
> > > Ok, unless I've messsed up something major, bisecting points to:
> > >
> > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
> > >
> > > Makes any sense ?
> >
> > Good question. ;-)
> >
> > Are any of your online CPUs missing rcuo kthreads? There should be
> > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU.
>
> Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8
> and the modprobe ppp_generic testcase reliably works, libvirt also manages
> to setup its bridge.
>
> Just with linux-tip , the rcuos are 6 but the failure is as reliable as
> before.
Thank you, very interesting. Which 6 of the rcuos are present?
> Awating instructions: :)
Well, I thought I understood the problem until you found that only 6 of
the expected 8 rcuos are present with linux-tip without the revert. ;-)
I am putting together a patch for the part of the problem that I think
I understand, of course, but it would help a lot to know which two of
the rcuos are missing. ;-)
Thanx, Paul
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Yanko Kaneti @ 2014-10-24 17:09 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev,
Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos
In-Reply-To: <20141024165454.GS4977@linux.vnet.ibm.com>
On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote:
> On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote:
> > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote:
> > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote:
> > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote:
> > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
> > > > > >
> > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
> > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
>
> [ . . . ]
>
> > > > Ok, unless I've messsed up something major, bisecting points to:
> > > >
> > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
> > > >
> > > > Makes any sense ?
> > >
> > > Good question. ;-)
> > >
> > > Are any of your online CPUs missing rcuo kthreads? There should be
> > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU.
> >
> > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8
> > and the modprobe ppp_generic testcase reliably works, libvirt also manages
> > to setup its bridge.
> >
> > Just with linux-tip , the rcuos are 6 but the failure is as reliable as
> > before.
> Thank you, very interesting. Which 6 of the rcuos are present?
Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this
Phenom II.
> > Awating instructions: :)
>
> Well, I thought I understood the problem until you found that only 6 of
> the expected 8 rcuos are present with linux-tip without the revert. ;-)
>
> I am putting together a patch for the part of the problem that I think
> I understand, of course, but it would help a lot to know which two of
> the rcuos are missing. ;-)
>
Ready to test
--Yanko
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Paul E. McKenney @ 2014-10-24 17:20 UTC (permalink / raw)
To: Yanko Kaneti
Cc: Josh Boyer, Eric W. Biederman, Cong Wang, Kevin Fenzi, netdev,
Linux-Kernel@Vger. Kernel. Org, jay.vosburgh, mroos
In-Reply-To: <20141024170931.GA21849@declera.com>
On Fri, Oct 24, 2014 at 08:09:31PM +0300, Yanko Kaneti wrote:
> On Fri-10/24/14-2014 09:54, Paul E. McKenney wrote:
> > On Fri, Oct 24, 2014 at 07:29:43PM +0300, Yanko Kaneti wrote:
> > > On Fri-10/24/14-2014 08:40, Paul E. McKenney wrote:
> > > > On Fri, Oct 24, 2014 at 12:08:57PM +0300, Yanko Kaneti wrote:
> > > > > On Thu-10/23/14-2014 15:04, Paul E. McKenney wrote:
> > > > > > On Fri, Oct 24, 2014 at 12:45:40AM +0300, Yanko Kaneti wrote:
> > > > > > >
> > > > > > > On Thu, 2014-10-23 at 13:05 -0700, Paul E. McKenney wrote:
> > > > > > > > On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
> >
> > [ . . . ]
> >
> > > > > Ok, unless I've messsed up something major, bisecting points to:
> > > > >
> > > > > 35ce7f29a44a rcu: Create rcuo kthreads only for onlined CPUs
> > > > >
> > > > > Makes any sense ?
> > > >
> > > > Good question. ;-)
> > > >
> > > > Are any of your online CPUs missing rcuo kthreads? There should be
> > > > kthreads named rcuos/0, rcuos/1, rcuos/2, and so on for each online CPU.
> > >
> > > Its a Phenom II X6. With 3.17 and linux-tip with 35ce7f29a44a reverted, the rcuos are 8
> > > and the modprobe ppp_generic testcase reliably works, libvirt also manages
> > > to setup its bridge.
> > >
> > > Just with linux-tip , the rcuos are 6 but the failure is as reliable as
> > > before.
>
> > Thank you, very interesting. Which 6 of the rcuos are present?
>
> Well, the rcuos are 0 to 5. Which sounds right for a 6 core CPU like this
> Phenom II.
Ah, you get 8 without the patch because it creates them for potential
CPUs as well as real ones. OK, got it.
> > > Awating instructions: :)
> >
> > Well, I thought I understood the problem until you found that only 6 of
> > the expected 8 rcuos are present with linux-tip without the revert. ;-)
> >
> > I am putting together a patch for the part of the problem that I think
> > I understand, of course, but it would help a lot to know which two of
> > the rcuos are missing. ;-)
>
> Ready to test
Well, if you are feeling aggressive, give the following patch a spin.
I am doing sanity tests on it in the meantime.
Thanx, Paul
------------------------------------------------------------------------
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 29fb23f33c18..927c17b081c7 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -2546,9 +2546,13 @@ static void rcu_spawn_one_nocb_kthread(struct rcu_state *rsp, int cpu)
rdp->nocb_leader = rdp_spawn;
if (rdp_last && rdp != rdp_spawn)
rdp_last->nocb_next_follower = rdp;
- rdp_last = rdp;
- rdp = rdp->nocb_next_follower;
- rdp_last->nocb_next_follower = NULL;
+ if (rdp == rdp_spawn) {
+ rdp = rdp->nocb_next_follower;
+ } else {
+ rdp_last = rdp;
+ rdp = rdp->nocb_next_follower;
+ rdp_last->nocb_next_follower = NULL;
+ }
} while (rdp);
rdp_spawn->nocb_next_follower = rdp_old_leader;
}
^ permalink raw reply related
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