* Re: [PATCH net-2.6] ethtool: Remove fallback to old ethtool operations for ETHTOOL_SFEATURES
From: Ben Hutchings @ 2011-05-16 2:45 UTC (permalink / raw)
To: Michał Mirosław; +Cc: David Miller, netdev
In-Reply-To: <20110514103539.GA5214@rere.qmqm.pl>
On Sat, 2011-05-14 at 12:35 +0200, Michał Mirosław wrote:
> On Sat, May 14, 2011 at 02:05:42AM +0100, Ben Hutchings wrote:
> > ethtool_set_feature_compat() squashes the feature mask into a boolean,
> > which is not correct for ethtool_ops::set_flags.
> >
> > We could fix this, but the fallback code for ETHTOOL_SFEATURES actually
> > makes things more complicated for the ethtool utility and any other
> > application using the ethtool API. They will still need to fall back to
> > the old offload control commands in order to support older kernel
> > versions. The fallback code in the kernel adds a third possibility for
> > them to handle. So make ETHTOOL_SFEATURES fail when the driver
> > implements the old offload control operations, and let userland do the
> > fallback.
>
> BTW, the idea behind the compat code is that if ETHTOOL_[GS]FEATURES is
> available, then there should be no need to fallback to old ops. For
> a userspace tool that targets only kernels >= 2.6.39 there's no need
> to care about old ops at all.
Well that's not true, because those tools still have to deal with
ETHTOOL_F_COMPAT. And we're supposed to have all drivers converted for
2.6.40, so the hypothetical new tool only has to wait one more release.
Ben.
--
Ben Hutchings, Senior Software 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
* [PATCH] 2.6.38 ENC28J60 works with half-duplex DMA
From: Davide Rizzo @ 2011-05-16 5:33 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 100 bytes --]
Please consider this patch, that allows ENC28J60 to be used on
machines with half-duplex DMA on SPI
[-- Attachment #2: enc28j60.c-2.6.38.patch --]
[-- Type: text/x-patch, Size: 5357 bytes --]
This patch modifies SPI access to take advantage of DMA on machines supporting
only half-duplex SPI DMA (like Samsung S3C2410)
Signed-off-by: Davide Rizzo <elpa.rizzo@gmail.com>
---
diff -urNp linux-2.6.38/drivers/net/enc28j60.c linux-2.6.38.elpa/drivers/net/enc28j60.c
--- linux-2.6.38/drivers/net/enc28j60.c 2011-03-15 02:20:32.000000000 +0100
+++ linux-2.6.38.elpa/drivers/net/enc28j60.c 2011-05-14 09:56:05.701797208 +0200
@@ -36,6 +36,8 @@
#define SPI_OPLEN 1
+#define FCLK_MAX 20000000
+
#define ENC28J60_MSG_DEFAULT \
(NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN | NETIF_MSG_LINK)
@@ -84,29 +86,33 @@ static struct {
* SPI read buffer
* wait for the SPI transfer and copy received data to destination
*/
-static int
-spi_read_buf(struct enc28j60_net *priv, int len, u8 *data)
+static int spi_read_buf(struct enc28j60_net *priv, int len, u8 *data)
{
- u8 *rx_buf = priv->spi_transfer_buf + 4;
- u8 *tx_buf = priv->spi_transfer_buf;
struct spi_transfer t = {
- .tx_buf = tx_buf,
- .rx_buf = rx_buf,
- .len = SPI_OPLEN + len,
+ .tx_buf = priv->spi_transfer_buf,
+ .rx_buf = NULL,
+ .len = SPI_OPLEN,
+ .cs_change = 0,
+ .speed_hz = FCLK_MAX,
+ };
+ struct spi_transfer r = {
+ .tx_buf = NULL,
+ .rx_buf = data,
+ .len = len,
+ .cs_change = 1,
+ .speed_hz = FCLK_MAX,
};
struct spi_message msg;
int ret;
- tx_buf[0] = ENC28J60_READ_BUF_MEM;
- tx_buf[1] = tx_buf[2] = tx_buf[3] = 0; /* don't care */
+ priv->spi_transfer_buf[0] = ENC28J60_READ_BUF_MEM;
spi_message_init(&msg);
spi_message_add_tail(&t, &msg);
+ spi_message_add_tail(&r, &msg);
ret = spi_sync(priv->spi, &msg);
- if (ret == 0) {
- memcpy(data, &rx_buf[SPI_OPLEN], len);
+ if (ret == 0)
ret = msg.status;
- }
if (ret && netif_msg_drv(priv))
printk(KERN_DEBUG DRV_NAME ": %s() failed: ret = %d\n",
__func__, ret);
@@ -114,20 +120,26 @@ spi_read_buf(struct enc28j60_net *priv,
return ret;
}
-/*
- * SPI write buffer
- */
-static int spi_write_buf(struct enc28j60_net *priv, int len,
- const u8 *data)
+static int spi_send(struct enc28j60_net *priv, u8 cmd, int len, const u8 *data)
{
int ret;
+ struct spi_message msg;
+ struct spi_transfer t = {
+ .tx_buf = priv->spi_transfer_buf,
+ .rx_buf = NULL,
+ .len = len + 1,
+ .cs_change = 1,
+ .speed_hz = FCLK_MAX,
+ };
if (len > SPI_TRANSFER_BUF_LEN - 1 || len <= 0)
ret = -EINVAL;
else {
- priv->spi_transfer_buf[0] = ENC28J60_WRITE_BUF_MEM;
+ spi_message_init(&msg);
+ spi_message_add_tail(&t, &msg);
+ priv->spi_transfer_buf[0] = cmd;
memcpy(&priv->spi_transfer_buf[1], data, len);
- ret = spi_write(priv->spi, priv->spi_transfer_buf, len + 1);
+ ret = spi_sync(priv->spi, &msg);
if (ret && netif_msg_drv(priv))
printk(KERN_DEBUG DRV_NAME ": %s() failed: ret = %d\n",
__func__, ret);
@@ -136,28 +148,56 @@ static int spi_write_buf(struct enc28j60
}
/*
+ * SPI write buffer
+ */
+static int spi_write_buf(struct enc28j60_net *priv, int len,
+ const u8 *data)
+{
+ return spi_send(priv, ENC28J60_WRITE_BUF_MEM, len, data);
+}
+
+/*
* basic SPI read operation
*/
-static u8 spi_read_op(struct enc28j60_net *priv, u8 op,
- u8 addr)
+static u8 spi_read_op(struct enc28j60_net *priv, u8 op, u8 addr)
{
- u8 tx_buf[2];
- u8 rx_buf[4];
+ u8 tx_buf;
+ u8 rx_buf[SPI_OPLEN + 1];
u8 val = 0;
+ struct spi_transfer t = {
+ .tx_buf = &tx_buf,
+ .rx_buf = NULL,
+ .len = SPI_OPLEN,
+ .cs_change = 0,
+ .speed_hz = FCLK_MAX,
+ };
+ struct spi_transfer r = {
+ .tx_buf = NULL,
+ .rx_buf = rx_buf,
+ .len = SPI_OPLEN,
+ .cs_change = 1,
+ .speed_hz = FCLK_MAX,
+ };
+ struct spi_message msg;
int ret;
- int slen = SPI_OPLEN;
/* do dummy read if needed */
if (addr & SPRD_MASK)
- slen++;
+ r.len++;
+
+ tx_buf = op | (addr & ADDR_MASK);
- tx_buf[0] = op | (addr & ADDR_MASK);
- ret = spi_write_then_read(priv->spi, tx_buf, 1, rx_buf, slen);
- if (ret)
+ spi_message_init(&msg);
+ spi_message_add_tail(&t, &msg);
+ spi_message_add_tail(&r, &msg);
+ ret = spi_sync(priv->spi, &msg);
+ if (ret == 0)
+ ret = msg.status;
+ if (ret && netif_msg_drv(priv))
printk(KERN_DEBUG DRV_NAME ": %s() failed: ret = %d\n",
__func__, ret);
else
- val = rx_buf[slen - 1];
+ val = rx_buf[r.len - 1];
return val;
}
@@ -165,18 +205,9 @@ static u8 spi_read_op(struct enc28j60_ne
/*
* basic SPI write operation
*/
-static int spi_write_op(struct enc28j60_net *priv, u8 op,
- u8 addr, u8 val)
+static int spi_write_op(struct enc28j60_net *priv, u8 op, u8 addr, u8 val)
{
- int ret;
-
- priv->spi_transfer_buf[0] = op | (addr & ADDR_MASK);
- priv->spi_transfer_buf[1] = val;
- ret = spi_write(priv->spi, priv->spi_transfer_buf, 2);
- if (ret && netif_msg_drv(priv))
- printk(KERN_DEBUG DRV_NAME ": %s() failed: ret = %d\n",
- __func__, ret);
- return ret;
+ return spi_send(priv, op | (addr & ADDR_MASK), 1, &val);
}
static void enc28j60_soft_reset(struct enc28j60_net *priv)
@@ -1572,6 +1603,12 @@ static int __devinit enc28j60_probe(stru
dev_set_drvdata(&spi->dev, priv); /* spi to priv reference */
SET_NETDEV_DEV(dev, &spi->dev);
+ /* Configure the SPI bus */
+ spi->mode = SPI_MODE_0;
+ spi->bits_per_word = 8;
+ spi->max_speed_hz = FCLK_MAX;
+ spi_setup(spi);
+
if (!enc28j60_chipset_init(dev)) {
if (netif_msg_probe(priv))
dev_info(&spi->dev, DRV_NAME " chip not found\n");
^ permalink raw reply
* Re: [PATCH 06/18] virtio_ring: avail event index interface
From: Rusty Russell @ 2011-05-16 6:23 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar, Carsten Otte, lguest-uLR06cmDAlY/bJ5BZ2RsiQ,
Shirley Ma, kvm-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
habanero-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, Heiko Carstens,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
steved-r/Jw6+rmf7HQT0dZR+AlfA, Christian Borntraeger,
Tom Lendacky, Martin Schwidefsky, linux390-tA70FqPdS9bQT0dZR+AlfA
In-Reply-To: <20110515124727.GA24932-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Sun, 15 May 2011 15:47:27 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, May 09, 2011 at 01:43:15PM +0930, Rusty Russell wrote:
> > On Wed, 4 May 2011 23:51:19 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > #define VIRTIO_RING_F_USED_EVENT_IDX 29
> > > +/* The Host publishes the avail index for which it expects a kick
> > > + * at the end of the used ring. Guest should ignore the used->flags field. */
> > > +#define VIRTIO_RING_F_AVAIL_EVENT_IDX 32
> >
> > Are you really sure we want to separate the two? Seems a little simpler
> > to have one bit to mean "we're publishing our threshold". For someone
> > implementing this from scratch, it's a little simpler.
> >
> > Or are there cases where the old style makes more sense?
> >
> > Thanks,
> > Rusty.
>
> Hmm, it makes debugging easier as each side can disable
> publishing separately - I used it all the time when I saw
> e.g. networking stuck to guess whether I need to investigate the
> interrupt or the exit handling.
>
> But I'm not hung up on this.
>
> Let me know pls.
If we combine them into one, then these patches no longer depend on
the feature bit expansion, which is worthwhile (though I'll take both).
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH 09/18] virtio: use avail_event index
From: Rusty Russell @ 2011-05-16 7:12 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar, Carsten Otte, lguest-uLR06cmDAlY/bJ5BZ2RsiQ,
Shirley Ma, kvm-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
habanero-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, Heiko Carstens,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
steved-r/Jw6+rmf7HQT0dZR+AlfA, Christian Borntraeger,
Tom Lendacky, Martin Schwidefsky, linux390-tA70FqPdS9bQT0dZR+AlfA
In-Reply-To: <20110515135541.GF24932-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Sun, 15 May 2011 16:55:41 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, May 09, 2011 at 02:03:26PM +0930, Rusty Russell wrote:
> > On Wed, 4 May 2011 23:51:47 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > Use the new avail_event feature to reduce the number
> > > of exits from the guest.
> >
> > Figures here would be nice :)
>
> You mean ASCII art in comments?
I mean benchmarks of some kind.
>
> > > @@ -228,6 +237,12 @@ add_head:
> > > * new available array entries. */
> > > virtio_wmb();
> > > vq->vring.avail->idx++;
> > > + /* If the driver never bothers to kick in a very long while,
> > > + * avail index might wrap around. If that happens, invalidate
> > > + * kicked_avail index we stored. TODO: make sure all drivers
> > > + * kick at least once in 2^16 and remove this. */
> > > + if (unlikely(vq->vring.avail->idx == vq->kicked_avail))
> > > + vq->kicked_avail_valid = true;
> >
> > If they don't, they're already buggy. Simply do:
> > WARN_ON(vq->vring.avail->idx == vq->kicked_avail);
>
> Hmm, but does it say that somewhere?
AFAICT it's a corollary of:
1) You have a finite ring of size <= 2^16.
2) You need to kick the other side once you've done some work.
> > > @@ -482,6 +517,8 @@ void vring_transport_features(struct virtio_device *vdev)
> > > break;
> > > case VIRTIO_RING_F_USED_EVENT_IDX:
> > > break;
> > > + case VIRTIO_RING_F_AVAIL_EVENT_IDX:
> > > + break;
> > > default:
> > > /* We don't understand this bit. */
> > > clear_bit(i, vdev->features);
> >
> > Does this belong in a prior patch?
> >
> > Thanks,
> > Rusty.
>
> Well if we don't support the feature in the ring we should not
> ack the feature, right?
Ah, you're right.
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH 14/18] virtio: add api for delayed callbacks
From: Rusty Russell @ 2011-05-16 7:13 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Krishna Kumar, Carsten Otte, lguest-uLR06cmDAlY/bJ5BZ2RsiQ,
Shirley Ma, kvm-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
habanero-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, Heiko Carstens,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
steved-r/Jw6+rmf7HQT0dZR+AlfA, Christian Borntraeger,
Tom Lendacky, Martin Schwidefsky, linux390-tA70FqPdS9bQT0dZR+AlfA
In-Reply-To: <20110515124818.GD24932-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Sun, 15 May 2011 15:48:18 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, May 09, 2011 at 03:27:33PM +0930, Rusty Russell wrote:
> > On Wed, 4 May 2011 23:52:33 +0300, "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > Add an API that tells the other side that callbacks
> > > should be delayed until a lot of work has been done.
> > > Implement using the new used_event feature.
> >
> > Since you're going to add a capacity query anyway, why not add the
> > threshold argument here?
>
> I thought that if we keep the API kind of generic
> there might be more of a chance that future transports
> will be able to implement it. For example, with an
> old host we can't commit to a specific index.
No, it's always a hint anyway: you can be notified before the threshold
is reached. But best make it explicit I think.
Cheers,
Rusty.
^ permalink raw reply
* [PATCH net-next-2.6 v2] net: ping: dont call udp_ioctl()
From: Eric Dumazet @ 2011-05-16 7:26 UTC (permalink / raw)
To: David Miller
Cc: solar, segoon, linux-kernel, netdev, peak, kees.cook,
dan.j.rosenberg, eugene, nelhage, kuznet, pekkas, jmorris,
yoshfuji, kaber
In-Reply-To: <20110515.174430.1379973540554096232.davem@davemloft.net>
Le dimanche 15 mai 2011 à 17:44 -0400, David Miller a écrit :
> Just get rid of ping_ioctl() entirely, as that is the effect of
> this change since inet_ioctl() returns -ENOIOCTLCMD when
> sk_prot->ioctl is NULL.
>
> Also get rid of asm/ioctls.h since that will be no longer needed.
Sure, here is updated version, thanks.
[PATCH net-next-2.6 v2] net: ping: dont call udp_ioctl()
udp_ioctl() really handles UDP and UDPLite protocols.
1) It can increment UDP_MIB_INERRORS in case first_packet_length() finds
a frame with bad checksum.
2) It has a dependency on sizeof(struct udphdr), not applicable to
ICMP/PING
If ping sockets need to handle SIOCINQ/SIOCOUTQ ioctl, this should be
done differently.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Vasiliy Kulikov <segoon@openwall.com>
---
net/ipv4/ping.c | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 7041d09..41836ab 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -22,7 +22,6 @@
#include <asm/system.h>
#include <linux/uaccess.h>
-#include <asm/ioctls.h>
#include <linux/types.h>
#include <linux/fcntl.h>
#include <linux/socket.h>
@@ -609,23 +608,6 @@ do_confirm:
goto out;
}
-/*
- * IOCTL requests applicable to the UDP^H^H^HICMP protocol
- */
-
-int ping_ioctl(struct sock *sk, int cmd, unsigned long arg)
-{
- pr_debug("ping_ioctl(sk=%p,sk->num=%u,cmd=%d,arg=%lu)\n",
- inet_sk(sk), inet_sk(sk)->inet_num, cmd, arg);
- switch (cmd) {
- case SIOCOUTQ:
- case SIOCINQ:
- return udp_ioctl(sk, cmd, arg);
- default:
- return -ENOIOCTLCMD;
- }
-}
-
int ping_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
size_t len, int noblock, int flags, int *addr_len)
{
@@ -735,7 +717,6 @@ struct proto ping_prot = {
.close = ping_close,
.connect = ip4_datagram_connect,
.disconnect = udp_disconnect,
- .ioctl = ping_ioctl,
.setsockopt = ip_setsockopt,
.getsockopt = ip_getsockopt,
.sendmsg = ping_sendmsg,
^ permalink raw reply related
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michael S. Tsirkin @ 2011-05-16 7:28 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, Ben Hutchings, herbert
In-Reply-To: <20110505152644.GA8459@rere.qmqm.pl>
On Thu, May 05, 2011 at 05:26:44PM +0200, Michał Mirosław wrote:
> On Wed, May 04, 2011 at 09:18:14PM +0300, Michael S. Tsirkin wrote:
> > BTW, I just noticed that net-next spits out
> > many of the following when I run any VMs:
> [...]
> > tap0: Features changed: 0x40004040 -> 0x401b4849
>
> Before this message, userspace called ioctl(TIOCSETOFFLOAD)
> turning offloads on.
>
> > tap0: Dropping NETIF_F_SG since no checksum feature.
> > tap0: Dropping NETIF_F_GSO since no SG feature.
> > tap0: Features changed: 0x401b4849 -> 0x40004040
>
> And then it probably called ioctl(TIOCSETOFFLOAD) again, disabling them.
>
> Best Regards,
> Michał Mirosław
I'd have to look at this some more, but I know qemu-kvm
supports offloads with current kernels.
There seems to be some kernel behaviour change here.
> --
> 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: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michael S. Tsirkin @ 2011-05-16 7:32 UTC (permalink / raw)
To: Herbert Xu; +Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110505100506.GA20111@gondor.apana.org.au>
On Thu, May 05, 2011 at 08:05:06PM +1000, Herbert Xu wrote:
> On Thu, May 05, 2011 at 05:34:43PM +0800, Shan Wei wrote:
> >
> > TUN_F_TSO4, TUN_F_TSO6, TUN_F_TSO_ECN, TUN_F_UFO these features are
> > depend on NETIF_F_SG. If NETIF_F_SG is not set, these features are not be
> > enabled and warnings are printed in netdev_fix_features().
>
> No, when the user turns off checksum offload everything should
> be turned off as well. However, when it's turned on, we shouldn't
> enable everything automatically.
>
> Cheers,
So how is NETIF_F_SG supposed to be enabled then?
In upstream kernels userspace can disable checksum offloading then
re-enable and get SG set back. userspace came to depend on this
behaviour so I think changing this is a regression.
> --
> 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
> --
> 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: [RFC 2/3] RDMA/cma: Add support for netlink statistics export
From: Or Gerlitz @ 2011-05-16 8:05 UTC (permalink / raw)
To: Hefty, Sean
Cc: Roland Dreier, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373F428-P5GAC/sN6hmkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
Hefty, Sean wrote:
>> +struct rdma_cm_id_stats {
>> + __u32 qp_num;
>> + __u32 bound_dev_if;
>> + __u32 port_space;
>> + __s32 pid;
>> + __u8 cm_state;
>> + __u8 node_type;
>> + __u8 port_num;
>> + __u8 reserved;
>> +};
>
> We may also want to add qp_type
Sean,
Isn't the port space enough here? specifically, what qp type buys us
over port space?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Herbert Xu @ 2011-05-16 8:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516073210.GB6610@redhat.com>
On Mon, May 16, 2011 at 10:32:10AM +0300, Michael S. Tsirkin wrote:
>
> So how is NETIF_F_SG supposed to be enabled then?
It should either be enabled at device creation time, or whatever
user-space entity managing the device creation should enable it
along with checksumming and anything else applicable.
> In upstream kernels userspace can disable checksum offloading then
> re-enable and get SG set back. userspace came to depend on this
> behaviour so I think changing this is a regression.
Can you point me to the relevant code in the upstream kernel?
I'm not aware of any automatic SG enabling for network devices
in general when you enable checksum offloading.
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: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michael S. Tsirkin @ 2011-05-16 8:18 UTC (permalink / raw)
To: Herbert Xu; +Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516080702.GA1857@gondor.apana.org.au>
On Mon, May 16, 2011 at 06:07:02PM +1000, Herbert Xu wrote:
> On Mon, May 16, 2011 at 10:32:10AM +0300, Michael S. Tsirkin wrote:
> >
> > So how is NETIF_F_SG supposed to be enabled then?
>
> It should either be enabled at device creation time, or whatever
> user-space entity managing the device creation should enable it
> along with checksumming and anything else applicable.
There's no interface for userspace to enable it: userspace
only has an ioctl to enable/disable checksum offloading.
SG is an implementation detail.
> > In upstream kernels userspace can disable checksum offloading then
> > re-enable and get SG set back. userspace came to depend on this
> > behaviour so I think changing this is a regression.
>
> Can you point me to the relevant code in the upstream kernel?
> I'm not aware of any automatic SG enabling for network devices
> in general when you enable checksum offloading.
>
> Cheers,
I think what happens _SG is enabled at device creation time and
then upstream just keeps it on always, even when user clears
CSUM. With net-next code changed so that _SG gets cleared when CSUM
'gets cleared. But then it does not get reenabled when CSUM
gets reenabled.
> --
> 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: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michael S. Tsirkin @ 2011-05-16 8:28 UTC (permalink / raw)
To: Herbert Xu; +Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516080702.GA1857@gondor.apana.org.au>
On Mon, May 16, 2011 at 06:07:02PM +1000, Herbert Xu wrote:
> On Mon, May 16, 2011 at 10:32:10AM +0300, Michael S. Tsirkin wrote:
> >
> > So how is NETIF_F_SG supposed to be enabled then?
>
> It should either be enabled at device creation time, or whatever
> user-space entity managing the device creation should enable it
> along with checksumming and anything else applicable.
>
> > In upstream kernels userspace can disable checksum offloading then
> > re-enable and get SG set back. userspace came to depend on this
> > behaviour so I think changing this is a regression.
>
> Can you point me to the relevant code in the upstream kernel?
> I'm not aware of any automatic SG enabling for network devices
> in general when you enable checksum offloading.
>
> Cheers,
By the way with kvm we let an unpriveledged application
control netdev flags through and ioctl. It's probably
not a good idea to print out stuff on flag change
unconditionally as that will let that application
fill up the system log.
> --
> 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: Kernel 2.6.38.6 page allocation failure (ixgbe)
From: Stefan Majer @ 2011-05-16 8:28 UTC (permalink / raw)
To: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel
In-Reply-To: <F169D4F5E1F1974DBFAFABF47F60C10AF23DC8FF@orsmsx507.amr.corp.intel.com>
Hi,
after enlarging vm.min_free_kbytes to 524288 we survived almost a
week, but today i got this again:
May 16 09:18:13 os03 kernel: [331036.332001] kworker/0:1: page
allocation failure. order:2, mode:0x4020
May 16 09:18:13 os03 kernel: [331036.332005] Pid: 0, comm: kworker/0:1
Tainted: P W 2.6.38.6-1.fits.3.el6.x86_64 #1
May 16 09:18:13 os03 kernel: [331036.332009] Call Trace:
May 16 09:18:13 os03 kernel: [331036.332011] <IRQ>
[<ffffffff81108ce7>] ? __alloc_pages_nodemask+0x6f7/0x8a0
May 16 09:18:13 os03 kernel: [331036.332024] [<ffffffff81146cd2>] ?
kmalloc_large_node+0x62/0xb0
May 16 09:18:13 os03 kernel: [331036.332028] [<ffffffff8114becb>] ?
__kmalloc_node_track_caller+0x15b/0x1d0
May 16 09:18:13 os03 kernel: [331036.332033] [<ffffffff814b06ed>] ?
ip_rcv+0x23d/0x310
May 16 09:18:13 os03 kernel: [331036.332038] [<ffffffff81466f74>] ?
__netdev_alloc_skb+0x24/0x50
May 16 09:18:13 os03 kernel: [331036.332042] [<ffffffff81466713>] ?
__alloc_skb+0x83/0x170
May 16 09:18:13 os03 kernel: [331036.332045] [<ffffffff81466f74>] ?
__netdev_alloc_skb+0x24/0x50
May 16 09:18:13 os03 kernel: [331036.332054] [<ffffffffa0170217>] ?
ixgbe_alloc_rx_buffers+0x2b7/0x370 [ixgbe]
May 16 09:18:13 os03 kernel: [331036.332059] [<ffffffff8108d29d>] ?
sched_clock_cpu+0xcd/0x110
May 16 09:18:13 os03 kernel: [331036.332063] [<ffffffff81474840>] ?
napi_skb_finish+0x50/0x70
May 16 09:18:13 os03 kernel: [331036.332069] [<ffffffffa0172678>] ?
ixgbe_clean_rx_irq+0x828/0x890 [ixgbe]
May 16 09:18:13 os03 kernel: [331036.332076] [<ffffffffa01747cf>] ?
ixgbe_clean_rxtx_many+0x10f/0x220 [ixgbe]
May 16 09:18:13 os03 kernel: [331036.332080] [<ffffffff81474eb2>] ?
net_rx_action+0x102/0x2a0
May 16 09:18:13 os03 kernel: [331036.332084] [<ffffffff8106b745>] ?
__do_softirq+0xb5/0x210
May 16 09:18:13 os03 kernel: [331036.332089] [<ffffffff810c7ca4>] ?
handle_IRQ_event+0x54/0x180
May 16 09:18:13 os03 kernel: [331036.332094] [<ffffffff8100cf3c>] ?
call_softirq+0x1c/0x30
May 16 09:18:13 os03 kernel: [331036.332097] [<ffffffff8100e975>] ?
do_softirq+0x65/0xa0
May 16 09:18:13 os03 kernel: [331036.332100] [<ffffffff8106b605>] ?
irq_exit+0x95/0xa0
May 16 09:18:13 os03 kernel: [331036.332105] [<ffffffff8154a276>] ?
do_IRQ+0x66/0xe0
May 16 09:18:13 os03 kernel: [331036.332108] [<ffffffff81542a53>] ?
ret_from_intr+0x0/0x15
May 16 09:18:13 os03 kernel: [331036.332110] <EOI>
[<ffffffff812db311>] ? intel_idle+0xc1/0x120
May 16 09:18:13 os03 kernel: [331036.332116] [<ffffffff812db2f4>] ?
intel_idle+0xa4/0x120
May 16 09:18:13 os03 kernel: [331036.332121] [<ffffffff8143bca5>] ?
cpuidle_idle_call+0xb5/0x240
May 16 09:18:13 os03 kernel: [331036.332125] [<ffffffff8100aa87>] ?
cpu_idle+0xb7/0x110
May 16 09:18:13 os03 kernel: [331036.332129] [<ffffffff81538ffe>] ?
start_secondary+0x21f/0x221
May 16 09:18:13 os03 kernel: [331036.332131] Mem-Info:
May 16 09:18:13 os03 kernel: [331036.332132] Node 0 DMA per-cpu:
May 16 09:18:13 os03 kernel: [331036.332135] CPU 0: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332137] CPU 1: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332140] CPU 2: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332142] CPU 3: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332144] CPU 4: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332146] CPU 5: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332148] CPU 6: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332150] CPU 7: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332152] Node 0 DMA32 per-cpu:
May 16 09:18:13 os03 kernel: [331036.332155] CPU 0: hi: 186, btch:
31 usd: 163
May 16 09:18:13 os03 kernel: [331036.332157] CPU 1: hi: 186, btch:
31 usd: 31
May 16 09:18:13 os03 kernel: [331036.332159] CPU 2: hi: 186, btch:
31 usd: 182
May 16 09:18:13 os03 kernel: [331036.332162] CPU 3: hi: 186, btch:
31 usd: 37
May 16 09:18:13 os03 kernel: [331036.332164] CPU 4: hi: 186, btch:
31 usd: 13
May 16 09:18:13 os03 kernel: [331036.332166] CPU 5: hi: 186, btch:
31 usd: 180
May 16 09:18:13 os03 kernel: [331036.332168] CPU 6: hi: 186, btch:
31 usd: 159
May 16 09:18:13 os03 kernel: [331036.332170] CPU 7: hi: 186, btch:
31 usd: 180
May 16 09:18:13 os03 kernel: [331036.332172] Node 0 Normal per-cpu:
May 16 09:18:13 os03 kernel: [331036.332174] CPU 0: hi: 186, btch:
31 usd: 156
May 16 09:18:13 os03 kernel: [331036.332177] CPU 1: hi: 186, btch:
31 usd: 160
May 16 09:18:13 os03 kernel: [331036.332179] CPU 2: hi: 186, btch:
31 usd: 163
May 16 09:18:13 os03 kernel: [331036.332181] CPU 3: hi: 186, btch:
31 usd: 168
May 16 09:18:13 os03 kernel: [331036.332183] CPU 4: hi: 186, btch:
31 usd: 163
May 16 09:18:13 os03 kernel: [331036.332185] CPU 5: hi: 186, btch:
31 usd: 180
May 16 09:18:13 os03 kernel: [331036.332187] CPU 6: hi: 186, btch:
31 usd: 156
May 16 09:18:13 os03 kernel: [331036.332189] CPU 7: hi: 186, btch:
31 usd: 182
May 16 09:18:13 os03 kernel: [331036.332195] active_anon:389538
inactive_anon:91572 isolated_anon:0
May 16 09:18:13 os03 kernel: [331036.332196] active_file:2597361
inactive_file:2476894 isolated_file:0
May 16 09:18:13 os03 kernel: [331036.332198] unevictable:123699
dirty:66164 writeback:11426 unstable:0
May 16 09:18:13 os03 kernel: [331036.332199] free:254614
slab_reclaimable:53393 slab_unreclaimable:15304
May 16 09:18:13 os03 kernel: [331036.332201] mapped:1251 shmem:91580
pagetables:1404 bounce:0
May 16 09:18:13 os03 kernel: [331036.332203] Node 0 DMA free:15852kB
min:328kB low:408kB high:492kB active_anon:0kB inactive_anon:0kB
active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:15660kB 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
May 16 09:18:13 os03 kernel: [331036.332214] lowmem_reserve[]: 0 2991
24201 24201
May 16 09:18:13 os03 kernel: [331036.332217] Node 0 DMA32
free:426948kB min:64764kB low:80952kB high:97144kB
active_anon:135484kB inactive_anon:0kB active_file:1133516kB
inactive_file:1093352kB unevictable:49788kB isolated(anon):0kB
isolated(file):0kB present:3063392kB mlocked:0kB dirty:110436kB
writeback:284kB mapped:432kB shmem:0kB slab_reclaimable:46680kB
slab_unreclaimable:5268kB kernel_stack:152kB pagetables:324kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
May 16 09:18:13 os03 kernel: [331036.332229] lowmem_reserve[]: 0 0 21210 21210
May 16 09:18:13 os03 kernel: [331036.332232] Node 0 Normal
free:575656kB min:459188kB low:573984kB high:688780kB
active_anon:1422668kB inactive_anon:366288kB active_file:9255928kB
inactive_file:8814224kB unevictable:445008kB isolated(anon):0kB
isolated(file):0kB present:21719040kB mlocked:0kB dirty:154220kB
writeback:45420kB mapped:4572kB shmem:366320kB
slab_reclaimable:166892kB slab_unreclaimable:55948kB
kernel_stack:3928kB pagetables:5292kB unstable:0kB bounce:0kB
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
May 16 09:18:13 os03 kernel: [331036.332245] lowmem_reserve[]: 0 0 0 0
May 16 09:18:13 os03 kernel: [331036.332248] Node 0 DMA: 1*4kB 1*8kB
0*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB
3*4096kB = 15852kB
May 16 09:18:13 os03 kernel: [331036.332256] Node 0 DMA32: 55808*4kB
24890*8kB 3*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB
0*2048kB 1*4096kB = 426496kB
May 16 09:18:13 os03 kernel: [331036.332264] Node 0 Normal: 142372*4kB
49*8kB 67*16kB 48*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB
0*2048kB 1*4096kB = 576648kB
May 16 09:18:13 os03 kernel: [331036.332272] 5289868 total pagecache pages
May 16 09:18:13 os03 kernel: [331036.332274] 0 pages in swap cache
Is there any way to further identify which is causing this bug? Any
help appreciated.
Greetings Stefan
On Tue, May 10, 2011 at 9:06 PM, Brandeburg, Jesse
<jesse.brandeburg@intel.com> wrote:
> Adding e1000-devel, our list for the out-of-tree ixgbe driver (the issue is reported below to be in both upstream and out-of-tree)
>
> do you have jumbo frames enabled?
>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Stefan Majer
> Sent: Tuesday, May 10, 2011 9:03 AM
> To: netdev@vger.kernel.org
> Subject: Kernel 2.6.38.6 page allocation failure (ixgbe)
>
> Hi,
>
> im running 4 nodes with ceph on top of btrfs with a dualport Intel
> X520 10Gb Ethernet Card with the latest 3.3.9 ixgbe driver.
> during benchmarks i get the following stack.
> I can easily reproduce this by simply running rados bench from a fast
> machine using this 4 nodes as ceph cluster.
> We saw this with stock ixgbe driver from 2.6.38.6 and with the latest
> 3.3.9 ixgbe.
> This kernel is tainted because we use fusion-io iodrives as journal
> devices for btrfs.
>
> Any hints to nail this down are welcome.
>
> Greetings Stefan Majer
>
> May 10 15:26:40 os02 kernel: [ 3652.485219] cosd: page allocation
> failure. order:2, mode:0x4020
> May 10 15:26:40 os02 kernel: [ 3652.485223] kswapd0: page allocation
> failure. order:2, mode:0x4020
> May 10 15:26:40 os02 kernel: [ 3652.485228] Pid: 57, comm: kswapd0
> Tainted: P W 2.6.38.6-1.fits.1.el6.x86_64 #1
> May 10 15:26:40 os02 kernel: [ 3652.485230] Call Trace:
> May 10 15:26:40 os02 kernel: [ 3652.485232] <IRQ>
> [<ffffffff81108ce7>] ? __alloc_pages_nodemask+0x6f7/0x8a0
> May 10 15:26:40 os02 kernel: [ 3652.485247] [<ffffffff814b0ad0>] ?
> ip_local_deliver+0x80/0x90
> May 10 15:26:40 os02 kernel: [ 3652.485250] cosd: page allocation
> failure. order:2, mode:0x4020
> May 10 15:26:40 os02 kernel: [ 3652.485256] [<ffffffff81146cd2>] ?
> kmalloc_large_node+0x62/0xb0
> May 10 15:26:40 os02 kernel: [ 3652.485259] Pid: 1849, comm: cosd
> Tainted: P W 2.6.38.6-1.fits.1.el6.x86_64 #1
> May 10 15:26:40 os02 kernel: [ 3652.485261] Call Trace:
> May 10 15:26:40 os02 kernel: [ 3652.485264] [<ffffffff8114becb>] ?
> __kmalloc_node_track_caller+0x15b/0x1d0
> May 10 15:26:40 os02 kernel: [ 3652.485266] <IRQ>
> [<ffffffff81466f74>] ? __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3652.485274] [<ffffffff81108ce7>] ?
> __alloc_pages_nodemask+0x6f7/0x8a0
> May 10 15:26:40 os02 kernel: [ 3652.485277] [<ffffffff81466713>] ?
> __alloc_skb+0x83/0x170
> May 10 15:26:40 os02 kernel: [ 3652.485281] [<ffffffff814b0ad0>] ?
> ip_local_deliver+0x80/0x90
> May 10 15:26:40 os02 kernel: [ 3652.485283] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3652.485287] [<ffffffff81146cd2>] ?
> kmalloc_large_node+0x62/0xb0
> May 10 15:26:40 os02 kernel: [ 3652.485297] [<ffffffffa005d9aa>] ?
> ixgbe_alloc_rx_buffers+0x9a/0x450 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3652.485300] [<ffffffff8114becb>] ?
> __kmalloc_node_track_caller+0x15b/0x1d0
> May 10 15:26:40 os02 kernel: [ 3652.485305] [<ffffffff812b79e0>] ?
> swiotlb_map_page+0x0/0x110
> May 10 15:26:40 os02 kernel: [ 3652.485308] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3652.485315] [<ffffffffa0060930>] ?
> ixgbe_poll+0x1140/0x1670 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3652.485318] [<ffffffff81466713>] ?
> __alloc_skb+0x83/0x170
> May 10 15:26:40 os02 kernel: [ 3652.485323] [<ffffffff810f33eb>] ?
> perf_pmu_enable+0x2b/0x40
> May 10 15:26:40 os02 kernel: [ 3652.485326] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3652.485330] [<ffffffff81474eb2>] ?
> net_rx_action+0x102/0x2a0
> May 10 15:26:40 os02 kernel: [ 3652.485336] [<ffffffffa005d9aa>] ?
> ixgbe_alloc_rx_buffers+0x9a/0x450 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3652.485341] [<ffffffff8106b745>] ?
> __do_softirq+0xb5/0x210
> May 10 15:26:40 os02 kernel: [ 3652.485344] [<ffffffff81474840>] ?
> napi_skb_finish+0x50/0x70
> May 10 15:26:40 os02 kernel: [ 3652.485348] [<ffffffff810c7ca4>] ?
> handle_IRQ_event+0x54/0x180
> May 10 15:26:40 os02 kernel: [ 3652.485354] [<ffffffffa0060930>] ?
> ixgbe_poll+0x1140/0x1670 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3652.485357] [<ffffffff8106b7bd>] ?
> __do_softirq+0x12d/0x210
> May 10 15:26:40 os02 kernel: [ 3652.485360] [<ffffffff810f33eb>] ?
> perf_pmu_enable+0x2b/0x40
> May 10 15:26:40 os02 kernel: [ 3652.485364] [<ffffffff8100cf3c>] ?
> call_softirq+0x1c/0x30
> May 10 15:26:40 os02 kernel: [ 3652.485367] [<ffffffff81474eb2>] ?
> net_rx_action+0x102/0x2a0
> May 10 15:26:40 os02 kernel: [ 3652.485369] [<ffffffff8100e975>] ?
> do_softirq+0x65/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.485372] [<ffffffff8106b745>] ?
> __do_softirq+0xb5/0x210
> May 10 15:26:40 os02 kernel: [ 3652.485375] [<ffffffff8106b605>] ?
> irq_exit+0x95/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.485379] [<ffffffff810c7ca4>] ?
> handle_IRQ_event+0x54/0x180
> May 10 15:26:40 os02 kernel: [ 3652.485383] [<ffffffff8154a276>] ?
> do_IRQ+0x66/0xe0
> May 10 15:26:40 os02 kernel: [ 3652.485386] [<ffffffff8106b7bd>] ?
> __do_softirq+0x12d/0x210
> May 10 15:26:40 os02 kernel: [ 3652.485389] [<ffffffff81542a53>] ?
> ret_from_intr+0x0/0x15
> May 10 15:26:40 os02 kernel: [ 3652.485391] <EOI>
> [<ffffffff8100cf3c>] ? call_softirq+0x1c/0x30
> May 10 15:26:40 os02 kernel: [ 3652.485397] [<ffffffff81110a54>] ?
> shrink_inactive_list+0x164/0x460
> May 10 15:26:40 os02 kernel: [ 3652.485400] [<ffffffff8100e975>] ?
> do_softirq+0x65/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.485404] [<ffffffff8153facc>] ?
> schedule+0x44c/0xa10
> May 10 15:26:40 os02 kernel: [ 3652.485407] [<ffffffff8106b605>] ?
> irq_exit+0x95/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.485412] [<ffffffff81109b1a>] ?
> determine_dirtyable_memory+0x1a/0x30
> May 10 15:26:40 os02 kernel: [ 3652.485416] [<ffffffff8154a276>] ?
> do_IRQ+0x66/0xe0
> May 10 15:26:40 os02 kernel: [ 3652.485419] [<ffffffff81111453>] ?
> shrink_zone+0x3d3/0x530
> May 10 15:26:40 os02 kernel: [ 3652.485422] [<ffffffff81542a53>] ?
> ret_from_intr+0x0/0x15
> May 10 15:26:40 os02 kernel: [ 3652.485423] <EOI>
> [<ffffffff81074a4a>] ? del_timer_sync+0x3a/0x60
> May 10 15:26:40 os02 kernel: [ 3652.485430] [<ffffffff812a774d>] ?
> copy_user_generic_string+0x2d/0x40
> May 10 15:26:40 os02 kernel: [ 3652.485435] [<ffffffff811054a5>] ?
> zone_watermark_ok_safe+0xb5/0xd0
> May 10 15:26:40 os02 kernel: [ 3652.485439] [<ffffffff810ff351>] ?
> iov_iter_copy_from_user_atomic+0x101/0x170
> May 10 15:26:40 os02 kernel: [ 3652.485442] [<ffffffff81112a69>] ?
> kswapd+0x889/0xb20
> May 10 15:26:40 os02 kernel: [ 3652.485457] [<ffffffffa026c91d>] ?
> btrfs_copy_from_user+0xcd/0x130 [btrfs]
> May 10 15:26:40 os02 kernel: [ 3652.485460] [<ffffffff811121e0>] ?
> kswapd+0x0/0xb20
> May 10 15:26:40 os02 kernel: [ 3652.485472] [<ffffffffa026d844>] ?
> __btrfs_buffered_write+0x1a4/0x330 [btrfs]
> May 10 15:26:40 os02 kernel: [ 3652.485476] [<ffffffff810862b6>] ?
> kthread+0x96/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.485479] [<ffffffff8117151f>] ?
> file_update_time+0x5f/0x170
> May 10 15:26:40 os02 kernel: [ 3652.485482] [<ffffffff8100ce44>] ?
> kernel_thread_helper+0x4/0x10
> May 10 15:26:40 os02 kernel: [ 3652.485493] [<ffffffffa026dc08>] ?
> btrfs_file_aio_write+0x238/0x4e0 [btrfs]
> May 10 15:26:40 os02 kernel: [ 3652.485496] [<ffffffff81086220>] ?
> kthread+0x0/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.485507] [<ffffffffa026d9d0>] ?
> btrfs_file_aio_write+0x0/0x4e0 [btrfs]
> May 10 15:26:40 os02 kernel: [ 3652.485511] [<ffffffff8100ce40>] ?
> kernel_thread_helper+0x0/0x10
> May 10 15:26:40 os02 kernel: [ 3652.485515] [<ffffffff81158ff3>] ?
> do_sync_readv_writev+0xd3/0x110
> May 10 15:26:40 os02 kernel: [ 3652.485516] Mem-Info:
> May 10 15:26:40 os02 kernel: [ 3652.485519] [<ffffffff81163d42>] ?
> path_put+0x22/0x30
> May 10 15:26:40 os02 kernel: [ 3652.485521] Node 0 DMA per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.485525] [<ffffffff812584a3>] ?
> selinux_file_permission+0xf3/0x150
> May 10 15:26:40 os02 kernel: [ 3652.485528] CPU 0: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485530] CPU 1: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485534] [<ffffffff81251583>] ?
> security_file_permission+0x23/0x90
> May 10 15:26:40 os02 kernel: [ 3652.485535] CPU 2: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485538] CPU 3: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485542] [<ffffffff81159f14>] ?
> do_readv_writev+0xd4/0x1e0
> May 10 15:26:40 os02 kernel: [ 3652.485544] CPU 4: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485547] CPU 5: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485550] [<ffffffff81540d91>] ?
> mutex_lock+0x31/0x60
> May 10 15:26:40 os02 kernel: [ 3652.485552] CPU 6: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485554] CPU 7: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485557] [<ffffffff8115a066>] ?
> vfs_writev+0x46/0x60
> May 10 15:26:40 os02 kernel: [ 3652.485558] Node 0 DMA32 per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.485562] [<ffffffff8115a1a1>] ?
> sys_writev+0x51/0xc0
> May 10 15:26:40 os02 kernel: [ 3652.485564] CPU 0: hi: 186, btch:
> 31 usd: 144
> May 10 15:26:40 os02 kernel: [ 3652.485567] CPU 1: hi: 186, btch:
> 31 usd: 198
> May 10 15:26:40 os02 kernel: [ 3652.485571] [<ffffffff8100c002>] ?
> system_call_fastpath+0x16/0x1b
> May 10 15:26:40 os02 kernel: [ 3652.485573] CPU 2: hi: 186, btch:
> 31 usd: 180
> May 10 15:26:40 os02 kernel: [ 3652.485574] Mem-Info:
> May 10 15:26:40 os02 kernel: [ 3652.485576] CPU 3: hi: 186, btch:
> 31 usd: 171
> May 10 15:26:40 os02 kernel: [ 3652.485578] Node 0 CPU 4: hi: 186,
> btch: 31 usd: 159
> May 10 15:26:40 os02 kernel: [ 3652.485581] DMA per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.485582] CPU 5: hi: 186, btch:
> 31 usd: 69
> May 10 15:26:40 os02 kernel: [ 3652.485585] CPU 0: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485587] CPU 6: hi: 186, btch:
> 31 usd: 180
> May 10 15:26:40 os02 kernel: [ 3652.485589] CPU 1: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485591] CPU 7: hi: 186, btch:
> 31 usd: 184
> May 10 15:26:40 os02 kernel: [ 3652.485593] CPU 2: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485594] Node 0 CPU 3: hi: 0,
> btch: 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485597] Normal per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.485598] CPU 4: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485600] CPU 0: hi: 186, btch:
> 31 usd: 100
> May 10 15:26:40 os02 kernel: [ 3652.485602] CPU 5: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485604] CPU 1: hi: 186, btch:
> 31 usd: 47
> May 10 15:26:40 os02 kernel: [ 3652.485606] CPU 6: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485608] CPU 2: hi: 186, btch:
> 31 usd: 168
> May 10 15:26:40 os02 kernel: [ 3652.485610] CPU 7: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485612] CPU 3: hi: 186, btch:
> 31 usd: 140
> May 10 15:26:40 os02 kernel: [ 3652.485614] Node 0 CPU 4: hi: 186,
> btch: 31 usd: 177
> May 10 15:26:40 os02 kernel: [ 3652.485617] DMA32 per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.485618] CPU 5: hi: 186, btch:
> 31 usd: 77
> May 10 15:26:40 os02 kernel: [ 3652.485621] CPU 0: hi: 186, btch:
> 31 usd: 144
> May 10 15:26:40 os02 kernel: [ 3652.485623] CPU 6: hi: 186, btch:
> 31 usd: 168
> May 10 15:26:40 os02 kernel: [ 3652.485625] CPU 1: hi: 186, btch:
> 31 usd: 198
> May 10 15:26:40 os02 kernel: [ 3652.485627] CPU 7: hi: 186, btch:
> 31 usd: 68
> May 10 15:26:40 os02 kernel: [ 3652.485629] CPU 2: hi: 186, btch:
> 31 usd: 180
> May 10 15:26:40 os02 kernel: [ 3652.485634] active_anon:255806
> inactive_anon:19454 isolated_anon:0
> May 10 15:26:40 os02 kernel: [ 3652.485636] active_file:420093
> inactive_file:5180559 isolated_file:0
> May 10 15:26:40 os02 kernel: [ 3652.485637] unevictable:50582
> dirty:314034 writeback:8484 unstable:0
> May 10 15:26:40 os02 kernel: [ 3652.485639] free:30074
> slab_reclaimable:35739 slab_unreclaimable:13526
> May 10 15:26:40 os02 kernel: [ 3652.485641] mapped:3440 shmem:51
> pagetables:1342 bounce:0
> May 10 15:26:40 os02 kernel: [ 3652.485643] CPU 3: hi: 186, btch:
> 31 usd: 171
> May 10 15:26:40 os02 kernel: [ 3652.485644] Node 0 CPU 4: hi: 186,
> btch: 31 usd: 159
> May 10 15:26:40 os02 kernel: [ 3652.485652] DMA free:15852kB min:12kB
> low:12kB high:16kB active_anon:0kB inactive_anon:0kB active_file:0kB
> inactive_file:0kB unevictable:0kB isolated(anon):0kB
> isolated(file):0kB present:15660kB 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
> May 10 15:26:40 os02 kernel: [ 3652.485659] CPU 5: hi: 186, btch:
> 31 usd: 69
> May 10 15:26:40 os02 kernel: [ 3652.485661] lowmem_reserve[]:CPU 6:
> hi: 186, btch: 31 usd: 180
> May 10 15:26:40 os02 kernel: [ 3652.485663] 0CPU 7: hi: 186,
> btch: 31 usd: 184
> May 10 15:26:40 os02 kernel: [ 3652.485665] 2991Node 0 24201Normal per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.485668] 24201CPU 0: hi: 186,
> btch: 31 usd: 100
> May 10 15:26:40 os02 kernel: [ 3652.485671]
> May 10 15:26:40 os02 kernel: [ 3652.485672] CPU 1: hi: 186, btch:
> 31 usd: 47
> May 10 15:26:40 os02 kernel: [ 3652.485674] Node 0 CPU 2: hi: 186,
> btch: 31 usd: 168
> May 10 15:26:40 os02 kernel: [ 3652.485682] DMA32 free:85748kB
> min:2460kB low:3072kB high:3688kB active_anon:20480kB
> inactive_anon:5268kB active_file:151588kB inactive_file:2645188kB
> unevictable:72kB isolated(anon):0kB isolated(file):0kB
> present:3063392kB mlocked:0kB dirty:210820kB writeback:0kB
> mapped:648kB shmem:0kB slab_reclaimable:28400kB
> slab_unreclaimable:2152kB kernel_stack:520kB pagetables:100kB
> unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
> all_unreclaimable? no
> May 10 15:26:40 os02 kernel: [ 3652.485690] CPU 3: hi: 186, btch:
> 31 usd: 140
> May 10 15:26:40 os02 kernel: [ 3652.485691] lowmem_reserve[]:CPU 4:
> hi: 186, btch: 31 usd: 177
> May 10 15:26:40 os02 kernel: [ 3652.485693] 0CPU 5: hi: 186,
> btch: 31 usd: 77
> May 10 15:26:40 os02 kernel: [ 3652.485696] 0CPU 6: hi: 186,
> btch: 31 usd: 168
> May 10 15:26:40 os02 kernel: [ 3652.485698] 21210CPU 7: hi: 186,
> btch: 31 usd: 68
> May 10 15:26:40 os02 kernel: [ 3652.485701] 21210active_anon:255806
> inactive_anon:19454 isolated_anon:0
> May 10 15:26:40 os02 kernel: [ 3652.485705] active_file:420093
> inactive_file:5180559 isolated_file:0
> May 10 15:26:40 os02 kernel: [ 3652.485706] unevictable:50582
> dirty:314034 writeback:8484 unstable:0
> May 10 15:26:40 os02 kernel: [ 3652.485707] free:30074
> slab_reclaimable:35739 slab_unreclaimable:13526
> May 10 15:26:40 os02 kernel: [ 3652.485708] mapped:3440 shmem:51
> pagetables:1342 bounce:0
> May 10 15:26:40 os02 kernel: [ 3652.485709]
> May 10 15:26:40 os02 kernel: [ 3652.485710] Node 0 Node 0 DMA
> free:15852kB min:12kB low:12kB high:16kB active_anon:0kB
> inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
> isolated(anon):0kB isolated(file):0kB present:15660kB 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
> May 10 15:26:40 os02 kernel: [ 3652.485724] Normal free:18696kB
> min:17440kB low:21800kB high:26160kB active_anon:1002744kB
> inactive_anon:72548kB active_file:1528784kB inactive_file:18077048kB
> unevictable:202256kB isolated(anon):0kB isolated(file):0kB
> present:21719040kB mlocked:0kB dirty:1045316kB writeback:33936kB
> mapped:13112kB shmem:204kB slab_reclaimable:114556kB
> slab_unreclaimable:51952kB kernel_stack:3768kB pagetables:5268kB
> unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:32
> all_unreclaimable? no
> May 10 15:26:40 os02 kernel: [ 3652.485731]
> lowmem_reserve[]:lowmem_reserve[]: 0 0 2991 0 24201 0 24201 0
> May 10 15:26:40 os02 kernel: [ 3652.485737]
> May 10 15:26:40 os02 kernel: [ 3652.485738] Node 0 Node 0 DMA32
> free:85748kB min:2460kB low:3072kB high:3688kB active_anon:20480kB
> inactive_anon:5268kB active_file:151588kB inactive_file:2645188kB
> unevictable:72kB isolated(anon):0kB isolated(file):0kB
> present:3063392kB mlocked:0kB dirty:210820kB writeback:0kB
> mapped:648kB shmem:0kB slab_reclaimable:28400kB
> slab_unreclaimable:2152kB kernel_stack:520kB pagetables:100kB
> unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
> all_unreclaimable? no
> May 10 15:26:40 os02 kernel: [ 3652.485747] DMA:
> lowmem_reserve[]:1*4kB 01*8kB 00*16kB 212101*32kB 212101*64kB
> May 10 15:26:40 os02 kernel: [ 3652.485754] 1*128kB Node 0 1*256kB
> Normal free:18696kB min:17440kB low:21800kB high:26160kB
> active_anon:1002744kB inactive_anon:72548kB active_file:1528784kB
> inactive_file:18077048kB unevictable:202256kB isolated(anon):0kB
> isolated(file):0kB present:21719040kB mlocked:0kB dirty:1045316kB
> writeback:33936kB mapped:13112kB shmem:204kB slab_reclaimable:114556kB
> slab_unreclaimable:51952kB kernel_stack:3768kB pagetables:5268kB
> unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:32
> all_unreclaimable? no
> May 10 15:26:40 os02 kernel: [ 3652.485764] 0*512kB
> lowmem_reserve[]:1*1024kB 01*2048kB 03*4096kB 0= 15852kB
> May 10 15:26:40 os02 kernel: [ 3652.485771] 0Node 0
> May 10 15:26:40 os02 kernel: [ 3652.485773] DMA32: Node 0 59*4kB DMA:
> 125*8kB 1*4kB 66*16kB 1*8kB 80*32kB 0*16kB 188*64kB 1*32kB 51*128kB
> 1*64kB 15*256kB 1*128kB 40*512kB 1*256kB 31*1024kB 0*512kB 1*2048kB
> 1*1024kB 1*4096kB 1*2048kB = 85620kB
> May 10 15:26:40 os02 kernel: [ 3652.485789] 3*4096kB Node 0 = 15852kB
> May 10 15:26:40 os02 kernel: [ 3652.485791] Normal: Node 0 3930*4kB
> DMA32: 0*8kB 59*4kB 1*16kB 125*8kB 0*32kB 66*16kB 0*64kB 80*32kB
> 0*128kB 188*64kB 1*256kB 51*128kB 1*512kB 15*256kB 0*1024kB 40*512kB
> 1*2048kB 31*1024kB 0*4096kB 1*2048kB = 18552kB
> May 10 15:26:40 os02 kernel: [ 3652.485807] 1*4096kB 5651289 total
> pagecache pages
> May 10 15:26:40 os02 kernel: [ 3652.485809] = 85620kB
> May 10 15:26:40 os02 kernel: [ 3652.485810] 0 pages in swap cache
> May 10 15:26:40 os02 kernel: [ 3652.485811] Node 0 Swap cache stats:
> add 0, delete 0, find 0/0
> May 10 15:26:40 os02 kernel: [ 3652.485814] Normal: Free swap = 1048572kB
> May 10 15:26:40 os02 kernel: [ 3652.485815] 3930*4kB Total swap = 1048572kB
> May 10 15:26:40 os02 kernel: [ 3652.485817] 0*8kB 1*16kB 0*32kB 0*64kB
> 0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 18552kB
> May 10 15:26:40 os02 kernel: [ 3652.485822] 5651289 total pagecache pages
> May 10 15:26:40 os02 kernel: [ 3652.485823] 0 pages in swap cache
> May 10 15:26:40 os02 kernel: [ 3652.485824] Swap cache stats: add 0,
> delete 0, find 0/0
> May 10 15:26:40 os02 kernel: [ 3652.485825] Free swap = 1048572kB
> May 10 15:26:40 os02 kernel: [ 3652.485826] Total swap = 1048572kB
> May 10 15:26:40 os02 kernel: [ 3652.486439] kworker/0:1: page
> allocation failure. order:2, mode:0x4020
> May 10 15:26:40 os02 kernel: [ 3652.486443] Pid: 0, comm: kworker/0:1
> Tainted: P W 2.6.38.6-1.fits.1.el6.x86_64 #1
> May 10 15:26:40 os02 kernel: [ 3652.486446] Call Trace:
> May 10 15:26:40 os02 kernel: [ 3652.486448] <IRQ>
> [<ffffffff81108ce7>] ? __alloc_pages_nodemask+0x6f7/0x8a0
> May 10 15:26:40 os02 kernel: [ 3652.486459] [<ffffffff814b0ad0>] ?
> ip_local_deliver+0x80/0x90
> May 10 15:26:40 os02 kernel: [ 3652.486464] [<ffffffff81146cd2>] ?
> kmalloc_large_node+0x62/0xb0
> May 10 15:26:40 os02 kernel: [ 3652.486468] [<ffffffff8114becb>] ?
> __kmalloc_node_track_caller+0x15b/0x1d0
> May 10 15:26:40 os02 kernel: [ 3652.486473] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3652.486476] [<ffffffff81466713>] ?
> __alloc_skb+0x83/0x170
> May 10 15:26:40 os02 kernel: [ 3652.486479] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3652.486489] [<ffffffffa005d9aa>] ?
> ixgbe_alloc_rx_buffers+0x9a/0x450 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3652.486494] [<ffffffff81474840>] ?
> napi_skb_finish+0x50/0x70
> May 10 15:26:40 os02 kernel: [ 3652.486501] [<ffffffffa0060930>] ?
> ixgbe_poll+0x1140/0x1670 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3652.486506] [<ffffffff81013379>] ?
> sched_clock+0x9/0x10
> May 10 15:26:40 os02 kernel: [ 3652.486510] [<ffffffff81474eb2>] ?
> net_rx_action+0x102/0x2a0
> May 10 15:26:40 os02 kernel: [ 3652.486514] [<ffffffff8106b745>] ?
> __do_softirq+0xb5/0x210
> May 10 15:26:40 os02 kernel: [ 3652.486520] [<ffffffff8108aec4>] ?
> hrtimer_interrupt+0x134/0x240
> May 10 15:26:40 os02 kernel: [ 3652.486523] [<ffffffff8100cf3c>] ?
> call_softirq+0x1c/0x30
> May 10 15:26:40 os02 kernel: [ 3652.486526] [<ffffffff8100e975>] ?
> do_softirq+0x65/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.486529] [<ffffffff8106b605>] ?
> irq_exit+0x95/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.486533] [<ffffffff8154a360>] ?
> smp_apic_timer_interrupt+0x70/0x9b
> May 10 15:26:40 os02 kernel: [ 3652.486536] [<ffffffff8100c9f3>] ?
> apic_timer_interrupt+0x13/0x20
> May 10 15:26:40 os02 kernel: [ 3652.486538] <EOI>
> [<ffffffff812db311>] ? intel_idle+0xc1/0x120
> May 10 15:26:40 os02 kernel: [ 3652.486544] [<ffffffff812db2f4>] ?
> intel_idle+0xa4/0x120
> May 10 15:26:40 os02 kernel: [ 3652.486549] [<ffffffff8143bca5>] ?
> cpuidle_idle_call+0xb5/0x240
> May 10 15:26:40 os02 kernel: [ 3652.486554] [<ffffffff8100aa87>] ?
> cpu_idle+0xb7/0x110
> May 10 15:26:40 os02 kernel: [ 3652.486558] [<ffffffff81538ffe>] ?
> start_secondary+0x21f/0x221
> May 10 15:26:40 os02 kernel: [ 3652.486561] Mem-Info:
> May 10 15:26:40 os02 kernel: [ 3652.486562] Node 0 DMA per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.486564] CPU 0: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486567] CPU 1: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486569] CPU 2: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486571] CPU 3: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486573] CPU 4: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486575] CPU 5: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486578] CPU 6: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486580] CPU 7: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486581] Node 0 DMA32 per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.486584] CPU 0: hi: 186, btch:
> 31 usd: 144
> May 10 15:26:40 os02 kernel: [ 3652.486586] CPU 1: hi: 186, btch:
> 31 usd: 198
> May 10 15:26:40 os02 kernel: [ 3652.486588] CPU 2: hi: 186, btch:
> 31 usd: 180
> May 10 15:26:40 os02 kernel: [ 3652.486590] CPU 3: hi: 186, btch:
> 31 usd: 172
> May 10 15:26:40 os02 kernel: [ 3652.486593] CPU 4: hi: 186, btch:
> 31 usd: 159
> May 10 15:26:40 os02 kernel: [ 3652.486595] CPU 5: hi: 186, btch:
> 31 usd: 69
> May 10 15:26:40 os02 kernel: [ 3652.486597] CPU 6: hi: 186, btch:
> 31 usd: 180
> May 10 15:26:40 os02 kernel: [ 3652.486599] CPU 7: hi: 186, btch:
> 31 usd: 184
> May 10 15:26:40 os02 kernel: [ 3652.486601] Node 0 Normal per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.486603] CPU 0: hi: 186, btch:
> 31 usd: 162
> May 10 15:26:40 os02 kernel: [ 3652.486605] CPU 1: hi: 186, btch:
> 31 usd: 47
> May 10 15:26:40 os02 kernel: [ 3652.486608] CPU 2: hi: 186, btch:
> 31 usd: 168
> May 10 15:26:40 os02 kernel: [ 3652.486610] CPU 3: hi: 186, btch:
> 31 usd: 141
> May 10 15:26:40 os02 kernel: [ 3652.486612] CPU 4: hi: 186, btch:
> 31 usd: 177
> May 10 15:26:40 os02 kernel: [ 3652.486614] CPU 5: hi: 186, btch:
> 31 usd: 77
> May 10 15:26:40 os02 kernel: [ 3652.486616] CPU 6: hi: 186, btch:
> 31 usd: 168
> May 10 15:26:40 os02 kernel: [ 3652.486618] CPU 7: hi: 186, btch:
> 31 usd: 174
> May 10 15:26:40 os02 kernel: [ 3652.486624] active_anon:255806
> inactive_anon:19454 isolated_anon:0
> May 10 15:26:40 os02 kernel: [ 3652.486625] active_file:420093
> inactive_file:5180745 isolated_file:0
> May 10 15:26:40 os02 kernel: [ 3652.486627] unevictable:50582
> dirty:314470 writeback:8484 unstable:0
> May 10 15:26:40 os02 kernel: [ 3652.486628] free:29795
> slab_reclaimable:35739 slab_unreclaimable:13526
> May 10 15:26:40 os02 kernel: [ 3652.486629] mapped:3440 shmem:51
> pagetables:1342 bounce:0
> May 10 15:26:40 os02 kernel: [ 3652.486631] Node 0 DMA free:15852kB
> min:12kB low:12kB high:16kB active_anon:0kB inactive_anon:0kB
> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> isolated(file):0kB present:15660kB 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
> May 10 15:26:40 os02 kernel: [ 3652.486642] lowmem_reserve[]: 0 2991 24201 24201
> May 10 15:26:40 os02 kernel: [ 3652.486645] Node 0 DMA32 free:85748kB
> min:2460kB low:3072kB high:3688kB active_anon:20480kB
> inactive_anon:5268kB active_file:151588kB inactive_file:2645188kB
> unevictable:72kB isolated(anon):0kB isolated(file):0kB
> present:3063392kB mlocked:0kB dirty:210820kB writeback:0kB
> mapped:648kB shmem:0kB slab_reclaimable:28400kB
> slab_unreclaimable:2152kB kernel_stack:520kB pagetables:100kB
> unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
> all_unreclaimable? no
> May 10 15:26:40 os02 kernel: [ 3652.486657] lowmem_reserve[]: 0 0 21210 21210
> May 10 15:26:40 os02 kernel: [ 3652.486660] Node 0 Normal free:17580kB
> min:17440kB low:21800kB high:26160kB active_anon:1002744kB
> inactive_anon:72548kB active_file:1528784kB inactive_file:18077792kB
> unevictable:202256kB isolated(anon):0kB isolated(file):0kB
> present:21719040kB mlocked:0kB dirty:1047060kB writeback:33936kB
> mapped:13112kB shmem:204kB slab_reclaimable:114556kB
> slab_unreclaimable:51952kB kernel_stack:3768kB pagetables:5268kB
> unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:64
> all_unreclaimable? no
> May 10 15:26:40 os02 kernel: [ 3652.486673] lowmem_reserve[]: 0 0 0 0
> May 10 15:26:40 os02 kernel: [ 3652.486675] Node 0 DMA: 1*4kB 1*8kB
> 0*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB
> 3*4096kB = 15852kB
> May 10 15:26:40 os02 kernel: [ 3652.486684] Node 0 DMA32: 59*4kB
> 125*8kB 66*16kB 80*32kB 188*64kB 51*128kB 15*256kB 40*512kB 31*1024kB
> 1*2048kB 1*4096kB = 85620kB
> May 10 15:26:40 os02 kernel: [ 3652.486692] Node 0 Normal: 3705*4kB
> 12*8kB 16*16kB 4*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB
> 0*4096kB = 18180kB
> May 10 15:26:40 os02 kernel: [ 3652.486700] 5651289 total pagecache pages
> May 10 15:26:40 os02 kernel: [ 3652.486702] 0 pages in swap cache
> May 10 15:26:40 os02 kernel: [ 3652.486704] Swap cache stats: add 0,
> delete 0, find 0/0
> May 10 15:26:40 os02 kernel: [ 3652.486705] Free swap = 1048572kB
> May 10 15:26:40 os02 kernel: [ 3652.486707] Total swap = 1048572kB
> May 10 15:26:40 os02 kernel: [ 3652.562795] 6291440 pages RAM
> May 10 15:26:40 os02 kernel: [ 3652.562798] 108688 pages reserved
> May 10 15:26:40 os02 kernel: [ 3652.562799] 5429575 pages shared
> May 10 15:26:40 os02 kernel: [ 3652.562801] 783596 pages non-shared
> May 10 15:26:40 os02 kernel: [ 3652.651570] 6291440 pages RAM
> May 10 15:26:40 os02 kernel: [ 3652.651572] 108688 pages reserved
> May 10 15:26:40 os02 kernel: [ 3652.651573] 5430055 pages shared
> May 10 15:26:40 os02 kernel: [ 3652.651575] 782974 pages non-shared
> May 10 15:26:40 os02 kernel: [ 3652.721553] 6291440 pages RAM
> May 10 15:26:40 os02 kernel: [ 3652.721555] 108688 pages reserved
> May 10 15:26:40 os02 kernel: [ 3652.721556] 5430961 pages shared
> May 10 15:26:40 os02 kernel: [ 3652.721557] 781496 pages non-shared
> May 10 15:26:40 os02 kernel: [ 3654.349865] Pid: 1846, comm: cosd
> Tainted: P W 2.6.38.6-1.fits.1.el6.x86_64 #1
> May 10 15:26:40 os02 kernel: [ 3654.358792] Call Trace:
> May 10 15:26:40 os02 kernel: [ 3654.361519] <IRQ>
> [<ffffffff81108ce7>] ? __alloc_pages_nodemask+0x6f7/0x8a0
> May 10 15:26:40 os02 kernel: [ 3654.369495] [<ffffffff814b0ad0>] ?
> ip_local_deliver+0x80/0x90
> May 10 15:26:40 os02 kernel: [ 3654.376005] [<ffffffff81146cd2>] ?
> kmalloc_large_node+0x62/0xb0
> May 10 15:26:40 os02 kernel: [ 3654.382703] [<ffffffff8114becb>] ?
> __kmalloc_node_track_caller+0x15b/0x1d0
> May 10 15:26:40 os02 kernel: [ 3654.390464] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3654.397163] [<ffffffff81466713>] ?
> __alloc_skb+0x83/0x170
> May 10 15:26:40 os02 kernel: [ 3654.403277] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3654.409970] [<ffffffffa005d9aa>] ?
> ixgbe_alloc_rx_buffers+0x9a/0x450 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3654.417926] [<ffffffff812b79e0>] ?
> swiotlb_map_page+0x0/0x110
> May 10 15:26:40 os02 kernel: [ 3654.424432] [<ffffffffa0060930>] ?
> ixgbe_poll+0x1140/0x1670 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3654.431518] [<ffffffff810f33eb>] ?
> perf_pmu_enable+0x2b/0x40
> May 10 15:26:40 os02 kernel: [ 3654.437924] [<ffffffff81474eb2>] ?
> net_rx_action+0x102/0x2a0
> May 10 15:26:40 os02 kernel: [ 3654.444329] [<ffffffff8106b745>] ?
> __do_softirq+0xb5/0x210
> May 10 15:26:40 os02 kernel: [ 3654.450541] [<ffffffff810c7ca4>] ?
> handle_IRQ_event+0x54/0x180
> May 10 15:26:40 os02 kernel: [ 3654.457138] [<ffffffff8106b7bd>] ?
> __do_softirq+0x12d/0x210
> May 10 15:26:40 os02 kernel: [ 3654.463446] [<ffffffff8100cf3c>] ?
> call_softirq+0x1c/0x30
> May 10 15:26:40 os02 kernel: [ 3654.469562] [<ffffffff8100e975>] ?
> do_softirq+0x65/0xa0
> May 10 15:26:40 os02 kernel: [ 3654.475484] [<ffffffff8106b605>] ?
> irq_exit+0x95/0xa0
> May 10 15:26:40 os02 kernel: [ 3654.481218] [<ffffffff8154a276>] ?
> do_IRQ+0x66/0xe0
> May 10 15:26:40 os02 kernel: [ 3654.486754] [<ffffffff81542a53>] ?
> ret_from_intr+0x0/0x15
> May 10 15:26:40 os02 kernel: [ 3654.492867] <EOI>
> [<ffffffff81286919>] ? __make_request+0x149/0x4c0
> May 10 15:26:40 os02 kernel: [ 3654.500061] [<ffffffff812868e4>] ?
> __make_request+0x114/0x4c0
> May 10 15:26:41 os02 kernel: [ 3654.506565] [<ffffffff812841bd>] ?
> generic_make_request+0x2fd/0x5e0
> May 10 15:26:41 os02 kernel: [ 3654.513649] [<ffffffff8142742b>] ?
> dm_get_live_table+0x4b/0x60
> May 10 15:26:41 os02 kernel: [ 3654.520248] [<ffffffff81427bc1>] ?
> dm_merge_bvec+0xc1/0x140
> May 10 15:26:41 os02 kernel: [ 3654.526555] [<ffffffff81284526>] ?
> submit_bio+0x86/0x110
> May 10 15:26:41 os02 kernel: [ 3654.532574] [<ffffffff8118deac>] ?
> dio_bio_submit+0xbc/0xc0
> May 10 15:26:41 os02 kernel: [ 3654.538881] [<ffffffff8118df40>] ?
> dio_send_cur_page+0x90/0xc0
> May 10 15:26:41 os02 kernel: [ 3654.545478] [<ffffffff8118dfd5>] ?
> submit_page_section+0x65/0x180
> May 10 15:26:41 os02 kernel: [ 3654.552370] [<ffffffff8118e918>] ?
> __blockdev_direct_IO+0x678/0xb30
> May 10 15:26:41 os02 kernel: [ 3654.559454] [<ffffffff81250eaf>] ?
> security_inode_getsecurity+0x1f/0x30
> May 10 15:26:41 os02 kernel: [ 3654.566924] [<ffffffff8118c627>] ?
> blkdev_direct_IO+0x57/0x60
> May 10 15:26:41 os02 kernel: [ 3654.573414] [<ffffffff8118b760>] ?
> blkdev_get_blocks+0x0/0xc0
> May 10 15:26:41 os02 kernel: [ 3654.579954] [<ffffffff811008f2>] ?
> generic_file_direct_write+0xc2/0x190
> May 10 15:26:41 os02 kernel: [ 3654.587424] [<ffffffff811715b6>] ?
> file_update_time+0xf6/0x170
> May 10 15:26:41 os02 kernel: [ 3654.594025] [<ffffffff811023eb>] ?
> __generic_file_aio_write+0x32b/0x460
> May 10 15:26:41 os02 kernel: [ 3654.601494] [<ffffffff8105c9e0>] ?
> wake_up_state+0x10/0x20
>
>
>
> and so on.
>
> --
> Stefan Majer
>
>
>
> --
> Stefan Majer
> --
> 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
>
--
Stefan Majer
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Herbert Xu @ 2011-05-16 9:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516081841.GA8073@redhat.com>
On Mon, May 16, 2011 at 11:18:41AM +0300, Michael S. Tsirkin wrote:
>
> There's no interface for userspace to enable it: userspace
> only has an ioctl to enable/disable checksum offloading.
> SG is an implementation detail.
Yes there is: ethtool -K
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
* several packets in a single buffer in Rx
From: Emmanuel Grumbach @ 2011-05-16 9:41 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Johannes Berg, Guy, Wey-Yi, guy.cohen-ral2JQCrhuEAvxtiuMwx3w
Hi,
I am trying to enable a HW feature on a wireless NIC that allows the
HW to put several packets in the same Rx buffer coming from the NIC.
This can save interrupts and traffic on the bus.
Today, the driver allocates pages in which the PCI-e device puts its
data. Then we create an skb and add a fragment that points to the
beginning of the page. The offset of the fragment is set to the offset
of the first byte of the mac header within the buffer. There is only
one packet per page / buffer.
I would like to be able to deliver the same page several times to the
stack without having the stack consume it before the last time I
deliver it.
Of course I would like to avoid cloning it.
I tried to look at shinfo->nr_frags but this looks more like a sgl
related variable
GRO doesn't seem to be related either since as far as I understood, it
is relevant for packets after 802.11 to 802.3 translation.
FWIW: I am talking about Intel's wireless device although I don't
think this fact matters
Thanks
Emmanuel Grumbach
egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michael S. Tsirkin @ 2011-05-16 9:48 UTC (permalink / raw)
To: Herbert Xu; +Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516093822.GA2779@gondor.apana.org.au>
On Mon, May 16, 2011 at 07:38:22PM +1000, Herbert Xu wrote:
> On Mon, May 16, 2011 at 11:18:41AM +0300, Michael S. Tsirkin wrote:
> >
> > There's no interface for userspace to enable it: userspace
> > only has an ioctl to enable/disable checksum offloading.
> > SG is an implementation detail.
>
> Yes there is: ethtool -K
>
> Cheers,
Ok. You are right of course, I was confused.
So it's just an info message: in the end if userspace DTRT features
get enabled properly. Functionally, there is no regression.
Both bridge and tun trigger the messages ATM. I note that
dev.c takes pains to avoid these messages:
Avoid warning from netdev_fix_features() for GSO without SG
Should all drivers do this: clear _SG if they clear checksum? What about _GSO?
If we start doing this, this spills info about flag dependencies out to drivers.
--
MST
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Herbert Xu @ 2011-05-16 10:43 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516094821.GA9427@redhat.com>
On Mon, May 16, 2011 at 12:48:21PM +0300, Michael S. Tsirkin wrote:
>
> Both bridge and tun trigger the messages ATM. I note that
> dev.c takes pains to avoid these messages:
> Avoid warning from netdev_fix_features() for GSO without SG
>
> Should all drivers do this: clear _SG if they clear checksum? What about _GSO?
> If we start doing this, this spills info about flag dependencies out to drivers.
Drivers don't need to do this at all since the network stack
will automatically clear SG and related features if checksum
is disabled.
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-next-2.6] rfkill: remove CONFIG_RFKILL_INPUT
From: Américo Wang @ 2011-05-16 10:44 UTC (permalink / raw)
To: Linux Kernel Network Developers, linux-wireless
Cc: David S. Miller, Johannes Berg, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
This is scheduled to be removed in 2.6.33, now we are at 2.6.39-rc2.
So I think it is safe to remove it completely.
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
---
[-- Attachment #2: net-rfkill-remove-rfkill-input.diff --]
[-- Type: text/x-patch, Size: 18654 bytes --]
Documentation/feature-removal-schedule.txt | 7 -
arch/mips/configs/bcm47xx_defconfig | 1 -
arch/mips/configs/lemote2f_defconfig | 1 -
net/rfkill/Kconfig | 6 -
net/rfkill/Makefile | 1 -
net/rfkill/core.c | 202 ----------------
net/rfkill/input.c | 350 ----------------------------
7 files changed, 0 insertions(+), 568 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 46679e4..ebf2db4 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -345,13 +345,6 @@ Who: Alex Chiang <achiang@hp.com>
---------------------------
-What: CONFIG_RFKILL_INPUT
-When: 2.6.33
-Why: Should be implemented in userspace, policy daemon.
-Who: Johannes Berg <johannes@sipsolutions.net>
-
-----------------------------
-
What: sound-slot/service-* module aliases and related clutters in
sound/sound_core.c
When: August 2010
diff --git a/arch/mips/configs/bcm47xx_defconfig b/arch/mips/configs/bcm47xx_defconfig
index 22fdf2f..3d724ef 100644
--- a/arch/mips/configs/bcm47xx_defconfig
+++ b/arch/mips/configs/bcm47xx_defconfig
@@ -268,7 +268,6 @@ CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_DEFAULT_PID=y
CONFIG_MAC80211_MESH=y
CONFIG_RFKILL=m
-CONFIG_RFKILL_INPUT=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_FW_LOADER=m
CONFIG_CONNECTOR=m
diff --git a/arch/mips/configs/lemote2f_defconfig b/arch/mips/configs/lemote2f_defconfig
index 167c1d0..3ffb909 100644
--- a/arch/mips/configs/lemote2f_defconfig
+++ b/arch/mips/configs/lemote2f_defconfig
@@ -103,7 +103,6 @@ CONFIG_LIB80211_DEBUG=y
CONFIG_MAC80211=m
CONFIG_MAC80211_LEDS=y
CONFIG_RFKILL=m
-CONFIG_RFKILL_INPUT=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=m
diff --git a/net/rfkill/Kconfig b/net/rfkill/Kconfig
index 48464ca..c192603 100644
--- a/net/rfkill/Kconfig
+++ b/net/rfkill/Kconfig
@@ -17,12 +17,6 @@ config RFKILL_LEDS
depends on LEDS_TRIGGERS = y || RFKILL = LEDS_TRIGGERS
default y
-config RFKILL_INPUT
- bool "RF switch input support" if EXPERT
- depends on RFKILL
- depends on INPUT = y || RFKILL = INPUT
- default y if !EXPERT
-
config RFKILL_REGULATOR
tristate "Generic rfkill regulator driver"
depends on RFKILL || !RFKILL
diff --git a/net/rfkill/Makefile b/net/rfkill/Makefile
index d9a5a58..0d5e3e1 100644
--- a/net/rfkill/Makefile
+++ b/net/rfkill/Makefile
@@ -3,6 +3,5 @@
#
rfkill-y += core.o
-rfkill-$(CONFIG_RFKILL_INPUT) += input.o
obj-$(CONFIG_RFKILL) += rfkill.o
obj-$(CONFIG_RFKILL_REGULATOR) += rfkill-regulator.o
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 0198191..47ab44e 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -304,153 +304,6 @@ static void rfkill_set_block(struct rfkill *rfkill, bool blocked)
rfkill_event(rfkill);
}
-#ifdef CONFIG_RFKILL_INPUT
-static atomic_t rfkill_input_disabled = ATOMIC_INIT(0);
-
-/**
- * __rfkill_switch_all - Toggle state of all switches of given type
- * @type: type of interfaces to be affected
- * @state: the new state
- *
- * This function sets the state of all switches of given type,
- * unless a specific switch is claimed by userspace (in which case,
- * that switch is left alone) or suspended.
- *
- * Caller must have acquired rfkill_global_mutex.
- */
-static void __rfkill_switch_all(const enum rfkill_type type, bool blocked)
-{
- struct rfkill *rfkill;
-
- rfkill_global_states[type].cur = blocked;
- list_for_each_entry(rfkill, &rfkill_list, node) {
- if (rfkill->type != type)
- continue;
-
- rfkill_set_block(rfkill, blocked);
- }
-}
-
-/**
- * rfkill_switch_all - Toggle state of all switches of given type
- * @type: type of interfaces to be affected
- * @state: the new state
- *
- * Acquires rfkill_global_mutex and calls __rfkill_switch_all(@type, @state).
- * Please refer to __rfkill_switch_all() for details.
- *
- * Does nothing if the EPO lock is active.
- */
-void rfkill_switch_all(enum rfkill_type type, bool blocked)
-{
- if (atomic_read(&rfkill_input_disabled))
- return;
-
- mutex_lock(&rfkill_global_mutex);
-
- if (!rfkill_epo_lock_active)
- __rfkill_switch_all(type, blocked);
-
- mutex_unlock(&rfkill_global_mutex);
-}
-
-/**
- * rfkill_epo - emergency power off all transmitters
- *
- * This kicks all non-suspended rfkill devices to RFKILL_STATE_SOFT_BLOCKED,
- * ignoring everything in its path but rfkill_global_mutex and rfkill->mutex.
- *
- * The global state before the EPO is saved and can be restored later
- * using rfkill_restore_states().
- */
-void rfkill_epo(void)
-{
- struct rfkill *rfkill;
- int i;
-
- if (atomic_read(&rfkill_input_disabled))
- return;
-
- mutex_lock(&rfkill_global_mutex);
-
- rfkill_epo_lock_active = true;
- list_for_each_entry(rfkill, &rfkill_list, node)
- rfkill_set_block(rfkill, true);
-
- for (i = 0; i < NUM_RFKILL_TYPES; i++) {
- rfkill_global_states[i].sav = rfkill_global_states[i].cur;
- rfkill_global_states[i].cur = true;
- }
-
- mutex_unlock(&rfkill_global_mutex);
-}
-
-/**
- * rfkill_restore_states - restore global states
- *
- * Restore (and sync switches to) the global state from the
- * states in rfkill_default_states. This can undo the effects of
- * a call to rfkill_epo().
- */
-void rfkill_restore_states(void)
-{
- int i;
-
- if (atomic_read(&rfkill_input_disabled))
- return;
-
- mutex_lock(&rfkill_global_mutex);
-
- rfkill_epo_lock_active = false;
- for (i = 0; i < NUM_RFKILL_TYPES; i++)
- __rfkill_switch_all(i, rfkill_global_states[i].sav);
- mutex_unlock(&rfkill_global_mutex);
-}
-
-/**
- * rfkill_remove_epo_lock - unlock state changes
- *
- * Used by rfkill-input manually unlock state changes, when
- * the EPO switch is deactivated.
- */
-void rfkill_remove_epo_lock(void)
-{
- if (atomic_read(&rfkill_input_disabled))
- return;
-
- mutex_lock(&rfkill_global_mutex);
- rfkill_epo_lock_active = false;
- mutex_unlock(&rfkill_global_mutex);
-}
-
-/**
- * rfkill_is_epo_lock_active - returns true EPO is active
- *
- * Returns 0 (false) if there is NOT an active EPO contidion,
- * and 1 (true) if there is an active EPO contition, which
- * locks all radios in one of the BLOCKED states.
- *
- * Can be called in atomic context.
- */
-bool rfkill_is_epo_lock_active(void)
-{
- return rfkill_epo_lock_active;
-}
-
-/**
- * rfkill_get_global_sw_state - returns global state for a type
- * @type: the type to get the global state of
- *
- * Returns the current global state for a given wireless
- * device type.
- */
-bool rfkill_get_global_sw_state(const enum rfkill_type type)
-{
- return rfkill_global_states[type].cur;
-}
-#endif
-
-
bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked)
{
bool ret, change;
@@ -950,13 +803,6 @@ int __must_check rfkill_register(struct rfkill *rfkill)
if (!rfkill->persistent || rfkill_epo_lock_active) {
schedule_work(&rfkill->sync_work);
- } else {
-#ifdef CONFIG_RFKILL_INPUT
- bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
-
- if (!atomic_read(&rfkill_input_disabled))
- __rfkill_switch_all(rfkill->type, soft_blocked);
-#endif
}
rfkill_send_events(rfkill, RFKILL_OP_ADD);
@@ -1179,43 +1025,11 @@ static int rfkill_fop_release(struct inode *inode, struct file *file)
list_for_each_entry_safe(ev, tmp, &data->events, list)
kfree(ev);
-#ifdef CONFIG_RFKILL_INPUT
- if (data->input_handler)
- if (atomic_dec_return(&rfkill_input_disabled) == 0)
- printk(KERN_DEBUG "rfkill: input handler enabled\n");
-#endif
-
kfree(data);
return 0;
}
-#ifdef CONFIG_RFKILL_INPUT
-static long rfkill_fop_ioctl(struct file *file, unsigned int cmd,
- unsigned long arg)
-{
- struct rfkill_data *data = file->private_data;
-
- if (_IOC_TYPE(cmd) != RFKILL_IOC_MAGIC)
- return -ENOSYS;
-
- if (_IOC_NR(cmd) != RFKILL_IOC_NOINPUT)
- return -ENOSYS;
-
- mutex_lock(&data->mtx);
-
- if (!data->input_handler) {
- if (atomic_inc_return(&rfkill_input_disabled) == 1)
- printk(KERN_DEBUG "rfkill: input handler disabled\n");
- data->input_handler = true;
- }
-
- mutex_unlock(&data->mtx);
-
- return 0;
-}
-#endif
-
static const struct file_operations rfkill_fops = {
.owner = THIS_MODULE,
.open = rfkill_fop_open,
@@ -1223,10 +1037,6 @@ static const struct file_operations rfkill_fops = {
.write = rfkill_fop_write,
.poll = rfkill_fop_poll,
.release = rfkill_fop_release,
-#ifdef CONFIG_RFKILL_INPUT
- .unlocked_ioctl = rfkill_fop_ioctl,
- .compat_ioctl = rfkill_fop_ioctl,
-#endif
.llseek = no_llseek,
};
@@ -1254,15 +1064,6 @@ static int __init rfkill_init(void)
goto out;
}
-#ifdef CONFIG_RFKILL_INPUT
- error = rfkill_handler_init();
- if (error) {
- misc_deregister(&rfkill_miscdev);
- class_unregister(&rfkill_class);
- goto out;
- }
-#endif
-
out:
return error;
}
@@ -1270,9 +1071,6 @@ subsys_initcall(rfkill_init);
static void __exit rfkill_exit(void)
{
-#ifdef CONFIG_RFKILL_INPUT
- rfkill_handler_exit();
-#endif
misc_deregister(&rfkill_miscdev);
class_unregister(&rfkill_class);
}
diff --git a/net/rfkill/input.c b/net/rfkill/input.c
deleted file mode 100644
index 1bca6d4..0000000
--- a/net/rfkill/input.c
+++ /dev/null
@@ -1,350 +0,0 @@
-/*
- * Input layer to RF Kill interface connector
- *
- * Copyright (c) 2007 Dmitry Torokhov
- * Copyright 2009 Johannes Berg <johannes@sipsolutions.net>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published
- * by the Free Software Foundation.
- *
- * If you ever run into a situation in which you have a SW_ type rfkill
- * input device, then you can revive code that was removed in the patch
- * "rfkill-input: remove unused code".
- */
-
-#include <linux/input.h>
-#include <linux/slab.h>
-#include <linux/workqueue.h>
-#include <linux/init.h>
-#include <linux/rfkill.h>
-#include <linux/sched.h>
-
-#include "rfkill.h"
-
-enum rfkill_input_master_mode {
- RFKILL_INPUT_MASTER_UNLOCK = 0,
- RFKILL_INPUT_MASTER_RESTORE = 1,
- RFKILL_INPUT_MASTER_UNBLOCKALL = 2,
- NUM_RFKILL_INPUT_MASTER_MODES
-};
-
-/* Delay (in ms) between consecutive switch ops */
-#define RFKILL_OPS_DELAY 200
-
-static enum rfkill_input_master_mode rfkill_master_switch_mode =
- RFKILL_INPUT_MASTER_UNBLOCKALL;
-module_param_named(master_switch_mode, rfkill_master_switch_mode, uint, 0);
-MODULE_PARM_DESC(master_switch_mode,
- "SW_RFKILL_ALL ON should: 0=do nothing (only unlock); 1=restore; 2=unblock all");
-
-static spinlock_t rfkill_op_lock;
-static bool rfkill_op_pending;
-static unsigned long rfkill_sw_pending[BITS_TO_LONGS(NUM_RFKILL_TYPES)];
-static unsigned long rfkill_sw_state[BITS_TO_LONGS(NUM_RFKILL_TYPES)];
-
-enum rfkill_sched_op {
- RFKILL_GLOBAL_OP_EPO = 0,
- RFKILL_GLOBAL_OP_RESTORE,
- RFKILL_GLOBAL_OP_UNLOCK,
- RFKILL_GLOBAL_OP_UNBLOCK,
-};
-
-static enum rfkill_sched_op rfkill_master_switch_op;
-static enum rfkill_sched_op rfkill_op;
-
-static void __rfkill_handle_global_op(enum rfkill_sched_op op)
-{
- unsigned int i;
-
- switch (op) {
- case RFKILL_GLOBAL_OP_EPO:
- rfkill_epo();
- break;
- case RFKILL_GLOBAL_OP_RESTORE:
- rfkill_restore_states();
- break;
- case RFKILL_GLOBAL_OP_UNLOCK:
- rfkill_remove_epo_lock();
- break;
- case RFKILL_GLOBAL_OP_UNBLOCK:
- rfkill_remove_epo_lock();
- for (i = 0; i < NUM_RFKILL_TYPES; i++)
- rfkill_switch_all(i, false);
- break;
- default:
- /* memory corruption or bug, fail safely */
- rfkill_epo();
- WARN(1, "Unknown requested operation %d! "
- "rfkill Emergency Power Off activated\n",
- op);
- }
-}
-
-static void __rfkill_handle_normal_op(const enum rfkill_type type,
- const bool complement)
-{
- bool blocked;
-
- blocked = rfkill_get_global_sw_state(type);
- if (complement)
- blocked = !blocked;
-
- rfkill_switch_all(type, blocked);
-}
-
-static void rfkill_op_handler(struct work_struct *work)
-{
- unsigned int i;
- bool c;
-
- spin_lock_irq(&rfkill_op_lock);
- do {
- if (rfkill_op_pending) {
- enum rfkill_sched_op op = rfkill_op;
- rfkill_op_pending = false;
- memset(rfkill_sw_pending, 0,
- sizeof(rfkill_sw_pending));
- spin_unlock_irq(&rfkill_op_lock);
-
- __rfkill_handle_global_op(op);
-
- spin_lock_irq(&rfkill_op_lock);
-
- /*
- * handle global ops first -- during unlocked period
- * we might have gotten a new global op.
- */
- if (rfkill_op_pending)
- continue;
- }
-
- if (rfkill_is_epo_lock_active())
- continue;
-
- for (i = 0; i < NUM_RFKILL_TYPES; i++) {
- if (__test_and_clear_bit(i, rfkill_sw_pending)) {
- c = __test_and_clear_bit(i, rfkill_sw_state);
- spin_unlock_irq(&rfkill_op_lock);
-
- __rfkill_handle_normal_op(i, c);
-
- spin_lock_irq(&rfkill_op_lock);
- }
- }
- } while (rfkill_op_pending);
- spin_unlock_irq(&rfkill_op_lock);
-}
-
-static DECLARE_DELAYED_WORK(rfkill_op_work, rfkill_op_handler);
-static unsigned long rfkill_last_scheduled;
-
-static unsigned long rfkill_ratelimit(const unsigned long last)
-{
- const unsigned long delay = msecs_to_jiffies(RFKILL_OPS_DELAY);
- return time_after(jiffies, last + delay) ? 0 : delay;
-}
-
-static void rfkill_schedule_ratelimited(void)
-{
- if (delayed_work_pending(&rfkill_op_work))
- return;
- schedule_delayed_work(&rfkill_op_work,
- rfkill_ratelimit(rfkill_last_scheduled));
- rfkill_last_scheduled = jiffies;
-}
-
-static void rfkill_schedule_global_op(enum rfkill_sched_op op)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&rfkill_op_lock, flags);
- rfkill_op = op;
- rfkill_op_pending = true;
- if (op == RFKILL_GLOBAL_OP_EPO && !rfkill_is_epo_lock_active()) {
- /* bypass the limiter for EPO */
- cancel_delayed_work(&rfkill_op_work);
- schedule_delayed_work(&rfkill_op_work, 0);
- rfkill_last_scheduled = jiffies;
- } else
- rfkill_schedule_ratelimited();
- spin_unlock_irqrestore(&rfkill_op_lock, flags);
-}
-
-static void rfkill_schedule_toggle(enum rfkill_type type)
-{
- unsigned long flags;
-
- if (rfkill_is_epo_lock_active())
- return;
-
- spin_lock_irqsave(&rfkill_op_lock, flags);
- if (!rfkill_op_pending) {
- __set_bit(type, rfkill_sw_pending);
- __change_bit(type, rfkill_sw_state);
- rfkill_schedule_ratelimited();
- }
- spin_unlock_irqrestore(&rfkill_op_lock, flags);
-}
-
-static void rfkill_schedule_evsw_rfkillall(int state)
-{
- if (state)
- rfkill_schedule_global_op(rfkill_master_switch_op);
- else
- rfkill_schedule_global_op(RFKILL_GLOBAL_OP_EPO);
-}
-
-static void rfkill_event(struct input_handle *handle, unsigned int type,
- unsigned int code, int data)
-{
- if (type == EV_KEY && data == 1) {
- switch (code) {
- case KEY_WLAN:
- rfkill_schedule_toggle(RFKILL_TYPE_WLAN);
- break;
- case KEY_BLUETOOTH:
- rfkill_schedule_toggle(RFKILL_TYPE_BLUETOOTH);
- break;
- case KEY_UWB:
- rfkill_schedule_toggle(RFKILL_TYPE_UWB);
- break;
- case KEY_WIMAX:
- rfkill_schedule_toggle(RFKILL_TYPE_WIMAX);
- break;
- case KEY_RFKILL:
- rfkill_schedule_toggle(RFKILL_TYPE_ALL);
- break;
- }
- } else if (type == EV_SW && code == SW_RFKILL_ALL)
- rfkill_schedule_evsw_rfkillall(data);
-}
-
-static int rfkill_connect(struct input_handler *handler, struct input_dev *dev,
- const struct input_device_id *id)
-{
- struct input_handle *handle;
- int error;
-
- handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL);
- if (!handle)
- return -ENOMEM;
-
- handle->dev = dev;
- handle->handler = handler;
- handle->name = "rfkill";
-
- /* causes rfkill_start() to be called */
- error = input_register_handle(handle);
- if (error)
- goto err_free_handle;
-
- error = input_open_device(handle);
- if (error)
- goto err_unregister_handle;
-
- return 0;
-
- err_unregister_handle:
- input_unregister_handle(handle);
- err_free_handle:
- kfree(handle);
- return error;
-}
-
-static void rfkill_start(struct input_handle *handle)
-{
- /*
- * Take event_lock to guard against configuration changes, we
- * should be able to deal with concurrency with rfkill_event()
- * just fine (which event_lock will also avoid).
- */
- spin_lock_irq(&handle->dev->event_lock);
-
- if (test_bit(EV_SW, handle->dev->evbit) &&
- test_bit(SW_RFKILL_ALL, handle->dev->swbit))
- rfkill_schedule_evsw_rfkillall(test_bit(SW_RFKILL_ALL,
- handle->dev->sw));
-
- spin_unlock_irq(&handle->dev->event_lock);
-}
-
-static void rfkill_disconnect(struct input_handle *handle)
-{
- input_close_device(handle);
- input_unregister_handle(handle);
- kfree(handle);
-}
-
-static const struct input_device_id rfkill_ids[] = {
- {
- .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT,
- .evbit = { BIT_MASK(EV_KEY) },
- .keybit = { [BIT_WORD(KEY_WLAN)] = BIT_MASK(KEY_WLAN) },
- },
- {
- .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT,
- .evbit = { BIT_MASK(EV_KEY) },
- .keybit = { [BIT_WORD(KEY_BLUETOOTH)] = BIT_MASK(KEY_BLUETOOTH) },
- },
- {
- .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT,
- .evbit = { BIT_MASK(EV_KEY) },
- .keybit = { [BIT_WORD(KEY_UWB)] = BIT_MASK(KEY_UWB) },
- },
- {
- .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT,
- .evbit = { BIT_MASK(EV_KEY) },
- .keybit = { [BIT_WORD(KEY_WIMAX)] = BIT_MASK(KEY_WIMAX) },
- },
- {
- .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT,
- .evbit = { BIT_MASK(EV_KEY) },
- .keybit = { [BIT_WORD(KEY_RFKILL)] = BIT_MASK(KEY_RFKILL) },
- },
- {
- .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_SWBIT,
- .evbit = { BIT(EV_SW) },
- .swbit = { [BIT_WORD(SW_RFKILL_ALL)] = BIT_MASK(SW_RFKILL_ALL) },
- },
- { }
-};
-
-static struct input_handler rfkill_handler = {
- .name = "rfkill",
- .event = rfkill_event,
- .connect = rfkill_connect,
- .start = rfkill_start,
- .disconnect = rfkill_disconnect,
- .id_table = rfkill_ids,
-};
-
-int __init rfkill_handler_init(void)
-{
- switch (rfkill_master_switch_mode) {
- case RFKILL_INPUT_MASTER_UNBLOCKALL:
- rfkill_master_switch_op = RFKILL_GLOBAL_OP_UNBLOCK;
- break;
- case RFKILL_INPUT_MASTER_RESTORE:
- rfkill_master_switch_op = RFKILL_GLOBAL_OP_RESTORE;
- break;
- case RFKILL_INPUT_MASTER_UNLOCK:
- rfkill_master_switch_op = RFKILL_GLOBAL_OP_UNLOCK;
- break;
- default:
- return -EINVAL;
- }
-
- spin_lock_init(&rfkill_op_lock);
-
- /* Avoid delay at first schedule */
- rfkill_last_scheduled =
- jiffies - msecs_to_jiffies(RFKILL_OPS_DELAY) - 1;
- return input_register_handler(&rfkill_handler);
-}
-
-void __exit rfkill_handler_exit(void)
-{
- input_unregister_handler(&rfkill_handler);
- cancel_delayed_work_sync(&rfkill_op_work);
-}
^ permalink raw reply related
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michał Mirosław @ 2011-05-16 10:53 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Herbert Xu, Shan Wei, Michał Mirosław, netdev,
Ben Hutchings
In-Reply-To: <20110516094821.GA9427@redhat.com>
2011/5/16 Michael S. Tsirkin <mst@redhat.com>:
> On Mon, May 16, 2011 at 07:38:22PM +1000, Herbert Xu wrote:
>> On Mon, May 16, 2011 at 11:18:41AM +0300, Michael S. Tsirkin wrote:
>> >
>> > There's no interface for userspace to enable it: userspace
>> > only has an ioctl to enable/disable checksum offloading.
>> > SG is an implementation detail.
>> Yes there is: ethtool -K
> Ok. You are right of course, I was confused.
>
> So it's just an info message: in the end if userspace DTRT features
> get enabled properly. Functionally, there is no regression.
I proposed changing those messages to DEBUG level some time ago.Those
dependencies are constant, so they could be moved to
Documentation/networking/.
> Both bridge and tun trigger the messages ATM. I note that
> dev.c takes pains to avoid these messages:
> Avoid warning from netdev_fix_features() for GSO without SG
>
> Should all drivers do this: clear _SG if they clear checksum? What about _GSO?
> If we start doing this, this spills info about flag dependencies out to drivers.
Drivers should not care about those dependencies.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: several packets in a single buffer in Rx
From: Michał Mirosław @ 2011-05-16 11:06 UTC (permalink / raw)
To: Emmanuel Grumbach
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Johannes Berg, Guy, Wey-Yi,
guy.cohen-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <BANLkTimkgtQL1A2A3iAP-UYK2KdDvPmY3Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011/5/16 Emmanuel Grumbach <egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> I would like to be able to deliver the same page several times to the
> stack without having the stack consume it before the last time I
> deliver it.
> Of course I would like to avoid cloning it.
Just do get_page() on the page having another packet in it before
passing skb up.
Best Regards,
Michał Mirosław
--
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: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michael S. Tsirkin @ 2011-05-16 11:21 UTC (permalink / raw)
To: Herbert Xu; +Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516104309.GA3534@gondor.apana.org.au>
On Mon, May 16, 2011 at 08:43:10PM +1000, Herbert Xu wrote:
> On Mon, May 16, 2011 at 12:48:21PM +0300, Michael S. Tsirkin wrote:
> >
> > Both bridge and tun trigger the messages ATM. I note that
> > dev.c takes pains to avoid these messages:
> > Avoid warning from netdev_fix_features() for GSO without SG
> >
> > Should all drivers do this: clear _SG if they clear checksum? What about _GSO?
> > If we start doing this, this spills info about flag dependencies out to drivers.
>
> Drivers don't need to do this at all since the network stack
> will automatically clear SG and related features if checksum
> is disabled.
>
> Cheers,
Yes, but then we get annoying info messages every time.
Change them all to debug or remove completely?
> --
> 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-2.6] ethtool: Remove fallback to old ethtool operations for ETHTOOL_SFEATURES
From: Michał Mirosław @ 2011-05-16 12:13 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1305513923.19966.20.camel@localhost>
On Mon, May 16, 2011 at 03:45:23AM +0100, Ben Hutchings wrote:
> On Sat, 2011-05-14 at 12:35 +0200, Michał Mirosław wrote:
> > On Sat, May 14, 2011 at 02:05:42AM +0100, Ben Hutchings wrote:
> > > ethtool_set_feature_compat() squashes the feature mask into a boolean,
> > > which is not correct for ethtool_ops::set_flags.
> > >
> > > We could fix this, but the fallback code for ETHTOOL_SFEATURES actually
> > > makes things more complicated for the ethtool utility and any other
> > > application using the ethtool API. They will still need to fall back to
> > > the old offload control commands in order to support older kernel
> > > versions. The fallback code in the kernel adds a third possibility for
> > > them to handle. So make ETHTOOL_SFEATURES fail when the driver
> > > implements the old offload control operations, and let userland do the
> > > fallback.
> > BTW, the idea behind the compat code is that if ETHTOOL_[GS]FEATURES is
> > available, then there should be no need to fallback to old ops. For
> > a userspace tool that targets only kernels >= 2.6.39 there's no need
> > to care about old ops at all.
> Well that's not true, because those tools still have to deal with
> ETHTOOL_F_COMPAT. And we're supposed to have all drivers converted for
> 2.6.40, so the hypothetical new tool only has to wait one more release.
I think that handling ETHTOOL_F_COMPAT is like ETHTOOL_F_WISH - the tool
needs to reread features and check what was changed. So we can get rid
of the former by replacing it with the latter.
Changing some feature state may change others that were not requested
to be changed (not present in .valid). This probably should be signalled
as well. Extend ETHTOOL_F_WISH meaning (I prefer this one) or introduce
new bit?
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Herbert Xu @ 2011-05-16 12:18 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516112133.GA11274@redhat.com>
On Mon, May 16, 2011 at 02:21:33PM +0300, Michael S. Tsirkin wrote:
>
> Yes, but then we get annoying info messages every time.
> Change them all to debug or remove completely?
If you are getting warning messages then it probably means that
your driver is doing something wrong.
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: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michał Mirosław @ 2011-05-16 12:24 UTC (permalink / raw)
To: Herbert Xu
Cc: Michael S. Tsirkin, Shan Wei, Michał Mirosław, netdev,
Ben Hutchings
In-Reply-To: <20110516121857.GA4495@gondor.apana.org.au>
2011/5/16 Herbert Xu <herbert@gondor.apana.org.au>:
> On Mon, May 16, 2011 at 02:21:33PM +0300, Michael S. Tsirkin wrote:
>> Yes, but then we get annoying info messages every time.
>> Change them all to debug or remove completely?
> If you are getting warning messages then it probably means that
> your driver is doing something wrong.
In this case - no. Those messages inform that driver supports more
feature combinations than network core and the feature set is reduced
because of that.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] net: ping: dont call udp_ioctl()
From: Vasiliy Kulikov @ 2011-05-16 12:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, solar, linux-kernel, netdev, peak, kees.cook,
dan.j.rosenberg, eugene, nelhage, kuznet, pekkas, jmorris,
yoshfuji, kaber
In-Reply-To: <1305530791.3120.217.camel@edumazet-laptop>
On Mon, May 16, 2011 at 09:26 +0200, Eric Dumazet wrote:
> Le dimanche 15 mai 2011 à 17:44 -0400, David Miller a écrit :
>
> > Just get rid of ping_ioctl() entirely, as that is the effect of
> > this change since inet_ioctl() returns -ENOIOCTLCMD when
> > sk_prot->ioctl is NULL.
> >
> > Also get rid of asm/ioctls.h since that will be no longer needed.
>
> Sure, here is updated version, thanks.
>
> [PATCH net-next-2.6 v2] net: ping: dont call udp_ioctl()
>
> udp_ioctl() really handles UDP and UDPLite protocols.
>
> 1) It can increment UDP_MIB_INERRORS in case first_packet_length() finds
> a frame with bad checksum.
>
> 2) It has a dependency on sizeof(struct udphdr), not applicable to
> ICMP/PING
>
> If ping sockets need to handle SIOCINQ/SIOCOUTQ ioctl, this should be
> done differently.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Vasiliy Kulikov <segoon@openwall.com>
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ 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