* Re: [PATCH v8 RESEND] ARM: net: JIT compiler for packet filters
From: Mircea Gherzan @ 2012-03-25 9:51 UTC (permalink / raw)
To: David Miller; +Cc: linux, netdev, linux-arm-kernel, eric.dumazet
In-Reply-To: <20120319.172005.1889334604020296555.davem@davemloft.net>
Am 19.03.2012 22:20, schrieb David Miller:
> I would like to see this merged however is feasible, this has been in
> a catatonic state for two releases and waiting longer isn't going to
> improve things enough to justify any further delay.
It has been merged into the ARM tree more than a week ago, but
unfortunately it seems it will not make it into 3.4.
Mircea
^ permalink raw reply
* Re: [PATCH v8 RESEND] ARM: net: JIT compiler for packet filters
From: Russell King - ARM Linux @ 2012-03-25 9:57 UTC (permalink / raw)
To: Mircea Gherzan; +Cc: David Miller, netdev, linux-arm-kernel, eric.dumazet
In-Reply-To: <4F6EEAB5.7070009@gmail.com>
On Sun, Mar 25, 2012 at 11:51:49AM +0200, Mircea Gherzan wrote:
> Am 19.03.2012 22:20, schrieb David Miller:
> > I would like to see this merged however is feasible, this has been in
> > a catatonic state for two releases and waiting longer isn't going to
> > improve things enough to justify any further delay.
>
> It has been merged into the ARM tree more than a week ago, but
> unfortunately it seems it will not make it into 3.4.
Why do you say that?
^ permalink raw reply
* [PATCH] Fix byte stats on eql
From: David Woodhouse @ 2012-03-25 10:01 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
diff --git a/drivers/net/eql.c b/drivers/net/eql.c
index a59cf96..f2d3741 100644
--- a/drivers/net/eql.c
+++ b/drivers/net/eql.c
@@ -345,6 +345,7 @@ static netdev_tx_t eql_slave_xmit(struct sk_buff
*skb, struct net_device *dev)
slave->bytes_queued += skb->len;
dev_queue_xmit(skb);
dev->stats.tx_packets++;
+ dev->stats.tx_bytes += skb->len;
} else {
dev->stats.tx_dropped++;
dev_kfree_skb(skb);
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5818 bytes --]
^ permalink raw reply related
* Enable some ZTE modems to use the new QMI WWAN driver
From: Andrew Bird @ 2012-03-25 10:10 UTC (permalink / raw)
To: gregkh; +Cc: smurf, linux-usb, netdev, linux-kernel
These patches enable the network devices on some Vodafone branded ZTE
devices to be bound by the new QMI / WWAN driver. I suspect that the
K3765-Z would also work, but at the moment I can't get the network
interface to be recognised during probe.
(Reposted as previously I didn't cc netdev)
^ permalink raw reply
* [PATCH 1/3] USB: qmi_wwan: Add ZTE (Vodafone) K3565-Z and K4505-Z net interfaces
From: Andrew Bird @ 2012-03-25 10:10 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: smurf-ci3XGGwdvIcvfNposrsB4g, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Bird
In-Reply-To: <1332670229-2045-1-git-send-email-ajb-5+cxppFmGx6/3pe1ocb+s/XRex20P6io@public.gmane.org>
Now that we have the beginnings of an OSS method to use the network
interfaces on these USB broadband modems, add the ZTE manufactured
Vodafone items to the whitelist
Signed-off-by: Andrew Bird <ajb-5+cxppFmGx6/3pe1ocb+s/XRex20P6io@public.gmane.org>
---
drivers/net/usb/qmi_wwan.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index aac68f5..0f83899 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -409,6 +409,24 @@ static const struct usb_device_id products[] = {
.bInterfaceProtocol = 0xff,
.driver_info = (unsigned long)&qmi_wwan_force_int4,
},
+ { /* ZTE (Vodafone) K3565-Z */
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x19d2,
+ .idProduct = 0x0063,
+ .bInterfaceClass = 0xff,
+ .bInterfaceSubClass = 0xff,
+ .bInterfaceProtocol = 0xff,
+ .driver_info = (unsigned long)&qmi_wwan_force_int4,
+ },
+ { /* ZTE (Vodafone) K4505-Z */
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x19d2,
+ .idProduct = 0x0104,
+ .bInterfaceClass = 0xff,
+ .bInterfaceSubClass = 0xff,
+ .bInterfaceProtocol = 0xff,
+ .driver_info = (unsigned long)&qmi_wwan_force_int4,
+ },
{QMI_GOBI_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
{QMI_GOBI_DEVICE(0x03f0, 0x1f1d)}, /* HP un2400 Gobi Modem Device */
{QMI_GOBI_DEVICE(0x03f0, 0x371d)}, /* HP un2430 Mobile Broadband Module */
--
1.7.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/3] USB: option: Ignore ZTE (Vodafone) K3570/71 net interfaces
From: Andrew Bird @ 2012-03-25 10:10 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: smurf-ci3XGGwdvIcvfNposrsB4g, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Bird
In-Reply-To: <1332670229-2045-1-git-send-email-ajb-5+cxppFmGx6/3pe1ocb+s/XRex20P6io@public.gmane.org>
These interfaces need to be handled by QMI/WWAN driver
Signed-off-by: Andrew Bird <ajb-5+cxppFmGx6/3pe1ocb+s/XRex20P6io@public.gmane.org>
---
drivers/usb/serial/option.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 6815701..836cfa9 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -903,8 +903,10 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0165, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0167, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1008, 0xff, 0xff, 0xff) },
- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1010, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1008, 0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1010, 0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1012, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1057, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1058, 0xff, 0xff, 0xff) },
--
1.7.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/3] USB: qmi_wwan: Add ZTE (Vodafone) K3570-Z and K3571-Z net interfaces
From: Andrew Bird @ 2012-03-25 10:10 UTC (permalink / raw)
To: gregkh; +Cc: smurf, linux-usb, netdev, linux-kernel, Andrew Bird
In-Reply-To: <1332670229-2045-1-git-send-email-ajb@spheresystems.co.uk>
Now that we have the beginnings of an OSS method to use the network
interfaces on these USB broadband modems, add the ZTE manufactured
Vodafone items to the whitelist
Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
---
drivers/net/usb/qmi_wwan.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 0f83899..552d24b 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -418,6 +418,24 @@ static const struct usb_device_id products[] = {
.bInterfaceProtocol = 0xff,
.driver_info = (unsigned long)&qmi_wwan_force_int4,
},
+ { /* ZTE (Vodafone) K3570-Z */
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x19d2,
+ .idProduct = 0x1008,
+ .bInterfaceClass = 0xff,
+ .bInterfaceSubClass = 0xff,
+ .bInterfaceProtocol = 0xff,
+ .driver_info = (unsigned long)&qmi_wwan_force_int4,
+ },
+ { /* ZTE (Vodafone) K3571-Z */
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x19d2,
+ .idProduct = 0x1010,
+ .bInterfaceClass = 0xff,
+ .bInterfaceSubClass = 0xff,
+ .bInterfaceProtocol = 0xff,
+ .driver_info = (unsigned long)&qmi_wwan_force_int4,
+ },
{ /* ZTE (Vodafone) K4505-Z */
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
.idVendor = 0x19d2,
--
1.7.6.5
^ permalink raw reply related
* Re: [STRAW MAN PATCH] sch_teql doesn't load-balance ppp(oatm) slaves
From: David Woodhouse @ 2012-03-25 10:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120322.230331.1623101647193498167.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 2893 bytes --]
On Thu, 2012-03-22 at 23:03 -0400, David Miller wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> Date: Thu, 22 Mar 2012 21:03:38 +0000
>
> > teql_dequeue() will *always* give up a skb when it's called, if there is
> > one. If there's *not*, and the tx queue becomes empty, then the device
> > for which teql_dequeue() was called is 'promoted' to the front of the
> > line (master->slaves). That device will receive the next packet that
> > comes in, even if there are other devices which are *also* idle and
> > waiting for packets. Whenever a new packet comes in, the *last* device
> > to call teql_dequeue() gets it.
>
> The teql master ->ndo_start_xmit() method is where the slave iteration
> occurs, and it occurs on every successful transmit of a single packet.
Thanks for the response.
I'd seen this in teql_master_xmit(), and it works *perfectly*, *if* we
let it do its job.
The only problem here is that the PPP code is greedily sucking up all
the packets it can, calling skb_dequeue() in a loop and not letting the
*other* device(s) get any of the packets. Even when it *doesn't* get a
packet because it's emptied the queue, it gets bumped to the front of
the slaves list again, so it'll get the *next* one!
Is it that behaviour which makes you say PPP is effectively a virtual
device for this purpose? I wonder if I should just *fix* that instead,
so that it behaves as like a real device.
It's a bad idea to have huge hidden queues (a whole wmem_default worth
of packets are in a hidden queue between ppp_generic and the ATM device,
ffs!) anyway, so perhaps if we just fix *that* within PPP, it should
work a bit better with TEQL?
The other odd thing that PPP does is call skb_dequeue, attempt to feed a
packet into the low-level driver, and then *requeue* the skb if that
fails. Which it *will* do, a lot of the time. So perhaps the PPP
low-level driver could have a method call to *ask* if it's able to
accept a new packet, to avoid that dequeue-and-requeue behaviour in
ppp_generic? I'll experiment with that.
> But this cannot, and is documented not to, work when device stacking
> is involved.
>
> If you're dealing with (what amounts to) virtual devices, you cannot
> use TEQL and must use something like drivers/net/eql.c
I'd looked briefly at eql.c. I eventually found eql-1.2.tar.gz... with a
timestamp from a few months before I first encountered Linux in 1995, a
ZMAGIC binary in the tarball, and source code which probably hasn't
compiled for a decade... so then I figured I'd try TEQL a bit more
first :)
Having fixed up the userspace, eql.c *does* work OK — but it seems to be
fairly unloved, and mostly duplicates the functionality of TEQL. The
fact that it forgets its slaves when you take it down and up is a bit of
a PITA too. I think I'd be happier getting TEQL working.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5818 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] USB: qmi_wwan: Add ZTE (Vodafone) K3570-Z and K3571-Z net interfaces
From: Bjørn Mork @ 2012-03-25 12:07 UTC (permalink / raw)
To: Andrew Bird; +Cc: gregkh, smurf, linux-usb, netdev, linux-kernel
In-Reply-To: <1332670229-2045-4-git-send-email-ajb@spheresystems.co.uk>
Andrew Bird <ajb@spheresystems.co.uk> writes:
> Now that we have the beginnings of an OSS method to use the network
> interfaces on these USB broadband modems, add the ZTE manufactured
> Vodafone items to the whitelist
>
> Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Acked-by: Bjørn Mork <bjorn@mork.no>
^ permalink raw reply
* Re: [PATCH 1/3] USB: qmi_wwan: Add ZTE (Vodafone) K3565-Z and K4505-Z net interfaces
From: Bjørn Mork @ 2012-03-25 12:08 UTC (permalink / raw)
To: Andrew Bird; +Cc: gregkh, smurf, linux-usb, netdev, linux-kernel
In-Reply-To: <1332670229-2045-2-git-send-email-ajb@spheresystems.co.uk>
Andrew Bird <ajb@spheresystems.co.uk> writes:
> Now that we have the beginnings of an OSS method to use the network
> interfaces on these USB broadband modems, add the ZTE manufactured
> Vodafone items to the whitelist
>
> Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Acked-by: Bjørn Mork <bjorn@mork.no>
^ permalink raw reply
* Re: [net-next PATCH v0 2/5] net: addr_list: add exclusive dev_uc_add
From: Roopa Prabhu @ 2012-03-25 13:07 UTC (permalink / raw)
To: John Fastabend, jhs, shemminger, bhutchings, davem,
jeffrey.t.kirsher
Cc: netdev, mst, chrisw, gregory.v.rose, kvm, sri, chealy
In-Reply-To: <20120319065157.10959.32215.stgit@jf-dev1-dcblab>
On 3/18/12 11:51 PM, "John Fastabend" <john.r.fastabend@intel.com> wrote:
> This adds a dev_uc_add_excl() call similar to the original
> dev_uc_add() except it sets the global bit. With this
> change the reference count will not be bumped and -EEXIST
> will be returned if a duplicate address exists.
>
> This is useful for drivers that support SR-IOV and want
> to manage the unicast lists.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
>
> include/linux/netdevice.h | 1 +
> net/core/dev_addr_lists.c | 19 +++++++++++++++++++
> 2 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 4208901..5e43cec 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -2571,6 +2571,7 @@ extern int dev_addr_init(struct net_device *dev);
>
> /* Functions used for unicast addresses handling */
> extern int dev_uc_add(struct net_device *dev, unsigned char *addr);
> +extern int dev_uc_add_excl(struct net_device *dev, unsigned char *addr);
> extern int dev_uc_del(struct net_device *dev, unsigned char *addr);
> extern int dev_uc_sync(struct net_device *to, struct net_device *from);
> extern void dev_uc_unsync(struct net_device *to, struct net_device *from);
> diff --git a/net/core/dev_addr_lists.c b/net/core/dev_addr_lists.c
> index 29c07fe..c7d27ad 100644
> --- a/net/core/dev_addr_lists.c
> +++ b/net/core/dev_addr_lists.c
> @@ -377,6 +377,25 @@ EXPORT_SYMBOL(dev_addr_del_multiple);
> */
>
> /**
> + * dev_uc_add_excl - Add a global secondary unicast address
> + * @dev: device
> + * @addr: address to add
> + */
> +int dev_uc_add_excl(struct net_device *dev, unsigned char *addr)
> +{
> + int err;
> +
> + netif_addr_lock_bh(dev);
> + err = __hw_addr_add_ex(&dev->uc, addr, dev->addr_len,
> + NETDEV_HW_ADDR_T_UNICAST, true);
> + if (!err)
> + __dev_set_rx_mode(dev);
> + netif_addr_unlock_bh(dev);
> + return err;
> +}
> +EXPORT_SYMBOL(dev_uc_add_excl);
> +
> +/**
ACK.
We will need a similar function for multicast as well ?. Macvlan could use
it.
Thanks,
Roopa
^ permalink raw reply
* Re: [net-next PATCH v0 3/5] net: add fdb generic dump routine
From: Roopa Prabhu @ 2012-03-25 13:09 UTC (permalink / raw)
To: John Fastabend, jhs, shemminger, bhutchings, davem,
jeffrey.t.kirsher
Cc: netdev, mst, chrisw, gregory.v.rose, kvm, sri, chealy
In-Reply-To: <20120319065202.10959.53491.stgit@jf-dev1-dcblab>
On 3/18/12 11:52 PM, "John Fastabend" <john.r.fastabend@intel.com> wrote:
> This adds a generic dump routine drivers can call. It
> should be sufficient to handle any bridging model that
> uses the unicast address list. This should be most SR-IOV
> enabled NICs.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
>
> net/core/rtnetlink.c | 56
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 56 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 8c3278a..35ee2d6 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -2082,6 +2082,62 @@ static int rtnl_fdb_del(struct sk_buff *skb, struct
> nlmsghdr *nlh, void *arg)
> return err;
> }
>
> +/**
> + * ndo_dflt_fdb_dump: default netdevice operation to dump an FDB table.
> + * @nlh: netlink message header
> + * @dev: netdevice
> + *
> + * Default netdevice operation to dump the existing unicast address list.
> + * Returns zero on success.
> + */
> +int ndo_dflt_fdb_dump(struct sk_buff *skb,
> + struct netlink_callback *cb,
> + struct net_device *dev,
> + int idx)
> +{
> + struct netdev_hw_addr *ha;
> + struct nlmsghdr *nlh;
> + struct ndmsg *ndm;
> + u32 pid, seq;
> +
> + pid = NETLINK_CB(cb->skb).pid;
> + seq = cb->nlh->nlmsg_seq;
> +
> + netif_addr_lock_bh(dev);
> + list_for_each_entry(ha, &dev->uc.list, list) {
> + if (idx < cb->args[0])
> + goto skip;
Any reason why its only uc ?. What about mc ?
> +
> + nlh = nlmsg_put(skb, pid, seq,
> + RTM_NEWNEIGH, sizeof(*ndm), NLM_F_MULTI);
> + if (!nlh)
> + break;
> +
> + ndm = nlmsg_data(nlh);
> + ndm->ndm_family = AF_BRIDGE;
> + ndm->ndm_pad1 = 0;
> + ndm->ndm_pad2 = 0;
> + ndm->ndm_flags = NTF_LOWERDEV;
> + ndm->ndm_type = 0;
> + ndm->ndm_ifindex = dev->ifindex;
> + ndm->ndm_state = NUD_PERMANENT;
> +
> + NLA_PUT(skb, NDA_LLADDR, ETH_ALEN, ha->addr);
> +
> + nlmsg_end(skb, nlh);
> +skip:
> + ++idx;
> + }
> + netif_addr_unlock_bh(dev);
> +
> + return idx;
> +nla_put_failure:
> + netif_addr_unlock_bh(dev);
> + nlmsg_cancel(skb, nlh);
> + return idx;
> +}
> +EXPORT_SYMBOL(ndo_dflt_fdb_dump);
> +
> static int rtnl_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb)
> {
> int idx = 0;
>
^ permalink raw reply
* Re: [PATCH v8 RESEND] ARM: net: JIT compiler for packet filters
From: Mircea Gherzan @ 2012-03-25 13:12 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: David Miller, netdev, linux-arm-kernel, eric.dumazet
In-Reply-To: <20120325095711.GC5611@n2100.arm.linux.org.uk>
Am 25.03.2012 11:57, schrieb Russell King - ARM Linux:
> On Sun, Mar 25, 2012 at 11:51:49AM +0200, Mircea Gherzan wrote:
>> Am 19.03.2012 22:20, schrieb David Miller:
>>> I would like to see this merged however is feasible, this has been in
>>> a catatonic state for two releases and waiting longer isn't going to
>>> improve things enough to justify any further delay.
>>
>> It has been merged into the ARM tree more than a week ago, but
>> unfortunately it seems it will not make it into 3.4.
>
> Why do you say that?
The patch is nowhere to be found in any of the branches of your
linaro.org tree, the tree from which Linus pulls.
^ permalink raw reply
* Re: [PATCH v8 RESEND] ARM: net: JIT compiler for packet filters
From: Russell King - ARM Linux @ 2012-03-25 13:35 UTC (permalink / raw)
To: Mircea Gherzan; +Cc: David Miller, netdev, linux-arm-kernel, eric.dumazet
In-Reply-To: <4F6F19C2.60602@gmail.com>
On Sun, Mar 25, 2012 at 03:12:34PM +0200, Mircea Gherzan wrote:
> Am 25.03.2012 11:57, schrieb Russell King - ARM Linux:
> > On Sun, Mar 25, 2012 at 11:51:49AM +0200, Mircea Gherzan wrote:
> >> Am 19.03.2012 22:20, schrieb David Miller:
> >>> I would like to see this merged however is feasible, this has been in
> >>> a catatonic state for two releases and waiting longer isn't going to
> >>> improve things enough to justify any further delay.
> >>
> >> It has been merged into the ARM tree more than a week ago, but
> >> unfortunately it seems it will not make it into 3.4.
> >
> > Why do you say that?
>
> The patch is nowhere to be found in any of the branches of your
> linaro.org tree, the tree from which Linus pulls.
I only push stuff out there just before asking Linus to pull. The main
tree is on zeniv aka ftp.arm.linux.org.uk as detailed on my website which
does contain your patch - and its this tree with linux-next fetches.
As Linus is away on an extended weekend, don't expect to see many more
pushes from me before Monday/Tuesday.
But, rest assured, I _am_ intending sending it for this merge window.
^ permalink raw reply
* Re: ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00008040
From: Justin P. Mattock @ 2012-03-25 15:05 UTC (permalink / raw)
To: Mohammed Shafi
Cc: Linux-wireless, Felix Fietkau,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linux-netdev
In-Reply-To: <CAD2nsn2b9yVrX16m4Pc0F96PHF09ySv8ncY8Qnr7_9CC8hrbtA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 03/20/2012 12:44 AM, Mohammed Shafi wrote:
>> /home/kernel/linux-next/drivers/net/wireless/ath/ath9k/ath9k.o...done.
>> (gdb) l *(ath_tx_start+0x284)
>> 0xcad4 is in ath_tx_start (drivers/net/wireless/ath/ath9k/xmit.c:1878).
>> 1873 ieee80211_is_data_qos(hdr->frame_control)) {
>> 1874 tidno = ieee80211_get_qos_ctl(hdr)[0]&
>> 1875 IEEE80211_QOS_CTL_TID_MASK;
>> 1876 tid = ATH_AN_2_TID(txctl->an, tidno);
>> 1877
>> 1878 WARN_ON(tid->ac->txq != txctl->txq);
>> 1879 }
>> 1880
>> 1881 if ((tx_info->flags& IEEE80211_TX_CTL_AMPDU)&& tid) {
>> 1882 /*
>> (gdb
>
> please check with the attached debug patch if tid is 'NULL'
>
>
> its my theory that tid is not initialized in ath_tx_node_init just after resume.
> during suspend ath9k_sta_remove may be called
> ieee80211_suspend -> drv_sta_state ->
> drv_sta_remove->ath9k_sta_remove->ath_node_detach->ath_tx_node_cleanup
>
> during resume
>
> ieee80211_resume ->
> ieee80211_reconfig->drv_sta_state->ath9k_sta_add->ath_node_attach->ath_tx_node_init
>
> now sta.ht_cap.ht_supported should be true. it will be set to true in
> assoc_sucess path and then sta_add is called.
>
> let me see if i had missed something or my analysis itself is wrong.
>
>>
>
>
>
after a few days of running these patches I did not hit anything, then
on a reboot I hit this. positive side though is I didnt loose internet
connectivity altogether i.g. my music streaming stayed connected but
internet surfing lost connection for a few seconds(30-40) then came back.
this is in dmesg..:
[ 18.801995] ieee80211 phy0: Selected rate control algorithm
'ath9k_rate_control'
[ 18.803477] Registered led device: ath9k-phy0
[ 18.803489] ieee80211 phy0: Atheros AR9285 Rev:2 mem=0xf8fa0000, irq=17
[ 18.863699] input: ETPS/2 Elantech Touchpad as
/devices/platform/i8042/serio1/input/input8
[ 18.905167] HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0
[ 18.905338] input: HDA Intel HDMI/DP,pcm=3 as
/devices/pci0000:00/0000:00:1b.0/sound/card0/input9
[ 22.178072] init: avahi-daemon main process (794) terminated with
status 2
[ 22.178116] init: avahi-daemon main process ended, respawning
[ 22.515462] init: ufw pre-start process (503) terminated with status 1
[ 22.523987] init: cups pre-start process (802) terminated with status 1
[ 23.122716] init: Failed to spawn smbd main process: unable to
execute: No such file or directory
[ 23.146521] init: failsafe main process (907) killed by TERM signal
[ 25.011529] ieee80211 phy0: device now idle
[ 25.046220] r8169 0000:06:00.0: eth0: bmcr: 1000 bmsr: 7849 gbcr:
0000 gbsr: 0000
[ 25.046223] r8169 0000:06:00.0: eth0: link down
[ 25.686361] ieee80211 phy0: device no longer idle - scanning
[ 27.311270] ieee80211 phy0: device now idle
[ 27.336454] ieee80211 phy0: device no longer idle - scanning
[ 28.206726] wlan0: authenticate with 00:1e:2a:62:6b:1e
[ 28.206800] ieee80211 phy0: Allocated STA 00:1e:2a:62:6b:1e
[ 28.220206] ieee80211 phy0: Inserted STA 00:1e:2a:62:6b:1e
[ 28.220211] wlan0: send auth to 00:1e:2a:62:6b:1e (try 1/3)
[ 28.222300] wlan0: authenticated
[ 28.222317] wlan0: moving STA 00:1e:2a:62:6b:1e to state 2
[ 28.229855] wlan0: associate with 00:1e:2a:62:6b:1e (try 1/3)
[ 28.232472] wlan0: RX AssocResp from 00:1e:2a:62:6b:1e (capab=0x31
status=0 aid=5)
[ 28.232479] wlan0: associated
[ 28.232495] wlan0: moving STA 00:1e:2a:62:6b:1e to state 3
[ 28.245788] wlan0: moving STA 00:1e:2a:62:6b:1e to state 4
[ 31.910960] init: nmbd pre-start process (1192) terminated with
status 127
[ 32.110327] EXT4-fs (sda9): re-mounted. Opts:
errors=remount-ro,commit=600
[ 35.706391] init: plymouth-stop pre-start process (1295) terminated
with status 1
[ 38.315982] EXT4-fs (sda9): re-mounted. Opts: errors=remount-ro,commit=0
[ 48.568651] EXT4-fs (sda9): re-mounted. Opts:
errors=remount-ro,commit=600
[ 941.868195] wlan0: detected beacon loss from AP - sending probe request
[ 942.040883] ath: phy0: Failed to stop TX DMA, queues=0x005!
[ 942.058737] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x02000020 DMADBG_7=0x00006040
[ 942.058749] ath: phy0: Could not stop RX, we could be confusing the
DMA engine when we start RX up
[ 942.058757] ------------[ cut here ]------------
[ 942.058778] WARNING: at drivers/net/wireless/ath/ath9k/recv.c:531
ath_stoprecv+0xfa/0x110 [ath9k]()
[ 942.058785] Hardware name: 0914
[ 942.058790] Modules linked in: dm_crypt xt_limit xt_tcpudp
xt_addrtype joydev xt_state snd_hda_codec_hdmi snd_hda_codec_conexant
arc4 ath9k snd_hda_intel mac80211 nf_conntrack_netbios_ns
nf_conntrack_broadcast snd_hda_codec snd_hwdep nf_nat_ftp nf_nat snd_pcm
nf_conntrack_ipv4 nf_defrag_ipv4 snd_seq_midi nf_conntrack_ftp
nf_conntrack snd_rawmidi ath9k_common snd_seq_midi_event snd_seq
snd_timer iptable_filter uvcvideo ath9k_hw ath lp parport cfg80211
snd_seq_device snd ip_tables ideapad_laptop videobuf2_core soundcore
snd_page_alloc x_tables psmouse sparse_keymap serio_raw videodev
videobuf2_vmalloc videobuf2_memops intel_ips i915 drm_kms_helper drm
i2c_algo_bit intel_agp intel_gtt r8169 agpgart video
[ 942.058960] Pid: 65, comm: kworker/u:3 Not tainted
3.3.0-next-20120322-00001-gba6003c #3
[ 942.058967] Call Trace:
[ 942.058987] [<c10492c2>] warn_slowpath_common+0x72/0xa0
[ 942.059003] [<f8b0897a>] ? ath_stoprecv+0xfa/0x110 [ath9k]
[ 942.059019] [<f8b0897a>] ? ath_stoprecv+0xfa/0x110 [ath9k]
[ 942.059030] [<c1049312>] warn_slowpath_null+0x22/0x30
[ 942.059045] [<f8b0897a>] ath_stoprecv+0xfa/0x110 [ath9k]
[ 942.059066] [<f8b044cd>] ath_prepare_reset+0x5d/0xd0 [ath9k]
[ 942.059082] [<f8b05adc>] ath_reset_internal+0x6c/0x170 [ath9k]
[ 942.059095] [<c10abcab>] ? trace_hardirqs_on+0xb/0x10
[ 942.059110] [<f8b05c05>] ath_reset+0x25/0xb0 [ath9k]
[ 942.059148] [<c10abc14>] ? trace_hardirqs_on_caller+0xf4/0x180
[ 942.059164] [<f8b07407>] ath_reset_work+0x17/0x20 [ath9k]
[ 942.059176] [<c1068706>] process_one_work+0x166/0x5c0
[ 942.059185] [<c1068692>] ? process_one_work+0xf2/0x5c0
[ 942.059199] [<c12d546b>] ? do_raw_spin_lock+0x3b/0xf0
[ 942.059219] [<f8b073f0>] ? ath_isr+0x270/0x270 [ath9k]
[ 942.059235] [<c1068e74>] worker_thread+0x124/0x2c0
[ 942.059245] [<c1068d50>] ? rescuer_thread+0x1c0/0x1c0
[ 942.059257] [<c106dbed>] kthread+0x7d/0x90
[ 942.059267] [<c106db70>] ? __init_kthread_worker+0x60/0x60
[ 942.059283] [<c15a0082>] kernel_thread_helper+0x6/0x10
[ 942.059286] ---[ end trace 6df3dcfe38b1fdb8 ]---
[ 942.066296] ieee80211 phy0: wlan0: No ack for nullfunc frame to AP
00:1e:2a:62:6b:1e, try 1/2
[ 942.561934] ieee80211 phy0: wlan0: Failed to send nullfunc to AP
00:1e:2a:62:6b:1e after 500ms, disconnecting.
[ 942.566506] wlan0: moving STA 00:1e:2a:62:6b:1e to state 3
[ 942.566514] wlan0: moving STA 00:1e:2a:62:6b:1e to state 2
[ 942.566556] wlan0: moving STA 00:1e:2a:62:6b:1e to state 1
[ 942.569979] ieee80211 phy0: Removed STA 00:1e:2a:62:6b:1e
[ 942.570946] ieee80211 phy0: Destroyed STA 00:1e:2a:62:6b:1e
[ 942.574474] ieee80211 phy0: device now idle
[ 942.574743] cfg80211: All devices are disconnected, going to restore
regulatory settings
[ 942.574757] cfg80211: Restoring regulatory settings
[ 942.574983] cfg80211: Calling CRDA to update world regulatory domain
[ 942.585392] cfg80211: Ignoring regulatory request Set by core since
the driver uses its own custom regulatory domain
[ 942.585519] cfg80211: World regulatory domain updated:
[ 942.585524] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 942.585530] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 942.585536] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300
mBi, 2000 mBm)
[ 942.585541] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300
mBi, 2000 mBm)
[ 942.585546] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 942.585552] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 942.965150] ieee80211 phy0: device no longer idle - scanning
[ 943.839899] wlan0: authenticate with 00:1e:2a:62:6b:1e
[ 943.839961] ieee80211 phy0: Allocated STA 00:1e:2a:62:6b:1e
[ 943.853169] ieee80211 phy0: Inserted STA 00:1e:2a:62:6b:1e
[ 943.853178] wlan0: send auth to 00:1e:2a:62:6b:1e (try 1/3)
[ 943.856967] wlan0: authenticated
[ 943.856980] wlan0: moving STA 00:1e:2a:62:6b:1e to state 2
[ 943.866660] wlan0: associate with 00:1e:2a:62:6b:1e (try 1/3)
[ 943.869352] wlan0: RX AssocResp from 00:1e:2a:62:6b:1e (capab=0x31
status=0 aid=5)
[ 943.869362] wlan0: associated
[ 943.869385] wlan0: moving STA 00:1e:2a:62:6b:1e to state 3
[ 943.884712] wlan0: moving STA 00:1e:2a:62:6b:1e to state 4
Justin P. Mattock
--
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: vhost question
From: Stefan Hajnoczi @ 2012-03-25 16:18 UTC (permalink / raw)
To: Steve Glass
In-Reply-To: <CADC0ay0ZRL79uMq72kAewOBTMCgMe1_1BLotdH9QnOwosJkTYQ@mail.gmail.com>
On Sun, Mar 25, 2012 at 1:29 PM, Steve Glass <stevie.glass@gmail.com> wrote:
> On 22 March 2012 19:52, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>>
>>
>> Can you queue a tx->rx kick on the vhost work queue with
>> vhost_work_queue()?
>>
>> Stefan
>
>
> I've been looking at this and trying to work out how to achieve that. I can
> see how I can enqueue some work on the vhost queue but the rx_handler needs
> to run in the process context of the receiving VM (or else it can't access
> the ring). I don't think that's true of the work queue (doesn't it run with
> the qemu process context?)
The vhost worker thread has the mm of the process, see use_mm(dev->mm)
in drivers/vhost/vhost.c:vhost_worker(). It sounds like you need
vhost worker A (tx) to schedule work for vhost worker B (rx).
Stefan
^ permalink raw reply
* [PATCH v2] gianfar: Fix possible overrun and simplify interrupt name field creation
From: Paul Gortmaker @ 2012-03-25 17:10 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, afleming, Joe Perches, Paul Gortmaker
In-Reply-To: <CAP=VYLrPbYv2C7hYaQ-aUJLFCfYh5zkJzFXJt8GFV2OTZ7h=og@mail.gmail.com>
From: Joe Perches <joe@perches.com>
Space allocated for int_name_<foo> is insufficient for
maximal device name, expand it.
Code to create int_name_<foo> is obscure, simplify it
by using sprintf.
Found by looking for unnecessary \ line continuations.
Signed-off-by: Joe Perches <joe@perches.com>
Tested-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
[v2: delete "uncompiled/untested" and fix typo in commit log]
The IRQ names appear unchanged after applying this patch:
root@SBC8641D:/root> for i in `seq 3` ; do ifconfig eth$i 192.168.0.$i ; done
root@SBC8641D:/root> cat /proc/interrupts
CPU0 CPU1
16: 0 0 MPIC Level phy_interrupt, phy_interrupt, phy_interrupt, phy_interrupt
29: 6884 0 MPIC Level eth0_g0_tx
30: 0 11578 MPIC Level eth0_g0_rx
31: 0 0 MPIC Level eth2_g0_tx
32: 0 0 MPIC Level eth2_g0_rx
33: 0 0 MPIC Level eth2_g0_er
34: 0 0 MPIC Level eth0_g0_er
35: 0 0 MPIC Level eth1_g0_tx
36: 0 0 MPIC Level eth1_g0_rx
37: 0 0 MPIC Level eth3_g0_tx
38: 0 0 MPIC Level eth3_g0_rx
39: 0 0 MPIC Level eth3_g0_er
40: 0 0 MPIC Level eth1_g0_er
Having them all in group "g0" may seem odd, but it is definitely
the same as it was before the commit. Tested on mar23 linux-next.
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index d9428f0..e7bed53 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -968,7 +968,6 @@ static int gfar_probe(struct platform_device *ofdev)
struct gfar_private *priv = NULL;
struct gfar __iomem *regs = NULL;
int err = 0, i, grp_idx = 0;
- int len_devname;
u32 rstat = 0, tstat = 0, rqueue = 0, tqueue = 0;
u32 isrg = 0;
u32 __iomem *baddr;
@@ -1169,40 +1168,16 @@ static int gfar_probe(struct platform_device *ofdev)
priv->device_flags & FSL_GIANFAR_DEV_HAS_MAGIC_PACKET);
/* fill out IRQ number and name fields */
- len_devname = strlen(dev->name);
for (i = 0; i < priv->num_grps; i++) {
- strncpy(&priv->gfargrp[i].int_name_tx[0], dev->name,
- len_devname);
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_MULTI_INTR) {
- strncpy(&priv->gfargrp[i].int_name_tx[len_devname],
- "_g", sizeof("_g"));
- priv->gfargrp[i].int_name_tx[
- strlen(priv->gfargrp[i].int_name_tx)] = i+48;
- strncpy(&priv->gfargrp[i].int_name_tx[strlen(
- priv->gfargrp[i].int_name_tx)],
- "_tx", sizeof("_tx") + 1);
-
- strncpy(&priv->gfargrp[i].int_name_rx[0], dev->name,
- len_devname);
- strncpy(&priv->gfargrp[i].int_name_rx[len_devname],
- "_g", sizeof("_g"));
- priv->gfargrp[i].int_name_rx[
- strlen(priv->gfargrp[i].int_name_rx)] = i+48;
- strncpy(&priv->gfargrp[i].int_name_rx[strlen(
- priv->gfargrp[i].int_name_rx)],
- "_rx", sizeof("_rx") + 1);
-
- strncpy(&priv->gfargrp[i].int_name_er[0], dev->name,
- len_devname);
- strncpy(&priv->gfargrp[i].int_name_er[len_devname],
- "_g", sizeof("_g"));
- priv->gfargrp[i].int_name_er[strlen(
- priv->gfargrp[i].int_name_er)] = i+48;
- strncpy(&priv->gfargrp[i].int_name_er[strlen(\
- priv->gfargrp[i].int_name_er)],
- "_er", sizeof("_er") + 1);
+ sprintf(priv->gfargrp[i].int_name_tx, "%s%s%c%s",
+ dev->name, "_g", '0' + i, "_tx");
+ sprintf(priv->gfargrp[i].int_name_rx, "%s%s%c%s",
+ dev->name, "_g", '0' + i, "_rx");
+ sprintf(priv->gfargrp[i].int_name_er, "%s%s%c%s",
+ dev->name, "_g", '0' + i, "_er");
} else
- priv->gfargrp[i].int_name_tx[len_devname] = '\0';
+ strcpy(priv->gfargrp[i].int_name_tx, dev->name);
}
/* Initialize the filer table */
diff --git a/drivers/net/ethernet/freescale/gianfar.h b/drivers/net/ethernet/freescale/gianfar.h
index fc2488a..4c9f8d4 100644
--- a/drivers/net/ethernet/freescale/gianfar.h
+++ b/drivers/net/ethernet/freescale/gianfar.h
@@ -517,7 +517,7 @@ extern const char gfar_driver_version[];
#define RXFCB_PERR_MASK 0x000c
#define RXFCB_PERR_BADL3 0x0008
-#define GFAR_INT_NAME_MAX IFNAMSIZ + 4
+#define GFAR_INT_NAME_MAX (IFNAMSIZ + 6) /* '_g#_xx' */
struct txbd8
{
--
1.7.9.1
^ permalink raw reply related
* Re: [GIT PATCH] TTY/serial patches for 3.4-rc1
From: Tilman Schmidt @ 2012-03-25 17:12 UTC (permalink / raw)
To: Greg KH, Jiri Slaby; +Cc: linux-kernel, linux-serial, netdev, hjlipp
In-Reply-To: <20120319195649.GD9883@kroah.com>
Jiri, Greg,
On 19.03.2012 20:56, Greg KH wrote:
> tty and serial merge for 3.4-rc1
[...]
> Jiri Slaby (77):
[...]
> TTY: isdn/gigaset, do not set tty->driver_data to NULL
It seems that the amendment we discussed on 05.03.2012 did not
make it into this patch. It would be nice if the following patch
could still be added on top of it.
Thanks,
Tilman
From: Tilman Schmidt <tilman@imap.cc>
Date: Sun, 25 Mar 2012 12:21:57 +0200
Subject: [PATCH] isdn/gigaset: use gig_dbg() for debugging output
The "TTY buffer in tty_port" patchset introduced an opencoded
debug message in the Gigaset tty device if_close() function.
Change it to use the gig_dbg() macro like everywhere else in
the driver.
Signed-off-by: Tilman Schmidt <tilman@imap.cc>
---
drivers/isdn/gigaset/interface.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/isdn/gigaset/interface.c b/drivers/isdn/gigaset/interface.c
index b3d6ac1..a6d9fd2 100644
--- a/drivers/isdn/gigaset/interface.c
+++ b/drivers/isdn/gigaset/interface.c
@@ -176,7 +176,7 @@ static void if_close(struct tty_struct *tty, struct file *filp)
struct cardstate *cs = tty->driver_data;
if (!cs) { /* happens if we didn't find cs in open */
- printk(KERN_DEBUG "%s: no cardstate\n", __func__);
+ gig_dbg(DEBUG_IF, "%s: no cardstate", __func__);
return;
}
--
1.7.3.4
^ permalink raw reply related
* Re: Enable some ZTE modems to use the new QMI WWAN driver
From: David Miller @ 2012-03-25 17:28 UTC (permalink / raw)
To: ajb; +Cc: gregkh, smurf, linux-usb, netdev, linux-kernel
In-Reply-To: <1332670229-2045-1-git-send-email-ajb@spheresystems.co.uk>
From: Andrew Bird <ajb@spheresystems.co.uk>
Date: Sun, 25 Mar 2012 11:10:26 +0100
> These patches enable the network devices on some Vodafone branded ZTE
> devices to be bound by the new QMI / WWAN driver. I suspect that the
> K3765-Z would also work, but at the moment I can't get the network
> interface to be recognised during probe.
>
> (Reposted as previously I didn't cc netdev)
All applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] gianfar: Fix possible overrun and simplify interrupt name field creation
From: David Miller @ 2012-03-25 17:29 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev, linux-kernel, afleming, joe
In-Reply-To: <1332695407-21167-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Sun, 25 Mar 2012 13:10:07 -0400
> From: Joe Perches <joe@perches.com>
>
> Space allocated for int_name_<foo> is insufficient for
> maximal device name, expand it.
>
> Code to create int_name_<foo> is obscure, simplify it
> by using sprintf.
>
> Found by looking for unnecessary \ line continuations.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Tested-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Applied.
^ permalink raw reply
* Re: [PATCH] Fix byte stats on eql
From: David Miller @ 2012-03-25 17:28 UTC (permalink / raw)
To: dwmw2; +Cc: netdev
In-Reply-To: <1332669700.32446.142.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Sun, 25 Mar 2012 11:01:40 +0100
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Please use a driver/subsystem prefix in your Subject lines,
in this case "eql: Fix byte stats." would have been appropriate.
> @@ -345,6 +345,7 @@ static netdev_tx_t eql_slave_xmit(struct sk_buff
> *skb, struct net_device *dev)
Patch corrupted by your email client.
^ permalink raw reply
* Re: [PATCH v2] net: add a truesize parameter to skb_add_rx_frag()
From: David Miller @ 2012-03-25 17:30 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, wey-yi.w.guy
In-Reply-To: <1332583173.3487.3.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 24 Mar 2012 02:59:33 -0700
> skb_add_rx_frag() API is misleading.
>
> Network skbs built with this helper can use uncharged kernel memory and
> eventually stress/crash machine in OOM.
>
> Add a 'truesize' parameter and then fix drivers in followup patches.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v15 04/13] arch/x86: add syscall_get_arch to syscall.h
From: H. Peter Anvin @ 2012-03-25 19:34 UTC (permalink / raw)
To: Will Drewry
Cc: linux-kernel, linux-arch, linux-doc, kernel-hardening, netdev,
x86, arnd, davem, mingo, oleg, peterz, rdunlap, mcgrathr, tglx,
luto, eparis, serge.hallyn, djm, scarybeasts, indan, pmoore, akpm,
corbet, eric.dumazet, markus, coreyb, keescook
In-Reply-To: <1331781125-15658-5-git-send-email-wad@chromium.org>
On 03/14/2012 08:11 PM, Will Drewry wrote:
>
> +static inline int syscall_get_arch(struct task_struct *task,
> + struct pt_regs *regs)
> +{
> +#ifdef CONFIG_IA32_EMULATION
> + /*
> + * TS_COMPAT is set for 32-bit syscall entries and then
> + * remains set until we return to user mode.
> + *
> + * TIF_IA32 tasks should always have TS_COMPAT set at
> + * system call time.
> + */
> + if (task_thread_info(task)->status & TS_COMPAT)
> + return AUDIT_ARCH_I386;
> +#endif
> + return AUDIT_ARCH_X86_64;
> +}
> #endif /* CONFIG_X86_32 */
>
> #endif /* _ASM_X86_SYSCALL_H */
Just one FYI on this: after the x32 changes are upstream this can be
implemented in terms of is_ia32_task().
-hpa
^ permalink raw reply
* Re: [PATCH v15 00/13] seccomp_filter: syscall filtering using BPF
From: H. Peter Anvin @ 2012-03-25 19:36 UTC (permalink / raw)
To: Will Drewry
Cc: linux-kernel, linux-arch, linux-doc, kernel-hardening, netdev,
x86, arnd, davem, mingo, oleg, peterz, rdunlap, mcgrathr, tglx,
luto, eparis, serge.hallyn, djm, scarybeasts, indan, pmoore, akpm,
corbet, eric.dumazet, markus, coreyb, keescook
In-Reply-To: <1331781125-15658-1-git-send-email-wad@chromium.org>
On 03/14/2012 08:11 PM, Will Drewry wrote:
> Please see prior revisions of this patch series for a high
> level blurb.
>
> This revision makes a number of refinements and tweaks. The biggest
> change is a slight renumbering of the return codes which will break
> existing code using this patch series.
>
> I believe this patch is in good shape, and I don't see the need for
> any more API changes at this point. I plan to start using this revision
> more extensively, and I'd certainly appreciate any testing.
>
> Thanks!
> will
>
x86 portions:
Reviewed-by: H. Peter Anvin <hpa@zytor.com>
What is the preferred way to push this upstream? (Presumably for 3.5 at
this point, but we should get it into -next as soon as possible after
the merge window.)
-hpa
^ permalink raw reply
* Re: [STRAW MAN PATCH] sch_teql doesn't load-balance ppp(oatm) slaves
From: David Miller @ 2012-03-25 21:36 UTC (permalink / raw)
To: dwmw2; +Cc: netdev
In-Reply-To: <1332672230.32446.160.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Sun, 25 Mar 2012 11:43:50 +0100
> It's a bad idea to have huge hidden queues (a whole wmem_default worth
> of packets are in a hidden queue between ppp_generic and the ATM device,
> ffs!) anyway, so perhaps if we just fix *that* within PPP, it should
> work a bit better with TEQL?
Yes, the ATM devices deep transmit queue is quite undesirable.
But I actually don't see how the problem arises yet, I need more
details.
PPP itself will always stop the queue, and return NETDEV_TX_OK on a
transmit attempt. It may wake the queue back up before returning if
the downstream device (such as pppoatm) accepted the packet.
But in either case NETDEV_TX_OK is returned and this is what the teql
master transmit sees, and this takes the code path which advances the
slave pointer to the next device.
Therefore the next teql master transmit should try the next device in
the slave list, not the PPP device used in the previous call.
^ 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