* Re: iwlwifi no authentication with AP - Re: pull request: wireless-next 2014-09-08
From: Oliver Hartkopp @ 2014-09-09 20:23 UTC (permalink / raw)
To: Emmanuel Grumbach
Cc: John W. Linville, linux-wireless,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CANUX_P3n0v1SzfbYuaAsE4TY7Hz_wo2Fb9SmHVNyFOC9hDhwdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 09.09.2014 22:02, Emmanuel Grumbach wrote:
> On Tue, Sep 9, 2014 at 10:46 PM, Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org> wrote:
>> Hello John, all,
>>
>> on my i7 Laptop with iwlwifi the latest net-next does not connect to my access point:
>
> Are you sure this wasn't the case before?
Indeed I moved to net-next right today - as I also had the LED lockdep splat
on 3.17-rcX with X < 4.
So it can be that this issue was already introduced at the beginning of this
net-next cycle. Don't know, sorry. The latest 3.17-rc4 from Linus' tree works
fine. I'm running a Debian unstable here (in both cases).
> Can you bisect?
Not really. I'm running the kernel on my bare machine - and I just wanted to
go to bed right now ...
So I will be able to test patches tomorrow morning again.
Tnx for your fast feedback,
Oliver
--
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: iwlwifi no authentication with AP - Re: pull request: wireless-next 2014-09-08
From: Oliver Hartkopp @ 2014-09-09 20:15 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140909195232.GO29412-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On 09.09.2014 21:52, John W. Linville wrote:
>
> Hopefully the Intel guys are listening. As a hunch, what sort of
> encryption are you using?
They are :-)
I'm using WPA2.
Regards,
Oliver
--
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 v2 net-next 10/12] net: fec: init complete variable in early to avoid kernel dump
From: Frank Li @ 2014-09-09 20:15 UTC (permalink / raw)
To: b38611-KZfg59tc24xl57MIdRCFDg, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA, lznuaa-Re5JQEeQqe8AvxtiuMwx3w
Cc: shawn.guo-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Fugang Duan, Frank Li
In-Reply-To: <1410293743-27874-1-git-send-email-Frank.Li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
From: Fugang Duan <B38611-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Software clear the MDIO interrupt before MDIO bus access, but
MAC still generate MDIO interrupt. The issue only happen on
imx6slx chip.
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc1-00399-g0bcad17 #315
Backtrace:
[<800121fc>] (dump_backtrace) from [<800124e0>] (show_stack+0x18/0x1c)
r6:8096e534 r5:8096e534 r4:00000000 r3:00000000
[<800124c8>] (show_stack) from [<806a4c60>] (dump_stack+0x8c/0xa4)
[<806a4bd4>] (dump_stack) from [<80060ab8>] (__lock_acquire+0x1814/0x1c40)
r6:be078000 r5:be074000 r4:be03f6e4 r3:be078000
[<8005f2a4>] (__lock_acquire) from [<800616e0>] (lock_acquire+0x70/0x84)
r10:809ada33 r9:be010600 r8:00000096 r7:00000001 r6:be074000 r5:00000000
r4:60000193
[<80061670>] (lock_acquire) from [<806abb20>] (_raw_spin_lock_irqsave+0x40/0x54)
r7:00000000 r6:8005a3f8 r5:00000193 r4:be03f6d4
[<806abae0>] (_raw_spin_lock_irqsave) from [<8005a3f8>] (complete+0x1c/0x4c)
r6:80950904 r5:be03f6d0 r4:be03f6d4
[<8005a3dc>] (complete) from [<8041b4c0>] (fec_enet_interrupt+0x128/0x164)
r6:80950904 r5:00800000 r4:be03f000 r3:00000000
[<8041b398>] (fec_enet_interrupt) from [<8006aeac>] (handle_irq_event_percpu+0x38/0x13c)
r6:00000000 r5:be01065c r4:be399e00 r3:8041b398
[<8006ae74>] (handle_irq_event_percpu) from [<8006aff4>] (handle_irq_event+0x44/0x64)
r10:be03f000 r9:80989fe0 r8:00000000 r7:00000096 r6:be399e00 r5:be01065c
r4:be010600
[<8006afb0>] (handle_irq_event) from [<8006e3e8>] (handle_fasteoi_irq+0xc8/0x1bc)
r6:8096e764 r5:be01065c r4:be010600 r3:00000000
[<8006e320>] (handle_fasteoi_irq) from [<8006a63c>] (generic_handle_irq+0x30/0x44)
r6:be074010 r5:80945e4c r4:00000096 r3:8006e320
[<8006a60c>] (generic_handle_irq) from [<8000f218>] (handle_IRQ+0x54/0xbc)
r4:80950d74 r3:00000180
[<8000f1c4>] (handle_IRQ) from [<800086cc>] (gic_handle_irq+0x30/0x68)
r8:be3ab478 r7:c080e100 r6:be075bd8 r5:80950eec r4:c080e10c r3:000000a0
[<8000869c>] (gic_handle_irq) from [<80013064>] (__irq_svc+0x44/0x5c)
Signed-off-by: Fugang Duan <B38611-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Frank Li <Frank.Li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
drivers/net/ethernet/freescale/fec_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 34ad932..5110181 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3061,6 +3061,7 @@ fec_probe(struct platform_device *pdev)
goto failed_irq;
}
+ init_completion(&fep->mdio_done);
ret = fec_enet_mii_init(pdev);
if (ret)
goto failed_mii_init;
--
1.9.1
--
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 related
* [Patch v2 net-next 00/12] net: fec: imx6sx multiqueue support
From: Frank Li @ 2014-09-09 20:15 UTC (permalink / raw)
To: b38611-KZfg59tc24xl57MIdRCFDg, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA, lznuaa-Re5JQEeQqe8AvxtiuMwx3w
Cc: shawn.guo-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Frank Li
These patches enable i.MX6SX multi queue support.
i.MX6SX support 3 queue and AVB feature.
Change from v1 to v2.
- Change num_tx_queue to unsigned int
- Avoid block non-dt platform
- remove call netif_set_real_num_rx_queues
- seperate multi queue patch two part, one is tx and rx handle, with fixed queue 0
then other one is initilized multiqueue
- use two difference alignment for tx and rx path
Frank Li (4):
net: fec: init multi queue date structure
net: fec: add enet-avb IP support
ARM: Documentation: Update fec dts binding doc
ARM: dts: imx6sx: add multi-queue support enet
Fugang Duan (8):
net:fec: add enet refrence clock for i.MX 6SX chip
net:fec: add enet AVB feature macro define for imx6sx
net: fec: change data structure to support multiqueue
net: fec: parser max queue number from dt file
net:fec: Disable enet-avb MAC instead of reset MAC
net:fec: Add fsl,imx6sx-fec compatible strings
net: fec: change FEC alignment according to i.mx6 sx requirement
net: fec: init complete variable in early to avoid kernel dump
Documentation/devicetree/bindings/net/fsl-fec.txt | 6 +
arch/arm/boot/dts/imx6sx.dtsi | 2 +
drivers/net/ethernet/freescale/fec.h | 154 +++-
drivers/net/ethernet/freescale/fec_main.c | 848 ++++++++++++++++------
4 files changed, 751 insertions(+), 259 deletions(-)
--
1.9.1
--
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: iwlwifi no authentication with AP - Re: pull request: wireless-next 2014-09-08
From: Emmanuel Grumbach @ 2014-09-09 20:02 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: John W. Linville, linux-wireless, netdev@vger.kernel.org
In-Reply-To: <540F5927.7000306@hartkopp.net>
On Tue, Sep 9, 2014 at 10:46 PM, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
> Hello John, all,
>
> on my i7 Laptop with iwlwifi the latest net-next does not connect to my access point:
Are you sure this wasn't the case before?
Can you bisect?
>
> [ 10.305284] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
> [ 10.312179] iwlwifi 0000:02:00.0: Radio type=0x1-0x3-0x1
> [ 10.524936] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
> [ 10.531762] iwlwifi 0000:02:00.0: Radio type=0x1-0x3-0x1
> [ 10.614189] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 17.097238] wlan0: authenticate with 84:c9:b2:d5:87:80
> [ 17.130120] wlan0: send auth to 84:c9:b2:d5:87:80 (try 1/3)
> [ 17.922281] wlan0: send auth to 84:c9:b2:d5:87:80 (try 2/3)
> [ 18.935272] wlan0: send auth to 84:c9:b2:d5:87:80 (try 3/3)
> [ 19.936236] wlan0: authentication with 84:c9:b2:d5:87:80 timed out
> [ 21.962337] iwlwifi 0000:02:00.0: fail to flush all tx fifo queues Q 0
> [ 21.962348] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 3
> [ 21.962413] iwl data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 21.962455] iwlwifi 0000:02:00.0: FH TRBs(0) = 0x00000000
> [ 21.962491] iwlwifi 0000:02:00.0: FH TRBs(1) = 0x00000000
> [ 21.962528] iwlwifi 0000:02:00.0: FH TRBs(2) = 0x00000000
> [ 21.962564] iwlwifi 0000:02:00.0: FH TRBs(3) = 0x00000000
> [ 21.962600] iwlwifi 0000:02:00.0: FH TRBs(4) = 0x00000000
> [ 21.962636] iwlwifi 0000:02:00.0: FH TRBs(5) = 0x00000000
> [ 21.962673] iwlwifi 0000:02:00.0: FH TRBs(6) = 0x00000000
> [ 21.962709] iwlwifi 0000:02:00.0: FH TRBs(7) = 0x0070402f
> [ 21.962790] iwlwifi 0000:02:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [0,3]
> [ 21.962869] iwlwifi 0000:02:00.0: Q 1 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
> [ 21.962949] iwlwifi 0000:02:00.0: Q 2 is active and mapped to fifo 1 ra_tid 0x0000 [0,0]
> [ 21.963030] iwlwifi 0000:02:00.0: Q 3 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963109] iwlwifi 0000:02:00.0: Q 4 is active and mapped to fifo 7 ra_tid 0x0000 [48,48]
> [ 21.963189] iwlwifi 0000:02:00.0: Q 5 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963270] iwlwifi 0000:02:00.0: Q 6 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963350] iwlwifi 0000:02:00.0: Q 7 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963428] iwlwifi 0000:02:00.0: Q 8 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963508] iwlwifi 0000:02:00.0: Q 9 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963588] iwlwifi 0000:02:00.0: Q 10 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963669] iwlwifi 0000:02:00.0: Q 11 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963750] iwlwifi 0000:02:00.0: Q 12 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963829] iwlwifi 0000:02:00.0: Q 13 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963909] iwlwifi 0000:02:00.0: Q 14 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963988] iwlwifi 0000:02:00.0: Q 15 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.964069] iwlwifi 0000:02:00.0: Q 16 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.964149] iwlwifi 0000:02:00.0: Q 17 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.964228] iwlwifi 0000:02:00.0: Q 18 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.964308] iwlwifi 0000:02:00.0: Q 19 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 22.116816] wlan0: authenticate with xx:xx:xx:xx:xx:xx
> [ 22.155887] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
>
> (..)
>
> and again and again ...
>
> Mainly this is the changing stuff in the following dmesg output:
>
> [ 21.962348] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 3
> [ 26.951325] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 6
> [ 34.979316] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 9
> [ 39.964287] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 12
> [ 47.984243] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 15
> [ 55.984240] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 18
> [ 60.981221] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 21
> [ 73.878064] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 24
> [ 86.342476] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 27
> [ 98.770854] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 30
> [ 111.287320] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 33
> [ 121.045034] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 36
>
> 02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6200 (rev 35)
>
> Any idea?
>
> Regards,
> Oliver
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: iwlwifi no authentication with AP - Re: pull request: wireless-next 2014-09-08
From: John W. Linville @ 2014-09-09 19:52 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: linux-wireless, netdev
In-Reply-To: <540F5927.7000306@hartkopp.net>
On Tue, Sep 09, 2014 at 09:46:47PM +0200, Oliver Hartkopp wrote:
> Hello John, all,
>
> on my i7 Laptop with iwlwifi the latest net-next does not connect to my access point:
>
> [ 10.305284] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
> [ 10.312179] iwlwifi 0000:02:00.0: Radio type=0x1-0x3-0x1
> [ 10.524936] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
> [ 10.531762] iwlwifi 0000:02:00.0: Radio type=0x1-0x3-0x1
> [ 10.614189] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 17.097238] wlan0: authenticate with 84:c9:b2:d5:87:80
> [ 17.130120] wlan0: send auth to 84:c9:b2:d5:87:80 (try 1/3)
> [ 17.922281] wlan0: send auth to 84:c9:b2:d5:87:80 (try 2/3)
> [ 18.935272] wlan0: send auth to 84:c9:b2:d5:87:80 (try 3/3)
> [ 19.936236] wlan0: authentication with 84:c9:b2:d5:87:80 timed out
> [ 21.962337] iwlwifi 0000:02:00.0: fail to flush all tx fifo queues Q 0
> [ 21.962348] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 3
> [ 21.962413] iwl data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [ 21.962455] iwlwifi 0000:02:00.0: FH TRBs(0) = 0x00000000
> [ 21.962491] iwlwifi 0000:02:00.0: FH TRBs(1) = 0x00000000
> [ 21.962528] iwlwifi 0000:02:00.0: FH TRBs(2) = 0x00000000
> [ 21.962564] iwlwifi 0000:02:00.0: FH TRBs(3) = 0x00000000
> [ 21.962600] iwlwifi 0000:02:00.0: FH TRBs(4) = 0x00000000
> [ 21.962636] iwlwifi 0000:02:00.0: FH TRBs(5) = 0x00000000
> [ 21.962673] iwlwifi 0000:02:00.0: FH TRBs(6) = 0x00000000
> [ 21.962709] iwlwifi 0000:02:00.0: FH TRBs(7) = 0x0070402f
> [ 21.962790] iwlwifi 0000:02:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [0,3]
> [ 21.962869] iwlwifi 0000:02:00.0: Q 1 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
> [ 21.962949] iwlwifi 0000:02:00.0: Q 2 is active and mapped to fifo 1 ra_tid 0x0000 [0,0]
> [ 21.963030] iwlwifi 0000:02:00.0: Q 3 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963109] iwlwifi 0000:02:00.0: Q 4 is active and mapped to fifo 7 ra_tid 0x0000 [48,48]
> [ 21.963189] iwlwifi 0000:02:00.0: Q 5 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963270] iwlwifi 0000:02:00.0: Q 6 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963350] iwlwifi 0000:02:00.0: Q 7 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963428] iwlwifi 0000:02:00.0: Q 8 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963508] iwlwifi 0000:02:00.0: Q 9 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963588] iwlwifi 0000:02:00.0: Q 10 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963669] iwlwifi 0000:02:00.0: Q 11 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963750] iwlwifi 0000:02:00.0: Q 12 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963829] iwlwifi 0000:02:00.0: Q 13 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963909] iwlwifi 0000:02:00.0: Q 14 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.963988] iwlwifi 0000:02:00.0: Q 15 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.964069] iwlwifi 0000:02:00.0: Q 16 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.964149] iwlwifi 0000:02:00.0: Q 17 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.964228] iwlwifi 0000:02:00.0: Q 18 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 21.964308] iwlwifi 0000:02:00.0: Q 19 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
> [ 22.116816] wlan0: authenticate with xx:xx:xx:xx:xx:xx
> [ 22.155887] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
>
> (..)
>
> and again and again ...
>
> Mainly this is the changing stuff in the following dmesg output:
>
> [ 21.962348] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 3
> [ 26.951325] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 6
> [ 34.979316] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 9
> [ 39.964287] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 12
> [ 47.984243] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 15
> [ 55.984240] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 18
> [ 60.981221] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 21
> [ 73.878064] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 24
> [ 86.342476] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 27
> [ 98.770854] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 30
> [ 111.287320] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 33
> [ 121.045034] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 36
>
> 02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6200 (rev 35)
>
> Any idea?
>
> Regards,
> Oliver
Hopefully the Intel guys are listening. As a hunch, what sort of
encryption are you using?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH ipvs v2] ipvs: Add simple weighted failover scheduler
From: Julian Anastasov @ 2014-09-09 19:55 UTC (permalink / raw)
To: Kenny Mathis; +Cc: netdev, Wensong Zhang, Simon Horman
In-Reply-To: <20140909132015.GA21984@kmathis.internal.monetra.com>
Hello,
On Tue, 9 Sep 2014, Kenny Mathis wrote:
> Please consider this patch for addition in 3.17
>
> Add simple weighted IPVS failover support to the Linux kernel. All
> other scheduling modules implement some form of load balancing, while
> this offers a simple failover solution. Connections are directed to
> the appropriate server based solely on highest weight value and server
> availability. Tested functionality with keepalived.
>
> Signed-off-by: Kenny Mathis <kmathis@chokepoint.net>
Looks good to me, thanks!
Acked-by: Julian Anastasov <ja@ssi.bg>
Simon, you can apply it to ipvs-next if there are
no any objections.
> ---
> net/netfilter/ipvs/Kconfig | 10 ++++++
> net/netfilter/ipvs/Makefile | 1 +
> net/netfilter/ipvs/ip_vs_fo.c | 79 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 90 insertions(+)
> create mode 100644 net/netfilter/ipvs/ip_vs_fo.c
>
> diff --git a/net/netfilter/ipvs/Kconfig b/net/netfilter/ipvs/Kconfig
> index 0c3b167..3b6929d 100644
> --- a/net/netfilter/ipvs/Kconfig
> +++ b/net/netfilter/ipvs/Kconfig
> @@ -152,6 +152,16 @@ config IP_VS_WLC
> If you want to compile it in kernel, say Y. To compile it as a
> module, choose M here. If unsure, say N.
>
> +config IP_VS_FO
> + tristate "weighted failover scheduling"
> + ---help---
> + The weighted failover scheduling algorithm directs network
> + connections to the server with the highest weight that is
> + currently available.
> +
> + If you want to compile it in kernel, say Y. To compile it as a
> + module, choose M here. If unsure, say N.
> +
> config IP_VS_LBLC
> tristate "locality-based least-connection scheduling"
> ---help---
> diff --git a/net/netfilter/ipvs/Makefile b/net/netfilter/ipvs/Makefile
> index 34ee602..38b2723 100644
> --- a/net/netfilter/ipvs/Makefile
> +++ b/net/netfilter/ipvs/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_IP_VS_RR) += ip_vs_rr.o
> obj-$(CONFIG_IP_VS_WRR) += ip_vs_wrr.o
> obj-$(CONFIG_IP_VS_LC) += ip_vs_lc.o
> obj-$(CONFIG_IP_VS_WLC) += ip_vs_wlc.o
> +obj-$(CONFIG_IP_VS_FO) += ip_vs_fo.o
> obj-$(CONFIG_IP_VS_LBLC) += ip_vs_lblc.o
> obj-$(CONFIG_IP_VS_LBLCR) += ip_vs_lblcr.o
> obj-$(CONFIG_IP_VS_DH) += ip_vs_dh.o
> diff --git a/net/netfilter/ipvs/ip_vs_fo.c b/net/netfilter/ipvs/ip_vs_fo.c
> new file mode 100644
> index 0000000..6a2647d
> --- /dev/null
> +++ b/net/netfilter/ipvs/ip_vs_fo.c
> @@ -0,0 +1,79 @@
> +/*
> + * IPVS: Weighted Fail Over module
> + *
> + * Authors: Kenny Mathis <kmathis@chokepoint.net>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + *
> + * Changes:
> + * Kenny Mathis : added initial functionality based on weight
> + *
> + */
> +
> +#define KMSG_COMPONENT "IPVS"
> +#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +
> +#include <net/ip_vs.h>
> +
> +/* Weighted Fail Over Module */
> +static struct ip_vs_dest *
> +ip_vs_fo_schedule(struct ip_vs_service *svc, const struct sk_buff *skb,
> + struct ip_vs_iphdr *iph)
> +{
> + struct ip_vs_dest *dest, *hweight = NULL;
> + int hw = 0; /* Track highest weight */
> +
> + IP_VS_DBG(6, "ip_vs_fo_schedule(): Scheduling...\n");
> +
> + /* Basic failover functionality
> + * Find virtual server with highest weight and send it traffic
> + */
> + list_for_each_entry_rcu(dest, &svc->destinations, n_list) {
> + if (!(dest->flags & IP_VS_DEST_F_OVERLOAD) &&
> + atomic_read(&dest->weight) > hw) {
> + hweight = dest;
> + hw = atomic_read(&dest->weight);
> + }
> + }
> +
> + if (hweight) {
> + IP_VS_DBG_BUF(6, "FO: server %s:%u activeconns %d weight %d\n",
> + IP_VS_DBG_ADDR(svc->af, &hweight->addr),
> + ntohs(hweight->port),
> + atomic_read(&hweight->activeconns),
> + atomic_read(&hweight->weight));
> + return hweight;
> + }
> +
> + ip_vs_scheduler_err(svc, "no destination available");
> + return NULL;
> +}
> +
> +static struct ip_vs_scheduler ip_vs_fo_scheduler = {
> + .name = "fo",
> + .refcnt = ATOMIC_INIT(0),
> + .module = THIS_MODULE,
> + .n_list = LIST_HEAD_INIT(ip_vs_fo_scheduler.n_list),
> + .schedule = ip_vs_fo_schedule,
> +};
> +
> +static int __init ip_vs_fo_init(void)
> +{
> + return register_ip_vs_scheduler(&ip_vs_fo_scheduler);
> +}
> +
> +static void __exit ip_vs_fo_cleanup(void)
> +{
> + unregister_ip_vs_scheduler(&ip_vs_fo_scheduler);
> + synchronize_rcu();
> +}
> +
> +module_init(ip_vs_fo_init);
> +module_exit(ip_vs_fo_cleanup);
> +MODULE_LICENSE("GPL");
> --
> 1.7.9.5
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* iwlwifi no authentication with AP - Re: pull request: wireless-next 2014-09-08
From: Oliver Hartkopp @ 2014-09-09 19:46 UTC (permalink / raw)
To: John W. Linville, linux-wireless; +Cc: netdev
In-Reply-To: <20140908191630.GB29412@tuxdriver.com>
Hello John, all,
on my i7 Laptop with iwlwifi the latest net-next does not connect to my access point:
[ 10.305284] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
[ 10.312179] iwlwifi 0000:02:00.0: Radio type=0x1-0x3-0x1
[ 10.524936] iwlwifi 0000:02:00.0: L1 Enabled; Disabling L0S
[ 10.531762] iwlwifi 0000:02:00.0: Radio type=0x1-0x3-0x1
[ 10.614189] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 17.097238] wlan0: authenticate with 84:c9:b2:d5:87:80
[ 17.130120] wlan0: send auth to 84:c9:b2:d5:87:80 (try 1/3)
[ 17.922281] wlan0: send auth to 84:c9:b2:d5:87:80 (try 2/3)
[ 18.935272] wlan0: send auth to 84:c9:b2:d5:87:80 (try 3/3)
[ 19.936236] wlan0: authentication with 84:c9:b2:d5:87:80 timed out
[ 21.962337] iwlwifi 0000:02:00.0: fail to flush all tx fifo queues Q 0
[ 21.962348] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 3
[ 21.962413] iwl data: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 21.962455] iwlwifi 0000:02:00.0: FH TRBs(0) = 0x00000000
[ 21.962491] iwlwifi 0000:02:00.0: FH TRBs(1) = 0x00000000
[ 21.962528] iwlwifi 0000:02:00.0: FH TRBs(2) = 0x00000000
[ 21.962564] iwlwifi 0000:02:00.0: FH TRBs(3) = 0x00000000
[ 21.962600] iwlwifi 0000:02:00.0: FH TRBs(4) = 0x00000000
[ 21.962636] iwlwifi 0000:02:00.0: FH TRBs(5) = 0x00000000
[ 21.962673] iwlwifi 0000:02:00.0: FH TRBs(6) = 0x00000000
[ 21.962709] iwlwifi 0000:02:00.0: FH TRBs(7) = 0x0070402f
[ 21.962790] iwlwifi 0000:02:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [0,3]
[ 21.962869] iwlwifi 0000:02:00.0: Q 1 is active and mapped to fifo 2 ra_tid 0x0000 [0,0]
[ 21.962949] iwlwifi 0000:02:00.0: Q 2 is active and mapped to fifo 1 ra_tid 0x0000 [0,0]
[ 21.963030] iwlwifi 0000:02:00.0: Q 3 is active and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.963109] iwlwifi 0000:02:00.0: Q 4 is active and mapped to fifo 7 ra_tid 0x0000 [48,48]
[ 21.963189] iwlwifi 0000:02:00.0: Q 5 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.963270] iwlwifi 0000:02:00.0: Q 6 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.963350] iwlwifi 0000:02:00.0: Q 7 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.963428] iwlwifi 0000:02:00.0: Q 8 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.963508] iwlwifi 0000:02:00.0: Q 9 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.963588] iwlwifi 0000:02:00.0: Q 10 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.963669] iwlwifi 0000:02:00.0: Q 11 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.963750] iwlwifi 0000:02:00.0: Q 12 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.963829] iwlwifi 0000:02:00.0: Q 13 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.963909] iwlwifi 0000:02:00.0: Q 14 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.963988] iwlwifi 0000:02:00.0: Q 15 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.964069] iwlwifi 0000:02:00.0: Q 16 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.964149] iwlwifi 0000:02:00.0: Q 17 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.964228] iwlwifi 0000:02:00.0: Q 18 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 21.964308] iwlwifi 0000:02:00.0: Q 19 is inactive and mapped to fifo 0 ra_tid 0x0000 [0,0]
[ 22.116816] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[ 22.155887] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
(..)
and again and again ...
Mainly this is the changing stuff in the following dmesg output:
[ 21.962348] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 3
[ 26.951325] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 6
[ 34.979316] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 9
[ 39.964287] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 12
[ 47.984243] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 15
[ 55.984240] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 18
[ 60.981221] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 21
[ 73.878064] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 24
[ 86.342476] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 27
[ 98.770854] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 30
[ 111.287320] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 33
[ 121.045034] iwlwifi 0000:02:00.0: Current SW read_ptr 0 write_ptr 36
02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6200 (rev 35)
Any idea?
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH net-next 0/6] bonding: get rid of bond->lock
From: Nikolay Aleksandrov @ 2014-09-09 19:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, vfalico, j.vosburgh, andy
In-Reply-To: <20140909.115755.1617761218805940442.davem@davemloft.net>
On 09/09/2014 08:57 PM, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 09 Sep 2014 11:51:39 -0700 (PDT)
>
>> You are a brave person playing with bond locking, I must say :)
>>
>> Series applied, thanks.
>
> Sorry I had to revert, there is code referencing the bond->lock in
> the cxgb4 driver :-/
>
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: In function ‘cxgb4_inet6addr_handler’:
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:4393:3: error: ‘struct bonding’ has no member named ‘lock’
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:4407:3: error: ‘struct bonding’ has no member named ‘lock’
>
> Please test build with allmodconfig.
>
Wow, my bad! Sorry about that, I didn't expect it.
I will take a look and fix it in v2 + the allmodconfig test :-)
Thanks!
^ permalink raw reply
* Re: Problems with Freescale FEC PHY driver
From: Jacob Pedersen @ 2014-09-09 19:35 UTC (permalink / raw)
To: netdev
In-Reply-To: <CALtTj7xGeXzUw0OSjSe94Be7Ve8=Kr8hfx4XC_=QkCpXNJUT5w@mail.gmail.com>
Hi John,
I'm struggling with the same problem at the moment, but on a Wandboard Quad.
Did you ever find a solution?
Jacob Pedersen
^ permalink raw reply
* Re: [PATCH net-next v5 11/13] net: dsa: add Broadcom SF2 switch driver
From: Alexander Duyck @ 2014-09-09 19:37 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Netdev, David Miller, John Linville, Jamal Hadi Salim
In-Reply-To: <1409184298-1793-12-git-send-email-f.fainelli@gmail.com>
On Wed, Aug 27, 2014 at 5:04 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Add support for the Broadcom Starfigther 2 switch chip using a DSA
> driver. This switch driver supports the following features:
>
> - configuration of the external switch port interface: MII, RevMII,
> RGMII and RGMII_NO_ID are supported
> - support for the per-port MIB counters
> - support for link interrupts for special ports (e.g: MoCA)
> - powering up/down of switch memories to conserve power when ports are
> unused
>
> Finally, update the compatible property for the DSA core code to match
> our switch top-level compatible node.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Changes in v4:
> - fixed typo on the word Starfighter
> - fixed a few checkpatch.pl warnings
>
> No changes in v3
>
> Changes in v2:
> - add support for reading to special MDIO phys (0 and 30)
> - added more power down optimization
> - added VLAN separation
>
> drivers/net/dsa/Kconfig | 11 +
> drivers/net/dsa/Makefile | 1 +
> drivers/net/dsa/bcm_sf2.c | 626 +++++++++++++++++++++++++++++++++++++++++
> drivers/net/dsa/bcm_sf2.h | 140 +++++++++
> drivers/net/dsa/bcm_sf2_regs.h | 227 +++++++++++++++
> net/dsa/dsa.c | 1 +
> 6 files changed, 1006 insertions(+)
> create mode 100644 drivers/net/dsa/bcm_sf2.c
> create mode 100644 drivers/net/dsa/bcm_sf2.h
> create mode 100644 drivers/net/dsa/bcm_sf2_regs.h
[...]
> diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
> new file mode 100644
> index 000000000000..bb7cb8e283b1
> --- /dev/null
> +++ b/drivers/net/dsa/bcm_sf2.c
[...]
> +static char *bcm_sf2_sw_probe(struct mii_bus *bus, int sw_addr)
> +{
> + return "Broadcom Starfighter 2";
> +}
> +
I hadn't noticed before but with this driver it seems like you could
potentially load on any DSA enabled device could you not? It seems
like this would be problematic since you could end up registering
before another DSA driver and prevent it from being able to load since
you always return success. Isn't there any test you could run to
determine if the switch is actually there or not?
Thanks,
Alex
^ permalink raw reply
* Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM
From: James Bottomley @ 2014-09-09 19:35 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Tejun Heo, Lennart Poettering, Kay Sievers, Dmitry Torokhov,
Greg Kroah-Hartman, Wu Zhangjin, Takashi Iwai, Arjan van de Ven,
linux-kernel@vger.kernel.org, Oleg Nesterov, hare, Andrew Morton,
Tetsuo Handa, Joseph Salisbury, Benjamin Poirier,
Santosh Rastapur, One Thousand Gnomes, Tim Gardner,
Pierre Fersing, Nagalakshmi Nandigama, Praveen Krishnamoorthy
In-Reply-To: <CAB=NE6WGAMvffGDTkN5x5Cd+YOtD-Cmo3v7_8FmJ5cvCRbFEpw@mail.gmail.com>
On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote:
> On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > If we want to sort out some sync/async mechanism for probing devices, as
> > an agreement between the init systems and the kernel, that's fine, but
> > its a to-be negotiated enhancement.
>
> Unfortunately as Tejun notes the train has left which already made
> assumptions on this.
Well, that's why it's a bug. It's a material regression impacting
users.
> I'm afraid distributions that want to avoid this
> sigkill at least on the kernel front will have to work around this
> issue either on systemd by increasing the default timeout which is now
> possible thanks to Hannes' changes or by some other means such as the
> combination of a modified non-chatty version of this patch + a check
> at the end of load_module() as mentioned earlier on these threads.
Increasing the default timeout in systemd seems like the obvious bug fix
to me. If the patch exists already, having distros that want it use it
looks to be correct ... not every bug is a kernel bug, after all.
Negotiating a probe vs init split for drivers is fine too, but it's a
longer term thing rather than a bug fix.
> > For the current bug fix, just fix the component that broke ... which would be systemd.
>
> For new systems it seems the proposed fix is to have systemd tell the
> kernel what it thought it should be seeing and that is all pure async
> probes through a sysctl, and then we'd do async probe on all modules
> unless a driver is specifically flagged with a need to run synchronous
> (we'll enable this for request_firmware() users for example to start
> off with).
I don't have very strong views on this one. However, I've got to say
from a systems point of view that if the desire is to flag when the
module is having problems, probing and initializing synchronously in a
thread spawned by init which the init process can watchdog and thus can
flash up warning messages seems to be more straightforwards than an
elaborate asynchronous mechanism with completion signalling which
achieves the same thing in a more complicated (and thus bug prone)
fashion.
James
^ permalink raw reply
* Re: 3.17-rc1 oops during network interface configuration
From: Chuck Lever @ 2014-09-09 19:30 UTC (permalink / raw)
To: netdev, LKML Kernel
Cc: linux-rdma, Bart Van Assche, Or Gerlitz, Saeed Mahameed, Tal Alon,
Yevgeny Petrilin, _govind
In-Reply-To: <53F47917.8080003@mellanox.com>
On Aug 20, 2014, at 6:31 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> On 18/08/2014 15:18, Bart Van Assche wrote:
>> Has anyone else already tried to boot kernel 3.17-rc1 on an IB system ? The
>> following call trace is triggered during boot on a system on which kernel
>> 3.16 runs fine:
>
> Yep, I see it on my systems too.
>
> I narrowed this down a bit to happen only when the port link type (these nodes have ConnectX) is IB and IPoIB gets to load.
>
> I reverted (below) all the IPoIB changes since 3.16 (except for the trivial commit c835a67) and the crash still exists.
>
> I guess this needs to go through systematic bisection.
This crash happens when booting v3.17-rcN on any of my IB-enabled
systems. I have both ConnectX-2 and mthca systems, all are affected.
I bisected this to:
commit e0f31d8498676fda36289603a054d0d490aa2679
Author: Govindarajulu Varadarajan <_govind@gmx.com>
AuthorDate: Mon Jun 23 16:07:58 2014 +0530
Commit: David S. Miller <davem@davemloft.net>
CommitDate: Mon Jun 23 14:32:19 2014 -0700
flow_keys: Record IP layer protocol in skb_flow_dissect()
skb_flow_dissect() dissects only transport header type in ip_proto. It dose not
give any information about IPv4 or IPv6.
This patch adds new member, n_proto, to struct flow_keys. Which records the
IP layer type. i.e IPv4 or IPv6.
This can be used in netdev->ndo_rx_flow_steer driver function to dissect flow.
Adding new member to flow_keys increases the struct size by around 4 bytes.
This causes BUILD_BUG_ON(sizeof(qcb->data) < sz); to fail in
qdisc_cb_private_validate()
So increase data size by 4
Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This commit includes a hunk that increases the size of struct qdisc_skb_cb
by at least 4 bytes:
> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
> index 624f985..a3cfb8e 100644
> --- a/include/net/sch_generic.h
> +++ b/include/net/sch_generic.h
> @@ -231,7 +231,7 @@ struct qdisc_skb_cb {
> unsigned int pkt_len;
> u16 slave_dev_queue_mapping;
> u16 _pad;
> - unsigned char data[20];
> + unsigned char data[24];
> };
>
> static inline void qdisc_cb_private_validate(const struct sk_buff *skb, int sz)
IPoIB defines the following structure in drivers/infiniband/ulp/ipoib/ipoib.h:
> struct ipoib_cb {
> struct qdisc_skb_cb qdisc_cb;
> u8 hwaddr[INFINIBAND_ALEN];
> };
IPoIB keeps this in the sk_buff:cb field, which is exactly 48 bytes.
After commit e0f31d84, the size of struct ipoib_cb on x86_64 becomes
52 bytes.
Thus IPoIB overruns sk_buff:cb, and trashes the sk_buff::_skb_refdst
field, which contains a pointer. By the time we get into
__dev_queue_xmit() and try to use the result of skb_dst(), that pointer
is garbage, and we oops.
Obviously, cb[] could be increased to 56 bytes to accommodate struct
ipoib_cb. I tried this, and it is effective in preventing the oops on
one of my systems.
But I suspect there is an historical reason I’m not aware of that it
has remained 48 bytes for years.
> Or.
>
>> net.git]# git log --oneline --no-merges v3.16.. drivers/infiniband/ulp/ipoib/
>> 8a118a4 Revert "IB/ipoib: Use P_Key change event instead of P_Key polling mechanism"
>> 90e6f39 Revert "IB/ipoib: Avoid flushing the workqueue from worker context"
>> 030ade7 Revert "IB/ipoib: Avoid multicast join attempts with invalid P_key"
>> 97ba2ff Revert "IPoIB: Remove unnecessary test for NULL before debugfs_remove()"
>> e42fa20 IPoIB: Remove unnecessary test for NULL before debugfs_remove()
>> dd57c93 IB/ipoib: Avoid multicast join attempts with invalid P_key
>> 4eae374 IB/ipoib: Avoid flushing the workqueue from worker context
>> db84f88 IB/ipoib: Use P_Key change event instead of P_Key polling mechanism
>> c835a67 net: set name_assign_type in alloc_netdev()
>
>
>> BUG: unable to handle kernel paging request at ffff88090000007e
>> IP: __dev_queue_xmit+0x519
>> Call Trace:
>> ? __dev_queue_xmit+0x49
>> dev_queue_xmit+0x10
>> neigh_connected_output
>> ? ip_finish_output
>> ip_finish_output
>> ? ip_finish_output
>> ? netif_rx_ni
>> ip_mc_output
>> ip_local_out_sk
>> ip_send_skb
>> udp_send_skb
>> udp_sendmsg
>> ? ip_reply_glue_bits
>> ? __lock_is_held
>> inet_sendmsg
>> ? inet_sendmsg
>> sock_sendmsg
>> ? might_fault
>> ? might_fault
>> ? move_addr_to_kernel.part.38
>> SYSC_sendto
>> ? sysret_check
>> ? trace_hardirqs_on_caller
>> ? trace_hardirqs_on_thunk
>> SyS_sendto
>> system_call_fastpath
>>
>> Kernel panic - not syncing: Fatal exception in interrupt
>> Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
>> drm_kms_helper: panic occurred, switching back to text console
>>
>> A screenshot of this kernel oops can be found here:
>> https://drive.google.com/file/d/0B1YQOreL3_FxVDB5UTNwekF6LVU/
>>
>> gdb translates the crash address into the following (not sure this makes sense
>> since offset 0x519 is past the end of __dev_queue_xmit()):
>>
>> (gdb) list *(__dev_queue_xmit+0x519)
>> 0xffffffff8136bc89 is in netdev_adjacent_rename_links (net/core/dev.c:5167).
>> 5162 void netdev_adjacent_rename_links(struct net_device *dev, char *oldname)
>> 5163 {
>> 5164 struct netdev_adjacent *iter;
>> 5165
>> 5166 list_for_each_entry(iter, &dev->adj_list.upper, list) {
>> 5167 netdev_adjacent_sysfs_del(iter->dev, oldname,
>> 5168 &iter->dev->adj_list.lower);
>> 5169 netdev_adjacent_sysfs_add(iter->dev, dev,
>> 5170 &iter->dev->adj_list.lower);
>> 5171 }
>>
>> And the address __dev_queue_xmit+0x49 is translated by gdb into:
>>
>> (gdb) list *(__dev_queue_xmit+0x49)
>> 0xffffffff8136b7b9 is in __dev_queue_xmit (./arch/x86/include/asm/preempt.h:75).
>> 70 * The various preempt_count add/sub methods
>> 71 */
>> 72
>> 73 static __always_inline void __preempt_count_add(int val)
>> 74 {
>> 75 raw_cpu_add_4(__preempt_count, val);
>> 76 }
>> 77
>> 78 static __always_inline void __preempt_count_sub(int val)
>> 79 {
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
* Re: [PATCH net-next 0/5] net: Changes to GRO for encapsulation
From: David Miller @ 2014-09-09 19:18 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <1410153989-23837-1-git-send-email-therbert@google.com>
From: Tom Herbert <therbert@google.com>
Date: Sun, 7 Sep 2014 22:26:24 -0700
> This patch set has some fixes for encapsulation and GRO.
>
> Tom Herbert (5):
> net: Fix GRE RX to use skb_transport_header for GRE header offset
> ipip: Add gro callbacks to ipip offload
> sit: Add gro callbacks to sit offload
> udp: Add try convert checksum is case of skb_steal_sock
> net: Export inet_offloads and inet6_offloads
Please address Eric's feedback and respin this series, thanks!
^ permalink raw reply
* Re: [RFC v2 3/6] kthread: warn on kill signal if not OOM
From: Luis R. Rodriguez @ 2014-09-09 19:16 UTC (permalink / raw)
To: James Bottomley
Cc: Tejun Heo, Lennart Poettering, Kay Sievers, Dmitry Torokhov,
Greg Kroah-Hartman, Wu Zhangjin, Takashi Iwai, Arjan van de Ven,
linux-kernel@vger.kernel.org, Oleg Nesterov, hare, Andrew Morton,
Tetsuo Handa, Joseph Salisbury, Benjamin Poirier,
Santosh Rastapur, One Thousand Gnomes, Tim Gardner,
Pierre Fersing, Nagalakshmi Nandigama, Praveen Krishnamoorthy
In-Reply-To: <1410241109.2028.22.camel@jarvis.lan>
On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2014-09-09 at 10:10 +0900, Tejun Heo wrote:
>> Hello, Luis.
>>
>> On Mon, Sep 08, 2014 at 06:04:23PM -0700, Luis R. Rodriguez wrote:
>> > > I have no idea how the selection should be. It could be per-insmod or
>> > > maybe just a system-wide flag with explicit exceptions marked on
>> > > drivers is good enough. I don't know.
>> >
>> > Its perfectly understandable if we don't know what path to take yet
>> > and its also understandable for it to take time to figure out --
>> > meanwhile though systemd already has merged a policy of a 30 second
>> > timeout for *all drivers* though so we therefore need:
>>
>> I'm not too convinced this is such a difficult problem to figure out.
>> We already have most of logic in place and the only thing missing is
>> how to switch it. Wouldn't something like the following work?
>>
>> * Add a sysctl knob to enable asynchronous device probing on module
>> load and enable asynchronous probing globally if the knob is set.
>>
>> * Identify cases which can't be asynchronous and make them
>> synchronous. e.g. keep who's doing request_module() and avoid
>> asynchronous probing if current is probing one of those.
>
> What's wrong with just fixing systemd? Arbitrary timeouts in init
> scripts for system bring up are plain wrong ... I thought we had this
> sorted out ten years ago when we were first having the arguments about
> how long to wait for root; I'm surprised it's coming back again.
By design it seems systemd should not allow worker processes to block
indefinitely and in fact it currently uses the same timeout for all
types of worker processes. I last recommended a multiplier to at least
allow systemd to distinguish and allow us to modify the timeout based
on the type of process by using an enum used to classify these, kmod
for example would be one type of command:
http://lists.freedesktop.org/archives/systemd-devel/2014-August/021852.html
This was deemed to introduce unnecessary complexity, but I believe
this was before we realized that the timeout was penalizing kmod usage
unfairly given that the original assumption that it was just init that
should be penalized was incorrect given that we batch both init +
probe together. I have been relaying updates back on that thread as we
move along with this discussion on the issues found with the timeout,
but haven't gotten feedback yet as to which path folks on systemd
would like to take in light of recent discussions / clarifications.
Perhaps your arguments might help folks here reconsider things a bit
as well.
If we want *tight* integration between init system / kernel these
discussions are necessary not only when we find issues but also should
be part of the design phase for major changes.
> If we want to sort out some sync/async mechanism for probing devices, as
> an agreement between the init systems and the kernel, that's fine, but
> its a to-be negotiated enhancement.
Unfortunately as Tejun notes the train has left which already made
assumptions on this. I'm afraid distributions that want to avoid this
sigkill at least on the kernel front will have to work around this
issue either on systemd by increasing the default timeout which is now
possible thanks to Hannes' changes or by some other means such as the
combination of a modified non-chatty version of this patch + a check
at the end of load_module() as mentioned earlier on these threads.
> For the current bug fix, just fix the component that broke ... which would be systemd.
For new systems it seems the proposed fix is to have systemd tell the
kernel what it thought it should be seeing and that is all pure async
probes through a sysctl, and then we'd do async probe on all modules
unless a driver is specifically flagged with a need to run synchronous
(we'll enable this for request_firmware() users for example to start
off with).
Luis
^ permalink raw reply
* Re: [PATCH net-next] ethernet: ti: remove unwanted THIS_MODULE macro
From: David Miller @ 2014-09-09 18:59 UTC (permalink / raw)
To: varkabhadram; +Cc: netdev, balbi, mugunthanvnm, linux, linux-kernel, varkab
In-Reply-To: <1410148699-3724-1-git-send-email-varkab@cdac.in>
From: Varka Bhadram <varkabhadram@gmail.com>
Date: Mon, 8 Sep 2014 09:28:19 +0530
> It removes the owner field updation of driver structure.
> It will be automatically updated by module_platform_driver()
>
> Signed-off-by: Varka Bhadram <varkab@cdac.in>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/6] bonding: get rid of bond->lock
From: David Miller @ 2014-09-09 18:57 UTC (permalink / raw)
To: nikolay; +Cc: netdev, vfalico, j.vosburgh, andy
In-Reply-To: <20140909.115139.1465933020340882843.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 09 Sep 2014 11:51:39 -0700 (PDT)
> You are a brave person playing with bond locking, I must say :)
>
> Series applied, thanks.
Sorry I had to revert, there is code referencing the bond->lock in
the cxgb4 driver :-/
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: In function ‘cxgb4_inet6addr_handler’:
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:4393:3: error: ‘struct bonding’ has no member named ‘lock’
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:4407:3: error: ‘struct bonding’ has no member named ‘lock’
Please test build with allmodconfig.
^ permalink raw reply
* Re: [PATCH net-next 1/3] ipv6: Clear flush_id to make GRO work
From: Tom Herbert @ 2014-09-09 18:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1410287886.7106.20.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Sep 9, 2014 at 11:38 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-09-09 at 11:23 -0700, Tom Herbert wrote:
>> In TCP gro we check flush_id which is derived from the IP identifier.
>> In IPv4 gro path the flush_id is set with the expectation that every
>> matched packet increments IP identifier. In IPv6, the flush_id is
>> never set and thus is uinitialized. What's worse is that in IPv6
>> over IPv4 encapsulation, the IP identifier is taken from the outer
>> header which is currently not incremented on every packet for Linux
>> stack, so GRO in this case never matches packets (identifier is
>> not increasing).
>>
>> This patch clears flush_id for every time for a matched packet in
>> IPv6 gro_receive. We need to do this each time to overwrite the
>> setting that would be done in IPv4 gro_receive per the outer
>> header in IPv6 over Ipv4 encapsulation.
>>
>> Signed-off-by: Tom Herbert <therbert@google.com>
>> ---
>> net/ipv6/ip6_offload.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
>> index 5bcda33..929bbbcd 100644
>> --- a/net/ipv6/ip6_offload.c
>> +++ b/net/ipv6/ip6_offload.c
>> @@ -261,6 +261,9 @@ static struct sk_buff **ipv6_gro_receive(struct sk_buff **head,
>> /* flush if Traffic Class fields are different */
>> NAPI_GRO_CB(p)->flush |= !!(first_word & htonl(0x0FF00000));
>> NAPI_GRO_CB(p)->flush |= flush;
>> +
>> + /* Clear flush_id, there's really no concept of ID in IPv6. */
>> + NAPI_GRO_CB(p)->flush_id = 0;
>> }
>>
>> NAPI_GRO_CB(skb)->flush |= flush;
>
> Yeah, I mentioned this problem months ago and apparently forgot to push
> the fix.
>
Unfortunately, probably not the last GRO issue. This whole thing is
really rather fragile and probably easy to break undetected...
> http://patchwork.ozlabs.org/patch/311212/
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
>
>
^ permalink raw reply
* Re: [PATCH net-next 0/6] bonding: get rid of bond->lock
From: David Miller @ 2014-09-09 18:51 UTC (permalink / raw)
To: nikolay; +Cc: netdev, vfalico, j.vosburgh, andy
In-Reply-To: <1410011971-24922-1-git-send-email-nikolay@redhat.com>
From: Nikolay Aleksandrov <nikolay@redhat.com>
Date: Sat, 6 Sep 2014 15:59:25 +0200
> This patch-set removes the last users of bond->lock and converts the places
> that needed it for sync to use curr_slave_lock or RCU as appropriate.
> I've run this with lockdep and have stress-tested it via loading/unloading
> and enslaving/releasing in parallel while outputting bond's proc, I didn't
> see any issues. Please pay special attention to the procfs change, I've
> done about an hour of stress-testing on it and have checked that the event
> that causes the bonding to delete its proc entry (NETDEV_UNREGISTER) is
> called before ndo_uninit() and the freeing of the dev so any readers will
> sync with that. Also ran sparse checks and there were no splats.
>
> Changes from the RFC:
> use RCU in procfs instead of RTNL since RTNL might lead to a deadlock with
> unloading and also is much slower. The bond destruction syncs with proc
> via the proc locks. There's one new patch that converts primary_slave to
> use RCU as it was necessary to fix a longstanding bugs in sysfs and
> procfs and to make it easy to migrate bond's procfs to RCU. And of course
> rebased on top of net-next current.
>
> This is the first patch-set in a series that should simplify the bond's
> locking requirements and will make it easier to define the locking
> conditions necessary for the various paths. The goal is to rely on RTNL
> and rcu alone, an extra lock would be needed in a few special cases that
> would be documented very well.
You are a brave person playing with bond locking, I must say :)
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH][net-next] openvswitch: change the data type of error status to atomic_long_t
From: David Miller @ 2014-09-09 18:47 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev, pshelar
In-Reply-To: <1410001571-13338-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Sat, 6 Sep 2014 19:06:11 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> Change the date type of error status from u64 to atomic_long_t, and use atomic
> operation, then remove the lock which is used to protect the error status.
>
> The operation of atomic maybe faster than spin lock.
>
> Cc: Pravin Shelar <pshelar@nicira.com>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
I think in the final analysis this is a good change, it shrinks a
datastructure by eliminating a spinlock, and the performance impact
is a non-argument since these are not happening in performance
critical paths.
So I am going to apply this, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/3] ipv6: Clear flush_id to make GRO work
From: Eric Dumazet @ 2014-09-09 18:38 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <1410286996-302-2-git-send-email-therbert@google.com>
On Tue, 2014-09-09 at 11:23 -0700, Tom Herbert wrote:
> In TCP gro we check flush_id which is derived from the IP identifier.
> In IPv4 gro path the flush_id is set with the expectation that every
> matched packet increments IP identifier. In IPv6, the flush_id is
> never set and thus is uinitialized. What's worse is that in IPv6
> over IPv4 encapsulation, the IP identifier is taken from the outer
> header which is currently not incremented on every packet for Linux
> stack, so GRO in this case never matches packets (identifier is
> not increasing).
>
> This patch clears flush_id for every time for a matched packet in
> IPv6 gro_receive. We need to do this each time to overwrite the
> setting that would be done in IPv4 gro_receive per the outer
> header in IPv6 over Ipv4 encapsulation.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> net/ipv6/ip6_offload.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
> index 5bcda33..929bbbcd 100644
> --- a/net/ipv6/ip6_offload.c
> +++ b/net/ipv6/ip6_offload.c
> @@ -261,6 +261,9 @@ static struct sk_buff **ipv6_gro_receive(struct sk_buff **head,
> /* flush if Traffic Class fields are different */
> NAPI_GRO_CB(p)->flush |= !!(first_word & htonl(0x0FF00000));
> NAPI_GRO_CB(p)->flush |= flush;
> +
> + /* Clear flush_id, there's really no concept of ID in IPv6. */
> + NAPI_GRO_CB(p)->flush_id = 0;
> }
>
> NAPI_GRO_CB(skb)->flush |= flush;
Yeah, I mentioned this problem months ago and apparently forgot to push
the fix.
http://patchwork.ozlabs.org/patch/311212/
Signed-off-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next] bridge: Cleanup of unncessary check.
From: David Miller @ 2014-09-09 18:32 UTC (permalink / raw)
To: ramirose; +Cc: netdev
In-Reply-To: <1409998088-12938-1-git-send-email-ramirose@gmail.com>
From: Rami Rosen <ramirose@gmail.com>
Date: Sat, 6 Sep 2014 13:08:08 +0300
> This patch removes an unncessary check in the br_afspec() method of
> br_netlink.c.
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: udp6_gro_complete() is static
From: Tom Herbert @ 2014-09-09 18:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1410275777.7106.8.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Sep 9, 2014 at 8:16 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> net/ipv6/udp_offload.c:159:5: warning: symbol 'udp6_gro_complete' was
> not declared. Should it be static?
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Fixes: 57c67ff4bd92 ("udp: additional GRO support")
> Cc: Tom Herbert <therbert@google.com>
> ---
> net/ipv6/udp_offload.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
> index 89cb9a9b8537..a1ad34b1c4ec 100644
> --- a/net/ipv6/udp_offload.c
> +++ b/net/ipv6/udp_offload.c
> @@ -156,7 +156,7 @@ flush:
> return NULL;
> }
>
> -int udp6_gro_complete(struct sk_buff *skb, int nhoff)
> +static int udp6_gro_complete(struct sk_buff *skb, int nhoff)
> {
> const struct ipv6hdr *ipv6h = ipv6_hdr(skb);
> struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
>
>
Acked-by: Tom Herbert <therbert@google.com>
^ permalink raw reply
* Re: [PATCH net-next] ipv4: udp4_gro_complete() is static
From: Tom Herbert @ 2014-09-09 18:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1410276552.7106.17.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Sep 9, 2014 at 8:29 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> net/ipv4/udp_offload.c:339:5: warning: symbol 'udp4_gro_complete' was
> not declared. Should it be static?
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Tom Herbert <therbert@google.com>
> Fixes: 57c67ff4bd92 ("udp: additional GRO support")
> ---
> net/ipv4/udp_offload.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> index 84e0e05c9c0e..52d5f46abf86 100644
> --- a/net/ipv4/udp_offload.c
> +++ b/net/ipv4/udp_offload.c
> @@ -336,7 +336,7 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff)
> return err;
> }
>
> -int udp4_gro_complete(struct sk_buff *skb, int nhoff)
> +static int udp4_gro_complete(struct sk_buff *skb, int nhoff)
> {
> const struct iphdr *iph = ip_hdr(skb);
> struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
>
>
Acked-by: Tom Herbert <therbert@google.com>
^ permalink raw reply
* Re: [patch net-next 0/5] bridge: implement rtnl_link options for getting and setting bridge options
From: David Miller @ 2014-09-09 18:30 UTC (permalink / raw)
To: jiri; +Cc: netdev, stephen, sfeldma, arvid.brodin, sucheta.chakraborty
In-Reply-To: <1409925092-17808-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 5 Sep 2014 15:51:27 +0200
> So far, only sysfs is complete interface for getting and setting bridge
> options. This patchset follows-up on the similar bonding code and
> allows userspace to get/set bridge master/port options using Netlink
> IFLA_INFO_DATA/IFLA_INFO_SLAVE_DATA attr.
Series applied, thanks Jiri.
^ 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