* Re: 3.0.23 WARNING: at net/ipv4/tcp_input.c:3375 tcp_ack+0x1d62/0x2030()
From: Eric Dumazet @ 2012-03-19 17:13 UTC (permalink / raw)
To: Greg KH; +Cc: Stefan Priebe - Profihost AG, stable, Linux Netdev List
In-Reply-To: <20120319161604.GA2972@kroah.com>
On Mon, 2012-03-19 at 09:16 -0700, Greg KH wrote:
> On Mon, Mar 19, 2012 at 09:15:34AM -0700, Greg KH wrote:
> > On Mon, Mar 19, 2012 at 09:10:51AM +0100, Stefan Priebe - Profihost AG wrote:
> > > Hi list,
> > >
> > > today i've seen the following error / backtrace several times on a
> > > machine running vanilla stable 3.0.23.
> >
> > Can you try 3.0.24?
>
> That would be 3.0.25, sorry about that.
Yes, this includes the following fixes :
Neal Cardwell (3):
tcp: fix false reordering signal in tcp_shifted_skb
tcp: don't fragment SACKed skbs in tcp_mark_head_lost()
tcp: fix tcp_shift_skb_data() to not shift SACKed data below snd_una
^ permalink raw reply
* Re: [E1000-devel] e1000e interface hang on 82574L
From: Nix @ 2012-03-19 17:31 UTC (permalink / raw)
To: Wyborny, Carolyn
Cc: Chris Boot, e1000-devel@lists.sourceforge.net, netdev, lkml
In-Reply-To: <9BBC4E0CF881AA4299206E2E1412B6260E512FB9@ORSMSX102.amr.corp.intel.com>
On 19 Mar 2012, Carolyn Wyborny said:
>>you'll see that I tested that, and it doesn't work :( even if it did
>>work, it shouldn't be needed: the driver attempts to turn off PCIe ASPM
>>on affected NICs, and fails, apparently because *something* turns it
>>back on again.
>>
> The driver attempts to disable L0s state, not the entire feature. It
It tries to disable L1 state as well (or it did when I tested this last,
although I suspect you're right and it may leave L1 turned on these
days: judging by the contents of e1000_82574_info, anyway.)
> is also required that the device upstream on the bus from the 82574L
> have this disabled. Yes, I agree there appears to be something in the
> os that either ren-enables or fails to disable the feature on the
> upstream device, as desired. Platforms/systems also appear to vary in
> this regard, so the solutions may vary a bit as well.
>
> Its worth trying your solution as well if what I suggested doesn't
> work, but there is not one solution that fits all, unfortunately.
I don't *have* a solution. :( 'setpci by hand some unknown amount of
time after booting once the interface has stabilized' hardly counts as a
solution of any sort. It's, at best, a workaround that lets me use my
systems without hourly lockups until a real solution is found.
(To clarify: manual setpci to force off the ASPM bits is the only thing
that works for me. The driver's automatic disabling of L0s and L1
doesn't work: nor does booting with pcie_aspm=off. In both cases, I end
up with both L0s and L1 turned on, and a lockup some time later, unless
I setpci the bits off by hand.)
--
NULL && (void)
^ permalink raw reply
* Re: 3.0.23 WARNING: at net/ipv4/tcp_input.c:3375 tcp_ack+0x1d62/0x2030()
From: Neal Cardwell @ 2012-03-19 17:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: Greg KH, Stefan Priebe - Profihost AG, stable, Linux Netdev List
In-Reply-To: <1332177220.9397.33.camel@edumazet-glaptop>
On Mon, Mar 19, 2012 at 09:10:51AM +0100, Stefan Priebe - Profihost AG wrote:
> WARNING: at net/ipv4/tcp_input.c:3375 tcp_ack+0x1d62/0x2030()
I double-checked the warning, and indeed in the 3.0.23 tcp_input.c at
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=net/ipv4/tcp_input.c;h=ee08f11ff21a802faa8b32efc1eb312e479878d6;hb=bf6a68d2a214e07f7c0d6538e00e17b826714160#l3375
that line is:
WARN_ON((int)tp->sacked_out < 0);
So this indeed looks like the known issue that is fixed by the commits
Eric mentions, which are in 3.0.25.
neal
^ permalink raw reply
* RE: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
From: Haiyang Zhang @ 2012-03-19 17:46 UTC (permalink / raw)
To: Eric Dumazet
Cc: KY Srinivasan, davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org
In-Reply-To: <1332177118.9397.32.camel@edumazet-glaptop>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Monday, March 19, 2012 1:12 PM
> To: Haiyang Zhang
> Cc: KY Srinivasan; davem@davemloft.net; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org
> Subject: Re: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
>
> On Mon, 2012-03-19 at 10:02 -0700, Haiyang Zhang wrote:
> > Instead of dropping the packet, we keep the skb buffer, and return
> > NETDEV_TX_BUSY to let upper layer retry send. This will not cause
> > endless loop, because the host is taking data away from ring buffer.
> >
> > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
> > ---
> > drivers/net/hyperv/netvsc_drv.c | 5 +----
> > 1 files changed, 1 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/hyperv/netvsc_drv.c
> > b/drivers/net/hyperv/netvsc_drv.c index 2517d20..dd29478 100644
> > --- a/drivers/net/hyperv/netvsc_drv.c
> > +++ b/drivers/net/hyperv/netvsc_drv.c
> > @@ -223,13 +223,10 @@ static int netvsc_start_xmit(struct sk_buff *skb,
> struct net_device *net)
> > net->stats.tx_bytes += skb->len;
> > net->stats.tx_packets++;
> > } else {
> > - /* we are shutting down or bus overloaded, just drop packet
> */
> > - net->stats.tx_dropped++;
> > kfree(packet);
> > - dev_kfree_skb_any(skb);
> > }
> >
> > - return NETDEV_TX_OK;
> > + return ret ? NETDEV_TX_BUSY : NETDEV_TX_OK;
> > }
> >
> > /*
>
> Thats simply not true at all.
>
> A start_xmit() cannot do that.
>
> TX_BUSY should never be returned at all, its a deprecated code, for pretty
> good reasons. (assuming queue is not stopped)
We actually stop queue when the ring buffer is busy, see the code in netvsc.c
> Try this on a machine with one CPU, I am pretty sure this can trigger
> complete freezes.
I have tested with one CPU. After NETDEV_TX_BUSY is returned, the Linux
guest OS continues to respond without any problem.
Thanks,
- Haiyang
^ permalink raw reply
* [PATCH] net: qmi_wwan: fix build error due to cdc-wdm dependecy
From: Bjørn Mork @ 2012-03-19 17:48 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, netdev, linux-usb, Greg KH,
Bjørn Mork
In-Reply-To: <20120319184830.fce597a16eaf7206195a7a45@canb.auug.org.au>
Fixes:
drivers/built-in.o: In function `qmi_wwan_bind_shared':
qmi_wwan.c:(.text+0x25b686): undefined reference to `usb_cdc_wdm_register'
make[1]: *** [.tmp_vmlinux1] Error 1
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
Thanks for noticing.
This should have been in commit c3ecb08a
net: qmi_wwan: support devices having a shared QMI/wwan interface
Bjørn
drivers/net/usb/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 4bad899..833e32f 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -401,6 +401,7 @@ config USB_NET_KALMIA
config USB_NET_QMI_WWAN
tristate "QMI WWAN driver for Qualcomm MSM based 3G and LTE modems"
depends on USB_USBNET
+ select USB_WDM
help
Support WWAN LTE/3G devices based on Qualcomm Mobile Data Modem
(MDM) chipsets. Examples of such devices are
--
1.7.9.1
^ permalink raw reply related
* Re: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
From: Stephen Hemminger @ 2012-03-19 17:48 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Haiyang Zhang, kys, davem, netdev, linux-kernel, devel
In-Reply-To: <1332177118.9397.32.camel@edumazet-glaptop>
On Mon, 19 Mar 2012 10:11:58 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2012-03-19 at 10:02 -0700, Haiyang Zhang wrote:
> > Instead of dropping the packet, we keep the skb buffer, and return
> > NETDEV_TX_BUSY to let upper layer retry send. This will not cause
> > endless loop, because the host is taking data away from ring buffer.
> >
> > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
> > ---
> > drivers/net/hyperv/netvsc_drv.c | 5 +----
> > 1 files changed, 1 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> > index 2517d20..dd29478 100644
> > --- a/drivers/net/hyperv/netvsc_drv.c
> > +++ b/drivers/net/hyperv/netvsc_drv.c
> > @@ -223,13 +223,10 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
> > net->stats.tx_bytes += skb->len;
> > net->stats.tx_packets++;
> > } else {
> > - /* we are shutting down or bus overloaded, just drop packet */
> > - net->stats.tx_dropped++;
> > kfree(packet);
> > - dev_kfree_skb_any(skb);
> > }
> >
> > - return NETDEV_TX_OK;
> > + return ret ? NETDEV_TX_BUSY : NETDEV_TX_OK;
> > }
> >
> > /*
>
> Thats simply not true at all.
>
> A start_xmit() cannot do that.
>
> TX_BUSY should never be returned at all, its a deprecated code, for
> pretty good reasons. (assuming queue is not stopped)
>
> Try this on a machine with one CPU, I am pretty sure this can trigger
> complete freezes.
>
> Once softirq loops in your start_xmit(), how do you think one process
> can help you now ?
Eric is right, look how devices with real physical rings work.
They test for space left at end of start xmit and stop the transmit
queue with netif_stop_queue. The transmit done code then re-enables
when enough space is netif_wake_queue. Think of it as classic
high/low water mark on a FIFO.
^ permalink raw reply
* RE: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
From: Haiyang Zhang @ 2012-03-19 17:50 UTC (permalink / raw)
To: Stephen Hemminger, Eric Dumazet
Cc: KY Srinivasan, davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org
In-Reply-To: <20120319104847.3a4c5fc0@nehalam.linuxnetplumber.net>
> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: Monday, March 19, 2012 1:49 PM
> To: Eric Dumazet
> Cc: Haiyang Zhang; KY Srinivasan; davem@davemloft.net;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org
> Subject: Re: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
>
> On Mon, 19 Mar 2012 10:11:58 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > On Mon, 2012-03-19 at 10:02 -0700, Haiyang Zhang wrote:
> > > Instead of dropping the packet, we keep the skb buffer, and return
> > > NETDEV_TX_BUSY to let upper layer retry send. This will not cause
> > > endless loop, because the host is taking data away from ring buffer.
> > >
> > > Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> > > Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
> > > ---
> > > drivers/net/hyperv/netvsc_drv.c | 5 +----
> > > 1 files changed, 1 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/net/hyperv/netvsc_drv.c
> > > b/drivers/net/hyperv/netvsc_drv.c index 2517d20..dd29478 100644
> > > --- a/drivers/net/hyperv/netvsc_drv.c
> > > +++ b/drivers/net/hyperv/netvsc_drv.c
> > > @@ -223,13 +223,10 @@ static int netvsc_start_xmit(struct sk_buff *skb,
> struct net_device *net)
> > > net->stats.tx_bytes += skb->len;
> > > net->stats.tx_packets++;
> > > } else {
> > > - /* we are shutting down or bus overloaded, just drop packet
> */
> > > - net->stats.tx_dropped++;
> > > kfree(packet);
> > > - dev_kfree_skb_any(skb);
> > > }
> > >
> > > - return NETDEV_TX_OK;
> > > + return ret ? NETDEV_TX_BUSY : NETDEV_TX_OK;
> > > }
> > >
> > > /*
> >
> > Thats simply not true at all.
> >
> > A start_xmit() cannot do that.
> >
> > TX_BUSY should never be returned at all, its a deprecated code, for
> > pretty good reasons. (assuming queue is not stopped)
> >
> > Try this on a machine with one CPU, I am pretty sure this can trigger
> > complete freezes.
> >
> > Once softirq loops in your start_xmit(), how do you think one process
> > can help you now ?
>
> Eric is right, look how devices with real physical rings work.
> They test for space left at end of start xmit and stop the transmit queue with
> netif_stop_queue. The transmit done code then re-enables when enough
> space is netif_wake_queue. Think of it as classic high/low water mark on a
> FIFO.
As in my previous reply to Eric --
We actually stop queue when the ring buffer is busy, see the code in netvsc.c
I have tested with one CPU. After NETDEV_TX_BUSY is returned, the Linux guest OS
continues to respond without any problem.
Thanks,
- Haiyang
^ permalink raw reply
* Re: 3.0.23 WARNING: at net/ipv4/tcp_input.c:3375 tcp_ack+0x1d62/0x2030()
From: Stefan Priebe @ 2012-03-19 18:20 UTC (permalink / raw)
To: Neal Cardwell
Cc: Eric Dumazet, Greg KH, stable@vger.kernel.org, Linux Netdev List
In-Reply-To: <CADVnQynya96iG0cZjVGhtac2MP3AOBWODP7nUTMVhMd=6GWSOQ@mail.gmail.com>
Am 19.03.2012 um 18:39 schrieb Neal Cardwell <ncardwell@google.com>:
> On Mon, Mar 19, 2012 at 09:10:51AM +0100, Stefan Priebe - Profihost AG wrote:
>> WARNING: at net/ipv4/tcp_input.c:3375 tcp_ack+0x1d62/0x2030()
>
> I double-checked the warning, and indeed in the 3.0.23 tcp_input.c at
>
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=net/ipv4/tcp_input.c;h=ee08f11ff21a802faa8b32efc1eb312e479878d6;hb=bf6a68d2a214e07f7c0d6538e00e17b826714160#l3375
>
> that line is:
> WARN_ON((int)tp->sacked_out < 0);
>
> So this indeed looks like the known issue that is fixed by the commits
> Eric mentions, which are in 3.0.25.
>
> neal
Perfect, thanks!
Greg any ETA?
Stefan
^ permalink raw reply
* RE: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
From: Eric Dumazet @ 2012-03-19 18:23 UTC (permalink / raw)
To: Haiyang Zhang
Cc: KY Srinivasan, davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org
In-Reply-To: <A1F3067C9B68744AA19F6802BAB8FFDC0DCEA84D@TK5EX14MBXC223.redmond.corp.microsoft.com>
On Mon, 2012-03-19 at 17:46 +0000, Haiyang Zhang wrote:
> We actually stop queue when the ring buffer is busy, see the code in netvsc.c
Then you dont need NETDEV_TX_BUSY at all.
When you used whole tx slots, you stop the queue, so start_xmit() wont
be called (and you wont recover from this useless call with
NETDEV_TX_BUSY)
>
> > Try this on a machine with one CPU, I am pretty sure this can trigger
> > complete freezes.
>
> I have tested with one CPU. After NETDEV_TX_BUSY is returned, the Linux
> guest OS continues to respond without any problem.
Problem is you might have used several billions cycles/instructions
without notice. Thats a busy loop and you assume consumer can empty som
tx slots while you're busy looping. Thats pretty lazy.
This path is actually hard to test. In fact most of the time its
probably never hit at all.
Some NETDEV_TX_BUSY bugs are in the code since ages and nobody
complained. Thats not a reason to add new ones.
See recents commits on this subject : Bug never triggered but it was
here fir sure.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=b8fbaef586176f6abe0eb7887ddae66e99898b79
^ permalink raw reply
* Re: 3.0.23 WARNING: at net/ipv4/tcp_input.c:3375 tcp_ack+0x1d62/0x2030()
From: David Miller @ 2012-03-19 18:24 UTC (permalink / raw)
To: s.priebe; +Cc: ncardwell, eric.dumazet, greg, stable, netdev
In-Reply-To: <AB9F1763-96B1-4AE4-8D94-73246EA08207@profihost.ag>
From: Stefan Priebe <s.priebe@profihost.ag>
Date: Mon, 19 Mar 2012 19:20:39 +0100
> Am 19.03.2012 um 18:39 schrieb Neal Cardwell <ncardwell@google.com>:
>
>> On Mon, Mar 19, 2012 at 09:10:51AM +0100, Stefan Priebe - Profihost AG wrote:
>>> WARNING: at net/ipv4/tcp_input.c:3375 tcp_ack+0x1d62/0x2030()
>>
>> I double-checked the warning, and indeed in the 3.0.23 tcp_input.c at
>>
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=net/ipv4/tcp_input.c;h=ee08f11ff21a802faa8b32efc1eb312e479878d6;hb=bf6a68d2a214e07f7c0d6538e00e17b826714160#l3375
>>
>> that line is:
>> WARN_ON((int)tp->sacked_out < 0);
>>
>> So this indeed looks like the known issue that is fixed by the commits
>> Eric mentions, which are in 3.0.25.
>>
>> neal
>
> Perfect, thanks!
>
> Greg any ETA?
He released it the very second he told you to use it.
^ permalink raw reply
* RE: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
From: Eric Dumazet @ 2012-03-19 18:30 UTC (permalink / raw)
To: Haiyang Zhang
Cc: Stephen Hemminger, KY Srinivasan, davem@davemloft.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <A1F3067C9B68744AA19F6802BAB8FFDC0DCEA873@TK5EX14MBXC223.redmond.corp.microsoft.com>
On Mon, 2012-03-19 at 17:50 +0000, Haiyang Zhang wrote:
> As in my previous reply to Eric --
> We actually stop queue when the ring buffer is busy, see the code in netvsc.c
>
> I have tested with one CPU. After NETDEV_TX_BUSY is returned, the Linux guest OS
> continues to respond without any problem.
Then something is wrong somewhere.
Dont hide a bug adding a trick.
If you ever return NETDEV_TX_BUSY from start_xmit(), then you MUST call
netif_tx_stop_queue() as well right before.
I believe I already told this before...
^ permalink raw reply
* [PATCH v3 3/4] mac80211: Framework to get wifi-driver stats via ethtool.
From: greearb-my8/4N5VtI7c+919tysfdA @ 2012-03-19 18:51 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Ben Greear
In-Reply-To: <1332183105-4447-1-git-send-email-greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
From: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
This adds hooks to call into the driver to get additional
stats for the ethtool API.
Signed-off-by: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
---
v3: No changes from v2.
:100644 100644 d49928b... a90cc8e... M include/net/mac80211.h
:100644 100644 bb834d7... f82b285... M net/mac80211/cfg.c
:100644 100644 b6ef8e7... c2d1661... M net/mac80211/driver-ops.h
:100644 100644 6e9df8f... f05fc9c... M net/mac80211/driver-trace.h
include/net/mac80211.h | 17 +++++++++++++++++
net/mac80211/cfg.c | 19 ++++++++++++++++---
net/mac80211/driver-ops.h | 37 +++++++++++++++++++++++++++++++++++++
net/mac80211/driver-trace.h | 15 +++++++++++++++
4 files changed, 85 insertions(+), 3 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d49928b..a90cc8e 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2108,6 +2108,14 @@ enum ieee80211_frame_release_type {
* The @tids parameter is a bitmap and tells the driver which TIDs the
* frames will be on; it will at most have two bits set.
* This callback must be atomic.
+ *
+ * @get_et_sset_count: Ethtool API to get string-set count.
+ *
+ * @get_et_stats: Ethtool API to get a set of u64 stats.
+ *
+ * @get_et_strings: Ethtool API to get a set of strings to describe stats
+ * and perhaps other supported types of ethtool data-sets.
+ *
*/
struct ieee80211_ops {
void (*tx)(struct ieee80211_hw *hw, struct sk_buff *skb);
@@ -2236,6 +2244,15 @@ struct ieee80211_ops {
u16 tids, int num_frames,
enum ieee80211_frame_release_type reason,
bool more_data);
+
+ int (*get_et_sset_count)(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif, int sset);
+ void (*get_et_stats)(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ethtool_stats *stats, u64 *data);
+ void (*get_et_strings)(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ u32 sset, u8 *data);
};
/**
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index bb834d7..f82b285 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -125,10 +125,17 @@ static int ieee80211_get_et_sset_count(struct wiphy *wiphy,
struct net_device *dev,
int sset)
{
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ int rv = 0;
+
if (sset == ETH_SS_STATS)
- return STA_STATS_LEN;
+ rv += STA_STATS_LEN;
- return -EOPNOTSUPP;
+ rv += drv_get_et_sset_count(sdata, sset);
+
+ if (rv == 0)
+ return -EOPNOTSUPP;
+ return rv;
}
static void ieee80211_get_et_stats(struct wiphy *wiphy,
@@ -167,16 +174,22 @@ static void ieee80211_get_et_stats(struct wiphy *wiphy,
BUG_ON(i != STA_STATS_LEN);
}
rcu_read_unlock();
+
+ drv_get_et_stats(sdata, stats, &(data[STA_STATS_LEN]));
}
static void ieee80211_get_et_strings(struct wiphy *wiphy,
struct net_device *dev,
u32 sset, u8 *data)
{
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ int sz_sta_stats = 0;
+
if (sset == ETH_SS_STATS) {
- int sz_sta_stats = sizeof(ieee80211_gstrings_sta_stats);
+ sz_sta_stats = sizeof(ieee80211_gstrings_sta_stats);
memcpy(data, *ieee80211_gstrings_sta_stats, sz_sta_stats);
}
+ drv_get_et_strings(sdata, sset, &(data[sz_sta_stats]));
}
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index b6ef8e7..c2d1661 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -35,6 +35,43 @@ static inline void drv_tx_frags(struct ieee80211_local *local,
local->ops->tx_frags(&local->hw, vif, sta, skbs);
}
+static inline void drv_get_et_strings(struct ieee80211_sub_if_data *sdata,
+ u32 sset, u8 *data)
+{
+ struct ieee80211_local *local = sdata->local;
+ if (local->ops->get_et_strings) {
+ trace_drv_get_et_strings(local, sset);
+ local->ops->get_et_strings(&local->hw, &sdata->vif, sset, data);
+ trace_drv_return_void(local);
+ }
+}
+
+static inline void drv_get_et_stats(struct ieee80211_sub_if_data *sdata,
+ struct ethtool_stats *stats,
+ u64 *data)
+{
+ struct ieee80211_local *local = sdata->local;
+ if (local->ops->get_et_stats) {
+ trace_drv_get_et_stats(local);
+ local->ops->get_et_stats(&local->hw, &sdata->vif, stats, data);
+ trace_drv_return_void(local);
+ }
+}
+
+static inline int drv_get_et_sset_count(struct ieee80211_sub_if_data *sdata,
+ int sset)
+{
+ struct ieee80211_local *local = sdata->local;
+ int rv = 0;
+ if (local->ops->get_et_sset_count) {
+ trace_drv_get_et_sset_count(local, sset);
+ rv = local->ops->get_et_sset_count(&local->hw, &sdata->vif,
+ sset);
+ trace_drv_return_int(local, rv);
+ }
+ return rv;
+}
+
static inline int drv_start(struct ieee80211_local *local)
{
int ret;
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 6e9df8f..f05fc9c 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -161,6 +161,21 @@ DEFINE_EVENT(local_only_evt, drv_start,
TP_ARGS(local)
);
+DEFINE_EVENT(local_u32_evt, drv_get_et_strings,
+ TP_PROTO(struct ieee80211_local *local, u32 sset),
+ TP_ARGS(local, sset)
+);
+
+DEFINE_EVENT(local_u32_evt, drv_get_et_sset_count,
+ TP_PROTO(struct ieee80211_local *local, u32 sset),
+ TP_ARGS(local, sset)
+);
+
+DEFINE_EVENT(local_only_evt, drv_get_et_stats,
+ TP_PROTO(struct ieee80211_local *local),
+ TP_ARGS(local)
+);
+
DEFINE_EVENT(local_only_evt, drv_suspend,
TP_PROTO(struct ieee80211_local *local),
TP_ARGS(local)
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 4/4] ath9k: Support ethtool getstats api.
From: greearb-my8/4N5VtI7c+919tysfdA @ 2012-03-19 18:51 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Ben Greear
In-Reply-To: <1332183105-4447-1-git-send-email-greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
From: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
This returns many of the values that formerly could
only be obtained from debugfs. This should be an
improvement when trying to access these counters
programatically. Currently this support is only
enabled when DEBUGFS is enabled because otherwise
these stats are not accumulated.
Signed-off-by: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
---
v3: No changes from v2
:100644 100644 4a00806... 7261f88... M drivers/net/wireless/ath/ath9k/main.c
drivers/net/wireless/ath/ath9k/main.c | 134 +++++++++++++++++++++++++++++++++
1 files changed, 134 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 4a00806..7261f88 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2430,6 +2430,134 @@ static int ath9k_get_antenna(struct ieee80211_hw *hw, u32 *tx_ant, u32 *rx_ant)
return 0;
}
+#ifdef CONFIG_ATH9K_DEBUGFS
+
+/* Ethtool support for get-stats */
+
+#define AMKSTR(nm) #nm "_BE", #nm "_BK", #nm "_VI", #nm "_VO"
+static const char ath9k_gstrings_stats[][ETH_GSTRING_LEN] = {
+ "tx_pkts_nic",
+ "tx_bytes_nic",
+ "rx_pkts_nic",
+ "rx_bytes_nic",
+ AMKSTR(d_tx_pkts),
+ AMKSTR(d_tx_bytes),
+ AMKSTR(d_tx_mpdus_queued),
+ AMKSTR(d_tx_mpdus_completed),
+ AMKSTR(d_tx_mpdu_retries),
+ AMKSTR(d_tx_aggregates),
+ AMKSTR(d_tx_ampdus_queued_hw),
+ AMKSTR(d_tx_ampdus_queued_sw),
+ AMKSTR(d_tx_ampdus_completed),
+ AMKSTR(d_tx_ampdu_retries),
+ AMKSTR(d_tx_ampdu_xretries),
+ AMKSTR(d_tx_fifo_underrun),
+ AMKSTR(d_tx_op_exceeded),
+ AMKSTR(d_tx_timer_expiry),
+ AMKSTR(d_tx_desc_cfg_err),
+ AMKSTR(d_tx_data_underrun),
+ AMKSTR(d_tx_delim_underrun),
+
+ "d_rx_decrypt_crc_err",
+ "d_rx_phy_err",
+ "d_rx_mic_err",
+ "d_rx_pre_delim_crc_err",
+ "d_rx_post_delim_crc_err",
+ "d_rx_decrypt_busy_err",
+
+ "d_rx_phyerr_radar",
+ "d_rx_phyerr_ofdm_timing",
+ "d_rx_phyerr_cck_timing",
+
+};
+#define ATH9K_SSTATS_LEN ARRAY_SIZE(ath9k_gstrings_stats)
+
+static void ath9k_get_et_strings(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ u32 sset, u8 *data)
+{
+ if (sset == ETH_SS_STATS)
+ memcpy(data, *ath9k_gstrings_stats,
+ sizeof(ath9k_gstrings_stats));
+}
+
+static int ath9k_get_et_sset_count(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif, int sset)
+{
+ if (sset == ETH_SS_STATS)
+ return ATH9K_SSTATS_LEN;
+ return 0;
+}
+
+#define PR_QNUM(_n) (sc->tx.txq_map[_n]->axq_qnum)
+#define AWDATA(elem) \
+ do { \
+ data[i++] = sc->debug.stats.txstats[PR_QNUM(WME_AC_BE)].elem; \
+ data[i++] = sc->debug.stats.txstats[PR_QNUM(WME_AC_BK)].elem; \
+ data[i++] = sc->debug.stats.txstats[PR_QNUM(WME_AC_VI)].elem; \
+ data[i++] = sc->debug.stats.txstats[PR_QNUM(WME_AC_VO)].elem; \
+ } while (0)
+
+#define AWDATA_RX(elem) \
+ do { \
+ data[i++] = sc->debug.stats.rxstats.elem; \
+ } while (0)
+
+static void ath9k_get_et_stats(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ethtool_stats *stats, u64 *data)
+{
+ struct ath_softc *sc = hw->priv;
+ int i = 0;
+
+ data[i++] = (sc->debug.stats.txstats[PR_QNUM(WME_AC_BE)].tx_pkts_all +
+ sc->debug.stats.txstats[PR_QNUM(WME_AC_BK)].tx_pkts_all +
+ sc->debug.stats.txstats[PR_QNUM(WME_AC_VI)].tx_pkts_all +
+ sc->debug.stats.txstats[PR_QNUM(WME_AC_VO)].tx_pkts_all);
+ data[i++] = (sc->debug.stats.txstats[PR_QNUM(WME_AC_BE)].tx_bytes_all +
+ sc->debug.stats.txstats[PR_QNUM(WME_AC_BK)].tx_bytes_all +
+ sc->debug.stats.txstats[PR_QNUM(WME_AC_VI)].tx_bytes_all +
+ sc->debug.stats.txstats[PR_QNUM(WME_AC_VO)].tx_bytes_all);
+ AWDATA_RX(rx_pkts_all);
+ AWDATA_RX(rx_bytes_all);
+
+ AWDATA(tx_pkts_all);
+ AWDATA(tx_bytes_all);
+ AWDATA(queued);
+ AWDATA(completed);
+ AWDATA(xretries);
+ AWDATA(a_aggr);
+ AWDATA(a_queued_hw);
+ AWDATA(a_queued_sw);
+ AWDATA(a_completed);
+ AWDATA(a_retries);
+ AWDATA(a_xretries);
+ AWDATA(fifo_underrun);
+ AWDATA(xtxop);
+ AWDATA(timer_exp);
+ AWDATA(desc_cfg_err);
+ AWDATA(data_underrun);
+ AWDATA(delim_underrun);
+
+ AWDATA_RX(decrypt_crc_err);
+ AWDATA_RX(phy_err);
+ AWDATA_RX(mic_err);
+ AWDATA_RX(pre_delim_crc_err);
+ AWDATA_RX(post_delim_crc_err);
+ AWDATA_RX(decrypt_busy_err);
+
+ AWDATA_RX(phy_err_stats[ATH9K_PHYERR_RADAR]);
+ AWDATA_RX(phy_err_stats[ATH9K_PHYERR_OFDM_TIMING]);
+ AWDATA_RX(phy_err_stats[ATH9K_PHYERR_CCK_TIMING]);
+
+ BUG_ON(i != ATH9K_SSTATS_LEN);
+}
+
+/* End of ethtool get-stats functions */
+
+#endif
+
+
struct ieee80211_ops ath9k_ops = {
.tx = ath9k_tx,
.start = ath9k_start,
@@ -2458,4 +2586,10 @@ struct ieee80211_ops ath9k_ops = {
.get_stats = ath9k_get_stats,
.set_antenna = ath9k_set_antenna,
.get_antenna = ath9k_get_antenna,
+
+#ifdef CONFIG_ATH9K_DEBUGFS
+ .get_et_sset_count = ath9k_get_et_sset_count,
+ .get_et_stats = ath9k_get_et_stats,
+ .get_et_strings = ath9k_get_et_strings,
+#endif
};
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 1/4] cfg80211: Add framework to support ethtool stats.
From: greearb @ 2012-03-19 18:51 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev, Ben Greear
From: Ben Greear <greearb@candelatech.com>
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v3: Add reference to ethtool_ops in comments.
This doesn't actually make kdoc generate links,
but hopefully a human can figure it out.
:100644 100644 9ed8021... c60b180... M include/net/cfg80211.h
:100644 100644 9bde4d1... 7eecdf4... M net/wireless/ethtool.c
include/net/cfg80211.h | 17 +++++++++++++++++
net/wireless/ethtool.c | 29 +++++++++++++++++++++++++++++
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9ed8021..c60b180 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1491,6 +1491,16 @@ struct cfg80211_gtk_rekey_data {
* later passes to cfg80211_probe_status().
*
* @set_noack_map: Set the NoAck Map for the TIDs.
+ *
+ * @get_et_sset_count: Ethtool API to get string-set count.
+ * See @ethtool_ops.get_sset_count
+ *
+ * @get_et_stats: Ethtool API to get a set of u64 stats.
+ * See @ethtool_ops.get_ethtool_stats
+ *
+ * @get_et_strings: Ethtool API to get a set of strings to describe stats
+ * and perhaps other supported types of ethtool data-sets.
+ * See @ethtool_ops.get_strings
*/
struct cfg80211_ops {
int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -1689,6 +1699,13 @@ struct cfg80211_ops {
u16 noack_map);
struct ieee80211_channel *(*get_channel)(struct wiphy *wiphy);
+
+ int (*get_et_sset_count)(struct wiphy *wiphy,
+ struct net_device *dev, int sset);
+ void (*get_et_stats)(struct wiphy *wiphy, struct net_device *dev,
+ struct ethtool_stats *stats, u64 *data);
+ void (*get_et_strings)(struct wiphy *wiphy, struct net_device *dev,
+ u32 sset, u8 *data);
};
/*
diff --git a/net/wireless/ethtool.c b/net/wireless/ethtool.c
index 9bde4d1..7eecdf4 100644
--- a/net/wireless/ethtool.c
+++ b/net/wireless/ethtool.c
@@ -68,6 +68,32 @@ static int cfg80211_set_ringparam(struct net_device *dev,
return -ENOTSUPP;
}
+static int cfg80211_get_sset_count(struct net_device *dev, int sset)
+{
+ struct wireless_dev *wdev = dev->ieee80211_ptr;
+ struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
+ if (rdev->ops->get_et_sset_count)
+ return rdev->ops->get_et_sset_count(wdev->wiphy, dev, sset);
+ return -EOPNOTSUPP;
+}
+
+static void cfg80211_get_stats(struct net_device *dev,
+ struct ethtool_stats *stats, u64 *data)
+{
+ struct wireless_dev *wdev = dev->ieee80211_ptr;
+ struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
+ if (rdev->ops->get_et_stats)
+ rdev->ops->get_et_stats(wdev->wiphy, dev, stats, data);
+}
+
+static void cfg80211_get_strings(struct net_device *dev, u32 sset, u8 *data)
+{
+ struct wireless_dev *wdev = dev->ieee80211_ptr;
+ struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
+ if (rdev->ops->get_et_strings)
+ rdev->ops->get_et_strings(wdev->wiphy, dev, sset, data);
+}
+
const struct ethtool_ops cfg80211_ethtool_ops = {
.get_drvinfo = cfg80211_get_drvinfo,
.get_regs_len = cfg80211_get_regs_len,
@@ -75,4 +101,7 @@ const struct ethtool_ops cfg80211_ethtool_ops = {
.get_link = ethtool_op_get_link,
.get_ringparam = cfg80211_get_ringparam,
.set_ringparam = cfg80211_set_ringparam,
+ .get_strings = cfg80211_get_strings,
+ .get_ethtool_stats = cfg80211_get_stats,
+ .get_sset_count = cfg80211_get_sset_count,
};
--
1.7.3.4
^ permalink raw reply related
* [PATCH v3 2/4] mac80211: Support getting sta_info stats via ethtool.
From: greearb @ 2012-03-19 18:51 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev, Ben Greear
In-Reply-To: <1332183105-4447-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
This lets ethtool print out stats related to stations
connected to the interface. Does not yet get stats
from the underlying driver.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v3: Update patch description.
:100644 100644 cf5b08a... bb834d7... M net/mac80211/cfg.c
net/mac80211/cfg.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index cf5b08a..bb834d7 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -112,6 +112,74 @@ static int ieee80211_set_noack_map(struct wiphy *wiphy,
return 0;
}
+static const char ieee80211_gstrings_sta_stats[][ETH_GSTRING_LEN] = {
+ "rx_packets", "rx_bytes", "wep_weak_iv_count",
+ "rx_duplicates", "rx_fragments", "rx_dropped",
+ "tx_packets", "tx_bytes", "tx_fragments",
+ "tx_filtered", "tx_retry_failed", "tx_retries",
+ "beacon_loss"
+};
+#define STA_STATS_LEN ARRAY_SIZE(ieee80211_gstrings_sta_stats)
+
+static int ieee80211_get_et_sset_count(struct wiphy *wiphy,
+ struct net_device *dev,
+ int sset)
+{
+ if (sset == ETH_SS_STATS)
+ return STA_STATS_LEN;
+
+ return -EOPNOTSUPP;
+}
+
+static void ieee80211_get_et_stats(struct wiphy *wiphy,
+ struct net_device *dev,
+ struct ethtool_stats *stats,
+ u64 *data)
+{
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+ struct sta_info *sta;
+ struct ieee80211_local *local = sdata->local;
+
+ memset(data, 0, sizeof(u64) * STA_STATS_LEN);
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(sta, &local->sta_list, list) {
+ int i = 0;
+
+ /* Make sure this station belongs to the proper dev */
+ if (sta->sdata->dev != dev)
+ continue;
+
+ data[i++] += sta->rx_packets;
+ data[i++] += sta->rx_bytes;
+ data[i++] += sta->wep_weak_iv_count;
+ data[i++] += sta->num_duplicates;
+ data[i++] += sta->rx_fragments;
+ data[i++] += sta->rx_dropped;
+
+ data[i++] += sta->tx_packets;
+ data[i++] += sta->tx_bytes;
+ data[i++] += sta->tx_fragments;
+ data[i++] += sta->tx_filtered_count;
+ data[i++] += sta->tx_retry_failed;
+ data[i++] += sta->tx_retry_count;
+ data[i++] += sta->beacon_loss_count;
+ BUG_ON(i != STA_STATS_LEN);
+ }
+ rcu_read_unlock();
+}
+
+static void ieee80211_get_et_strings(struct wiphy *wiphy,
+ struct net_device *dev,
+ u32 sset, u8 *data)
+{
+ if (sset == ETH_SS_STATS) {
+ int sz_sta_stats = sizeof(ieee80211_gstrings_sta_stats);
+ memcpy(data, *ieee80211_gstrings_sta_stats, sz_sta_stats);
+ }
+}
+
+
static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
u8 key_idx, bool pairwise, const u8 *mac_addr,
struct key_params *params)
@@ -2768,4 +2836,7 @@ struct cfg80211_ops mac80211_config_ops = {
.probe_client = ieee80211_probe_client,
.get_channel = ieee80211_wiphy_get_channel,
.set_noack_map = ieee80211_set_noack_map,
+ .get_et_sset_count = ieee80211_get_et_sset_count,
+ .get_et_stats = ieee80211_get_et_stats,
+ .get_et_strings = ieee80211_get_et_strings,
};
--
1.7.3.4
^ permalink raw reply related
* Re: Kernel Panic with bonding + IPoIB on 3.2.9
From: Roland Dreier @ 2012-03-19 19:05 UTC (permalink / raw)
To: Joseph Glanville
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAOzFzEi=UOnwiV+qVks7+RnYU3PFbaQ+3OaEE3YFG2HHuD5ydQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Mar 18, 2012 at 1:21 PM, Joseph Glanville
<joseph.glanville-2MxvZkOi9dvvnOemgxGiVw@public.gmane.org> wrote:
> [ 422.047024] kernel BUG at net/core/dev.c:1896!
So this line is
BUG_ON(offset >= skb_headlen(skb));
right? No paritcular idea how we hit this, though...
--
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: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
From: Haiyang Zhang @ 2012-03-19 19:17 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Hemminger, KY Srinivasan, davem@davemloft.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <1332181858.9397.49.camel@edumazet-glaptop>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Monday, March 19, 2012 2:31 PM
> To: Haiyang Zhang
> Cc: Stephen Hemminger; KY Srinivasan; davem@davemloft.net;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org
> Subject: RE: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
>
> On Mon, 2012-03-19 at 17:50 +0000, Haiyang Zhang wrote:
>
> > As in my previous reply to Eric --
> > We actually stop queue when the ring buffer is busy, see the code in
> > netvsc.c
> >
> > I have tested with one CPU. After NETDEV_TX_BUSY is returned, the
> > Linux guest OS continues to respond without any problem.
>
> Then something is wrong somewhere.
>
> Dont hide a bug adding a trick.
>
> If you ever return NETDEV_TX_BUSY from start_xmit(), then you MUST call
> netif_tx_stop_queue() as well right before.
Yes, we called the stop_queue before returning NETDEV_TX_BUSY.
The stop_queue was called in the function netvsc_send() in file netvsc.c, then it returns to rndis_filter_send(), which returns to netvsc_start_xmit() in file netvsc_drv.c. So the NETDEV_TX_BUSY is indeed returned AFTER queue is stopped.
Thanks,
- Haiyang
^ permalink raw reply
* Re: netfilter: Hung task
From: Christoph Lameter @ 2012-03-19 20:03 UTC (permalink / raw)
To: Sasha Levin
Cc: Pablo Neira Ayuso, kaber, davem, Dave Jones, netfilter-devel,
linux-kernel@vger.kernel.org List, netdev
In-Reply-To: <CA+1xoqeinbEVMUGu=zx8nDbdDFx30RiTS=qiSgFKZnSYYPDZ+Q@mail.gmail.com>
On Mon, 19 Mar 2012, Sasha Levin wrote:
> lockdep listed all the held locks there.
None of the locks listed are slub locks.
> I've mentioned that it looks very similar to
> https://lkml.org/lkml/2012/1/14/45 where the userspace helper tried to
> read from the sysfs files, but got into a deadlock since the kernel
> side held them before it called the usermode helper.
Ah yes. In that case slub held a semaphore. Code was changed since then to
no longer hold a semaphore when calling into sysfs.
The uevent handler can execute arbitrary user space code. Do you have to
hold locks while calling kmem_cache_destroy?
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: fix build error due to cdc-wdm dependecy
From: Randy Dunlap @ 2012-03-19 20:16 UTC (permalink / raw)
To: Bjørn Mork
Cc: Stephen Rothwell, linux-next, LKML, netdev, linux-usb, Greg KH
In-Reply-To: <1332179309-4163-1-git-send-email-bjorn@mork.no>
On 03/19/2012 10:48 AM, Bjørn Mork wrote:
> Fixes:
>
> drivers/built-in.o: In function `qmi_wwan_bind_shared':
> qmi_wwan.c:(.text+0x25b686): undefined reference to `usb_cdc_wdm_register'
> make[1]: *** [.tmp_vmlinux1] Error 1
>
> Reported-by: Randy Dunlap <rdunlap@xenotime.net>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Thanks.
> ---
> Thanks for noticing.
>
> This should have been in commit c3ecb08a
> net: qmi_wwan: support devices having a shared QMI/wwan interface
>
>
> Bjørn
>
>
> drivers/net/usb/Kconfig | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
> index 4bad899..833e32f 100644
> --- a/drivers/net/usb/Kconfig
> +++ b/drivers/net/usb/Kconfig
> @@ -401,6 +401,7 @@ config USB_NET_KALMIA
> config USB_NET_QMI_WWAN
> tristate "QMI WWAN driver for Qualcomm MSM based 3G and LTE modems"
> depends on USB_USBNET
> + select USB_WDM
> help
> Support WWAN LTE/3G devices based on Qualcomm Mobile Data Modem
> (MDM) chipsets. Examples of such devices are
--
~Randy
^ permalink raw reply
* RE: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
From: Eric Dumazet @ 2012-03-19 20:46 UTC (permalink / raw)
To: Haiyang Zhang
Cc: Stephen Hemminger, KY Srinivasan, davem@davemloft.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <A1F3067C9B68744AA19F6802BAB8FFDC0DCEA930@TK5EX14MBXC223.redmond.corp.microsoft.com>
On Mon, 2012-03-19 at 19:17 +0000, Haiyang Zhang wrote:
> Yes, we called the stop_queue before returning NETDEV_TX_BUSY.
>
> The stop_queue was called in the function netvsc_send() in file
> netvsc.c, then it returns to rndis_filter_send(), which returns to
> netvsc_start_xmit() in file netvsc_drv.c. So the NETDEV_TX_BUSY is
> indeed returned AFTER queue is stopped.
>
Thats should be in your changelog, so that next time, reviewers dont
have to spend their time to check you did it right, especially when
start_xmit() code is not self contained or at least in a single file.
Each time we see a NETDEV_TX_BUSY in a patch, this is a sign of a
possible problem.
Your initial changelog was :
Instead of dropping the packet, we keep the skb buffer, and return
NETDEV_TX_BUSY to let upper layer retry send. This will not cause
endless loop, because the host is taking data away from ring buffer.
And this is the typical message that doesnt explain why its safe.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/4] Gianfar byte queue limits
From: David Miller @ 2012-03-19 20:46 UTC (permalink / raw)
To: paul.gortmaker; +Cc: eric.dumazet, therbert, netdev, linuxppc-dev
In-Reply-To: <1332106761-18293-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Sun, 18 Mar 2012 17:39:17 -0400
> The following changes since commit cdf485be3a63d1f34293740fb726088c6840ceea:
>
> ixgbe: dcb: use DCB config values for FCoE traffic class on open (2012-03-14 00:49:10 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git gianfar-bql
>
> for you to fetch changes up to 5407b14c6792d6ff122ecb1a2a6acffad60ef389:
>
> gianfar: use netif_tx_queue_stopped instead of __netif_subqueue_stopped (2012-03-18 17:11:22 -0400)
Pulled, thanks.
^ permalink raw reply
* RE: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
From: Haiyang Zhang @ 2012-03-19 20:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Hemminger, KY Srinivasan, davem@davemloft.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org
In-Reply-To: <1332190018.9397.61.camel@edumazet-glaptop>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Monday, March 19, 2012 4:47 PM
> To: Haiyang Zhang
> Cc: Stephen Hemminger; KY Srinivasan; davem@davemloft.net;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org
> Subject: RE: [PATCH 1/1] net/hyperv: Fix the code handling tx busy
>
> On Mon, 2012-03-19 at 19:17 +0000, Haiyang Zhang wrote:
>
> > Yes, we called the stop_queue before returning NETDEV_TX_BUSY.
> >
> > The stop_queue was called in the function netvsc_send() in file
> > netvsc.c, then it returns to rndis_filter_send(), which returns to
> > netvsc_start_xmit() in file netvsc_drv.c. So the NETDEV_TX_BUSY is
> > indeed returned AFTER queue is stopped.
> >
>
> Thats should be in your changelog, so that next time, reviewers dont have to
> spend their time to check you did it right, especially when
> start_xmit() code is not self contained or at least in a single file.
>
> Each time we see a NETDEV_TX_BUSY in a patch, this is a sign of a possible
> problem.
>
> Your initial changelog was :
>
> Instead of dropping the packet, we keep the skb buffer, and return
> NETDEV_TX_BUSY to let upper layer retry send. This will not cause endless
> loop, because the host is taking data away from ring buffer.
>
> And this is the typical message that doesnt explain why its safe.
Thanks for your time, I will re-submit the patch with the explanation in the change
log.
Thanks,
- Haiyang
^ permalink raw reply
* [PATCH] net: update the usage of CHECKSUM_UNNECESSARY
From: Yi Zou @ 2012-03-19 21:12 UTC (permalink / raw)
To: netdev; +Cc: devel, bhutchings, jeffrey.t.kirsher
As suggested by Ben, this adds the clarification on the usage of
CHECKSUM_UNNECESSARY on the outgoing patch. Also add the usage
description of NETIF_F_FCOE_CRC and CHECKSUM_UNNECESSARY
for the kernel FCoE protocol driver.
This is a follow-up to the following:
http://patchwork.ozlabs.org/patch/147315/
Signed-off-by: Yi Zou <yi.zou@intel.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: www.Open-FCoE.org <devel@open-fcoe.org>
---
include/linux/skbuff.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 8dc8257..a2b9953 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -94,6 +94,13 @@
* about CHECKSUM_UNNECESSARY. 8)
* NETIF_F_IPV6_CSUM about as dumb as the last one but does IPv6 instead.
*
+ * UNNECESSARY: device will do per protocol specific csum. Protocol drivers
+ * that do not want net to perform the checksum calculation should use
+ * this flag in their outgoing skbs.
+ * NETIF_F_FCOE_CRC this indicates the device can do FCoE FC CRC
+ * offload. Correspondingly, the FCoE protocol driver
+ * stack should use CHECKSUM_UNNECESSARY.
+ *
* Any questions? No questions, good. --ANK
*/
^ permalink raw reply related
* Re: [net-next 0/9] bnx2x: feature patch series
From: David Miller @ 2012-03-19 20:57 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, eilong
In-Reply-To: <1332102825-7838-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Sun, 18 Mar 2012 16:33:36 -0400
> This patch series contains several small features, including
> a fix of the consistent statistics for boards with old bc firmware
> (this feature still exists only in 'net-next', hence why it isn't being
> submitted to 'net'), as well as several semantic changes -
> mostly the revision of the bnx2x's prints.
>
> Please consider applying this series to 'net-next'.
Series applied, thanks.
^ permalink raw reply
* Re: [net-next RFC 0/4] be2net: patch series
From: David Miller @ 2012-03-19 20:57 UTC (permalink / raw)
To: ajit.khaparde; +Cc: netdev
In-Reply-To: <20120318162259.GA7618@akhaparde-VBox>
From: Ajit Khaparde <ajit.khaparde@Emulex.Com>
Date: Sun, 18 Mar 2012 11:22:59 -0500
> Please apply.
>
> [1/4] be2net: enable WOL by default if h/w supports it
> [2/4] be2net: Program secondary UC MAC address into MAC filter
> [3/4] be2net: Fix number of vlan slots in flex mode
> [4/4] be2net: fix programming of transparent VLAN tags for VF
All applied to net-next, thanks.
^ 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