* ANNOUNCEMENT: linux-can repos are now at kernel.org
From: Marc Kleine-Budde @ 2015-01-15 16:14 UTC (permalink / raw)
To: linux-can@vger.kernel.org; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
-T: git git://gitorious.org/linux-can/linux-can-next.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
'Nuff Said!
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: ANNOUNCEMENT: linux-can repos are now at kernel.org
From: Oliver Hartkopp @ 2015-01-15 17:03 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can@vger.kernel.org; +Cc: netdev
In-Reply-To: <54B7E77C.5040509@pengutronix.de>
Very cool!
That was really fast.
Thanks,
Oliver
On 15.01.2015 17:14, Marc Kleine-Budde wrote:
> -T: git git://gitorious.org/linux-can/linux-can-next.git
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
>
> 'Nuff Said!
>
^ permalink raw reply
* Re: Re: Re: Re: [bisected regression] e1000e: "Detected Hardware Unit Hang"
From: Thomas Jarosch @ 2015-01-15 17:04 UTC (permalink / raw)
To: Eric Dumazet
Cc: 'Linux Netdev List', Eric Dumazet, Jeff Kirsher,
e1000-devel
In-Reply-To: <1421337658.11734.76.camel@edumazet-glaptop2.roam.corp.google.com>
On Thursday, 15. January 2015 08:00:58 Eric Dumazet wrote:
> Please apply this patch, and try to lower
> /proc/sys/net/core/gro_max_frags and see if this makes a difference
> (leaving GRO enabled)
>
> (start with 7 and increase it, limit being 17)
Patch applied to 3.19-rc4+.
Results:
7: hang
8: hang
9: hang
10: hang
11: hang
12: hang
13: hang
14: hang
15: hang
16: hang
17: hang
for the sake of completeness:
1: hang
2: hang
3: hang
4: hang
5: hang
6: hang
Regarding the test procedure: I stopped the download script on the client,
changed gro_max_frags and started the download again. No cable unplugging /
reboot of the box in between. Just mentioning it to make sure it somehow
does not affect what we actually wanted to test.
Additional tests have been done with gro_max_frags 1, 7 and 17:
- stop networking + unload e1000e -> restart -> download: hang
One thing I can say from the testing: The more I increase gro_max_frags,
the longer it takes to trigger it. I tried each setting below three times.
A value of 17 is really noticeable.
1: 3-8 seconds till hang
7: 7-10 seconds till hang
17: 23-26 seconds till hang
Thomas
^ permalink raw reply
* Re: [PATCH for 3.19 3/3] rtlwifi: rtl8192ee: Fix several bugs
From: Larry Finger @ 2015-01-15 17:05 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Troy Tan,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87bnm0xoar.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
On 01/15/2015 05:42 AM, Kalle Valo wrote:
> Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> writes:
>
>> From: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
>>
>> The following bugs are fixed in this driver:
>> 1. Problems parsing C2H CMD
>> 2. An ad-hoc connection can cause a TX freeze.
>> 3. There are additional conditions that cause a TX freeze.
>> 4. The previous code failed to handle situations where an RX
>> descriptor was unavailable.
>>
>> Signed-off-by: Troy Tan <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org>
>> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
>
> Is this really so important that it should go to 3.19? A patch titled
> "Fix several bugs" immediately makes me cautious and then I look at the
> patch itself I see rewriting functions instead of simple bug fixes. From
> a quick look this looks more -next material than 3.19.
It is not a simple rewrite of functions. Tho mishandling of the descriptor ring
buffer locks up the device and requires a cold boot. These patches prevent that
from happening.
Yes, the patches are rather larger than I would like at the -rc4 stage, and I
defer to your judgement. At least we have an external source of corrected code
for users of 3.18 and 3.19.
Larry
--
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
* [PATCH iproute2] tests: Add few 'ip link' related tests
From: Vadim Kochan @ 2015-01-15 16:59 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
From: Vadim Kochan <vadim4j@gmail.com>
Added two tests which checks the following fixed issues:
1) Bug when not possible add new virtual interface via:
$ ip link add dev XXX type
It was fixed a few releases ago.
2) Crash on older kernels when VF rate info does not exist:
$ ip link show
Used dump file from William Dauchy <william@gandi.net>:
testsuite/tests/ip/link/dev_wo_vf_rate.nl
So 'ip link show' replaced by 'ip -d monitor file ...' which does
the same thing.
Also added new func in testsuite/lib/generic.sh to gen new random dev name.
Added 'clean' dependency on running all tests.
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
testsuite/Makefile | 3 ++-
testsuite/lib/generic.sh | 8 +++++++-
testsuite/tests/ip/link/dev_wo_vf_rate.nl | Bin 0 -> 14076 bytes
testsuite/tests/ip/link/new_link.t | 11 +++++++++++
testsuite/tests/ip/link/show_dev_wo_vf_rate.t | 6 ++++++
5 files changed, 26 insertions(+), 2 deletions(-)
create mode 100644 testsuite/tests/ip/link/dev_wo_vf_rate.nl
create mode 100755 testsuite/tests/ip/link/new_link.t
create mode 100755 testsuite/tests/ip/link/show_dev_wo_vf_rate.t
diff --git a/testsuite/Makefile b/testsuite/Makefile
index 2ba9547..a2c8a2d 100644
--- a/testsuite/Makefile
+++ b/testsuite/Makefile
@@ -31,12 +31,13 @@ listtests:
alltests: $(TESTS)
clean:
+ @echo "Removing $(RESULTS_DIR) dir ..."
@rm -rf $(RESULTS_DIR)
distclean: clean
echo "Entering iproute2" && cd iproute2 && $(MAKE) distclean && cd ..;
-$(TESTS):
+$(TESTS): clean
@mkdir -p $(RESULTS_DIR)
@for d in $(TESTS_DIR); do \
diff --git a/testsuite/lib/generic.sh b/testsuite/lib/generic.sh
index 8f76e49..3473cc1 100644
--- a/testsuite/lib/generic.sh
+++ b/testsuite/lib/generic.sh
@@ -62,8 +62,9 @@ ts_ip()
TMP_OUT=`mktemp /tmp/tc_testsuite.XXXXXX` || exit
$IP $@ 2> $TMP_ERR > $TMP_OUT
+ RET=$?
- if [ -s $TMP_ERR ]; then
+ if [ -s $TMP_ERR ] || [ "$RET" != "0" ]; then
ts_err "${SCRIPT}: ${DESC} failed:"
ts_err "command: $IP $@"
ts_err "stderr output:"
@@ -91,3 +92,8 @@ ts_qdisc_available()
return 1;
fi
}
+
+rand_dev()
+{
+ echo "dev-$(tr -dc "[:alpha:]" < /dev/urandom | head -c 6)"
+}
diff --git a/testsuite/tests/ip/link/dev_wo_vf_rate.nl b/testsuite/tests/ip/link/dev_wo_vf_rate.nl
new file mode 100644
index 0000000000000000000000000000000000000000..40fa87ff1b158fb972e064efb38f76b0e9a56697
GIT binary patch
literal 14076
zcmeI2QD_`h6o$|4X4B1fZMT}ns!(GsCQqft8lx5o_Nk#2gn}Z4n3_#@VcVp2BSi%l
zK`m6<ASk{l3L;Xdtzh4LXw?UwEWQ;H>|<XAeW{rB{P)gj@7$T$&U9yYCpZUo?##V+
z&N*}MnQzaXnJq-Lk$)l|{C)nwxqpi^KR{HbES=`#u}x?l$YprDm#`&TM>(o55*6q!
zb)4tkkUXi*T+a%)Z-E|A^#$7Mln*Km1sYXlo*q(Vi3aKD;<4q*a)q|j2GuucGkCJq
zDyp+|k0Sdi@-ln2m0iT|)VKO4ZE=*})4fVJbioD$cFa;AC2zZuy`N6-ST&5X6EATo
z_D|Z(Qu>&6?e@!KMAvgf!`ULof*!D8j*?c3=uZxngEPAQq%()pN?GQnhhmRa(B~Ye
z(A8pTJ~c$m=QA9IL@)C6>*%|64N6VG20Ecbn#D)dZ_ng7{!(c-0=xKL9c<UZr)`+;
zOIvp4ZN_9&6znPMI2q#Etu(4TaUM8>c>-r(+vLpn!)W(%rl8In<u>%!oLR?bA34VJ
ztQhmlKitHza7C5aH$^e#k$UUmB_c2eF@vZ9V+O7g?SGr-@R?S2`HvUO)6{;^Q==<_
z>do$84D>@_0|GlJ{cNG$mN0hAbE5V)&o%c8v{}vJPc*{gl%a9wPJSu7_~x%4nmyh7
z_^&agr0#58Q&RsW`ra<_Op1tpM9YpZCUc_~rNvu9zm6*12K{mj{n*D3`lUV&UV1%g
zUn49sc-a(QK6ek%rHYrAh=1`}t|P~0gqN_`DKAAobcv6sGkGaYxZrel&nWIuE#r2B
zQ{U?X846^*F1%akI<{ai+lX9uP#2Sz_NB|1*yo1jC0w(3`6zUChnGJ%y!^2}FE4v}
zc^~`4;Y(kR5Iyaa-ff1{cPQW`^h00+0y_{tTe`))?Zm!YQ?#QXUVc;E_S@cCu&z#d
zdFYwH@;|S(*YAYC>a-Sl`4vy<)WPKPQdrOom<Gw1u9*`N(6<-W;%^Wy<vPl@;ic#a
z^4a92-ABg6uJ_|*!?T9Xs7xa3EEb&nass-*ORO!BU&22#zx<t34!`^o(_*e;p=TrK
zmrDz^g~i#0xmO#KXQCxokY`GMWapU}Yh3fbA)*<df$Jo112<(ZWn5tg;%7^@xVN3y
zcWa7v1a3kSlB1F2Xjs#Jeag!m#E{&^DDlH>((4>evgfMfjQGT^D3Lh0ZZ}AW9+z?D
zXmZ^_?wic9FI~pOJ~u3LVB2EOW6;%a=E$1Kk2%Oo5Afy_nE*KKh=T|@j8vM;k=z${
zAbz%Vi+kINeYd7)M@eSR)Y+6d(PlHaw}ia>H+p(HfVkbdu%FDqn$%*>E?h?+nbSm`
zBkLNQIT&+rc8UjWMkW9b#~|u?nxjWp4m*%2w(S1}t)aWyBr|8__2e=~QsrjA^hg|B
z>&K+}_#|!wF=yI2C&_CojH$(($KiG#nZwWRGbGPC{FsB(11wnSB6B3q5#~g(C2@gq
z?3E;$In!rS=EM~T5?gD9IZJ$x;_1w-ZxZl*frmMh7@s>~&a^sjlu+V*A;kT@P*nwP
z)ceBsZ)C3Q^FIF$JSm0-<Tq<ogf#>FzA%Z;a&|wPT;8nJIq$aL=Chozw)~#u`0)nM
z9;_Va3E1c>Z}z9W2|Le8=S_7_%A2rrnUsEU@uumM-{Ad<yx-r%Zw!`}57le0%+A%9
zs&lx0a0lY|{bktqR>%XRe18dh$aOw@YwX6@yD57x9$}<Rck}x;UXLEH%^$8L=H1oJ
z?~6wGmD=tEudl+4@&B<;T>LrV!yl{-g+KTPWWMs+?8L;AedW&T$F&Wg?nt>4HrA8Q
zozu*nt1D^V6Lvn6(yyD`DH+^Z&)jJouhr}PC3rvcoyj*o+V<UhDR;ugU(&g=%G@cv
PlX55Qd?uw|T-^B&_@nmR
literal 0
HcmV?d00001
diff --git a/testsuite/tests/ip/link/new_link.t b/testsuite/tests/ip/link/new_link.t
new file mode 100755
index 0000000..549ff25
--- /dev/null
+++ b/testsuite/tests/ip/link/new_link.t
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+source lib/generic.sh
+
+ts_log "[Testing add/del virtual links]"
+
+NEW_DEV="$(rand_dev)"
+
+ts_ip "$0" "Add $NEW_DEV dummy interface" link add dev $NEW_DEV type dummy
+ts_ip "$0" "Show $NEW_DEV dummy interface" link show dev $NEW_DEV
+ts_ip "$0" "Del $NEW_DEV dummy interface" link del dev $NEW_DEV
diff --git a/testsuite/tests/ip/link/show_dev_wo_vf_rate.t b/testsuite/tests/ip/link/show_dev_wo_vf_rate.t
new file mode 100755
index 0000000..a600ba6
--- /dev/null
+++ b/testsuite/tests/ip/link/show_dev_wo_vf_rate.t
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+source lib/generic.sh
+
+NL_FILE="tests/ip/link/dev_wo_vf_rate.nl"
+ts_ip "$0" "Show VF devices w/o VF rate info" -d monitor file $NL_FILE
--
2.1.3
^ permalink raw reply related
* Re: [net-next 16/17] i40e: Support for NPAR iSCSI partition with DCB
From: Or Gerlitz @ 2015-01-15 17:11 UTC (permalink / raw)
To: Jeff Kirsher
Cc: David Miller, Neerav Parikh, Linux Netdev List, nhorman, sassmann,
jogreene
In-Reply-To: <1421324368-6860-17-git-send-email-jeffrey.t.kirsher@intel.com>
On Thu, Jan 15, 2015 at 2:19 PM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> --- a/drivers/net/ethernet/intel/i40e/i40e_type.h
> +++ b/drivers/net/ethernet/intel/i40e/i40e_type.h
> @@ -211,6 +211,7 @@ struct i40e_hw_capabilities {
> bool evb_802_1_qbh; /* Bridge Port Extension */
> bool dcb;
> bool fcoe;
> + bool iscsi; /* Indicates iSCSI enabled */
> bool mfp_mode_1;
> bool mgmt_cem;
> bool ieee_1588;
Hey Jeff, just a 0.02$ small tip... you can easily save the annoying
addition of bool X_is_supported/enabled cap variable for every new cap
with having a 64 bit flags field with a bit per feature... it also
makes the code much more readable.
^ permalink raw reply
* Re: [net-next 13/17] i40e: AQ API updates for new commands
From: Or Gerlitz @ 2015-01-15 17:14 UTC (permalink / raw)
To: Jeff Kirsher
Cc: David Miller, Shannon Nelson, Linux Netdev List, nhorman,
sassmann, jogreene, Kamil Krawczyk
In-Reply-To: <1421324368-6860-14-git-send-email-jeffrey.t.kirsher@intel.com>
On Thu, Jan 15, 2015 at 2:19 PM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> From: Shannon Nelson <shannon.nelson@intel.com>
>
> Add lldp control commands, add oem ocsd and ocbb commands, and fix up
> NVM config read and write data structs.
Sounds to me like a proofed nightmare for someone doing future
bisection and landing here... we want kernel patches to be made of
basically one logical change, right?
^ permalink raw reply
* Re: [PATCH for 3.19 2/3] rtlwifi: Fix handling of new style descriptors
From: Larry Finger @ 2015-01-15 17:14 UTC (permalink / raw)
To: Kalle Valo, 谭杭波
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <87y4p4w8wb.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
On 01/15/2015 06:00 AM, Kalle Valo wrote:
> Hi Troy,
>
> please avoid top-posting.
>
> 谭杭波 <troy_tan-kXabqFNEczNtrwSWzY7KCg@public.gmane.org> writes:
>
>> You can find get_available_desc here:
>>
>> diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/
>> pci.c
>> index e25faac..a62170e 100644
>> --- a/drivers/net/wireless/rtlwifi/pci.c
>> +++ b/drivers/net/wireless/rtlwifi/pci.c
>> @@ -578,6 +578,13 @@ static void _rtl_pci_tx_isr(struct ieee80211_hw *hw, int
>> prio)
>> else
>> entry = (u8 *)(&ring->desc[ring->idx]);
>>
>> + if (rtlpriv->cfg->ops->get_available_desc &&
>> + rtlpriv->cfg->ops->get_available_desc(hw, prio) <= 1) {
>> + RT_TRACE(rtlpriv, (COMP_INTR | COMP_SEND), DBG_DMESG,
>> + "no available desc!\n");
>> + return;
>> + }
>
> I don't see rtlpriv->cfg->ops->get_available_desc set here, only being
> called?
Only one of the drivers (rtl8192ee) needs to implement that routine, which is
the reason it is checked for non-NULL before it is called. The implementation is
in patch 3 in file rtl8192ee/sw.c where it says:
@@ -241,6 +239,7 @@ static struct rtl_hal_ops rtl8192ee_hal_ops = {
.set_desc = rtl92ee_set_desc,
.get_desc = rtl92ee_get_desc,
.is_tx_desc_closed = rtl92ee_is_tx_desc_closed,
+ .get_available_desc = rtl92ee_get_available_desc,
.tx_polling = rtl92ee_tx_polling,
.enable_hw_sec = rtl92ee_enable_hw_security_config,
.init_sw_leds = rtl92ee_init_sw_leds,
Larry
--
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: [net-next 13/17] i40e: AQ API updates for new commands
From: Nelson, Shannon @ 2015-01-15 17:19 UTC (permalink / raw)
To: Or Gerlitz, Kirsher, Jeffrey T
Cc: David Miller, Linux Netdev List, nhorman@redhat.com,
sassmann@redhat.com, jogreene@redhat.com, Krawczyk, Kamil
In-Reply-To: <CAJ3xEMiCLBjuUSh1HGhfJU0gqA7J1MHsp0riLU5kk_uwkAdFqg@mail.gmail.com>
> From: Or Gerlitz [mailto:gerlitz.or@gmail.com]
> Sent: Thursday, January 15, 2015 9:14 AM
>
> On Thu, Jan 15, 2015 at 2:19 PM, Jeff Kirsher
> <jeffrey.t.kirsher@intel.com> wrote:
> > From: Shannon Nelson <shannon.nelson@intel.com>
> >
> > Add lldp control commands, add oem ocsd and ocbb commands, and fix up
> > NVM config read and write data structs.
>
> Sounds to me like a proofed nightmare for someone doing future
> bisection and landing here... we want kernel patches to be made of
> basically one logical change, right?
Yes, but note that these are mostly API additions for transactions that aren't used in the code quite yet. There are a couple of defines that get changed as well, but they aren't used yet either else they'd be accompanied by related code changes.
sln
^ permalink raw reply
* Re: Re: Re: Re: [bisected regression] e1000e: "Detected Hardware Unit Hang"
From: Eric Dumazet @ 2015-01-15 17:20 UTC (permalink / raw)
To: Thomas Jarosch
Cc: 'Linux Netdev List', Eric Dumazet, Jeff Kirsher,
e1000-devel
In-Reply-To: <1837410.pEGIH05mML@storm>
On Thu, 2015-01-15 at 18:04 +0100, Thomas Jarosch wrote:
> On Thursday, 15. January 2015 08:00:58 Eric Dumazet wrote:
> > Please apply this patch, and try to lower
> > /proc/sys/net/core/gro_max_frags and see if this makes a difference
> > (leaving GRO enabled)
> >
> > (start with 7 and increase it, limit being 17)
>
> Patch applied to 3.19-rc4+.
>
> Results:
> 7: hang
> 8: hang
> 9: hang
> 10: hang
> 11: hang
> 12: hang
> 13: hang
> 14: hang
> 15: hang
> 16: hang
> 17: hang
>
> for the sake of completeness:
> 1: hang
This is weird : This should have same effect then GRO off (at most one
segment per packet)
> 2: hang
> 3: hang
> 4: hang
> 5: hang
> 6: hang
>
> Regarding the test procedure: I stopped the download script on the client,
> changed gro_max_frags and started the download again. No cable unplugging /
> reboot of the box in between. Just mentioning it to make sure it somehow
> does not affect what we actually wanted to test.
>
> Additional tests have been done with gro_max_frags 1, 7 and 17:
> - stop networking + unload e1000e -> restart -> download: hang
>
> One thing I can say from the testing: The more I increase gro_max_frags,
> the longer it takes to trigger it. I tried each setting below three times.
> A value of 17 is really noticeable.
>
> 1: 3-8 seconds till hang
> 7: 7-10 seconds till hang
> 17: 23-26 seconds till hang
Could you try the following ?
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 38cb586b1bf42fa7a50e19f3e650e8c139788820..6d93facddab78f8db7000fddaa24322651a0eae9 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -1264,7 +1264,7 @@ static bool e1000_clean_tx_irq(struct e1000_ring *tx_ring)
netdev_completed_queue(netdev, pkts_compl, bytes_compl);
-#define TX_WAKE_THRESHOLD 32
+#define TX_WAKE_THRESHOLD (MAX_SKB_FRAGS * 3 + 2)
if (count && netif_carrier_ok(netdev) &&
e1000_desc_unused(tx_ring) >= TX_WAKE_THRESHOLD) {
/* Make sure that anybody stopping the queue after this
@@ -5650,10 +5650,7 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
netdev_sent_queue(netdev, skb->len);
e1000_tx_queue(tx_ring, tx_flags, count);
/* Make sure there is space in the ring for the next send. */
- e1000_maybe_stop_tx(tx_ring,
- (MAX_SKB_FRAGS *
- DIV_ROUND_UP(PAGE_SIZE,
- adapter->tx_fifo_limit) + 2));
+ e1000_maybe_stop_tx(tx_ring, 3 * MAX_SKB_FRAGS + 2);
} else {
dev_kfree_skb_any(skb);
tx_ring->buffer_info[first].time_stamp = 0;
^ permalink raw reply related
* Re: [bisected regression] e1000e: "Detected Hardware Unit Hang"
From: Thomas Jarosch @ 2015-01-15 17:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: e1000-devel, 'Linux Netdev List', Eric Dumazet
In-Reply-To: <1421342437.11734.79.camel@edumazet-glaptop2.roam.corp.google.com>
On Thursday, 15. January 2015 09:20:37 Eric Dumazet wrote:
> > for the sake of completeness:
> > 1: hang
>
> This is weird : This should have same effect then GRO off (at most one
> segment per packet)
I thought so, too. OTOH the code path was changed from
"goto merge" to "return -E2BIG". I didn't look at the code
what happens at the "merge" label.
> Could you try the following ?
>
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> b/drivers/net/ethernet/intel/e1000e/netdev.c index
> 38cb586b1bf42fa7a50e19f3e650e8c139788820..6d93facddab78f8db7000fddaa24322
> 651a0eae9 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -1264,7 +1264,7 @@ static bool e1000_clean_tx_irq(struct e1000_ring
> *tx_ring)
>
> netdev_completed_queue(netdev, pkts_compl, bytes_compl);
>
> -#define TX_WAKE_THRESHOLD 32
> +#define TX_WAKE_THRESHOLD (MAX_SKB_FRAGS * 3 + 2)
> if (count && netif_carrier_ok(netdev) &&
> e1000_desc_unused(tx_ring) >= TX_WAKE_THRESHOLD) {
> /* Make sure that anybody stopping the queue after this
> @@ -5650,10 +5650,7 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff
> *skb, netdev_sent_queue(netdev, skb->len);
> e1000_tx_queue(tx_ring, tx_flags, count);
> /* Make sure there is space in the ring for the next send. */
> - e1000_maybe_stop_tx(tx_ring,
> - (MAX_SKB_FRAGS *
> - DIV_ROUND_UP(PAGE_SIZE,
> - adapter->tx_fifo_limit) + 2));
> + e1000_maybe_stop_tx(tx_ring, 3 * MAX_SKB_FRAGS + 2);
> } else {
> dev_kfree_skb_any(skb);
> tx_ring->buffer_info[first].time_stamp = 0;
I was just about to leave the office... and switched the test box back on.
Also reverted to vanilla 3.19-rc4+ and applied the above patch instead.
Still hangs. Grrr. More testing tomorrow.
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
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: [net-next 13/17] i40e: AQ API updates for new commands
From: Or Gerlitz @ 2015-01-15 18:04 UTC (permalink / raw)
To: Nelson, Shannon
Cc: Kirsher, Jeffrey T, David Miller, Linux Netdev List,
nhorman@redhat.com, sassmann@redhat.com, jogreene@redhat.com,
Krawczyk, Kamil
In-Reply-To: <FC41C24E35F18A40888AACA1A36F3E418ADD335B@fmsmsx115.amr.corp.intel.com>
On Thu, Jan 15, 2015 at 7:19 PM, Nelson, Shannon
<shannon.nelson@intel.com> wrote:
>> From: Or Gerlitz [mailto:gerlitz.or@gmail.com]
>> Sent: Thursday, January 15, 2015 9:14 AM
>>
>> On Thu, Jan 15, 2015 at 2:19 PM, Jeff Kirsher
>> <jeffrey.t.kirsher@intel.com> wrote:
>> > From: Shannon Nelson <shannon.nelson@intel.com>
>> >
>> > Add lldp control commands, add oem ocsd and ocbb commands, and fix up
>> > NVM config read and write data structs.
>>
>> Sounds to me like a proofed nightmare for someone doing future
>> bisection and landing here... we want kernel patches to be made of
>> basically one logical change, right?
>
> Yes, but note that these are mostly API additions for transactions that aren't used in the code quite yet. There are a couple of defines that get changed as well, but they aren't used yet either else they'd be accompanied by related code changes.
So NVM config read and write data structs aren't in use? anyway, this
way or another, I think we should stick to the practice of avoiding to
load few different changes on one patch
^ permalink raw reply
* Re: [PATCH] net: Add ndo_gso_check
From: Or Gerlitz @ 2015-01-15 18:18 UTC (permalink / raw)
To: Tom Herbert
Cc: Alexander Duyck, John Fastabend, Jeff Kirsher, David Miller,
Linux Netdev List, Thomas Graf, Pravin Shelar, Andy Zhou
In-Reply-To: <CA+mtBx9HMuMnsmN0rjqV9-5iK9H6b+J8OZQsmmbFHwjm+qW7bQ@mail.gmail.com>
On Mon, Oct 6, 2014 at 11:28 PM, Tom Herbert <therbert@google.com> wrote:
> On Mon, Oct 6, 2014 at 1:22 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> Are we going to have a session on the encapsulation/offloads design @ LPC?
> yes, I will talk about FOU and GUE implementation. You should
> abstracts in the schedule now.
Hi Tom, so that LPC discussion eventually didn't made it to happen...
I saw [1] you're planning (hopefully exiting) three parts discussion @
netdev01
I would strongly vote for his to be on the workshops/tutorials days,
i.e not limited to 45m or alike... and the 1st part you plan for an
updated reply of your LSK preso [2] which missed LPC?
[1] https://netdev01.org/news/22
[2] http://vger.kernel.org/encapsulation_offloads.pdf
>> I think a replay of your LKS presentation along with open discussion
>> on how to get there with the legacy requirements could be very
>> helpful.
^ permalink raw reply
* [PATCH net] ip: zero sockaddr returned on error queue
From: Willem de Bruijn @ 2015-01-15 18:18 UTC (permalink / raw)
To: netdev; +Cc: davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
The sockaddr is returned in IP(V6)_RECVERR as part of errhdr. That
structure is defined and allocated on the stack as
struct {
struct sock_extended_err ee;
struct sockaddr_in(6) offender;
} errhdr;
The second part is only initialized for certain SO_EE_ORIGIN values.
Always initialize it completely.
An MTU exceeded error on a SOCK_RAW/IPPROTO_RAW is one example that
would return uninitialized bytes.
Signed-off-by: Willem de Bruijn <willemb@google.com>
----
Also verified that there is no padding between errhdr.ee and
errhdr.offender that could leak additional kernel data.
---
net/ipv4/ip_sockglue.c | 8 ++------
net/ipv6/datagram.c | 10 +++-------
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 8a89c73..6b85adb 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -461,17 +461,13 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
memcpy(&errhdr.ee, &serr->ee, sizeof(struct sock_extended_err));
sin = &errhdr.offender;
- sin->sin_family = AF_UNSPEC;
+ memset(sin, 0, sizeof(*sin));
if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP ||
ipv4_pktinfo_prepare_errqueue(sk, skb, serr->ee.ee_origin)) {
- struct inet_sock *inet = inet_sk(sk);
-
sin->sin_family = AF_INET;
sin->sin_addr.s_addr = ip_hdr(skb)->saddr;
- sin->sin_port = 0;
- memset(&sin->sin_zero, 0, sizeof(sin->sin_zero));
- if (inet->cmsg_flags)
+ if (inet_sk(sk)->cmsg_flags)
ip_cmsg_recv(msg, skb);
}
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 100c589..49f5e73 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -393,11 +393,10 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
memcpy(&errhdr.ee, &serr->ee, sizeof(struct sock_extended_err));
sin = &errhdr.offender;
- sin->sin6_family = AF_UNSPEC;
+ memset(sin, 0, sizeof(*sin));
+
if (serr->ee.ee_origin != SO_EE_ORIGIN_LOCAL) {
sin->sin6_family = AF_INET6;
- sin->sin6_flowinfo = 0;
- sin->sin6_port = 0;
if (np->rxopt.all) {
if (serr->ee.ee_origin != SO_EE_ORIGIN_ICMP &&
serr->ee.ee_origin != SO_EE_ORIGIN_ICMP6)
@@ -412,12 +411,9 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
ipv6_iface_scope_id(&sin->sin6_addr,
IP6CB(skb)->iif);
} else {
- struct inet_sock *inet = inet_sk(sk);
-
ipv6_addr_set_v4mapped(ip_hdr(skb)->saddr,
&sin->sin6_addr);
- sin->sin6_scope_id = 0;
- if (inet->cmsg_flags)
+ if (inet_sk(sk)->cmsg_flags)
ip_cmsg_recv(msg, skb);
}
}
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related
* Re: [PATCH net-next RFC 1/5] net-timestamp: no-payload option
From: Willem de Bruijn @ 2015-01-15 18:22 UTC (permalink / raw)
To: Richard Cochran
Cc: Network Development, David Miller, Eric Dumazet, Andy Lutomirski
In-Reply-To: <20150111202650.GB4214@localhost.localdomain>
On Sun, Jan 11, 2015 at 3:26 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Fri, Jan 09, 2015 at 12:31:55PM -0500, Willem de Bruijn wrote:
>> diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
>> index a317797..d81ef70 100644
>> --- a/net/ipv4/ip_sockglue.c
>> +++ b/net/ipv4/ip_sockglue.c
>> @@ -440,7 +440,7 @@ static bool ipv4_pktinfo_prepare_errqueue(const struct sock *sk,
>>
>> if ((ee_origin != SO_EE_ORIGIN_TIMESTAMPING) ||
>> (!(sk->sk_tsflags & SOF_TIMESTAMPING_OPT_CMSG)) ||
>> - (!skb->dev))
>> + (!skb->dev) || (!skb->len))
>> return false;
>
> Nit: You have already tested for the condition (!skb->len) ...
Thanks! I'll fix that when I send v1.
I had planned to do that today, but will hold off a bit to avoid merge
conflicts with a fix queued for net (http://patchwork.ozlabs.org/patch/429553/)
I will drop patches 4 and 5 when sending out v1, btw.
>
>>
>> info->ipi_spec_dst.s_addr = ip_hdr(skb)->saddr;
>> @@ -483,7 +483,7 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
>>
>> serr = SKB_EXT_ERR(skb);
>>
>> - if (sin) {
>> + if (sin && skb->len) {
>> sin->sin_family = AF_INET;
>> sin->sin_addr.s_addr = *(__be32 *)(skb_network_header(skb) +
>> serr->addr_offset);
>> @@ -496,8 +496,9 @@ int ip_recv_error(struct sock *sk, struct msghdr *msg, int len, int *addr_len)
>> sin = &errhdr.offender;
>> sin->sin_family = AF_UNSPEC;
>>
>> - if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP ||
>> - ipv4_pktinfo_prepare_errqueue(sk, skb, serr->ee.ee_origin)) {
>> + if (skb->len &&
>> + (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP ||
>> + ipv4_pktinfo_prepare_errqueue(sk, skb, serr->ee.ee_origin))) {
>
> ... here.
>
>> struct inet_sock *inet = inet_sk(sk);
>>
>> sin->sin_family = AF_INET;
>
> Thanks,
> Richard
^ permalink raw reply
* Re: Re: Re: Re: Re: [bisected regression] e1000e: "Detected Hardware Unit Hang"
From: Eric Dumazet @ 2015-01-15 18:24 UTC (permalink / raw)
To: Thomas Jarosch
Cc: 'Linux Netdev List', Eric Dumazet, Jeff Kirsher,
e1000-devel
In-Reply-To: <1951915.1kCMSXLj6g@storm>
On Thu, 2015-01-15 at 18:37 +0100, Thomas Jarosch wrote:
> On Thursday, 15. January 2015 09:20:37 Eric Dumazet wrote:
> > > for the sake of completeness:
> > > 1: hang
> >
> > This is weird : This should have same effect then GRO off (at most one
> > segment per packet)
>
> I thought so, too. OTOH the code path was changed from
> "goto merge" to "return -E2BIG". I didn't look at the code
> what happens at the "merge" label.
If you leave the "goto merge", then GRO still builds big GRO packets,
using a linked list of packets.
Then because drivers do not generally support NETIF_F_FRAGLIST,
core networking code linearizes such GRO packets before reaching
ndo_start_xmit()
Check 8a29111c7ca68d928dfab58636f3f6acf0ac04f7 "net: gro: allow to build
full sized skb" for details about this.
^ permalink raw reply
* Re: [PATCH RFC v2 net-next 2/2] ip_tunnel: Remove struct gro_cells
From: Martin Lau @ 2015-01-15 18:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, kernel-team
In-Reply-To: <1421276039.11734.25.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, Jan 14, 2015 at 02:53:59PM -0800, Eric Dumazet wrote:
> On Tue, 2015-01-13 at 15:42 -0800, Martin KaFai Lau wrote:
> > After adding percpu gro_cells, struct gro_cells can be removed.
> >
> > Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> > ---
> > include/net/gro_cells.h | 34 ++++++++++++++++------------------
> > include/net/ip_tunnels.h | 2 +-
> > net/ipv4/ip_tunnel.c | 11 +++++------
> > 3 files changed, 22 insertions(+), 25 deletions(-)
> >
> > diff --git a/include/net/gro_cells.h b/include/net/gro_cells.h
> > index 0f712c0..b1aeea1 100644
> > --- a/include/net/gro_cells.h
> > +++ b/include/net/gro_cells.h
> > @@ -10,21 +10,18 @@ struct gro_cell {
> > struct napi_struct napi;
> > };
> >
> > -struct gro_cells {
> > - struct gro_cell __percpu *cells;
> > -};
> > -
>
> This seems a lot of code churn for no runtime difference ?
>
> If we ever want to add an additional 'field', we likely have to revert
> this patch.
It seems cleaning up an one item struct is unnecessary. I
will repost without patch 2/2.
>
> -static inline void gro_cells_destroy(struct gro_cells *gcells)
> +static inline void gro_cell_free_percpu(struct gro_cell __percpu *gcells)
> {
> int i;
>
> - if (!gcells->cells)
> + if (IS_ERR_OR_NULL(gcells))
> return;
>
> For example, I have no idea why this part is needed.
For this change:
- err = gro_cells_init(&tunnel->gro_cells, dev);
- if (err) {
+ tunnel->gro_cells = gro_cell_alloc_percpu(dev);
+ if (IS_ERR(tunnel->gro_cells)) {
Thanks,
--Martin
^ permalink raw reply
* Re: net: prevent of emerging cross-namespace symlinks patches for 3.14?
From: Alexander Y. Fomichev @ 2015-01-15 18:39 UTC (permalink / raw)
To: Miquel van Smoorenburg; +Cc: netdev, stable, David Miller
In-Reply-To: <54B6E36F.9060703@xs4all.net>
Hi,
no objections of course,
actually it was written and tested with 3.14 in mind.
On Thu, Jan 15, 2015 at 12:45 AM, Miquel van Smoorenburg
<mikevs@xs4all.net> wrote:
> [first sent to lkml, now to netdev and the original patch author]
>
> When running 'lxc' on the latest -stable kernel, 3.14.28, I'm seeing these
> errors:
>
> Jan 14 17:47:16 lxc2 kernel: [ 10.704890] WARNING: CPU: 0 PID: 3209 at
> fs/sys
> fs/dir.c:52 sysfs_warn_dup+0x8c/0xb0()
> Jan 14 17:47:16 lxc2 kernel: [ 10.704892] sysfs: cannot create duplicate
> filename '/devices/virtual/net/eth0.104/upper_eth0'
> Jan 14 17:47:16 lxc2 kernel: [ 10.704954] CPU: 0 PID: 3209 Comm:
> lxc-autostart Not tainted 3.14.28-xsserver #1
>
> I did not see these errors in 3.12. This was fixed in 3.17 by:
>
> net: prevent of emerging cross-namespace symlinks
> https://github.com/torvalds/linux/commit/4c75431ac3520631f1d9e74aa88407e6374dbbc4
>
> net: fix creation adjacent device symlinks
> https://github.com/torvalds/linux/commit/7ce64c79c4decdeb1afe0bf2f6ef834b382871d1
>
> These patches apply cleanly to 3.14.28.
>
> If you agree that this should go into 3.14-stable, please ack.
>
> Thanks,
>
> Mike.
--
Best regards.
Alexander Y. Fomichev <git.user@gmail.com>
^ permalink raw reply
* Re: [net PATCH 1/1] drivers: net: cpsw: fix cpsw hung with add vlan using vconfig
From: David Miller @ 2015-01-15 18:57 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev
In-Reply-To: <1421314168-12009-1-git-send-email-mugunthanvnm@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Thu, 15 Jan 2015 14:59:28 +0530
> while adding vlan in dual EMAC mode, only specific ports should be
> subscribed for the vlan, else it will lead to switching mode and
> if both ports connected to same switch cpsw will hung as it creates
> a network loop. Fixing this by adding only specific ports in case
> of dual EMAC.
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2] socket: use iov_length()
From: David Miller @ 2015-01-15 18:57 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1421314558-4252-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 15 Jan 2015 10:35:58 +0100
> Better to use available helpers.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: core: Fix race by protecting process_queues at CPU hotplug
From: subashab @ 2015-01-15 19:03 UTC (permalink / raw)
To: Eric Dumazet, netdev
In-Reply-To: <1421305282.11734.38.camel@edumazet-glaptop2.roam.corp.google.com>
When a CPU is hotplugged while processing incoming packets,
dev_cpu_callback() will copy the poll list from the offline
CPU and raise the softIRQ. In the same context, it will also
process process_queue of the offline CPU by de-queueing and
calling netif_rx. Due to this there is a potential for race
condition between process_backlog() and dev_cpu_callback()
accessing the same process_queue resource. This patch
protects this concurrent access by locking.
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
net/core/dev.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index df0b522..aa8f503 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3640,6 +3640,7 @@ static void flush_backlog(void *arg)
struct net_device *dev = arg;
struct softnet_data *sd = &__get_cpu_var(softnet_data);
struct sk_buff *skb, *tmp;
+ unsigned long flags;
rps_lock(sd);
skb_queue_walk_safe(&sd->input_pkt_queue, skb, tmp) {
@@ -3651,6 +3652,7 @@ static void flush_backlog(void *arg)
}
rps_unlock(sd);
+ spin_lock_irqsave(&sd->process_queue.lock, flags);
skb_queue_walk_safe(&sd->process_queue, skb, tmp) {
if (skb->dev == dev) {
__skb_unlink(skb, &sd->process_queue);
@@ -3658,6 +3660,7 @@ static void flush_backlog(void *arg)
input_queue_head_incr(sd);
}
}
+ spin_unlock_irqrestore(&sd->process_queue.lock, flags);
}
static int napi_gro_complete(struct sk_buff *skb)
@@ -4021,7 +4024,7 @@ static int process_backlog(struct napi_struct *napi,
int quota)
{
int work = 0;
struct softnet_data *sd = container_of(napi, struct softnet_data, backlog);
-
+ unsigned long flags;
#ifdef CONFIG_RPS
/* Check if we have pending ipi, its better to send them now,
* not waiting net_rx_action() end.
@@ -4032,18 +4035,19 @@ static int process_backlog(struct napi_struct
*napi, int quota)
}
#endif
napi->weight = weight_p;
- local_irq_disable();
+ spin_lock_irqsave(&sd->process_queue.lock, flags);
while (work < quota) {
struct sk_buff *skb;
unsigned int qlen;
while ((skb = __skb_dequeue(&sd->process_queue))) {
- local_irq_enable();
+ spin_unlock_irqrestore(&sd->process_queue.lock, flags);
__netif_receive_skb(skb);
- local_irq_disable();
+ spin_lock_irqsave(&sd->process_queue.lock, flags);
input_queue_head_incr(sd);
if (++work >= quota) {
- local_irq_enable();
+ spin_unlock_irqrestore(&sd->process_queue.lock,
+ flags);
return work;
}
}
@@ -4054,6 +4058,7 @@ static int process_backlog(struct napi_struct *napi,
int quota)
skb_queue_splice_tail_init(&sd->input_pkt_queue,
&sd->process_queue);
+
if (qlen < quota - work) {
/*
* Inline a custom version of __napi_complete().
@@ -4069,7 +4074,7 @@ static int process_backlog(struct napi_struct *napi,
int quota)
}
rps_unlock(sd);
}
- local_irq_enable();
+ spin_unlock_irqrestore(&sd->process_queue.lock, flags);
return work;
}
@@ -5991,6 +5996,7 @@ static int dev_cpu_callback(struct notifier_block *nfb,
struct sk_buff *skb;
unsigned int cpu, oldcpu = (unsigned long)ocpu;
struct softnet_data *sd, *oldsd;
+ unsigned long flags;
if (action != CPU_DEAD && action != CPU_DEAD_FROZEN)
return NOTIFY_OK;
@@ -6024,11 +6030,15 @@ static int dev_cpu_callback(struct notifier_block
*nfb,
raise_softirq_irqoff(NET_TX_SOFTIRQ);
local_irq_enable();
+ spin_lock_irqsave(&oldsd->process_queue.lock, flags);
/* Process offline CPU's input_pkt_queue */
while ((skb = __skb_dequeue(&oldsd->process_queue))) {
+ spin_unlock_irqrestore(&oldsd->process_queue.lock, flags);
netif_rx(skb);
+ spin_lock_irqsave(&oldsd->process_queue.lock, flags);
input_queue_head_incr(oldsd);
}
+ spin_unlock_irqrestore(&oldsd->process_queue.lock, flags);
while ((skb = __skb_dequeue(&oldsd->input_pkt_queue))) {
netif_rx(skb);
input_queue_head_incr(oldsd);
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
> On Thu, 2015-01-15 at 03:13 +0000, subashab@codeaurora.org wrote:
>> I am seeing frequent crashes in high throughput conditions in a
>> multiprocessor system with kernel version 3.10 where cores are getting
>> hot
>> plugged. I have pinned the network stack to a particular core using
>> receive packet steering (RPS). At the time of crash, it looks like a
>> contention of the process_queue between dev_cpu_callback and
>> process_backlog.
>
> Your patch is mangled, hard to tell what is going on.
>
>
> --
> 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 related
* Re: [PATCH 0/2] Remove T4 FCoE support
From: David Miller @ 2015-01-15 19:04 UTC (permalink / raw)
To: praveenm; +Cc: netdev, linux-scsi, JBottomley, hch, hariprasad, varun
In-Reply-To: <cover.1421328605.git.praveenm@chelsio.com>
From: Praveen Madhavan <praveenm@chelsio.com>
Date: Thu, 15 Jan 2015 19:15:50 +0530
> These patches removes FCoE support for chelsio T4 adapter.
> Please apply on net-next since depends on previous commits.
Why is it being removed? You have to state this in the
commit log messages at a minimum.
^ permalink raw reply
* Re: [PATCH net] ip: zero sockaddr returned on error queue
From: Eric Dumazet @ 2015-01-15 19:06 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: netdev, davem
In-Reply-To: <1421345920-13994-1-git-send-email-willemb@google.com>
On Thu, 2015-01-15 at 13:18 -0500, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> The sockaddr is returned in IP(V6)_RECVERR as part of errhdr. That
> structure is defined and allocated on the stack as
>
> struct {
> struct sock_extended_err ee;
> struct sockaddr_in(6) offender;
> } errhdr;
>
> The second part is only initialized for certain SO_EE_ORIGIN values.
> Always initialize it completely.
>
> An MTU exceeded error on a SOCK_RAW/IPPROTO_RAW is one example that
> would return uninitialized bytes.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> ----
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH_V5] dm9000: Add regulator and reset support to dm9000
From: David Miller @ 2015-01-15 19:08 UTC (permalink / raw)
To: Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8
In-Reply-To: <1421316746-38128-1-git-send-email-Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
From: Zubair Lutfullah Kakakhel <Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
Date: Thu, 15 Jan 2015 10:12:26 +0000
> In boards, the dm9000 chip's power and reset can be controlled by gpio.
>
> It makes sense to add them to the dm9000 driver and let dt be used to
> enable power and reset the phy.
>
> Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Paul Burton <paul.burton-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
Applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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] sh_eth: Fix addition of .trscer_err_mask to wrong SoC data
From: David Miller @ 2015-01-15 19:09 UTC (permalink / raw)
To: geert+renesas
Cc: nobuhiro.iwamatsu.yj, yoshihiro.shimoda.uh, netdev, linux-sh
In-Reply-To: <1421319139-22655-1-git-send-email-geert+renesas@glider.be>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Thu, 15 Jan 2015 11:52:19 +0100
> commit b284fbe3b3ef9cf8 ("sh_eth: Fix access to TRSCER register") wanted
> to add a .trscer_err_mask value to the R-Car Gen2 family-specific data
> structure (r8a779x_data), but it was accidentally added to the
> SH7724-specific data structure (sh7724_data).
>
> Presumably this happened due to a patch conflict with commit
> d407bc0203539031 ("sh-eth: Set fdr_value of R-Car SoCs"), which added
> another field at the same position.
>
> Move the field setting to fix this.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Fixes: b284fbe3b3ef9cf8 ("sh_eth: Fix access to TRSCER register")
Oops, applied, thanks Geert.
^ 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