* Re: [PATCH] net: orphan queued skbs if device tx can stall
From: Herbert Xu @ 2012-04-09 7:33 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, linux-kernel, David S. Miller, Jamal Hadi Salim,
Stephen Hemminger, Jason Wang, Neil Horman, Jiri Pirko,
Jeff Kirsher, Eric Dumazet, Michał Mirosław,
Ben Hutchings
In-Reply-To: <20120409072849.GA12014@redhat.com>
On Mon, Apr 09, 2012 at 10:28:49AM +0300, Michael S. Tsirkin wrote:
>
> > 1) Doesn't this break local UDP push-back?
>
> What is meant by UDP pushback here? Two tap
> devices communicating by UDP packets locally?
> This was always broken, see below.
I mean push-back from UDP transmission to the physical NIC.
Your patch breaks that as now the guest will have no push-back
whatsoever so anything that transmits UDP without protocol-level
congestion control will start dropping most of their packets.
Granted you can argue that these apps are broken, but they do
exist and we've always catered for them, both on baremetal and
under virtualisation.
> Thus we get this situation
> tap1 sends packets, some of them to tap2, tap2 does not consume them,
> as a result tap2 queue overflows, tap2 stops forever and
> packets get queued in the qdisc, now tap1
> send buffer gets full so it can not communicate to any destination.
>
> So the problem is one VM can block all networking from another one.
This should be addressed in the backend, as it can distinguish
between packets going out to physical and packets stuck going to
a local VM. In the latter case you can then duplicate and release
the sender's memory.
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] net: orphan queued skbs if device tx can stall
From: Michael S. Tsirkin @ 2012-04-09 7:39 UTC (permalink / raw)
To: Herbert Xu
Cc: netdev, linux-kernel, David S. Miller, Jamal Hadi Salim,
Stephen Hemminger, Jason Wang, Neil Horman, Jiri Pirko,
Jeff Kirsher, Eric Dumazet, Michał Mirosław,
Ben Hutchings
In-Reply-To: <20120409073354.GA3218@gondor.apana.org.au>
On Mon, Apr 09, 2012 at 03:33:54PM +0800, Herbert Xu wrote:
> On Mon, Apr 09, 2012 at 10:28:49AM +0300, Michael S. Tsirkin wrote:
> >
> > > 1) Doesn't this break local UDP push-back?
> >
> > What is meant by UDP pushback here? Two tap
> > devices communicating by UDP packets locally?
> > This was always broken, see below.
>
> I mean push-back from UDP transmission to the physical NIC.
>
> Your patch breaks that
I think there's some misunderstanding. pushback is only disabled
for destinations that set IFF_TX_CAN_STALL. I expect that
no physical NICs set this flag - only tun and possibly
other userspace-controlled devices in the future.
> as now the guest will have no push-back
> whatsoever so anything that transmits UDP without protocol-level
> congestion control will start dropping most of their packets.
>
> Granted you can argue that these apps are broken, but they do
> exist and we've always catered for them, both on baremetal and
> under virtualisation.
> > Thus we get this situation
> > tap1 sends packets, some of them to tap2, tap2 does not consume them,
> > as a result tap2 queue overflows, tap2 stops forever and
> > packets get queued in the qdisc, now tap1
> > send buffer gets full so it can not communicate to any destination.
> >
> > So the problem is one VM can block all networking from another one.
>
> This should be addressed in the backend, as it can distinguish
> between packets going out to physical and packets stuck going to
> a local VM.
Sorry I still have no clue what you call a backend.
Could you clarify please? All packets from a tun device
go to userspace.
> In the latter case you can then duplicate and release
> the sender's memory.
>
> Cheers,
The problem this patch is trying to address is tun device
can get stopped forever, which causes packets to
accumulate in qdisc again forever. So tun does not
get a chance to release sender's memory for these packets.
> --
> 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] net: orphan queued skbs if device tx can stall
From: Herbert Xu @ 2012-04-09 8:29 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, linux-kernel, David S. Miller, Jamal Hadi Salim,
Stephen Hemminger, Jason Wang, Neil Horman, Jiri Pirko,
Jeff Kirsher, Eric Dumazet, Michał Mirosław,
Ben Hutchings
In-Reply-To: <20120409073953.GD12014@redhat.com>
On Mon, Apr 09, 2012 at 10:39:54AM +0300, Michael S. Tsirkin wrote:
> On Mon, Apr 09, 2012 at 03:33:54PM +0800, Herbert Xu wrote:
> > On Mon, Apr 09, 2012 at 10:28:49AM +0300, Michael S. Tsirkin wrote:
> > >
> > > > 1) Doesn't this break local UDP push-back?
> > >
> > > What is meant by UDP pushback here? Two tap
> > > devices communicating by UDP packets locally?
> > > This was always broken, see below.
> >
> > I mean push-back from UDP transmission to the physical NIC.
> >
> > Your patch breaks that
>
> I think there's some misunderstanding. pushback is only disabled
> for destinations that set IFF_TX_CAN_STALL. I expect that
> no physical NICs set this flag - only tun and possibly
> other userspace-controlled devices in the future.
I'm talking about an app running in the guest transmitting UDP
to the physical NIC via virtio/vhost. This will break with your
patch.
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] net: orphan queued skbs if device tx can stall
From: Michael S. Tsirkin @ 2012-04-09 8:34 UTC (permalink / raw)
To: Herbert Xu
Cc: netdev, linux-kernel, David S. Miller, Jamal Hadi Salim,
Stephen Hemminger, Jason Wang, Neil Horman, Jiri Pirko,
Jeff Kirsher, Eric Dumazet, Michał Mirosław,
Ben Hutchings
In-Reply-To: <20120409082919.GA3471@gondor.apana.org.au>
On Mon, Apr 09, 2012 at 04:29:20PM +0800, Herbert Xu wrote:
> On Mon, Apr 09, 2012 at 10:39:54AM +0300, Michael S. Tsirkin wrote:
> > On Mon, Apr 09, 2012 at 03:33:54PM +0800, Herbert Xu wrote:
> > > On Mon, Apr 09, 2012 at 10:28:49AM +0300, Michael S. Tsirkin wrote:
> > > >
> > > > > 1) Doesn't this break local UDP push-back?
> > > >
> > > > What is meant by UDP pushback here? Two tap
> > > > devices communicating by UDP packets locally?
> > > > This was always broken, see below.
> > >
> > > I mean push-back from UDP transmission to the physical NIC.
> > >
> > > Your patch breaks that
> >
> > I think there's some misunderstanding. pushback is only disabled
> > for destinations that set IFF_TX_CAN_STALL. I expect that
> > no physical NICs set this flag - only tun and possibly
> > other userspace-controlled devices in the future.
>
> I'm talking about an app running in the guest transmitting UDP
> to the physical NIC via virtio/vhost. This will break with your
> patch.
>
> Cheers,
Puzzled. This patch orphans skbs only if the destination device sets
IFF_TX_CAN_STALL. Since the physical NIC doesn't stall forever it never
sets this flag.
So it seems that this patch should not affect the configuration
you describe at all.
Could you please clarify? What did I miss?
> --
> 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] net: orphan queued skbs if device tx can stall
From: Herbert Xu @ 2012-04-09 8:39 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, linux-kernel, David S. Miller, Jamal Hadi Salim,
Stephen Hemminger, Jason Wang, Neil Horman, Jiri Pirko,
Jeff Kirsher, Eric Dumazet, Michał Mirosław,
Ben Hutchings
In-Reply-To: <20120409083402.GA28249@redhat.com>
On Mon, Apr 09, 2012 at 11:34:02AM +0300, Michael S. Tsirkin wrote:
>
> Puzzled. This patch orphans skbs only if the destination device sets
> IFF_TX_CAN_STALL. Since the physical NIC doesn't stall forever it never
> sets this flag.
>
> So it seems that this patch should not affect the configuration
> you describe at all.
>
> Could you please clarify? What did I miss?
Oops, you're right. Somehow I was thinking you were patching
virtio-net instead of tun.
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
* [PATCH] net/key/af_key.c: add missing kfree_skb
From: Julia Lawall @ 2012-04-09 8:41 UTC (permalink / raw)
To: David S. Miller; +Cc: kernel-janitors, netdev, linux-kernel
From: Julia Lawall <Julia.Lawall@lip6.fr>
At the point of this error-handling code, alloc_skb has succeded, so free
the resulting skb by jumping to the err label.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
net/key/af_key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 11dbb22..7e5d927 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3480,7 +3480,7 @@ static int pfkey_send_migrate(const struct xfrm_selector *sel, u8 dir, u8 type,
/* Addresses to be used by KM for negotiation, if ext is available */
if (k != NULL && (set_sadb_kmaddress(skb, k) < 0))
- return -EINVAL;
+ goto err;
/* selector src */
set_sadb_address(skb, sasize_sel, SADB_EXT_ADDRESS_SRC, sel);
^ permalink raw reply related
* Re: [PATCH] net: orphan queued skbs if device tx can stall
From: Michael S. Tsirkin @ 2012-04-09 8:42 UTC (permalink / raw)
To: Herbert Xu
Cc: netdev, linux-kernel, David S. Miller, Jamal Hadi Salim,
Stephen Hemminger, Jason Wang, Neil Horman, Jiri Pirko,
Jeff Kirsher, Eric Dumazet, Michał Mirosław,
Ben Hutchings
In-Reply-To: <20120409083958.GA3951@gondor.apana.org.au>
On Mon, Apr 09, 2012 at 04:39:58PM +0800, Herbert Xu wrote:
> On Mon, Apr 09, 2012 at 11:34:02AM +0300, Michael S. Tsirkin wrote:
> >
> > Puzzled. This patch orphans skbs only if the destination device sets
> > IFF_TX_CAN_STALL. Since the physical NIC doesn't stall forever it never
> > sets this flag.
> >
> > So it seems that this patch should not affect the configuration
> > you describe at all.
> >
> > Could you please clarify? What did I miss?
>
> Oops, you're right. Somehow I was thinking you were patching
> virtio-net instead of tun.
>
> Cheers,
Cool. Want to ack the patch then just to make it clear you are happy?
> --
> 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: [RFC] API to modify /proc/sys/net/ipv4/ip_local_reserved_ports
From: Cong Wang @ 2012-04-09 8:43 UTC (permalink / raw)
To: Helge Deller
Cc: Octavian Purdila, netdev, David Miller, Andrew Morton,
Eric W. Biederman, Frank Danapfel, Laszlo Ersek, shemminger
In-Reply-To: <4F7CADE8.3060205@gmx.de>
On Wed, 2012-04-04 at 22:24 +0200, Helge Deller wrote:
> I would like to follow up on my last patch series to be able to modify
> the contents of the /proc/sys/net/ipv4/ip_local_reserved_ports port list
> from userspace.
>
> My last patch (https://lkml.org/lkml/2012/3/10/187) was based on
> modifications to the proc interface, which - based on the feedback here
> on the list - seemed to not be the right way to go (although I personally
> still like the idea very much :-)).
>
> Anyway, with this RFC I would like to get feedback about a new proposed
> API and attached kernel patch.
>
> The idea is to introduce a new <optname> value for get/setsockopt()
> named SO_RESERVED_PORTS to get/set the ip_local_reserved_ports
> bitmap via standard get/setsockopt() syscalls.
> As far as I understand this seems to be similiar to how iptables works.
>
> An untested kernel patch for review and feedback is attached below.
>
> In userspace it then would be possible to write a new tool or to extend
> for example the "ip" tool to accept commands like:
> $> ip reserved_ports add 100-2000
> $> ip reserved_ports remove 50-60
> $> ip reserved_ports list (to show current reserved port list)
>
> This userspace tool could then read the port bitmap from kernel via
> a) socket(PF_INET, SOCK_RAW, IPPROTO_RAW)
> b) getsockopt(3, SOL_SOCKET, SO_RESERVED_PORTS, <bitmaplist>)
> and write back the results after modification via
> c) setsockopt(3, SOL_SOCKET, SO_RESERVED_PORTS, <bitmaplist>)
>
> Would that be an acceptable solution?
Hmm, it is indeed that bitmap fits for syscall rather than /proc file.
But it seems that using getsockopt()/setsockopt() makes it like it is a
per-socket setting, actually it is a system-wide setting. So I am
wondering if exporting a binary /proc file for this is a better
solution.
Thanks.
^ permalink raw reply
* [PATCH] net/wireless/wext-core.c: add missing kfree
From: Julia Lawall @ 2012-04-09 9:01 UTC (permalink / raw)
To: John W. Linville
Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
From: Julia Lawall <Julia.Lawall-L2FTfq7BK8M@public.gmane.org>
Free extra as done in the error-handling code just above.
Signed-off-by: Julia Lawall <Julia.Lawall-L2FTfq7BK8M@public.gmane.org>
---
net/wireless/wext-core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
index 9f544c9..22adfeb 100644
--- a/net/wireless/wext-core.c
+++ b/net/wireless/wext-core.c
@@ -781,8 +781,10 @@ static int ioctl_standard_iw_point(struct iw_point *iwp, unsigned int cmd,
if (cmd == SIOCSIWENCODEEXT) {
struct iw_encode_ext *ee = (void *) extra;
- if (iwp->length < sizeof(*ee) + ee->key_len)
- return -EFAULT;
+ if (iwp->length < sizeof(*ee) + ee->key_len) {
+ err = -EFAULT;
+ goto out;
+ }
}
}
--
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] net: orphan queued skbs if device tx can stall
From: Eric Dumazet @ 2012-04-09 9:13 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Herbert Xu, netdev, linux-kernel, David S. Miller,
Jamal Hadi Salim, Stephen Hemminger, Jason Wang, Neil Horman,
Jiri Pirko, Jeff Kirsher, Michał Mirosław,
Ben Hutchings
In-Reply-To: <20120409084208.GA28362@redhat.com>
On Mon, 2012-04-09 at 11:42 +0300, Michael S. Tsirkin wrote:
> On Mon, Apr 09, 2012 at 04:39:58PM +0800, Herbert Xu wrote:
> > On Mon, Apr 09, 2012 at 11:34:02AM +0300, Michael S. Tsirkin wrote:
> > >
> > > Puzzled. This patch orphans skbs only if the destination device sets
> > > IFF_TX_CAN_STALL. Since the physical NIC doesn't stall forever it never
> > > sets this flag.
> > >
> > > So it seems that this patch should not affect the configuration
> > > you describe at all.
> > >
> > > Could you please clarify? What did I miss?
> >
> > Oops, you're right. Somehow I was thinking you were patching
> > virtio-net instead of tun.
> >
> > Cheers,
>
> Cool. Want to ack the patch then just to make it clear you are happy?
I am not happy with this patch.
Since its Easter, I dont have much time to comment right now, I'll do
that tomorrow.
^ permalink raw reply
* [PATCH] skbuff: struct ubuf_info callback type safety
From: Michael S. Tsirkin @ 2012-04-09 10:24 UTC (permalink / raw)
To: linux-kernel, kvm, virtualization, netdev
Cc: Shirley Ma, Stephen Hemminger, David S. Miller, Eric Dumazet,
Ian Campbell
The skb struct ubuf_info callback gets passed struct ubuf_info
itself, not the arg value as the field name and the function signature
seem to imply. Rename the arg field to ctx to match usage,
add documentation and change the callback argument type
to make usage clear and to have compiler check correctness.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/vhost/net.c | 2 +-
drivers/vhost/vhost.c | 5 ++---
drivers/vhost/vhost.h | 2 +-
include/linux/skbuff.h | 7 ++++---
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index f0da2c3..1f21d2a 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -238,7 +238,7 @@ static void handle_tx(struct vhost_net *net)
vq->heads[vq->upend_idx].len = len;
ubuf->callback = vhost_zerocopy_callback;
- ubuf->arg = vq->ubufs;
+ ubuf->ctx = vq->ubufs;
ubuf->desc = vq->upend_idx;
msg.msg_control = ubuf;
msg.msg_controllen = sizeof(ubuf);
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 947f00d..51e4c1e 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1598,10 +1598,9 @@ void vhost_ubuf_put_and_wait(struct vhost_ubuf_ref *ubufs)
kfree(ubufs);
}
-void vhost_zerocopy_callback(void *arg)
+void vhost_zerocopy_callback(struct ubuf_info *ubuf)
{
- struct ubuf_info *ubuf = arg;
- struct vhost_ubuf_ref *ubufs = ubuf->arg;
+ struct vhost_ubuf_ref *ubufs = ubuf->ctx;
struct vhost_virtqueue *vq = ubufs->vq;
/* set len = 1 to mark this desc buffers done DMA */
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 8dcf4cc..8de1fd5 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -188,7 +188,7 @@ bool vhost_enable_notify(struct vhost_dev *, struct vhost_virtqueue *);
int vhost_log_write(struct vhost_virtqueue *vq, struct vhost_log *log,
unsigned int log_num, u64 len);
-void vhost_zerocopy_callback(void *arg);
+void vhost_zerocopy_callback(struct ubuf_info *);
int vhost_zerocopy_signal_used(struct vhost_virtqueue *vq);
#define vq_err(vq, fmt, ...) do { \
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 3337027..4c3f138 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -238,11 +238,12 @@ enum {
/*
* The callback notifies userspace to release buffers when skb DMA is done in
* lower device, the skb last reference should be 0 when calling this.
- * The desc is used to track userspace buffer index.
+ * The ctx field is used to track device context.
+ * The desc field is used to track userspace buffer index.
*/
struct ubuf_info {
- void (*callback)(void *);
- void *arg;
+ void (*callback)(struct ubuf_info *);
+ void *ctx;
unsigned long desc;
};
--
1.7.9.111.gf3fb0
^ permalink raw reply related
* [PATCH] davinci_emac: Add cpu_freq support
From: Manjunathappa, Prakash @ 2012-04-09 10:49 UTC (permalink / raw)
To: netdev
Cc: davem, linux-kernel, davinci-linux-open-source,
Manjunathappa, Prakash
Reconfigure interrupt coalesce parameter for changed emac bus_freq
due to DVFS.
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
---
drivers/net/ethernet/ti/davinci_emac.c | 60 ++++++++++++++++++++++++++++++++
1 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 174a334..11d3bd7 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -50,6 +50,7 @@
#include <linux/ctype.h>
#include <linux/spinlock.h>
#include <linux/dma-mapping.h>
+#include <linux/cpufreq.h>
#include <linux/clk.h>
#include <linux/platform_device.h>
#include <linux/semaphore.h>
@@ -344,6 +345,9 @@ struct emac_priv {
/*platform specific members*/
void (*int_enable) (void);
void (*int_disable) (void);
+#ifdef CONFIG_CPU_FREQ
+ struct notifier_block freq_transition;
+#endif
};
/* clock frequency for EMAC */
@@ -1761,6 +1765,46 @@ static const struct net_device_ops emac_netdev_ops = {
#endif
};
+#ifdef CONFIG_CPU_FREQ
+static int davinci_emac_cpufreq_transition(struct notifier_block *nb,
+ unsigned long val, void *data)
+{
+ int ret = 0;
+ struct emac_priv *priv;
+
+ priv = container_of(nb, struct emac_priv, freq_transition);
+ if (priv->coal_intvl != 0) {
+ if (val == CPUFREQ_POSTCHANGE) {
+ if (emac_bus_frequency != clk_get_rate(emac_clk)) {
+ struct ethtool_coalesce coal;
+
+ emac_bus_frequency = clk_get_rate(emac_clk);
+
+ priv->bus_freq_mhz = (u32)(emac_bus_frequency /
+ 1000000);
+ coal.rx_coalesce_usecs = (priv->coal_intvl
+ << 4);
+ ret = emac_set_coalesce(priv->ndev, &coal);
+ }
+ }
+ }
+ return ret;
+}
+
+static inline int davinci_emac_cpufreq_register(struct emac_priv *priv)
+{
+ priv->freq_transition.notifier_call = davinci_emac_cpufreq_transition;
+ return cpufreq_register_notifier(&priv->freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+
+static inline void davinci_emac_cpufreq_deregister(struct emac_priv *priv)
+{
+ cpufreq_unregister_notifier(&priv->freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+#endif
+
/**
* davinci_emac_probe: EMAC device probe
* @pdev: The DaVinci EMAC device that we are removing
@@ -1925,8 +1969,21 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
"(regs: %p, irq: %d)\n",
(void *)priv->emac_base_phys, ndev->irq);
}
+
+#ifdef CONFIG_CPU_FREQ
+ rc = davinci_emac_cpufreq_register(priv);
+ if (rc) {
+ dev_err(&pdev->dev, "error in register_netdev\n");
+ rc = -ENODEV;
+ goto cpufreq_reg_err;
+ }
+#endif
return 0;
+#ifdef CONFIG_CPU_FREQ
+cpufreq_reg_err:
+ unregister_netdev(ndev);
+#endif
netdev_reg_err:
clk_disable(emac_clk);
no_irq_res:
@@ -1973,6 +2030,9 @@ static int __devexit davinci_emac_remove(struct platform_device *pdev)
release_mem_region(res->start, resource_size(res));
+#ifdef CONFIG_CPU_FREQ
+ davinci_emac_cpufreq_deregister(priv);
+#endif
unregister_netdev(ndev);
iounmap(priv->remap_addr);
free_netdev(ndev);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] davinci_emac: Add cpu_freq support
From: Sergei Shtylyov @ 2012-04-09 11:29 UTC (permalink / raw)
To: Manjunathappa, Prakash
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1333968549-3282-1-git-send-email-prakash.pm-l0cyMroinI0@public.gmane.org>
Hello.
On 09-04-2012 14:49, Manjunathappa, Prakash wrote:
> Reconfigure interrupt coalesce parameter for changed emac bus_freq
> due to DVFS.
> Signed-off-by: Manjunathappa, Prakash<prakash.pm-l0cyMroinI0@public.gmane.org>
> ---
> drivers/net/ethernet/ti/davinci_emac.c | 60 ++++++++++++++++++++++++++++++++
> 1 files changed, 60 insertions(+), 0 deletions(-)
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
> index 174a334..11d3bd7 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
[...]
> @@ -1761,6 +1765,46 @@ static const struct net_device_ops emac_netdev_ops = {
> #endif
> };
>
> +#ifdef CONFIG_CPU_FREQ
> +static int davinci_emac_cpufreq_transition(struct notifier_block *nb,
> + unsigned long val, void *data)
> +{
> + int ret = 0;
> + struct emac_priv *priv;
> +
> + priv = container_of(nb, struct emac_priv, freq_transition);
> + if (priv->coal_intvl != 0) {
> + if (val == CPUFREQ_POSTCHANGE) {
> + if (emac_bus_frequency != clk_get_rate(emac_clk)) {
These 3 *if*s could be collapsed into one, and so indentation level
lowered significantly.
> + struct ethtool_coalesce coal;
> +
> + emac_bus_frequency = clk_get_rate(emac_clk);
> +
> + priv->bus_freq_mhz = (u32)(emac_bus_frequency /
> + 1000000);
> + coal.rx_coalesce_usecs = (priv->coal_intvl
> + << 4);
> + ret = emac_set_coalesce(priv->ndev,&coal);
> + }
> + }
> + }
> + return ret;
> +}
> +
> +static inline int davinci_emac_cpufreq_register(struct emac_priv *priv)
> +{
> + priv->freq_transition.notifier_call = davinci_emac_cpufreq_transition;
> + return cpufreq_register_notifier(&priv->freq_transition,
> + CPUFREQ_TRANSITION_NOTIFIER);
> +}
> +
> +static inline void davinci_emac_cpufreq_deregister(struct emac_priv *priv)
> +{
> + cpufreq_unregister_notifier(&priv->freq_transition,
> + CPUFREQ_TRANSITION_NOTIFIER);
> +}
> +#endif
> +
> /**
> * davinci_emac_probe: EMAC device probe
> * @pdev: The DaVinci EMAC device that we are removing
> @@ -1925,8 +1969,21 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
> "(regs: %p, irq: %d)\n",
> (void *)priv->emac_base_phys, ndev->irq);
> }
> +
> +#ifdef CONFIG_CPU_FREQ
> + rc = davinci_emac_cpufreq_register(priv);
> + if (rc) {
> + dev_err(&pdev->dev, "error in register_netdev\n");
Really?
> + rc = -ENODEV;
> + goto cpufreq_reg_err;
> + }
> +#endif
> return 0;
>
> +#ifdef CONFIG_CPU_FREQ
> +cpufreq_reg_err:
> + unregister_netdev(ndev);
> +#endif
> netdev_reg_err:
> clk_disable(emac_clk);
> no_irq_res:
> @@ -1973,6 +2030,9 @@ static int __devexit davinci_emac_remove(struct platform_device *pdev)
>
> release_mem_region(res->start, resource_size(res));
>
> +#ifdef CONFIG_CPU_FREQ
> + davinci_emac_cpufreq_deregister(priv);
> +#endif
This is considered a bad practice to use #ifdef in the body of function.
Define the faunction you call here as empty inline in case CONFIG_CPU_FREQ is
not defined instead. The same about davinci_emac_cpufreq_register().
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 6/6] tilegx network driver: initial support
From: Arnd Bergmann @ 2012-04-09 13:49 UTC (permalink / raw)
To: Chris Metcalf; +Cc: linux-kernel, netdev
In-Reply-To: <201204062101.q36L1uCi011406@farm-0027.internal.tilera.com>
On Friday 06 April 2012, Chris Metcalf wrote:
> This change adds support for the tilegx network driver based on the
> GXIO IORPC support in the tilegx software stack, using the on-chip
> mPIPE packet processing engine.
>
> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
> ---
> drivers/net/ethernet/tile/Kconfig | 1 +
> drivers/net/ethernet/tile/Makefile | 4 +-
> drivers/net/ethernet/tile/tilegx.c | 2045 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 2048 insertions(+), 2 deletions(-)
> create mode 100644 drivers/net/ethernet/tile/tilegx.c
I think the directory name should be the company, not the architecture here, so make
it drivers/net/ethernet/tilera/tilegx.c instead.
> +
> +MODULE_AUTHOR("Tilera");
> +MODULE_LICENSE("GPL");
> +
MODULE_AUTHOR is normally a real person with an email address.
> +/* Statistics counters for a specific cpu and device. */
> +struct tile_net_stats_t {
> + u32 rx_packets;
> + u32 rx_bytes;
> + u32 tx_packets;
> + u32 tx_bytes;
> +};
I think you need to drop the _t postfix here, which presumably comes
from converting it from a typedef.
> +
> +/* The actual devices. */
> +static struct net_device *tile_net_devs[TILE_NET_DEVS];
> +
> +/* The device for a given channel. HACK: We use "32", not
> + * TILE_NET_CHANNELS, because it is fairly subtle that the 5 bit
> + * "idesc.channel" field never exceeds TILE_NET_CHANNELS.
> + */
> +static struct net_device *tile_net_devs_for_channel[32];
When you need to keep a list or array of device structures in a driver, you're
usually doing something very wrong. The convention is to just pass the pointer
around to where you need it.
> +
> +/* Convert a "buffer ptr" into a "buffer cpa". */
> +static inline void *buf_to_cpa(void *buf)
> +{
> + return (void *)__pa(buf);
> +}
> +
> +
> +/* Convert a "buffer cpa" into a "buffer ptr". */
> +static inline void *cpa_to_buf(void *cpa)
> +{
> + return (void *)__va(cpa);
> +}
This is almost certainly wrong: The type returned by __pa is a phys_addr_t,
which cannot be dereferenced like a pointer. On normal drivers, you would
use dma_map_single()/dma_unmap_single() to get a token that can get
passed into a dma engine. From what I can tell, this device is directly mapped,
while your PCI uses an IOMMU, so that would require two different
implementations of dma mapping operations.
> +/* Allocate and push a buffer. */
> +static bool tile_net_provide_buffer(bool small)
> +{
> + int stack = small ? small_buffer_stack : large_buffer_stack;
> +
> + /* Buffers must be aligned. */
> + const unsigned long align = 128;
> +
> + /* Note that "dev_alloc_skb()" adds NET_SKB_PAD more bytes,
> + * and also "reserves" that many bytes.
> + */
> + int len = sizeof(struct sk_buff **) + align + (small ? 128 : 1664);
> +
> + /* Allocate (or fail). */
> + struct sk_buff *skb = dev_alloc_skb(len);
> + if (skb == NULL)
> + return false;
> +
> + /* Make room for a back-pointer to 'skb'. */
> + skb_reserve(skb, sizeof(struct sk_buff **));
> +
> + /* Make sure we are aligned. */
> + skb_reserve(skb, -(long)skb->data & (align - 1));
> +
> + /* Save a back-pointer to 'skb'. */
> + *(struct sk_buff **)(skb->data - sizeof(struct sk_buff **)) = skb;
This looks very wrong: why would you put the pointer to the skb into the
skb itself?
> + /* Make sure "skb" and the back-pointer have been flushed. */
> + __insn_mf();
Try to use archicture independent names for flush operations like this
to make it more readable. I assume this should be smp_wmb()?
> +
> + /* Compute the "ip checksum". */
> + jsum = isum_hack + htons(s_len - eh_len) + htons(id);
> + jsum = __insn_v2sadu(jsum, 0);
> + jsum = __insn_v2sadu(jsum, 0);
> + jsum = (0xFFFF ^ jsum);
> + jh->check = jsum;
> +
> + /* Update the tcp "seq". */
> + uh->seq = htonl(seq);
> +
> + /* Update some flags. */
> + if (!final)
> + uh->fin = uh->psh = 0;
> +
> + /* Compute the tcp pseudo-header checksum. */
> + usum = tsum_hack + htons(s_len);
> + usum = __insn_v2sadu(usum, 0);
> + usum = __insn_v2sadu(usum, 0);
> + uh->check = usum;
Why to you open-code the ip checksum functions here? Normally the stack takes
care of this by calling the functions you already provide in
arch/tile/lib/checksum.c
Arnd
^ permalink raw reply
* [PATCH] net/garp: fix GID rbtree ordering
From: David Ward @ 2012-04-09 14:13 UTC (permalink / raw)
To: netdev; +Cc: Jorge Boncompte [DTI2], David Ward
The comparison operators were backwards in both garp_attr_lookup and
garp_attr_create, so the entire GID rbtree was in reverse order.
(There was no practical side effect to this though, except that PDUs
were sent with attributes listed in reverse order, which is still
valid by the protocol. This change is only for clarity.)
Signed-off-by: David Ward <david.ward@ll.mit.edu>
---
net/802/garp.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/802/garp.c b/net/802/garp.c
index a5c2248..8456f5d 100644
--- a/net/802/garp.c
+++ b/net/802/garp.c
@@ -157,9 +157,9 @@ static struct garp_attr *garp_attr_lookup(const struct garp_applicant *app,
while (parent) {
attr = rb_entry(parent, struct garp_attr, node);
d = garp_attr_cmp(attr, data, len, type);
- if (d < 0)
+ if (d > 0)
parent = parent->rb_left;
- else if (d > 0)
+ else if (d < 0)
parent = parent->rb_right;
else
return attr;
@@ -178,9 +178,9 @@ static struct garp_attr *garp_attr_create(struct garp_applicant *app,
parent = *p;
attr = rb_entry(parent, struct garp_attr, node);
d = garp_attr_cmp(attr, data, len, type);
- if (d < 0)
+ if (d > 0)
p = &parent->rb_left;
- else if (d > 0)
+ else if (d < 0)
p = &parent->rb_right;
else {
/* The attribute already exists; re-use it. */
--
1.7.4.1
^ permalink raw reply related
* [PATCH]Fix misplaces parenthesis in virtio_net.c
From: Torsten Kaiser @ 2012-04-09 15:14 UTC (permalink / raw)
To: David Miller, Rick Jones; +Cc: netdev, linux-kernel
Commit 2e57b79ccef1ff1422fdf45a9b28fe60f8f084f7 misplaced its
parenthesis and now tx_fifo_errors will only be incremented if an
ENOMEM error is not written to the syslog.
Correct the parenthesis and indentation to the original goal of
counting all non ENOMEM errors and ratelimiting only the messages.
Signed-of-by: Torsten Kaiser <just.for.lkml@googlemail.com>
--- a/drivers/net/virtio_net.c 2012-04-09 16:55:31.366847092 +0200
+++ b/drivers/net/virtio_net.c 2012-04-09 16:56:31.196847799 +0200
@@ -626,16 +626,15 @@
/* This can happen with OOM and indirect buffers. */
if (unlikely(capacity < 0)) {
if (likely(capacity == -ENOMEM)) {
- if (net_ratelimit()) {
+ if (net_ratelimit())
dev_warn(&dev->dev,
"TX queue failure: out of memory\n");
- } else {
+ } else {
dev->stats.tx_fifo_errors++;
if (net_ratelimit())
dev_warn(&dev->dev,
"Unexpected TX queue failure: %d\n",
capacity);
- }
}
dev->stats.tx_dropped++;
kfree_skb(skb);
^ permalink raw reply
* Re: [PATCH] davinci_emac: Add cpu_freq support
From: Ben Hutchings @ 2012-04-09 15:56 UTC (permalink / raw)
To: Manjunathappa, Prakash
Cc: netdev, davem, linux-kernel, davinci-linux-open-source
In-Reply-To: <1333968549-3282-1-git-send-email-prakash.pm@ti.com>
On Mon, 2012-04-09 at 16:19 +0530, Manjunathappa, Prakash wrote:
> Reconfigure interrupt coalesce parameter for changed emac bus_freq
> due to DVFS.
>
> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
> ---
> drivers/net/ethernet/ti/davinci_emac.c | 60 ++++++++++++++++++++++++++++++++
> 1 files changed, 60 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
> index 174a334..11d3bd7 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
> @@ -50,6 +50,7 @@
> #include <linux/ctype.h>
> #include <linux/spinlock.h>
> #include <linux/dma-mapping.h>
> +#include <linux/cpufreq.h>
> #include <linux/clk.h>
> #include <linux/platform_device.h>
> #include <linux/semaphore.h>
> @@ -344,6 +345,9 @@ struct emac_priv {
> /*platform specific members*/
> void (*int_enable) (void);
> void (*int_disable) (void);
> +#ifdef CONFIG_CPU_FREQ
> + struct notifier_block freq_transition;
> +#endif
> };
>
> /* clock frequency for EMAC */
> @@ -1761,6 +1765,46 @@ static const struct net_device_ops emac_netdev_ops = {
> #endif
> };
>
> +#ifdef CONFIG_CPU_FREQ
> +static int davinci_emac_cpufreq_transition(struct notifier_block *nb,
> + unsigned long val, void *data)
> +{
> + int ret = 0;
> + struct emac_priv *priv;
> +
> + priv = container_of(nb, struct emac_priv, freq_transition);
> + if (priv->coal_intvl != 0) {
> + if (val == CPUFREQ_POSTCHANGE) {
> + if (emac_bus_frequency != clk_get_rate(emac_clk)) {
> + struct ethtool_coalesce coal;
> +
> + emac_bus_frequency = clk_get_rate(emac_clk);
> +
> + priv->bus_freq_mhz = (u32)(emac_bus_frequency /
> + 1000000);
> + coal.rx_coalesce_usecs = (priv->coal_intvl
> + << 4);
> + ret = emac_set_coalesce(priv->ndev, &coal);
[...]
Ick. Why don't you break up emac_set_coalesce() so that you can push
this one value to the hardware without faking up a struct
ethtool_coalesce? Don't you need to push it on reset/resume anyway?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: 3.2.8/amd64 full interrupt hangs and deadlocks under big network copies (page allocation failure)
From: Marc MERLIN @ 2012-04-09 17:20 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linux-wireless, netdev
In-Reply-To: <1333044575.2656.1.camel@bwh-desktop.uk.solarflarecom.com>
On Thu, Mar 29, 2012 at 07:09:35PM +0100, Ben Hutchings wrote:
> On Thu, 2012-03-29 at 09:38 -0700, Marc MERLIN wrote:
> [...]
> > Below are some sysreq dumps I took (syslog to local disk was still
> > working fine). I know I have Tainted 'G', and I have no idea where that
> > came from, sorry :-/
> [...]
>
> 'G' isn't a taint flag, but the following 'O' is; it means you have one
> or more out-of-tree modules loaded. Care to tell us what they are?
Ok, I just had time to reproduce this without tainting. It was with 3.2.5
though since I'm debugging a battery power use issue too.
I confirmed that the problem only happens when I do NFS copies. Doing the
same copy with rsync over SSH works fine.
I'm not much of a kernel guy, but it looks like there is a memory problem,
which in turn causes the network driver to deadlock waiting on RAM with
interrupts turned off (mouse cursor won't move). Eventually it gets a bit of
the special RAM it seems to need, at that point, my frozen mouse pointer
unfreezes until it locks again soon after.
So there are 2 problems
1) memory issue
2) driver waits for RAM with interrupts turned off
The log below shows offlineimap first getting memory allocation problems
as soon after I start the copy, then firefox, and some:
ieee80211 phy0: failed to reallocate TX buffer
No taint flags this time.
I'll paste a few lines below.
Any idea what's going on, what bucket of RAM is an issue for the driver
(total RAM is more than plenty), and where I should go from there?
kernel config: http://marc.merlins.org/tmp/config.txt
Thanks,
Marc
09:44:12 offlineimap: page allocation failure: order:1, mode:0x20
09:44:12 Pid: 6269, comm: offlineimap Tainted: G O 3.2.5amd64-volpreempt-noide-20120208 #1
09:44:12 Call Trace:
09:44:12 <IRQ> [<ffffffff810b755a>] ? warn_alloc_failed+0x11a/0x12d
09:44:12 [<ffffffff810ba394>] ? __alloc_pages_nodemask+0x6b2/0x726
09:44:12 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:12 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:12 [<ffffffff810ea421>] ? fallback_alloc+0x123/0x1c2
09:44:12 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:12 [<ffffffff810ea923>] ? __kmalloc+0xba/0x112
09:44:12 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:12 [<ffffffffa07a81c0>] ? ieee80211_skb_resize+0x64/0x9d [mac80211]
09:44:12 [<ffffffffa07aa087>] ? ieee80211_subif_start_xmit+0x68e/0x80c [mac80211]
09:44:12 [<ffffffffa07922c8>] ? ieee80211_tx_status_irqsafe+0x2e/0x7f [mac80211]
09:44:12 [<ffffffff812877f3>] ? dev_hard_start_xmit+0x3fc/0x543
09:44:12 [<ffffffff81070551>] ? arch_local_irq_save+0x11/0x17
09:44:12 [<ffffffff8129da01>] ? sch_direct_xmit+0x5e/0x12f
09:44:12 [<ffffffff8129dbc9>] ? __qdisc_run+0xf7/0x10f
09:44:12 [<ffffffff81282d56>] ? net_tx_action+0xf1/0x128
09:44:12 [<ffffffff8104bc88>] ? __do_softirq+0xb9/0x177
09:44:12 [<ffffffff81065863>] ? timekeeping_get_ns+0xd/0x2a
09:44:12 [<ffffffff81349dac>] ? call_softirq+0x1c/0x30
09:44:12 [<ffffffff8100f875>] ? do_softirq+0x3c/0x7b
09:44:12 [<ffffffff8104bef0>] ? irq_exit+0x3c/0x9a
09:44:12 [<ffffffff8100f5a5>] ? do_IRQ+0x82/0x98
09:44:12 [<ffffffff81342e2e>] ? common_interrupt+0x6e/0x6e
09:44:12 <EOI> [<ffffffff81061e33>] ? hrtimer_cancel+0xc/0x16
09:44:12 [<ffffffff8110629a>] ? select_estimate_accuracy+0xcf/0xed
09:44:12 [<ffffffff8110629a>] ? select_estimate_accuracy+0xcf/0xed
09:44:12 [<ffffffff81106464>] ? do_select+0x13c/0x46a
09:44:12 [<ffffffff81034a8c>] ? walk_tg_tree_from+0x70/0x99
09:44:12 [<ffffffff811060ab>] ? poll_freewait+0x97/0x97
09:44:12 [<ffffffff8103a520>] ? update_curr+0xd0/0xf5
09:44:12 [<ffffffff8100d758>] ? __switch_to+0x1fc/0x20e
09:44:12 [<ffffffff8103ac9c>] ? dequeue_entity+0x13e/0x161
09:44:12 [<ffffffff8103891c>] ? finish_task_switch+0x88/0xb9
09:44:12 [<ffffffff813417fc>] ? __schedule+0x5ac/0x5c3
09:44:12 [<ffffffff8106c902>] ? get_futex_value_locked+0x2d/0x3d
09:44:12 [<ffffffff810349f1>] ? set_task_rq+0x23/0x35
09:44:12 [<ffffffff81035ef0>] ? cpumask_next+0x17/0x1a
09:44:12 [<ffffffff8104073f>] ? select_task_rq_fair+0x435/0x67e
09:44:12 [<ffffffff8101353d>] ? paravirt_read_tsc+0x5/0x8
09:44:12 [<ffffffff81013999>] ? native_sched_clock+0x27/0x2f
09:44:12 [<ffffffff810139a6>] ? sched_clock+0x5/0x8
09:44:12 [<ffffffff810634b0>] ? sched_clock_local+0xd/0x6f
09:44:12 [<ffffffff81026aa4>] ? _flat_send_IPI_mask+0x68/0x78
09:44:12 [<ffffffff8103f175>] ? try_to_wake_up+0x187/0x196
09:44:12 [<ffffffff81106907>] ? core_sys_select+0x175/0x21a
09:44:12 [<ffffffff8106e85a>] ? do_futex+0xab/0x7ed
09:44:12 [<ffffffff8104afef>] ? timespec_add_safe+0x32/0x63
09:44:12 [<ffffffff81028a44>] ? read_hpet+0xd/0x10
09:44:12 [<ffffffff81065863>] ? timekeeping_get_ns+0xd/0x2a
09:44:12 [<ffffffff81106a34>] ? sys_select+0x88/0xad
09:44:12 [<ffffffff81347b52>] ? system_call_fastpath+0x16/0x1b
09:44:12 Mem-Info:
09:44:12 Node 0 DMA per-cpu:
09:44:12 CPU 0: hi: 0, btch: 1 usd: 0
09:44:12 CPU 1: hi: 0, btch: 1 usd: 0
09:44:12 Node 0 DMA32 per-cpu:
09:44:12 CPU 0: hi: 186, btch: 31 usd: 96
09:44:12 CPU 1: hi: 186, btch: 31 usd: 61
09:44:12 Node 0 Normal per-cpu:
09:44:12 CPU 0: hi: 186, btch: 31 usd: 178
09:44:12 CPU 1: hi: 186, btch: 31 usd: 37
09:44:12 active_anon:992922 inactive_anon:263416 isolated_anon:0
09:44:12 active_file:59734 inactive_file:529995 isolated_file:0
09:44:12 unevictable:1 dirty:52839 writeback:339893 unstable:7544
09:44:12 free:55501 slab_reclaimable:33311 slab_unreclaimable:30518
09:44:12 mapped:18500 shmem:43519 pagetables:21479 bounce:0
09:44:12 Node 0 DMA free:15908kB min:128kB low:160kB high:192kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15684kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
09:44:12 lowmem_reserve[]: 0 2960 7947 7947
09:44:12 Node 0 DMA32 free:153280kB min:25128kB low:31408kB high:37692kB active_anon:1579176kB inactive_anon:524080kB active_file:33708kB inactive_file:618072kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3031688kB mlocked:0kB dirty:81192kB writeback:322428kB mapped:6704kB shmem:67068kB slab_reclaimable:41408kB slab_unreclaimable:30268kB kernel_stack:2216kB pagetables:24408kB unstable:10048kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:12 lowmem_reserve[]: 0 0 4986 4986
09:44:12 Node 0 Normal free:52816kB min:42324kB low:52904kB high:63484kB active_anon:2392512kB inactive_anon:529584kB active_file:205228kB inactive_file:1501908kB unevictable:4kB isolated(anon):0kB isolated(file):0kB present:5106560kB mlocked:4kB dirty:130164kB writeback:1037144kB mapped:67296kB shmem:107008kB slab_reclaimable:91836kB slab_unreclaimable:91804kB kernel_stack:4216kB pagetables:61508kB unstable:20128kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:12 lowmem_reserve[]: 0 0 0 0
09:44:12 Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15908kB
09:44:12 Node 0 DMA32: 37156*4kB 0*8kB 1*16kB 1*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 1*4096kB = 153280kB
09:44:12 Node 0 Normal: 12180*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 52816kB
09:44:12 676507 total pagecache pages
09:44:12 43251 pages in swap cache
09:44:12 Swap cache stats: add 803319, delete 760068, find 297792/318561
09:44:12 Free swap = 1763732kB
09:44:12 Total swap = 4106248kB
09:44:12 2080752 pages RAM
09:44:12 57163 pages reserved
09:44:12 988140 pages shared
09:44:12 1496507 pages non-shared
09:44:12 ieee80211 phy0: failed to reallocate TX buffer
09:44:12 kworker/0:1: page allocation failure: order:1, mode:0x20
09:44:12 Pid: 8162, comm: kworker/0:1 Tainted: G O 3.2.5amd64-volpreempt-noide-20120208 #1
09:44:12 Call Trace:
09:44:12 <IRQ> [<ffffffff810b755a>] ? warn_alloc_failed+0x11a/0x12d
09:44:12 [<ffffffff810ba394>] ? __alloc_pages_nodemask+0x6b2/0x726
09:44:12 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:12 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:12 [<ffffffff810ea421>] ? fallback_alloc+0x123/0x1c2
09:44:12 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:12 [<ffffffff810ea923>] ? __kmalloc+0xba/0x112
09:44:12 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:12 [<ffffffffa07a81c0>] ? ieee80211_skb_resize+0x64/0x9d [mac80211]
09:44:12 [<ffffffffa07aa087>] ? ieee80211_subif_start_xmit+0x68e/0x80c [mac80211]
09:44:12 [<ffffffffa07922c8>] ? ieee80211_tx_status_irqsafe+0x2e/0x7f [mac80211]
09:44:12 [<ffffffff812877f3>] ? dev_hard_start_xmit+0x3fc/0x543
09:44:12 [<ffffffff81070551>] ? arch_local_irq_save+0x11/0x17
09:44:12 [<ffffffff8129da01>] ? sch_direct_xmit+0x5e/0x12f
09:44:12 [<ffffffff8129dbc9>] ? __qdisc_run+0xf7/0x10f
09:44:12 [<ffffffff81282d56>] ? net_tx_action+0xf1/0x128
09:44:12 [<ffffffff8104bc88>] ? __do_softirq+0xb9/0x177
09:44:12 [<ffffffff8103a946>] ? check_preempt_wakeup+0x10c/0x18e
09:44:12 [<ffffffff81349dac>] ? call_softirq+0x1c/0x30
09:44:12 [<ffffffff8100f875>] ? do_softirq+0x3c/0x7b
09:44:12 [<ffffffff8104bef0>] ? irq_exit+0x3c/0x9a
09:44:12 [<ffffffff8100f5a5>] ? do_IRQ+0x82/0x98
09:44:12 [<ffffffff81342e2e>] ? common_interrupt+0x6e/0x6e
09:44:12 <EOI> [<ffffffffa0089052>] ? dec128+0x15a/0x80c [aes_x86_64]
09:44:12 [<ffffffff8118f263>] ? crypto_cbc_decrypt_inplace.isra.4+0x84/0xef
09:44:12 [<ffffffffa06bb6ee>] ? decode_attr_time+0x2f/0x5d [nfs]
09:44:12 [<ffffffffa0089704>] ? dec128+0x80c/0x80c [aes_x86_64]
09:44:12 [<ffffffff8118f328>] ? crypto_cbc_decrypt+0x5a/0x10a
09:44:12 [<ffffffff8118756b>] ? async_decrypt+0x37/0x3c
09:44:12 [<ffffffffa0108df7>] ? crypt_convert+0x223/0x2b8 [dm_crypt]
09:44:12 [<ffffffffa0109185>] ? kcryptd_crypt+0x56/0x342 [dm_crypt]
09:44:12 [<ffffffffa010912f>] ? crypt_convert_init.isra.17+0x4f/0x4f [dm_crypt]
09:44:12 [<ffffffffa010912f>] ? crypt_convert_init.isra.17+0x4f/0x4f [dm_crypt]
09:44:12 [<ffffffffa010912f>] ? crypt_convert_init.isra.17+0x4f/0x4f [dm_crypt]
09:44:12 [<ffffffff8105ac3d>] ? process_one_work+0x163/0x284
09:44:12 [<ffffffff8105bc05>] ? worker_thread+0xc2/0x145
09:44:12 [<ffffffff8105bb43>] ? manage_workers.isra.23+0x15b/0x15b
09:44:12 [<ffffffff8105ed41>] ? kthread+0x76/0x7e
09:44:12 [<ffffffff81349cb4>] ? kernel_thread_helper+0x4/0x10
09:44:12 [<ffffffff8105eccb>] ? kthread_worker_fn+0x139/0x139
09:44:12 [<ffffffff81349cb0>] ? gs_change+0x13/0x13
09:44:12 Mem-Info:
09:44:12 Node 0 DMA per-cpu:
09:44:12 CPU 0: hi: 0, btch: 1 usd: 0
09:44:12 CPU 1: hi: 0, btch: 1 usd: 0
09:44:12 Node 0 DMA32 per-cpu:
09:44:12 CPU 0: hi: 186, btch: 31 usd: 77
09:44:12 CPU 1: hi: 186, btch: 31 usd: 53
09:44:12 Node 0 Normal per-cpu:
09:44:12 CPU 0: hi: 186, btch: 31 usd: 165
09:44:12 CPU 1: hi: 186, btch: 31 usd: 64
09:44:12 active_anon:992922 inactive_anon:263441 isolated_anon:0
09:44:12 active_file:59734 inactive_file:530249 isolated_file:0
09:44:12 unevictable:1 dirty:52950 writeback:339764 unstable:7673
09:44:12 free:55214 slab_reclaimable:33311 slab_unreclaimable:30507
09:44:12 mapped:18500 shmem:43519 pagetables:21479 bounce:0
09:44:12 Node 0 DMA free:15908kB min:128kB low:160kB high:192kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15684kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
09:44:12 lowmem_reserve[]: 0 2960 7947 7947
09:44:12 Node 0 DMA32 free:152124kB min:25128kB low:31408kB high:37692kB active_anon:1579176kB inactive_anon:524180kB active_file:33708kB inactive_file:618972kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3031688kB mlocked:0kB dirty:81636kB writeback:322428kB mapped:6704kB shmem:67068kB slab_reclaimable:41408kB slab_unreclaimable:30456kB kernel_stack:2216kB pagetables:24408kB unstable:10048kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:12 lowmem_reserve[]: 0 0 4986 4986
09:44:12 Node 0 Normal free:52824kB min:42324kB low:52904kB high:63484kB active_anon:2392512kB inactive_anon:529584kB active_file:205228kB inactive_file:1502024kB unevictable:4kB isolated(anon):0kB isolated(file):0kB present:5106560kB mlocked:4kB dirty:130164kB writeback:1036628kB mapped:67296kB shmem:107008kB slab_reclaimable:91836kB slab_unreclaimable:91572kB kernel_stack:4216kB pagetables:61508kB unstable:20644kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:12 lowmem_reserve[]: 0 0 0 0
09:44:12 Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15908kB
09:44:12 Node 0 DMA32: 36855*4kB 0*8kB 0*16kB 1*32kB 1*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 1*4096kB = 152124kB
09:44:12 Node 0 Normal: 12182*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 52824kB
09:44:12 676809 total pagecache pages
09:44:12 43260 pages in swap cache
09:44:12 Swap cache stats: add 803337, delete 760077, find 297801/318574
09:44:12 Free swap = 1763768kB
09:44:12 Total swap = 4106248kB
09:44:12 2080752 pages RAM
09:44:12 57163 pages reserved
09:44:12 988161 pages shared
09:44:12 1496613 pages non-shared
09:44:12 ieee80211 phy0: failed to reallocate TX buffer
09:44:13 firefox-bin: page allocation failure: order:1, mode:0x20
09:44:13 Pid: 6697, comm: firefox-bin Tainted: G O 3.2.5amd64-volpreempt-noide-20120208 #1
09:44:13 Call Trace:
09:44:13 <IRQ> [<ffffffff810b755a>] ? warn_alloc_failed+0x11a/0x12d
09:44:13 [<ffffffff810ba394>] ? __alloc_pages_nodemask+0x6b2/0x726
09:44:13 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:13 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:13 [<ffffffff810ea421>] ? fallback_alloc+0x123/0x1c2
09:44:13 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:13 [<ffffffff810ea923>] ? __kmalloc+0xba/0x112
09:44:13 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:13 [<ffffffffa07a81c0>] ? ieee80211_skb_resize+0x64/0x9d [mac80211]
09:44:13 [<ffffffffa07aa087>] ? ieee80211_subif_start_xmit+0x68e/0x80c [mac80211]
09:44:13 [<ffffffff812877f3>] ? dev_hard_start_xmit+0x3fc/0x543
09:44:13 [<ffffffff8129da01>] ? sch_direct_xmit+0x5e/0x12f
09:44:13 [<ffffffff8129dbc9>] ? __qdisc_run+0xf7/0x10f
09:44:13 [<ffffffff81282d56>] ? net_tx_action+0xf1/0x128
09:44:13 [<ffffffff8104bc88>] ? __do_softirq+0xb9/0x177
09:44:13 [<ffffffff8103a95f>] ? check_preempt_wakeup+0x125/0x18e
09:44:13 [<ffffffff81349dac>] ? call_softirq+0x1c/0x30
09:44:13 [<ffffffff8100f875>] ? do_softirq+0x3c/0x7b
09:44:13 [<ffffffff8104bef0>] ? irq_exit+0x3c/0x9a
09:44:13 [<ffffffff8100f5a5>] ? do_IRQ+0x82/0x98
09:44:13 [<ffffffff81342e2e>] ? common_interrupt+0x6e/0x6e
09:44:13 <EOI> [<ffffffff81347c84>] ? sysret_audit+0x16/0x20
09:44:13 Mem-Info:
09:44:13 Node 0 DMA per-cpu:
09:44:13 CPU 0: hi: 0, btch: 1 usd: 0
09:44:13 CPU 1: hi: 0, btch: 1 usd: 0
09:44:13 Node 0 DMA32 per-cpu:
09:44:13 CPU 0: hi: 186, btch: 31 usd: 78
09:44:13 CPU 1: hi: 186, btch: 31 usd: 66
09:44:13 Node 0 Normal per-cpu:
09:44:13 CPU 0: hi: 186, btch: 31 usd: 165
09:44:13 CPU 1: hi: 186, btch: 31 usd: 70
09:44:13 active_anon:992947 inactive_anon:263499 isolated_anon:0
09:44:13 active_file:59734 inactive_file:535571 isolated_file:0
09:44:13 unevictable:1 dirty:56763 writeback:339764 unstable:7673
09:44:13 free:49597 slab_reclaimable:33311 slab_unreclaimable:30582
09:44:13 mapped:18500 shmem:43562 pagetables:21479 bounce:0
09:44:13 Node 0 DMA free:15908kB min:128kB low:160kB high:192kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15684kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
09:44:13 lowmem_reserve[]: 0 2960 7947 7947
09:44:13 Node 0 DMA32 free:129656kB min:25128kB low:31408kB high:37692kB active_anon:1579276kB inactive_anon:524180kB active_file:33708kB inactive_file:640772kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3031688kB mlocked:0kB dirty:92588kB writeback:322428kB mapped:6704kB shmem:67068kB slab_reclaimable:41408kB slab_unreclaimable:30756kB kernel_stack:2216kB pagetables:24408kB unstable:10048kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:13 lowmem_reserve[]: 0 0 4986 4986
09:44:13 Node 0 Normal free:52824kB min:42324kB low:52904kB high:63484kB active_anon:2392512kB inactive_anon:529816kB active_file:205228kB inactive_file:1501512kB unevictable:4kB isolated(anon):0kB isolated(file):0kB present:5106560kB mlocked:4kB dirty:134464kB writeback:1036628kB mapped:67296kB shmem:107180kB slab_reclaimable:91836kB slab_unreclaimable:91572kB kernel_stack:4216kB pagetables:61508kB unstable:20644kB bounce:0kB writeback_tmp:0kB pages_scanned:1703 all_unreclaimable? no
09:44:13 lowmem_reserve[]: 0 0 0 0
09:44:13 Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15908kB
09:44:13 Node 0 DMA32: 31254*4kB 0*8kB 0*16kB 1*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 1*4096kB = 129656kB
09:44:13 Node 0 Normal: 12182*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 52824kB
09:44:13 682242 total pagecache pages
09:44:13 43259 pages in swap cache
09:44:13 Swap cache stats: add 803338, delete 760079, find 297802/318575
09:44:13 Free swap = 1763768kB
09:44:13 Total swap = 4106248kB
09:44:13 2080752 pages RAM
09:44:13 57163 pages reserved
09:44:13 992010 pages shared
09:44:13 1498343 pages non-shared
09:44:13 ieee80211 phy0: failed to reallocate TX buffer
09:44:13 firefox-bin: page allocation failure: order:1, mode:0x20
09:44:13 Pid: 6706, comm: firefox-bin Tainted: G O 3.2.5amd64-volpreempt-noide-20120208 #1
09:44:13 Call Trace:
09:44:13 <IRQ> [<ffffffff810b755a>] ? warn_alloc_failed+0x11a/0x12d
09:44:13 [<ffffffff810ba394>] ? __alloc_pages_nodemask+0x6b2/0x726
09:44:13 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:13 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:13 [<ffffffff810ea421>] ? fallback_alloc+0x123/0x1c2
09:44:13 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:13 [<ffffffff810ea923>] ? __kmalloc+0xba/0x112
09:44:13 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:13 [<ffffffffa07a81c0>] ? ieee80211_skb_resize+0x64/0x9d [mac80211]
09:44:13 [<ffffffffa07aa087>] ? ieee80211_subif_start_xmit+0x68e/0x80c [mac80211]
09:44:13 [<ffffffffa07922c8>] ? ieee80211_tx_status_irqsafe+0x2e/0x7f [mac80211]
09:44:13 [<ffffffff812877f3>] ? dev_hard_start_xmit+0x3fc/0x543
09:44:13 [<ffffffff81070551>] ? arch_local_irq_save+0x11/0x17
09:44:13 [<ffffffff8129da01>] ? sch_direct_xmit+0x5e/0x12f
09:44:13 [<ffffffff8129dbc9>] ? __qdisc_run+0xf7/0x10f
09:44:13 [<ffffffff81282d56>] ? net_tx_action+0xf1/0x128
09:44:13 [<ffffffff8104bc88>] ? __do_softirq+0xb9/0x177
09:44:13 [<ffffffff8106a67b>] ? clockevents_program_event+0xaa/0xce
09:44:13 [<ffffffff81349dac>] ? call_softirq+0x1c/0x30
09:44:13 [<ffffffff8100f875>] ? do_softirq+0x3c/0x7b
09:44:13 [<ffffffff8104bef0>] ? irq_exit+0x3c/0x9a
09:44:13 [<ffffffff8100f5a5>] ? do_IRQ+0x82/0x98
09:44:13 [<ffffffff81342e2e>] ? common_interrupt+0x6e/0x6e
09:44:13 <EOI> [<ffffffff81347c84>] ? sysret_audit+0x16/0x20
09:44:13 Mem-Info:
09:44:13 Node 0 DMA per-cpu:
09:44:13 CPU 0: hi: 0, btch: 1 usd: 0
09:44:13 CPU 1: hi: 0, btch: 1 usd: 0
09:44:13 Node 0 DMA32 per-cpu:
09:44:13 CPU 0: hi: 186, btch: 31 usd: 69
09:44:13 CPU 1: hi: 186, btch: 31 usd: 35
09:44:13 Node 0 Normal per-cpu:
09:44:13 CPU 0: hi: 186, btch: 31 usd: 178
09:44:13 CPU 1: hi: 186, btch: 31 usd: 68
09:44:13 active_anon:992947 inactive_anon:263499 isolated_anon:0
09:44:13 active_file:59734 inactive_file:536198 isolated_file:0
09:44:13 unevictable:1 dirty:57182 writeback:339764 unstable:7673
09:44:13 free:49028 slab_reclaimable:33311 slab_unreclaimable:30581
09:44:13 mapped:18500 shmem:43562 pagetables:21479 bounce:0
09:44:13 Node 0 DMA free:15908kB min:128kB low:160kB high:192kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15684kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
09:44:13 lowmem_reserve[]: 0 2960 7947 7947
09:44:13 Node 0 DMA32 free:127380kB min:25128kB low:31408kB high:37692kB active_anon:1579276kB inactive_anon:524180kB active_file:33708kB inactive_file:643272kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3031688kB mlocked:0kB dirty:93920kB writeback:322428kB mapped:6704kB shmem:67068kB slab_reclaimable:41408kB slab_unreclaimable:30752kB kernel_stack:2216kB pagetables:24408kB unstable:10048kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:13 lowmem_reserve[]: 0 0 4986 4986
09:44:13 Node 0 Normal free:52824kB min:42324kB low:52904kB high:63484kB active_anon:2392512kB inactive_anon:529816kB active_file:205228kB inactive_file:1501520kB unevictable:4kB isolated(anon):0kB isolated(file):0kB present:5106560kB mlocked:4kB dirty:134808kB writeback:1036628kB mapped:67296kB shmem:107180kB slab_reclaimable:91836kB slab_unreclaimable:91572kB kernel_stack:4216kB pagetables:61508kB unstable:20644kB bounce:0kB writeback_tmp:0kB pages_scanned:112 all_unreclaimable? no
09:44:13 lowmem_reserve[]: 0 0 0 0
09:44:13 Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15908kB
09:44:13 Node 0 DMA32: 30640*4kB 1*8kB 1*16kB 0*32kB 1*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 1*4096kB = 127256kB
09:44:13 Node 0 Normal: 12182*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 52824kB
09:44:13 682828 total pagecache pages
09:44:13 43261 pages in swap cache
09:44:13 Swap cache stats: add 803340, delete 760079, find 297802/318575
09:44:13 Free swap = 1763760kB
09:44:13 Total swap = 4106248kB
09:44:13 2080752 pages RAM
09:44:13 57163 pages reserved
09:44:13 992430 pages shared
09:44:13 1498647 pages non-shared
09:44:13 ieee80211 phy0: failed to reallocate TX buffer
09:44:13 kworker/0:0: page allocation failure: order:1, mode:0x20
09:44:13 Pid: 7949, comm: kworker/0:0 Tainted: G O 3.2.5amd64-volpreempt-noide-20120208 #1
09:44:13 Call Trace:
09:44:13 <IRQ> [<ffffffff810b755a>] ? warn_alloc_failed+0x11a/0x12d
09:44:13 [<ffffffff810ba394>] ? __alloc_pages_nodemask+0x6b2/0x726
09:44:13 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:13 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:13 [<ffffffff810ea421>] ? fallback_alloc+0x123/0x1c2
09:44:13 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:13 [<ffffffff810ea923>] ? __kmalloc+0xba/0x112
09:44:13 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:13 [<ffffffffa07a81c0>] ? ieee80211_skb_resize+0x64/0x9d [mac80211]
09:44:13 [<ffffffffa07aa087>] ? ieee80211_subif_start_xmit+0x68e/0x80c [mac80211]
09:44:13 [<ffffffffa07922c8>] ? ieee80211_tx_status_irqsafe+0x2e/0x7f [mac80211]
09:44:13 [<ffffffff812877f3>] ? dev_hard_start_xmit+0x3fc/0x543
09:44:13 [<ffffffff8129da01>] ? sch_d9704>] ? dec128+0x80c/0x80c [aes_x86_64]
09:44:13 [<ffffffff810349f1>] ? set_task_rq+0x23/0x35
09:44:13 [<ffffffff8118f328>] ? crypto_cbc_decrypt+0x5a/0x10a
09:44:13 [<ffffffff8118756b>] ? async_decrypt+0x37/0x3c
09:44:13 [<ffffffffa0108df7>] ? crypt_convert+0x223/0x2b8 [dm_crypt]
09:44:13 [<ffffffffa0109185>] ? kcryptd_crypt+0x56/0x342 [dm_crypt]
09:44:13 [<ffffffff810388e2>] ? finish_task_switch+0x4e/0xb9
09:44:13 [<ffffffff811a4021>] ? cfq_init_queue+0x403/0x403
09:44:13 [<ffffffffa010912f>] ? crypt_convert_init.isra.17+0x4f/0x4f [dm_crypt]
09:44:13 [<ffffffff8105ac3d>] ? process_one_work+0x163/0x284
09:44:13 [<ffffffff8105bc05>] ? worker_thread+0xc2/0x145
09:44:13 [<ffffffff8105bb43>] ? manage_workers.isra.23+0x15b/0x15b
09:44:13 [<ffffffff8105ed41>] ? kthread+0x76/0x7e
09:44:13 [<ffffffff81349cb4>] ? kernel_thread_helper+0x4/0x10
09:44:13 [<ffffffff8105eccb>] ? kthread_worker_fn+0x139/0x139
09:44:13 [<ffffffff81349cb0>] ? gs_change+0x13/0x13
09:44:13 Mem-Info:
09:44:13 Node 0 DMA per-cpu:
09:44:13 CPU 0: hi: 0, btch: 1 usd: 0
09:44:13 CPU 1: hi: 0, btch: 1 usd: 0
09:44:13 Node 0 DMA32 per-cpu:
09:44:13 CPU 0: hi: 186, btch: 31 usd: 17
09:44:13 CPU 1: hi: 186, btch: 31 usd: 0
09:44:13 Node 0 Normal per-cpu:
09:44:13 CPU 0: hi: 186, btch: 31 usd: 69
09:44:13 CPU 1: hi: 186, btch: 31 usd: 125
09:44:13 active_anon:992968 inactive_anon:263499 isolated_anon:1
09:44:13 active_file:59749 inactive_file:538771 isolated_file:12
09:44:13 unevictable:1 dirty:59393 writeback:339244 unstable:8193
09:44:13 free:46512 slab_reclaimable:33220 slab_unreclaimable:30692
09:44:13 mapped:18504 shmem:43598 pagetables:21479 bounce:0
09:44:13 Node 0 DMA free:15908kB min:128kB low:160kB high:192kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15684kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
09:44:13 lowmem_reserve[]: 0 2960 7947 7947
09:44:13 Node 0 DMA32 free:117308kB min:25128kB low:31408kB high:37692kB active_anon:1579336kB inactive_anon:524204kB active_file:33764kB inactive_file:653796kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3031688kB mlocked:0kB dirty:99216kB writeback:322356kB mapped:6716kB shmem:67128kB slab_reclaimable:41324kB slab_unreclaimable:30888kB kernel_stack:2216kB pagetables:24408kB unstable:10120kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:13 lowmem_reserve[]: 0 0 4986 4986
09:44:13 Node 0 Normal free:52832kB min:42324kB low:52904kB high:63484kB active_anon:2392536kB inactive_anon:529792kB active_file:205232kB inactive_file:1501288kB unevictable:4kB isolated(anon):4kB isolated(file):48kB present:5106560kB mlocked:4kB dirty:138356kB writeback:1034620kB mapped:67300kB shmem:107264kB slab_reclaimable:91556kB slab_unreclaimable:91880kB kernel_stack:4216kB pagetables:61508kB unstable:22652kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:13 lowmem_reserve[]: 0 0 0 0
09:44:13 Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15908kB
09:44:13 Node 0 DMA32: 28147*4kB 0*8kB 1*16kB 1*32kB 1*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 1*4096kB = 117308kB
09:44:13 Node 0 Normal: 12094*4kB 5*8kB 12*16kB 4*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 52832kB
09:44:13 685431 total pagecache pages
09:44:13 43261 pages in swap cache
09:44:13 Swap cache stats: add 803341, delete 760080, find 297802/318575
09:44:13 Free swap = 1763756kB
09:44:13 Total swap = 4106248kB
09:44:13 2080752 pages RAM
09:44:13 57163 pages reserved
09:44:13 994159 pages shared
09:44:13 1498949 pages non-shared
09:44:13 ieee80211 phy0: failed to reallocate TX buffer
09:44:13 kworker/0:0: page allocation failure: order:1, mode:0x20
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
^ permalink raw reply
* Re: [PATCH v2 2/2] cgroup: get rid of populate for memcg
From: Tejun Heo @ 2012-04-09 17:40 UTC (permalink / raw)
To: Glauber Costa
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A, Li Zefan, Johannes Weiner,
Michal Hocko, Balbir Singh
In-Reply-To: <1333728250-14248-3-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
(cc'ing other memcg ppl just in case)
Hello,
I don't think the error handling is correct here.
On Fri, Apr 06, 2012 at 08:04:10PM +0400, Glauber Costa wrote:
> The last man standing justifying the need for populate() is the
> sock memcg initialization functions. Now that we are able to pass
> a struct mem_cgroup instead of a struct cgroup to the socket
> initialization, there is nothing that stops us from initializing
> everything in create().
>
> Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> CC: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> CC: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> ---
...
> @@ -5010,7 +5010,9 @@ mem_cgroup_create(struct cgroup *cont)
> memcg->move_charge_at_immigrate = 0;
> mutex_init(&memcg->thresholds_lock);
> spin_lock_init(&memcg->move_lock);
> - return &memcg->css;
> +
> + if (!memcg_init_kmem(memcg, &mem_cgroup_subsys))
> + return &memcg->css;
> free_out:
> __mem_cgroup_free(memcg);
> return ERR_PTR(error);
So, the control is just falling through free_out: on kmem init
failure; however, there seem to be stuff which needs to be undone -
hotcpu_notifier() registration, which BTW seems incorrect even on its
own - unmounting and mounting again would probably make the same
notifier registered multiple times corrupting notification chain, and
ref inc on the parent.
It probably would be best to reorganize the function slightly such
that, it's organized as...
1. alloc
2. init stuff w/o other side effects
3. make side effects
and add kmemcg init at the end of the second step.
Also, memcg maintainers, once the patches get updated and acked, I'd
like to route them through cgroup tree so that I can kill ->populate
there. cgroup/for-3.5 is stable branch which can be pulled into other
trees including the memcg one. Would that be okay?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v2 2/2] cgroup: get rid of populate for memcg
From: Glauber Costa @ 2012-04-09 17:51 UTC (permalink / raw)
To: Tejun Heo
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A, Li Zefan, Johannes Weiner,
Michal Hocko, Balbir Singh
In-Reply-To: <20120409174042.GA7522-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On 04/09/2012 02:40 PM, Tejun Heo wrote:
> which BTW seems incorrect even on its
> own - unmounting and mounting again would probably make the same
> notifier registered multiple times corrupting notification chain, and
> ref inc on the parent.
For the maintainers: Should I fix those in a new submission, or do you
intend to do it yourselves?
the refcnt dropping should probably be done in my patch, it is a new
leak (sorry). The hotplug notifier, as tejun pointed, was already there.
It seems simple enough to fix, so if you guys want, I can bundle it in
a new submission.
^ permalink raw reply
* Re: [PATCH net-next v3 5/5] r8169: support RTL8411
From: Francois Romieu @ 2012-04-09 18:02 UTC (permalink / raw)
To: hayeswang; +Cc: netdev
In-Reply-To: <20120405083743.GB32027@electric-eye.fr.zoreil.com>
Francois Romieu <romieu@fr.zoreil.com> :
> hayeswang <hayeswang@realtek.com> :
> [...]
> > There is nothing to do for rtl_init_jumbo_ops. It is all right for keeping
> > NULL.
>
> Ok, I'll add it to the commit message for future reference.
>
> > Do I need to resend this patch?
>
> No, I'll give it a short testing and forward to David.
Rx/Tx is ok, WoL + shutdown is ok but runtime power management is not.
I tried net-next + your patches + cff4c16296754888b6fd8c886bc860a888e20257
("r8169: enable napi on resume.", required for RPM or suspend/resume after
regression in da78dbff2e05630921c551dbbc70a4b7981a8fff).
- set a 8402 and a 8411 in the same test box
- ip addr add ...
- ip link set dev ... up
- start ping from remote host
- echo auto > /sys/bus/pci/devices/.../power/control
- unplug cable
- ping stops flowing
- cat /sys/bus/pci/devices/.../power/runtime_status
-> "active"
- plug cable
-> RPM status does not change, no link, no packet, no fun.
I have tried the same with a built-in 8168b (XID 18000000).
-> RPM status changes, link recovers, packets flow.
The 8168b is a bit special, so I swapped the 8411 for a 8102e (XID 04a00000).
It resumed correctly as well.
Any idea ?
--
Ueimor
Will code drivers for food.
^ permalink raw reply
* Re: 3.2.8/amd64 full interrupt hangs and deadlocks under big network copies (page allocation failure)
From: David Miller @ 2012-04-09 18:12 UTC (permalink / raw)
To: marc; +Cc: bhutchings, linux-wireless, netdev
In-Reply-To: <20120409172051.GR32290@merlins.org>
From: Marc MERLIN <marc@merlins.org>
Date: Mon, 9 Apr 2012 10:20:51 -0700
> Any idea what's going on, what bucket of RAM is an issue for the driver
> (total RAM is more than plenty), and where I should go from there?
The wireless layer is allocating high-order pages, so it's
not the amount of ram, it's the fragmentation of it leading
to a lack of those high-order pages.
^ permalink raw reply
* Re: [PATCH v2 2/2] cgroup: get rid of populate for memcg
From: Tejun Heo @ 2012-04-09 18:13 UTC (permalink / raw)
To: Glauber Costa
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A, Li Zefan, Johannes Weiner,
Michal Hocko, Balbir Singh
In-Reply-To: <4F83218E.7060502-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Hello,
On Mon, Apr 09, 2012 at 02:51:10PM -0300, Glauber Costa wrote:
> On 04/09/2012 02:40 PM, Tejun Heo wrote:
> >which BTW seems incorrect even on its
> >own - unmounting and mounting again would probably make the same
> >notifier registered multiple times corrupting notification chain, and
> >ref inc on the parent.
>
>
> For the maintainers: Should I fix those in a new submission, or do
> you intend to do it yourselves?
>
> the refcnt dropping should probably be done in my patch, it is a new
> leak (sorry). The hotplug notifier, as tejun pointed, was already
> there.
>
> It seems simple enough to fix, so if you guys want, I can bundle it in
> a new submission.
I think it would be best to create a separate patch which is routed
through the usual memcg path (I suppose memcg patches go through
-mm?).
Thanks.
--
tejun
^ permalink raw reply
* Re: 3.2.8/amd64 full interrupt hangs and deadlocks under big network copies (page allocation failure)
From: Marc MERLIN @ 2012-04-09 18:36 UTC (permalink / raw)
To: David Miller
Cc: bhutchings-s/n/eUQHGBpZroRs9YW3xA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120409.141241.1216091936509309354.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Mon, Apr 09, 2012 at 02:12:41PM -0400, David Miller wrote:
> From: Marc MERLIN <marc-xnduUnryOU1AfugRpC6u6w@public.gmane.org>
> Date: Mon, 9 Apr 2012 10:20:51 -0700
>
> > Any idea what's going on, what bucket of RAM is an issue for the driver
> > (total RAM is more than plenty), and where I should go from there?
>
> The wireless layer is allocating high-order pages, so it's
> not the amount of ram, it's the fragmentation of it leading
> to a lack of those high-order pages.
I figured it was something of the sort, thanks for the professional
confirmation :)
What's my next step, file a bug with a specific team?
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
--
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
* Re: 3.2.8/amd64 full interrupt hangs and deadlocks under big network copies (page allocation failure)
From: David Miller @ 2012-04-09 18:37 UTC (permalink / raw)
To: marc; +Cc: bhutchings, linux-wireless, netdev
In-Reply-To: <20120409183632.GO29342@merlins.org>
From: Marc MERLIN <marc@merlins.org>
Date: Mon, 9 Apr 2012 11:36:32 -0700
> On Mon, Apr 09, 2012 at 02:12:41PM -0400, David Miller wrote:
>> From: Marc MERLIN <marc@merlins.org>
>> Date: Mon, 9 Apr 2012 10:20:51 -0700
>>
>> > Any idea what's going on, what bucket of RAM is an issue for the driver
>> > (total RAM is more than plenty), and where I should go from there?
>>
>> The wireless layer is allocating high-order pages, so it's
>> not the amount of ram, it's the fragmentation of it leading
>> to a lack of those high-order pages.
>
> I figured it was something of the sort, thanks for the professional
> confirmation :)
>
> What's my next step, file a bug with a specific team?
Wait patiently for a wireless developer to look into your bug.
^ 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