* Re: pull request: bluetooth 2014-12-17
From: David Miller @ 2014-12-18 20:32 UTC (permalink / raw)
To: johan.hedberg; +Cc: netdev, linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <20141217204614.GA15480@t440s.P-661HNU-F1>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Wed, 17 Dec 2014 22:46:14 +0200
> Here's the first direct (i.e. skipping the wireless tree) bluetooth pull
> request for you, intended for 3.19. It's just one patch: a fix from
> Marcel for for remote service discovery filtering which also fixes a
> 'used uninitialized' compiler warning.
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thanks Johan.
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Nils Holland @ 2014-12-18 20:26 UTC (permalink / raw)
To: Prashant Sreedharan
Cc: Bjorn Helgaas, Marcelo Ricardo Leitner, Michael Chan, Rajat Jain,
David Miller, netdev, linux-pci@vger.kernel.org, Rafael Wysocki
In-Reply-To: <1418930889.3433.8.camel@prashant>
On Thu, Dec 18, 2014 at 11:28:09AM -0800, Prashant Sreedharan wrote:
> On Thu, 2014-12-18 at 12:15 -0700, Bjorn Helgaas wrote:
> >
> > Any updates from the hardware team?
> >
> > This is a pretty serious regression, but as far as I can tell, it is
> > not a PCI bug. The device should respond to a config read of vendor
> > ID. If the driver does something that make the read return CRS
> > status, I think the driver is responsible for doing whatever delay or
> > other fixup is required.
> >
> > I'm inclined to reassign this bug to the tg3 driver unless you think
> > the PCI core is doing something wrong here.
> >
> > Bjorn
>
> We were not able to reproduce this issue, could you please check what is
> the value of reg 0x70, before the pci_device_is_present call is made ?
> if bit 15 is set config access will be retried.
>
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -9025,6 +9025,7 @@ static int tg3_chip_reset(struct tg3 *tp)
> void (*write_op)(struct tg3 *, u32, u32);
> int i, err;
>
> + printk(KERN_ERR "config state: %x\n", tr32(TG3PCI_PCISTATE));
> if (!pci_device_is_present(tp->pdev))
> return -ENODEV;
No problem, I gave this a try and here is what I get:
[ 2.185190] libphy: tg3 mdio bus: probed
[ 2.229357] tsc: Refined TSC clocksource calibration: 2399.999 MHz
[ 2.244993] config state: 1292
[ 2.247136] tg3 0000:02:00.0 eth0: Tigon3 [partno(BCM57780) rev 57780001]
(PCI Express) MAC address 00:19:99:ce:13:a6
[ 2.249279] tg3 0000:02:00.0 eth0: attached PHY driver [Broadcom BCM57780]
(mii_bus:phy_addr=200:01)
[ 2.251460] tg3 0000:02:00.0 eth0: RXcsums[1] LinkChgREG[0]
MIirq[0] ASF[0] TSOcap[1]
[ 2.253672] tg3 0000:02:00.0 eth0: dma_rwctrl[76180000] dma_mask[64-bit]
[...]
[ 12.204692] tg3 0000:02:00.0
enp2s0: No firmware running
[ 12.206653] config state: 1292
[ 12.208655] config state: 1292
That's all of the three times the new debugging line gets hit when I
boot my system using the supplied diagnostic patch.
Hope that helps - of course, I'd gladly test any further
(diagnostic) patches if required! Also, if I can provide any
additional information that might be of value, just ask:-)
Greetings,
Nils
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: changes for wireless
From: Luca Coelho @ 2014-12-18 20:14 UTC (permalink / raw)
To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, John W. Linville
In-Reply-To: <1418836025-9035-1-git-send-email-linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On Wed, 2014-12-17 at 12:07 -0500, John W. Linville wrote:
> http://marc.info/?l=linux-wireless&m=141883202530292&w=2
>
> This makes it official... :-)
>
> Signed-off-by: John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> ---
> MAINTAINERS | 19 ++++++++-----------
> 1 file changed, 8 insertions(+), 11 deletions(-)
[...]
> +NETWORKING DRIVERS (WIRELESS)
> +M: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> +L: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +Q: http://patchwork.kernel.org/project/linux-wireless/list/
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git/
> +S: Maintained
> +F: drivers/net/wireless/
Kalle, welcome to your new role! I'm sure you're the right person for
the job. You've been the person to thank (or to blame? ;) for getting
me into the Linux Wireless community and you've also been a mentor,
guide and friend along the way. I'm very happy for you and for the
community as a whole, which will certainly benefit from your work!
Thanks for taking the position!
--
Luca.
--
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: [GIT PULL nf-next] Second round of IPVS Updates for v3.19
From: Pablo Neira Ayuso @ 2014-12-18 20:11 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov
In-Reply-To: <1418201201-19257-1-git-send-email-horms@verge.net.au>
On Wed, Dec 10, 2014 at 05:46:40PM +0900, Simon Horman wrote:
> Hi Pablo,
>
> please consider these IPVS updates for v3.19 or alternatively v3.20.
>
> The single patch in this series fixes a long standing bug that
> has not caused any trouble and thus is not being prioritised as a fix.
>
>
> The following changes since commit d6b00fec5dbbe976904b4d77e7d4f9493df5c2ec:
>
> macvlan: play well with ipvlan device (2014-12-09 16:10:06 -0500)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git tags/ipvs2-for-v3.19
Pulled, thanks Simon.
This applies cleanly to:
3.2.x
3.4.x
3.10.x
3.14.x
3.17.x
3.18.x
Please, let me know if this patch has some non obvious dependencies
that needs to be fulfilled before passing it to -stable or it's plain
fine to pass it on.
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Marcelo Ricardo Leitner @ 2014-12-18 20:09 UTC (permalink / raw)
To: Prashant Sreedharan, Bjorn Helgaas
Cc: Michael Chan, Rajat Jain, Nils Holland, David Miller, netdev,
linux-pci@vger.kernel.org, Rafael Wysocki
In-Reply-To: <1418930889.3433.8.camel@prashant>
On 18-12-2014 17:28, Prashant Sreedharan wrote:
> On Thu, 2014-12-18 at 12:15 -0700, Bjorn Helgaas wrote:
>> On Tue, Dec 16, 2014 at 12:54 PM, Michael Chan <mchan@broadcom.com> wrote:
>>> On Tue, 2014-12-16 at 15:59 -0200, Marcelo Ricardo Leitner wrote:
>>>> It's a
>>>> 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722
>>>> Gigabit Ethernet PCI Express
>>>> over here
>>>>
>>>> I put a WARN_ON(1) after those printks, and this is what I got:
>>>>
>>>> [ 1.550640] pci 0000:02:00.0: 1st 1 1
>>>> [ 1.550643] pci 0000:02:00.0: crs_timeout: 0
>>>> [ 1.550645] ------------[ cut here ]------------
>>>> [ 1.550651] WARNING: CPU: 6 PID: 364 at drivers/pci/probe.c:1445 pci_bus_read_dev_vendor_id+0x1d4/0x1e0()
>>>> [ 1.550652] Modules linked in: i915(+) raid0 i2c_algo_bit drm_kms_helper drm e1000e(+) tg3(+) ptp pps_core video
>>>> [ 1.550660] CPU: 6 PID: 364 Comm: systemd-udevd Not tainted 3.18.0-rc6+ #8
>>>> [ 1.550661] Hardware name: Dell Inc. OptiPlex 9010/03K80F, BIOS A15 08/12/2013
>>>> [ 1.550662] 0000000000000000 000000004de2d8dc ffff8807eabdf948 ffffffff8173db46
>>>> [ 1.550665] 0000000000000000 0000000000000000 ffff8807eabdf988 ffffffff81094d41
>>>> [ 1.550667] ffff8807eabdf968 ffff8807f1e27000 0000000000000000 0000000000000000
>>>> [ 1.550669] Call Trace:
>>>> [ 1.550675] [<ffffffff8173db46>] dump_stack+0x46/0x58
>>>> [ 1.550679] [<ffffffff81094d41>] warn_slowpath_common+0x81/0xa0
>>>> [ 1.550681] [<ffffffff81094e5a>] warn_slowpath_null+0x1a/0x20
>>>> [ 1.550683] [<ffffffff813b2864>] pci_bus_read_dev_vendor_id+0x1d4/0x1e0
>>>> [ 1.550687] [<ffffffff813b7c3e>] pci_device_is_present+0x2e/0x50
>>>> [ 1.550693] [<ffffffffa003364f>] tg3_chip_reset+0x2f/0x940 [tg3]
>>>> [ 1.550697] [<ffffffffa0033f9f>] tg3_halt+0x3f/0x1e0 [tg3]
>>>> [ 1.550701] [<ffffffffa0044f83>] tg3_init_one+0xb83/0x1a40 [tg3]
>>>
>>> So does it work if you use a non-zero crs_timeout? The driver has
>>> called tg3_halt() which may affect configuration read responses. I need
>>> to check with the hardware team to see if the 5722 will return CRS in
>>> this scenario.
>>
>> Any updates from the hardware team?
>>
>> This is a pretty serious regression, but as far as I can tell, it is
>> not a PCI bug. The device should respond to a config read of vendor
>> ID. If the driver does something that make the read return CRS
>> status, I think the driver is responsible for doing whatever delay or
>> other fixup is required.
>>
>> I'm inclined to reassign this bug to the tg3 driver unless you think
>> the PCI core is doing something wrong here.
>>
>> Bjorn
>
> We were not able to reproduce this issue, could you please check what is
> the value of reg 0x70, before the pci_device_is_present call is made ?
> if bit 15 is set config access will be retried.
>
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -9025,6 +9025,7 @@ static int tg3_chip_reset(struct tg3 *tp)
> void (*write_op)(struct tg3 *, u32, u32);
> int i, err;
>
> + printk(KERN_ERR "config state: %x\n", tr32(TG3PCI_PCISTATE));
> if (!pci_device_is_present(tp->pdev))
> return -ENODEV;
>
With that PCI patch applied and my debugs, without the timeout hack (so crs_timeout=0):
[ 1.545554] config state: 12b2
[ 1.548636] pci 0000:02:00.0: 1st 1 1
[ 1.548637] pci 0000:02:00.0: crs_timeout: 0
[ 1.548783] tg3 0000:02:00.0 eth0: Tigon3 [partno(BCM95722) rev a200] (PCI Express) MAC address 00:0a:f7:2b:9b:39
[ 1.548785] tg3 0000:02:00.0 eth0: attached PHY is 5722/5756 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[ 1.548786] tg3 0000:02:00.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[ 1.548787] tg3 0000:02:00.0 eth0: dma_rwctrl[76180000] dma_mask[64-bit]
[ 1.554389] tg3 0000:02:00.0 p1p1: renamed from eth0
...
That's the only time your printk got printed.
Marcelo
^ permalink raw reply
* Re: [iwlwifi] BUG: unable to handle kernel
From: Grumbach, Emmanuel @ 2014-12-18 19:42 UTC (permalink / raw)
To: Wu, Fengguang
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, lkp@01.org,
linux-leds@vger.kernel.org
In-Reply-To: <20141218171309.GD9298@wfg-t540p.sh.intel.com>
On Thu, 2014-12-18 at 09:13 -0800, Fengguang Wu wrote:
> Hi All,
>
> I don't see any relationship between the BUG and this bisected commit.
> Anyway, it's better to report it to the lists than to ignore.
Right - but I have to say that I have no clue how this comment can cause
the bug you are seeing...
Do you even have an Intel Wireless device the VM could access?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git master
>
> commit 03d6c3b0fa4f5f0379cede079ec828a6c999fe43
> Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> AuthorDate: Wed Dec 3 10:39:07 2014 +0200
> Commit: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> CommitDate: Sun Dec 14 10:20:29 2014 +0200
>
> iwlwifi: pcie: re-ACK all interrupts after device reset
>
> When we reset the device, the CSR_INT gets cleared as well
> as CSR_INT_MASK. Meaning that we shouldn't get any interrupt
> but, due to a hardware bug, recent devices will keep sending
> interrupts. This leads to an interrupt storm while stopping
> the device.
> The way to fix this is to ACK all the interrupts after the
> device is reset so that the value of CSR_INT will stay
> 0xffffffff.
>
> Fixes: 522713c81e4e ("iwlwifi: pcie: properly reset the device")
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>
> +------------------------------------------+------------+------------+------------+
> | | 0a79a0c011 | 03d6c3b0fa | iwlwifi-fi |
> +------------------------------------------+------------+------------+------------+
> | boot_successes | 60 | 19 | 3 |
> | boot_failures | 0 | 1 | 9 |
> | BUG:unable_to_handle_kernel | 0 | 1 | 9 |
> | Oops | 0 | 1 | 9 |
> | RIP:strcmp | 0 | 1 | 9 |
> | Kernel_panic-not_syncing:Fatal_exception | 0 | 1 | 9 |
> | backtrace:led_trigger_register_simple | 0 | 1 | 9 |
> | backtrace:ledtrig_usb_init | 0 | 1 | 9 |
> | backtrace:kernel_init_freeable | 0 | 1 | 9 |
> +------------------------------------------+------------+------------+------------+
>
> [ 5.345018] g_serial gadget: Gadget Serial v2.4
> [ 5.345927] g_serial gadget: g_serial ready
> [ 5.345927] g_serial gadget: g_serial ready
> [ 5.346777] BUG: unable to handle kernel
> [ 5.346777] BUG: unable to handle kernel paging requestpaging request at ffff88000004e5f0
> at ffff88000004e5f0
> [ 5.348183] IP:
> [ 5.348183] IP: [<ffffffff81446a68>] strcmp+0x6/0x20
> [<ffffffff81446a68>] strcmp+0x6/0x20
> [ 5.349183] PGD 37f1067
> [ 5.349183] PGD 37f1067 PUD 37f2067 PUD 37f2067 PMD 37f3067 PMD 37f3067 PTE 800000000004e060PTE 800000000004e060
>
> [ 5.350498] Oops: 0000 [#1]
> [ 5.350498] Oops: 0000 [#1] DEBUG_PAGEALLOCDEBUG_PAGEALLOC
>
> [ 5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
> [ 5.351360] CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-g03d6c3b #1
> [ 5.352660] task: ffff880012060000 ti: ffff88001204c000 task.ti: ffff88001204c000
> [ 5.352660] task: ffff880012060000 ti: ffff88001204c000 task.ti: ffff88001204c000
> [ 5.354143] RIP: 0010:[<ffffffff81446a68>]
> [ 5.354143] RIP: 0010:[<ffffffff81446a68>] [<ffffffff81446a68>] strcmp+0x6/0x20
> [<ffffffff81446a68>] strcmp+0x6/0x20
> [ 5.354451] RSP: 0000:ffff88001204fe28 EFLAGS: 00010246
> [ 5.354451] RSP: 0000:ffff88001204fe28 EFLAGS: 00010246
> [ 5.354451] RAX: 0000000000000000 RBX: ffff88000c08fe00 RCX: ffffffff81d35310
> [ 5.354451] RAX: 0000000000000000 RBX: ffff88000c08fe00 RCX: ffffffff81d35310
> [ 5.354451] RDX: ffff88000c08fe68 RSI: ffffffff826d05be RDI: ffff88000004e5f0
> [ 5.354451] RDX: ffff88000c08fe68 RSI: ffffffff826d05be RDI: ffff88000004e5f0
> [ 5.354451] RBP: ffff88001204fe28 R08: 0000000000000001 R09: 000000000000033a
> [ 5.354451] RBP: ffff88001204fe28 R08: 0000000000000001 R09: 000000000000033a
> [ 5.354451] R10: 0000000000000000 R11: ffffffff82531cd1 R12: ffff88000c19fa00
> [ 5.354451] R10: 0000000000000000 R11: ffffffff82531cd1 R12: ffff88000c19fa00
> [ 5.354451] R13: 0000000000000000 R14: ffffffff837958b8 R15: 0000000000000000
> [ 5.354451] R13: 0000000000000000 R14: ffffffff837958b8 R15: 0000000000000000
> [ 5.354451] FS: 0000000000000000(0000) GS:ffffffff82789000(0000) knlGS:0000000000000000
> [ 5.354451] FS: 0000000000000000(0000) GS:ffffffff82789000(0000) knlGS:0000000000000000
> [ 5.354451] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 5.354451] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 5.354451] CR2: ffff88000004e5f0 CR3: 0000000002776000 CR4: 00000000000006b0
> [ 5.354451] CR2: ffff88000004e5f0 CR3: 0000000002776000 CR4: 00000000000006b0
> [ 5.354451] Stack:
> [ 5.354451] Stack:
> [ 5.354451] ffff88001204fe58
> [ 5.354451] ffff88001204fe58 ffffffff81d35334 ffffffff81d35334 0000000000000000 0000000000000000 ffff88000c19fa00 ffff88000c19fa00
>
> [ 5.354451] ffffffff826d05be
> [ 5.354451] ffffffff826d05be 0000000000000000 0000000000000000 ffff88001204fe88 ffff88001204fe88 ffffffff81d35648 ffffffff81d35648
>
> [ 5.354451] ffff88000e3bbcc0
> [ 5.354451] ffff88000e3bbcc0 ffffffff82b3fe61 ffffffff82b3fe61 0000000000000000 0000000000000000 ffffffff82b98910 ffffffff82b98910
>
> [ 5.354451] Call Trace:
> [ 5.354451] Call Trace:
> [ 5.354451] [<ffffffff81d35334>] led_trigger_register+0x63/0x129
> [ 5.354451] [<ffffffff81d35334>] led_trigger_register+0x63/0x129
> [ 5.354451] [<ffffffff81d35648>] led_trigger_register_simple+0x35/0x79
> [ 5.354451] [<ffffffff81d35648>] led_trigger_register_simple+0x35/0x79
> [ 5.354451] [<ffffffff82b3fe61>] ? gs_bind+0xea/0xea
> [ 5.354451] [<ffffffff82b3fe61>] ? gs_bind+0xea/0xea
> [ 5.354451] [<ffffffff82b3fe78>] ledtrig_usb_init+0x17/0x2e
> [ 5.354451] [<ffffffff82b3fe78>] ledtrig_usb_init+0x17/0x2e
> [ 5.354451] [<ffffffff82b00044>] do_one_initcall+0xe6/0x171
> [ 5.354451] [<ffffffff82b00044>] do_one_initcall+0xe6/0x171
> [ 5.354451] [<ffffffff82b001c7>] kernel_init_freeable+0xf8/0x180
> [ 5.354451] [<ffffffff82b001c7>] kernel_init_freeable+0xf8/0x180
> [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> [ 5.354451] [<ffffffff8206079a>] kernel_init+0x9/0xd0
> [ 5.354451] [<ffffffff8206079a>] kernel_init+0x9/0xd0
> [ 5.354451] [<ffffffff8207d2ba>] ret_from_fork+0x7a/0xb0
> [ 5.354451] [<ffffffff8207d2ba>] ret_from_fork+0x7a/0xb0
> [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> [ 5.354451] [<ffffffff82060791>] ? rest_init+0xbd/0xbd
> [ 5.354451] Code:
> [ 5.354451] Code: c0 c0 eb eb f5 f5 31 31 c9 c9 40 40 8a 8a 3c 3c 0e 0e 4d 4d 8d 8d 0c 0c 08 08 40 40 84 84 ff ff 41 41 88 88 3c 3c 08 08 74 74 0d 0d 48 48 ff ff c1 c1 48 48 39 39 ca ca 75 75 e7 e7 41 41 c6 c6 41 41 01 01 00 00 5d 5d c3 c3 55 55 31 31 c0 c0 48 48 89 89 e5 e5 <8a> <8a> 14 14 07 07 3a 3a 14 14 06 06 74 74 07 07 19 19 c0 c0 83 83 c8 c8 01 01 eb eb 09 09 48 48 ff ff c0 c0 84 84 d2 d2 75 75
>
> [ 5.354451] RIP
> [ 5.354451] RIP [<ffffffff81446a68>] strcmp+0x6/0x20
> [<ffffffff81446a68>] strcmp+0x6/0x20
> [ 5.354451] RSP <ffff88001204fe28>
> [ 5.354451] RSP <ffff88001204fe28>
> [ 5.354451] CR2: ffff88000004e5f0
> [ 5.354451] CR2: ffff88000004e5f0
> [ 5.354451] ---[ end trace 8f9377b34c860a0c ]---
> [ 5.354451] ---[ end trace 8f9377b34c860a0c ]---
>
> git bisect start baa21e834941ee5fbe4bd421c871f7c0c5f9a086 70e71ca0af244f48a5dcf56dc435243792e3a495 --
> git bisect bad 03d6c3b0fa4f5f0379cede079ec828a6c999fe43 # 16:23 0- 1 iwlwifi: pcie: re-ACK all interrupts after device reset
> git bisect good 0a79a0c011cb291675e3b80760a452fcba5c59d9 # 16:28 20+ 0 iwlwifi: mvm: clear IN_HW_RESTART flag on stop()
> # first bad commit: [03d6c3b0fa4f5f0379cede079ec828a6c999fe43] iwlwifi: pcie: re-ACK all interrupts after device reset
> git bisect good 0a79a0c011cb291675e3b80760a452fcba5c59d9 # 16:30 60+ 0 iwlwifi: mvm: clear IN_HW_RESTART flag on stop()
> # extra tests on HEAD of iwlwifi-fixes/master
> git bisect bad baa21e834941ee5fbe4bd421c871f7c0c5f9a086 # 16:30 0- 9 iwlwifi: pcie: limit fw chunk sizes given to fh
> # extra tests on tree/branch iwlwifi-fixes/master
> git bisect bad baa21e834941ee5fbe4bd421c871f7c0c5f9a086 # 16:30 0- 9 iwlwifi: pcie: limit fw chunk sizes given to fh
> # extra tests on tree/branch linus/master
> git bisect good 44e8967d591686463e84a88b46b03beba3ab49fb # 16:32 60+ 0 Ceph: remove left-over reject file
> # extra tests on tree/branch next/master
> git bisect good cfaa3a95dd2b402599b1d8122dc3107478db8717 # 16:35 60+ 1 Add linux-next specific files for 20141218
>
>
> This script may reproduce the error.
>
> ----------------------------------------------------------------------------
> #!/bin/bash
>
> kernel=$1
> initrd=quantal-core-x86_64.cgz
>
> wget --no-clobber https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
>
> kvm=(
> qemu-system-x86_64
> -cpu kvm64
> -enable-kvm
> -kernel $kernel
> -initrd $initrd
> -m 320
> -smp 2
> -net nic,vlan=1,model=e1000
> -net user,vlan=1
> -boot order=nc
> -no-reboot
> -watchdog i6300esb
> -rtc base=localtime
> -serial stdio
> -display none
> -monitor null
> )
>
> append=(
> hung_task_panic=1
> earlyprintk=ttyS0,115200
> debug
> apic=debug
> sysrq_always_enabled
> rcupdate.rcu_cpu_stall_timeout=100
> panic=-1
> softlockup_panic=1
> nmi_watchdog=panic
> oops=panic
> load_ramdisk=2
> prompt_ramdisk=0
> console=ttyS0,115200
> console=tty0
> vga=normal
> root=/dev/ram0
> rw
> drbd.minor_count=8
> )
>
> "${kvm[@]}" --append "${append[*]}"
> ----------------------------------------------------------------------------
>
> Thanks,
> Fengguang
> _______________________________________________
> LKP mailing list
> LKP@linux.intel.com
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Prashant Sreedharan @ 2014-12-18 19:28 UTC (permalink / raw)
To: Bjorn Helgaas, Marcelo Ricardo Leitner
Cc: Michael Chan, Rajat Jain, Nils Holland, David Miller, netdev,
linux-pci@vger.kernel.org, Rafael Wysocki
In-Reply-To: <CAErSpo7sqZS+-4LHo3wbo-pa73mcP_3d0Z37U0tfnASaxp-D_g@mail.gmail.com>
On Thu, 2014-12-18 at 12:15 -0700, Bjorn Helgaas wrote:
> On Tue, Dec 16, 2014 at 12:54 PM, Michael Chan <mchan@broadcom.com> wrote:
> > On Tue, 2014-12-16 at 15:59 -0200, Marcelo Ricardo Leitner wrote:
> >> It's a
> >> 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722
> >> Gigabit Ethernet PCI Express
> >> over here
> >>
> >> I put a WARN_ON(1) after those printks, and this is what I got:
> >>
> >> [ 1.550640] pci 0000:02:00.0: 1st 1 1
> >> [ 1.550643] pci 0000:02:00.0: crs_timeout: 0
> >> [ 1.550645] ------------[ cut here ]------------
> >> [ 1.550651] WARNING: CPU: 6 PID: 364 at drivers/pci/probe.c:1445 pci_bus_read_dev_vendor_id+0x1d4/0x1e0()
> >> [ 1.550652] Modules linked in: i915(+) raid0 i2c_algo_bit drm_kms_helper drm e1000e(+) tg3(+) ptp pps_core video
> >> [ 1.550660] CPU: 6 PID: 364 Comm: systemd-udevd Not tainted 3.18.0-rc6+ #8
> >> [ 1.550661] Hardware name: Dell Inc. OptiPlex 9010/03K80F, BIOS A15 08/12/2013
> >> [ 1.550662] 0000000000000000 000000004de2d8dc ffff8807eabdf948 ffffffff8173db46
> >> [ 1.550665] 0000000000000000 0000000000000000 ffff8807eabdf988 ffffffff81094d41
> >> [ 1.550667] ffff8807eabdf968 ffff8807f1e27000 0000000000000000 0000000000000000
> >> [ 1.550669] Call Trace:
> >> [ 1.550675] [<ffffffff8173db46>] dump_stack+0x46/0x58
> >> [ 1.550679] [<ffffffff81094d41>] warn_slowpath_common+0x81/0xa0
> >> [ 1.550681] [<ffffffff81094e5a>] warn_slowpath_null+0x1a/0x20
> >> [ 1.550683] [<ffffffff813b2864>] pci_bus_read_dev_vendor_id+0x1d4/0x1e0
> >> [ 1.550687] [<ffffffff813b7c3e>] pci_device_is_present+0x2e/0x50
> >> [ 1.550693] [<ffffffffa003364f>] tg3_chip_reset+0x2f/0x940 [tg3]
> >> [ 1.550697] [<ffffffffa0033f9f>] tg3_halt+0x3f/0x1e0 [tg3]
> >> [ 1.550701] [<ffffffffa0044f83>] tg3_init_one+0xb83/0x1a40 [tg3]
> >
> > So does it work if you use a non-zero crs_timeout? The driver has
> > called tg3_halt() which may affect configuration read responses. I need
> > to check with the hardware team to see if the 5722 will return CRS in
> > this scenario.
>
> Any updates from the hardware team?
>
> This is a pretty serious regression, but as far as I can tell, it is
> not a PCI bug. The device should respond to a config read of vendor
> ID. If the driver does something that make the read return CRS
> status, I think the driver is responsible for doing whatever delay or
> other fixup is required.
>
> I'm inclined to reassign this bug to the tg3 driver unless you think
> the PCI core is doing something wrong here.
>
> Bjorn
We were not able to reproduce this issue, could you please check what is
the value of reg 0x70, before the pci_device_is_present call is made ?
if bit 15 is set config access will be retried.
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -9025,6 +9025,7 @@ static int tg3_chip_reset(struct tg3 *tp)
void (*write_op)(struct tg3 *, u32, u32);
int i, err;
+ printk(KERN_ERR "config state: %x\n", tr32(TG3PCI_PCISTATE));
if (!pci_device_is_present(tp->pdev))
return -ENODEV;
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: John Fastabend @ 2014-12-18 19:21 UTC (permalink / raw)
To: Roopa Prabhu, Varlese, Marco
Cc: netdev@vger.kernel.org, Thomas Graf, Jiri Pirko,
sfeldma@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <54931969.7040209@cumulusnetworks.com>
On 12/18/2014 10:14 AM, Roopa Prabhu wrote:
> On 12/18/14, 10:02 AM, Varlese, Marco wrote:
>> Removed unnecessary content for ease of reading...
>>
>>>>>>>> +/* Switch Port Attributes section */
>>>>>>>> +
>>>>>>>> +enum {
>>>>>>>> + IFLA_ATTR_UNSPEC,
>>>>>>>> + IFLA_ATTR_LEARNING,
>>>>>>> Any reason you want learning here ?. This is covered as part of
>>>>>>> the bridge setlink attributes.
>>>>>>>
>>>>>> Yes, because the user may _not_ want to go through a bridge
>>>>>> interface
>>>>> necessarily.
>>>>> But, the bridge setlink/getlink interface was changed to accommodate
>>> 'self'
>>>>> for exactly such cases.
>>>>> I kind of understand your case for the other attributes (these are
>>>>> per port settings that switch asics provide).
>>>>>
>>>>> However, i don't understand the reason to pull in bridge attributes here.
>>>>>
>>>> Maybe, I am missing something so you might help. The learning attribute -
>>> in my case - it is like all other attributes: a port attribute (as you said, port
>>> settings that the switch provides per port).
>>>> So, what I was saying is "why the user shall go through a bridge to configure
>>> the learning attribute"? From my perspective, it is as any other attribute and
>>> as such configurable on the port.
>>>
>>> Thinking about this some more, i don't see why any of these attributes
>>> (except loopback. I dont understand the loopback attribute) cant be part of
>>> the birdge port attributes.
>>>
>>> With this we will end up adding l2 attributes in two places: the general link
>>> attributes and bridge attributes.
>>>
>>> And since we have gone down the path of using ndo_bridge_setlink/getlink
>>> with 'self'....we should stick to that for all l2 attributes.
>>>
>>> The idea of overloading ndo_bridge_set/getlink, was to have the same set of
>>> attributes but support both cases where the user wants to go through the
>>> bridge driver or directly to the switch port driver. So, you are not really going
>>> through the bridge driver if you use 'self' and ndo_bridge_setlink/getlink.
>>>
>> Roopa, one of the comments I got from Thomas Graf on my v1 patch
>> was that your patch and mine were supplementary ("I think Roopa's
>> patches are supplementary. Not all switchdev users will be backed
>> with a Linux Bridge. I therefore welcome your patches very
>> much")... I also understood by others that the patch made sense for
>> the same reason. I simply do not understand why these attributes
>> (and maybe others in the future) could not be configured directly
>> on a standard port but have to go through a bridge.
>>
> ok, i am very confused in that case. The whole moving of bridge
> attributes from the bridge driver to rtnetlink.c was to make the
> bridge attributes accessible to any driver who wants to set l2/bridge
> attributes on their switch ports. So, its unclear to me why we are
> doing this parallel thing again. This move to rtnetlink.c was done
> during the recent rocker support. so, maybe scott/jiri can elaborate
> more.
Not sure if this will add to the confusion or help. But you do not
need to have the bridge.ko loaded or netdev's attached to a bridge
to use the setlink/getlink ndo ops and netlink messages.
This was intentionally done. Its already used with NIC devices to
configure embedded bridge settings such as VEB/VEPA.
I think I'm just repeating Roopa though.
^ permalink raw reply
* Re: [bisected] tg3 broken in 3.18.0?
From: Bjorn Helgaas @ 2014-12-18 19:15 UTC (permalink / raw)
To: Michael Chan
Cc: Marcelo Ricardo Leitner, Rajat Jain, Nils Holland, David Miller,
netdev, linux-pci@vger.kernel.org, Rafael Wysocki,
Prashant Sreedharan
In-Reply-To: <1418759684.4248.12.camel@LTIRV-MCHAN1.corp.ad.broadcom.com>
On Tue, Dec 16, 2014 at 12:54 PM, Michael Chan <mchan@broadcom.com> wrote:
> On Tue, 2014-12-16 at 15:59 -0200, Marcelo Ricardo Leitner wrote:
>> It's a
>> 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722
>> Gigabit Ethernet PCI Express
>> over here
>>
>> I put a WARN_ON(1) after those printks, and this is what I got:
>>
>> [ 1.550640] pci 0000:02:00.0: 1st 1 1
>> [ 1.550643] pci 0000:02:00.0: crs_timeout: 0
>> [ 1.550645] ------------[ cut here ]------------
>> [ 1.550651] WARNING: CPU: 6 PID: 364 at drivers/pci/probe.c:1445 pci_bus_read_dev_vendor_id+0x1d4/0x1e0()
>> [ 1.550652] Modules linked in: i915(+) raid0 i2c_algo_bit drm_kms_helper drm e1000e(+) tg3(+) ptp pps_core video
>> [ 1.550660] CPU: 6 PID: 364 Comm: systemd-udevd Not tainted 3.18.0-rc6+ #8
>> [ 1.550661] Hardware name: Dell Inc. OptiPlex 9010/03K80F, BIOS A15 08/12/2013
>> [ 1.550662] 0000000000000000 000000004de2d8dc ffff8807eabdf948 ffffffff8173db46
>> [ 1.550665] 0000000000000000 0000000000000000 ffff8807eabdf988 ffffffff81094d41
>> [ 1.550667] ffff8807eabdf968 ffff8807f1e27000 0000000000000000 0000000000000000
>> [ 1.550669] Call Trace:
>> [ 1.550675] [<ffffffff8173db46>] dump_stack+0x46/0x58
>> [ 1.550679] [<ffffffff81094d41>] warn_slowpath_common+0x81/0xa0
>> [ 1.550681] [<ffffffff81094e5a>] warn_slowpath_null+0x1a/0x20
>> [ 1.550683] [<ffffffff813b2864>] pci_bus_read_dev_vendor_id+0x1d4/0x1e0
>> [ 1.550687] [<ffffffff813b7c3e>] pci_device_is_present+0x2e/0x50
>> [ 1.550693] [<ffffffffa003364f>] tg3_chip_reset+0x2f/0x940 [tg3]
>> [ 1.550697] [<ffffffffa0033f9f>] tg3_halt+0x3f/0x1e0 [tg3]
>> [ 1.550701] [<ffffffffa0044f83>] tg3_init_one+0xb83/0x1a40 [tg3]
>
> So does it work if you use a non-zero crs_timeout? The driver has
> called tg3_halt() which may affect configuration read responses. I need
> to check with the hardware team to see if the 5722 will return CRS in
> this scenario.
Any updates from the hardware team?
This is a pretty serious regression, but as far as I can tell, it is
not a PCI bug. The device should respond to a config read of vendor
ID. If the driver does something that make the read return CRS
status, I think the driver is responsible for doing whatever delay or
other fixup is required.
I'm inclined to reassign this bug to the tg3 driver unless you think
the PCI core is doing something wrong here.
Bjorn
^ permalink raw reply
* Re: [PATCH net] netlink: Don't reorder loads/stores before marking mmap netlink frame as available
From: Linus Torvalds @ 2014-12-18 19:13 UTC (permalink / raw)
To: Thomas Graf
Cc: Eric Dumazet, David Miller, Daniel Borkmann, Andy Lutomirski,
Patrick McHardy, Network Development
In-Reply-To: <20141218103026.GA16239@casper.infradead.org>
On Thu, Dec 18, 2014 at 2:30 AM, Thomas Graf <tgraf@suug.ch> wrote:
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index ef5f77b..2662821 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -550,9 +550,9 @@ static enum nl_mmap_status netlink_get_status(const struct nl_mmap_hdr *hdr)
> static void netlink_set_status(struct nl_mmap_hdr *hdr,
> enum nl_mmap_status status)
> {
> + smp_mb();
> hdr->nm_status = status;
> flush_dcache_page(pgvec_to_page(hdr));
> - smp_wmb();
> }
If this is performance-critical code (I have no idea), then a better
idea might be to use
smp_store_release(&hdr->nm_status, status);
instead of using explicit memory barriers. That's going to generally
be much cheaper than a memory barrier.
Linus
^ permalink raw reply
* Re: [PATCH net 2/2] geneve: Fix races between socket add and release.
From: Jesse Gross @ 2014-12-18 18:34 UTC (permalink / raw)
To: Thomas Graf; +Cc: David Miller, netdev, Andy Zhou, Stephen Hemminger
In-Reply-To: <20141217211513.GF28766@casper.infradead.org>
On Wed, Dec 17, 2014 at 1:15 PM, Thomas Graf <tgraf@suug.ch> wrote:
> On 12/17/14 at 10:48am, Jesse Gross wrote:
>> I generally agree (with the exception of kfree_rcu() - I believe that
>> is still needed since incoming packets reference it using RCU).
>
> I didn't inspect this in full detail but seems like the data path
> should only care about gs->sock which is properly refcnt'ed.
The data path (if you include the consumer in OVS), goes from sk to gs
to gs->rcv_data so it does care about the stuff that is being freed
here.
>> for destroying the socket. This was added by Stephen in "vxlan: listen
>> on multiple ports" but it's not obvious to me what problem it is
>> trying to avoid and I don't see a comment. If possible, it would be
>> nice to simplify this as well if the issue doesn't apply to Geneve.
>
> I don't have an explanation for that either. Each entry on the
> vni_list[] takes a vs->refcnt.
I don't think the workqueue is about refcounting - it looks to me like
the issue that is being avoided is either that RTNL is held and a
lower layer tries to take it again or another lock that nests in the
opposite way with RTNL. However, looking through the code, the problem
wasn't obvious to me.
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Roopa Prabhu @ 2014-12-18 18:14 UTC (permalink / raw)
To: Varlese, Marco
Cc: netdev@vger.kernel.org, Fastabend, John R, Thomas Graf,
Jiri Pirko, sfeldma@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <C4896FB061E7DE4AAC93031BDCA044B104ADA310@IRSMSX108.ger.corp.intel.com>
On 12/18/14, 10:02 AM, Varlese, Marco wrote:
> Removed unnecessary content for ease of reading...
>
>>>>>>> +/* Switch Port Attributes section */
>>>>>>> +
>>>>>>> +enum {
>>>>>>> + IFLA_ATTR_UNSPEC,
>>>>>>> + IFLA_ATTR_LEARNING,
>>>>>> Any reason you want learning here ?. This is covered as part of
>>>>>> the bridge setlink attributes.
>>>>>>
>>>>> Yes, because the user may _not_ want to go through a bridge
>>>>> interface
>>>> necessarily.
>>>> But, the bridge setlink/getlink interface was changed to accommodate
>> 'self'
>>>> for exactly such cases.
>>>> I kind of understand your case for the other attributes (these are
>>>> per port settings that switch asics provide).
>>>>
>>>> However, i don't understand the reason to pull in bridge attributes here.
>>>>
>>> Maybe, I am missing something so you might help. The learning attribute -
>> in my case - it is like all other attributes: a port attribute (as you said, port
>> settings that the switch provides per port).
>>> So, what I was saying is "why the user shall go through a bridge to configure
>> the learning attribute"? From my perspective, it is as any other attribute and
>> as such configurable on the port.
>>
>> Thinking about this some more, i don't see why any of these attributes
>> (except loopback. I dont understand the loopback attribute) cant be part of
>> the birdge port attributes.
>>
>> With this we will end up adding l2 attributes in two places: the general link
>> attributes and bridge attributes.
>>
>> And since we have gone down the path of using ndo_bridge_setlink/getlink
>> with 'self'....we should stick to that for all l2 attributes.
>>
>> The idea of overloading ndo_bridge_set/getlink, was to have the same set of
>> attributes but support both cases where the user wants to go through the
>> bridge driver or directly to the switch port driver. So, you are not really going
>> through the bridge driver if you use 'self' and ndo_bridge_setlink/getlink.
>>
> Roopa, one of the comments I got from Thomas Graf on my v1 patch was that your patch and mine were supplementary ("I think Roopa's patches are supplementary. Not all switchdev users will be backed with a Linux Bridge. I therefore welcome your patches very much")... I also understood by others that the patch made sense for the same reason. I simply do not understand why these attributes (and maybe others in the future) could not be configured directly on a standard port but have to go through a bridge.
>
ok, i am very confused in that case. The whole moving of bridge
attributes from the bridge driver to rtnetlink.c was to make the bridge
attributes accessible to any driver who wants to set l2/bridge
attributes on their switch ports. So, its unclear to me why we are doing
this parallel thing again.
This move to rtnetlink.c was done during the recent rocker support. so,
maybe scott/jiri can elaborate more.
^ permalink raw reply
* RE: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Varlese, Marco @ 2014-12-18 18:02 UTC (permalink / raw)
To: Roopa Prabhu
Cc: netdev@vger.kernel.org, Fastabend, John R, Thomas Graf,
Jiri Pirko, sfeldma@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <549313B8.6050102@cumulusnetworks.com>
Removed unnecessary content for ease of reading...
> >>>>> +/* Switch Port Attributes section */
> >>>>> +
> >>>>> +enum {
> >>>>> + IFLA_ATTR_UNSPEC,
> >>>>> + IFLA_ATTR_LEARNING,
> >>>> Any reason you want learning here ?. This is covered as part of
> >>>> the bridge setlink attributes.
> >>>>
> >>> Yes, because the user may _not_ want to go through a bridge
> >>> interface
> >> necessarily.
> >> But, the bridge setlink/getlink interface was changed to accommodate
> 'self'
> >> for exactly such cases.
> >> I kind of understand your case for the other attributes (these are
> >> per port settings that switch asics provide).
> >>
> >> However, i don't understand the reason to pull in bridge attributes here.
> >>
> > Maybe, I am missing something so you might help. The learning attribute -
> in my case - it is like all other attributes: a port attribute (as you said, port
> settings that the switch provides per port).
> > So, what I was saying is "why the user shall go through a bridge to configure
> the learning attribute"? From my perspective, it is as any other attribute and
> as such configurable on the port.
>
> Thinking about this some more, i don't see why any of these attributes
> (except loopback. I dont understand the loopback attribute) cant be part of
> the birdge port attributes.
>
> With this we will end up adding l2 attributes in two places: the general link
> attributes and bridge attributes.
>
> And since we have gone down the path of using ndo_bridge_setlink/getlink
> with 'self'....we should stick to that for all l2 attributes.
>
> The idea of overloading ndo_bridge_set/getlink, was to have the same set of
> attributes but support both cases where the user wants to go through the
> bridge driver or directly to the switch port driver. So, you are not really going
> through the bridge driver if you use 'self' and ndo_bridge_setlink/getlink.
>
Roopa, one of the comments I got from Thomas Graf on my v1 patch was that your patch and mine were supplementary ("I think Roopa's patches are supplementary. Not all switchdev users will be backed with a Linux Bridge. I therefore welcome your patches very much")... I also understood by others that the patch made sense for the same reason. I simply do not understand why these attributes (and maybe others in the future) could not be configured directly on a standard port but have to go through a bridge.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: changes for wireless
From: John W. Linville @ 2014-12-18 17:58 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141218.124231.114306102839964827.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thu, Dec 18, 2014 at 12:42:31PM -0500, David Miller wrote:
> From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Date: Wed, 17 Dec 2014 12:07:05 -0500
>
> > http://marc.info/?l=linux-wireless&m=141883202530292&w=2
> >
> > This makes it official... :-)
> >
> > Signed-off-by: John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
>
> Applied, and thank you for all of your tireless work over the many
> years that you have maintained the wireless code.
>
> You have undoubtedly made my life easier and made things run much more
> smoothly than they otherwise would have, and for that I am eternally
> grateful.
>
> Thank you!
Thanks, Dave and everyone else, for the kind words of appreciation.
They are warmly received!
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
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: [PATCHv1 net] xen-netback: support frontends without feature-rx-notify again
From: David Vrabel @ 2014-12-18 17:55 UTC (permalink / raw)
To: David Miller; +Cc: netdev, xen-devel, ian.campbell, wei.liu2
In-Reply-To: <20141218.125009.1837191564956948256.davem@davemloft.net>
On 18/12/14 17:50, David Miller wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Thu, 18 Dec 2014 11:13:06 +0000
>
>> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
>> feature-rx-notify mandatory) incorrectly assumed that there were no
>> frontends in use that did not support this feature. But the frontend
>> driver in MiniOS does not and since this is used by (qemu) stubdoms,
>> these stopped working.
>>
>> Netback sort of works as-is in this mode except:
>>
>> - If there are no Rx requests and the internal Rx queue fills, only
>> the drain timeout will wake the thread. The default drain timeout
>> of 10 s would give unacceptable pauses.
>>
>> - If an Rx stall was detected and the internal Rx queue is drained,
>> then the Rx thread would never wake.
>>
>> Handle these two cases (when feature-rx-notify is disabled) by:
>>
>> - Reducing the drain timeout to 30 ms.
>>
>> - Disabling Rx stall detection.
>>
>> Reported-by: John <jw@nuclearfallout.net>
>> Tested-by: John <jw@nuclearfallout.net>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>
> Applied, and I assume that 3.18 -stable needs this as well?
Yes, please. Without it, netback just doesn't work with an important
use case.
Thanks.
David
^ permalink raw reply
* Re: [PATCH net] be2net: Fix incorrect setting of tunnel offload flag in netdev features
From: David Miller @ 2014-12-18 17:51 UTC (permalink / raw)
To: sriharsha.basavapatna; +Cc: netdev
In-Reply-To: <1418963418-18792-1-git-send-email-sriharsha.basavapatna@emulex.com>
From: Sriharsha Basavapatna <sriharsha.basavapatna@emulex.com>
Date: Fri, 19 Dec 2014 10:00:18 +0530
> An earlier commit to resolve an issue with encapsulation offloads missed
> setting a bit in the outer netdev features flag. This results in loss of TSO
> feature on a VxLAN interface.
>
> Fixes: 630f4b70 ("Export tunnel offloads only when a VxLAN tunnel is created")
>
> Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] bnx2x: fix typos in "configure"
From: David Miller @ 2014-12-18 17:50 UTC (permalink / raw)
To: jbenc; +Cc: netdev, ariel.elior
In-Reply-To: <fcb186d22a0f6a2e3b07a6a88baebbada6742003.1418889837.git.jbenc@redhat.com>
From: Jiri Benc <jbenc@redhat.com>
Date: Thu, 18 Dec 2014 09:04:35 +0100
> Noticed when debugging ptp.
>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
Applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCHv1 net] xen-netback: support frontends without feature-rx-notify again
From: David Miller @ 2014-12-18 17:50 UTC (permalink / raw)
To: david.vrabel; +Cc: netdev, xen-devel, ian.campbell, wei.liu2
In-Reply-To: <1418901186-14478-1-git-send-email-david.vrabel@citrix.com>
From: David Vrabel <david.vrabel@citrix.com>
Date: Thu, 18 Dec 2014 11:13:06 +0000
> Commit bc96f648df1bbc2729abbb84513cf4f64273a1f1 (xen-netback: make
> feature-rx-notify mandatory) incorrectly assumed that there were no
> frontends in use that did not support this feature. But the frontend
> driver in MiniOS does not and since this is used by (qemu) stubdoms,
> these stopped working.
>
> Netback sort of works as-is in this mode except:
>
> - If there are no Rx requests and the internal Rx queue fills, only
> the drain timeout will wake the thread. The default drain timeout
> of 10 s would give unacceptable pauses.
>
> - If an Rx stall was detected and the internal Rx queue is drained,
> then the Rx thread would never wake.
>
> Handle these two cases (when feature-rx-notify is disabled) by:
>
> - Reducing the drain timeout to 30 ms.
>
> - Disabling Rx stall detection.
>
> Reported-by: John <jw@nuclearfallout.net>
> Tested-by: John <jw@nuclearfallout.net>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Applied, and I assume that 3.18 -stable needs this as well?
Thanks.
^ permalink raw reply
* Re: [PATCH 01/10] core: Split out UFO6 support
From: Michael S. Tsirkin @ 2014-12-18 17:50 UTC (permalink / raw)
To: Vlad Yasevich
Cc: netdev, Vladislav Yasevich, virtualization, stefanha, ben,
David Miller
In-Reply-To: <20141218173546.GB5425@redhat.com>
On Thu, Dec 18, 2014 at 07:35:46PM +0200, Michael S. Tsirkin wrote:
> > > We should either generate our own ID,
> > > like we always did, or make sure we don't accept
> > > these packets.
> > > Second option is almost sure to break userspace,
> > > so it seems we must do the first one.
> > >
> >
> > Right. This was missing from packet sockets. I can fix it.
> >
> > -vlad
>
> Also, this can't be a patch on top, since we don't
> want bisect to give us configurations which
> can BUG().
So how doing this in stages:
1. add helper that checks skb GSO type.
If it is SKB_GSO_UDP, check for IPv6, and
generate the fragment ID.
Call this helper in
- virtio net rx path
- tun rx path (get user)
- macvtap tx patch (get user)
- packet socket tx patch (get user)
2. Put back UFO flag everywhere: virtio,tun,macvtap,packet,
since we can handle IPv6 now even if it's suboptimal.
Above two seem like smalling patches, appropriate for stable.
Next, work on a new feature to pass
fragment ID in virtio header:
3. split UFO/UFO6 as you did here, but add code
in above 4 places to convert UDP to UDP6,
additionally, add code in
- virtio net tx path
- tun tx path (get user)
- macvtap rx patch (put user)
- packet socket rx patch (put user)
to convert UDP6 to UDP.
step 3 needs to be bisect-clean, somehow.
4. add new field in header, new feature bit for virtio net to gate it,
new ioctls to tun,macvtap,packet socket.
These two are more like optimizations, so not stable material.
--
MST
^ permalink raw reply
* Re: [RFC PATCH net-next v2 1/1] net: Support for switch port configuration
From: Roopa Prabhu @ 2014-12-18 17:49 UTC (permalink / raw)
To: Varlese, Marco
Cc: netdev@vger.kernel.org, Fastabend, John R, Thomas Graf,
Jiri Pirko, sfeldma@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <C4896FB061E7DE4AAC93031BDCA044B104ADA16F@IRSMSX108.ger.corp.intel.com>
On 12/18/14, 9:25 AM, Varlese, Marco wrote:
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Roopa Prabhu
>> Sent: Thursday, December 18, 2014 3:16 PM
>> To: Varlese, Marco
>> Cc: netdev@vger.kernel.org; Fastabend, John R; Thomas Graf; Jiri Pirko;
>> sfeldma@gmail.com; linux-kernel@vger.kernel.org
>> Subject: Re: [RFC PATCH net-next v2 1/1] net: Support for switch port
>> configuration
>>
>> On 12/18/14, 6:55 AM, Varlese, Marco wrote:
>>>> -----Original Message-----
>>>> From: Roopa Prabhu [mailto:roopa@cumulusnetworks.com]
>>>> Sent: Thursday, December 18, 2014 2:45 PM
>>>> To: Varlese, Marco
>>>> Cc: netdev@vger.kernel.org; Fastabend, John R; Thomas Graf; Jiri
>>>> Pirko; sfeldma@gmail.com; linux-kernel@vger.kernel.org
>>>> Subject: Re: [RFC PATCH net-next v2 1/1] net: Support for switch port
>>>> configuration
>>>>
>>>> On 12/18/14, 3:29 AM, Varlese, Marco wrote:
>>>>> From: Marco Varlese <marco.varlese@intel.com>
>>>>>
>>>>> Switch hardware offers a list of attributes that are configurable on
>>>>> a per port basis.
>>>>> This patch provides a mechanism to configure switch ports by adding
>>>>> an NDO for setting specific values to specific attributes.
>>>>> There will be a separate patch that adds the "get" functionality via
>>>>> another NDO and another patch that extends iproute2 to call the two
>>>>> new NDOs.
>>>>>
>>>>> Signed-off-by: Marco Varlese <marco.varlese@intel.com>
>>>>> ---
>>>>> include/linux/netdevice.h | 5 ++++
>>>>> include/uapi/linux/if_link.h | 15 ++++++++++++
>>>>> net/core/rtnetlink.c | 54
>>>> ++++++++++++++++++++++++++++++++++++++++++++
>>>>> 3 files changed, 74 insertions(+)
>>>>>
>>>>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>>>> index c31f74d..4881c7b 100644
>>>>> --- a/include/linux/netdevice.h
>>>>> +++ b/include/linux/netdevice.h
>>>>> @@ -1027,6 +1027,9 @@ typedef u16 (*select_queue_fallback_t)(struct
>>>> net_device *dev,
>>>>> * int (*ndo_switch_port_stp_update)(struct net_device *dev, u8
>> state);
>>>>> * Called to notify switch device port of bridge port STP
>>>>> * state change.
>>>>> + * int (*ndo_switch_port_set_cfg)(struct net_device *dev,
>>>>> + * u32 attr, u64 value);
>>>>> + * Called to set specific switch ports attributes.
>>>>> */
>>>>> struct net_device_ops {
>>>>> int (*ndo_init)(struct net_device *dev);
>>>>> @@ -1185,6 +1188,8 @@ struct net_device_ops {
>>>>> struct
>>>> netdev_phys_item_id *psid);
>>>>> int (*ndo_switch_port_stp_update)(struct
>>>> net_device *dev,
>>>>> u8 state);
>>>>> + int (*ndo_switch_port_set_cfg)(struct
>>>> net_device *dev,
>>>>> + u32 attr, u64 value);
>>>>> #endif
>>>>> };
>>>>>
>>>>> diff --git a/include/uapi/linux/if_link.h
>>>>> b/include/uapi/linux/if_link.h index f7d0d2d..19cb51a 100644
>>>>> --- a/include/uapi/linux/if_link.h
>>>>> +++ b/include/uapi/linux/if_link.h
>>>>> @@ -146,6 +146,7 @@ enum {
>>>>> IFLA_PHYS_PORT_ID,
>>>>> IFLA_CARRIER_CHANGES,
>>>>> IFLA_PHYS_SWITCH_ID,
>>>>> + IFLA_SWITCH_PORT_CFG,
>>>>> __IFLA_MAX
>>>>> };
>>>>>
>>>>> @@ -603,4 +604,18 @@ enum {
>>>>>
>>>>> #define IFLA_HSR_MAX (__IFLA_HSR_MAX - 1)
>>>>>
>>>>> +/* Switch Port Attributes section */
>>>>> +
>>>>> +enum {
>>>>> + IFLA_ATTR_UNSPEC,
>>>>> + IFLA_ATTR_LEARNING,
>>>> Any reason you want learning here ?. This is covered as part of the
>>>> bridge setlink attributes.
>>>>
>>> Yes, because the user may _not_ want to go through a bridge interface
>> necessarily.
>> But, the bridge setlink/getlink interface was changed to accommodate 'self'
>> for exactly such cases.
>> I kind of understand your case for the other attributes (these are per port
>> settings that switch asics provide).
>>
>> However, i don't understand the reason to pull in bridge attributes here.
>>
> Maybe, I am missing something so you might help. The learning attribute - in my case - it is like all other attributes: a port attribute (as you said, port settings that the switch provides per port).
> So, what I was saying is "why the user shall go through a bridge to configure the learning attribute"? From my perspective, it is as any other attribute and as such configurable on the port.
Thinking about this some more, i don't see why any of these attributes
(except loopback. I dont understand the loopback attribute)
cant be part of the birdge port attributes.
With this we will end up adding l2 attributes in two places: the general
link attributes and bridge attributes.
And since we have gone down the path of using ndo_bridge_setlink/getlink
with 'self'....we should stick to that for all l2 attributes.
The idea of overloading ndo_bridge_set/getlink, was to have the same set
of attributes but support both cases where the user wants to go through
the bridge driver or directly to the switch port driver. So, you are not
really going through the bridge driver if you use 'self' and
ndo_bridge_setlink/getlink.
>>>>> + IFLA_ATTR_LOOPBACK,
>>>>> + IFLA_ATTR_BCAST_FLOODING,
>>>>> + IFLA_ATTR_UCAST_FLOODING,
>>>>> + IFLA_ATTR_MCAST_FLOODING,
>>>>> + __IFLA_ATTR_MAX
>>>>> +};
>>>>> +
>>>>> +#define IFLA_ATTR_MAX (__IFLA_ATTR_MAX - 1)
>>>>> +
>>>>> #endif /* _UAPI_LINUX_IF_LINK_H */ diff --git
>>>>> a/net/core/rtnetlink.c b/net/core/rtnetlink.c index
>>>>> eaa057f..c0d1c45 100644
>>>>> --- a/net/core/rtnetlink.c
>>>>> +++ b/net/core/rtnetlink.c
>>>>> @@ -1389,6 +1389,46 @@ static int validate_linkmsg(struct net_device
>>>> *dev, struct nlattr *tb[])
>>>>> return 0;
>>>>> }
>>>>>
>>>>> +#ifdef CONFIG_NET_SWITCHDEV
>>>>> +static int do_setswcfg(struct net_device *dev, struct nlattr *attr) {
>>>>> + int rem, err = -EINVAL;
>>>>> + struct nlattr *v;
>>>>> + const struct net_device_ops *ops = dev->netdev_ops;
>>>>> +
>>>>> + nla_for_each_nested(v, attr, rem) {
>>>>> + u32 op = nla_type(v);
>>>>> + u64 value = 0;
>>>>> +
>>>>> + switch (op) {
>>>>> + case IFLA_ATTR_LEARNING:
>>>>> + case IFLA_ATTR_LOOPBACK:
>>>>> + case IFLA_ATTR_BCAST_FLOODING:
>>>>> + case IFLA_ATTR_UCAST_FLOODING:
>>>>> + case IFLA_ATTR_MCAST_FLOODING: {
>>>>> + if (nla_len(v) < sizeof(value)) {
>>>>> + err = -EINVAL;
>>>>> + break;
>>>>> + }
>>>>> +
>>>>> + value = nla_get_u64(v);
>>>>> + err = ops->ndo_switch_port_set_cfg(dev,
>>>>> + op,
>>>>> + value);
>>>>> + break;
>>>>> + }
>>>>> + default:
>>>>> + err = -EINVAL;
>>>>> + break;
>>>>> + }
>>>>> + if (err)
>>>>> + break;
>>>>> + }
>>>>> + return err;
>>>>> +}
>>>>> +
>>>>> +#endif
>>>>> +
>>>>> static int do_setvfinfo(struct net_device *dev, struct nlattr *attr)
>>>>> {
>>>>> int rem, err = -EINVAL;
>>>>> @@ -1740,6 +1780,20 @@ static int do_setlink(const struct sk_buff *skb,
>>>>> status |= DO_SETLINK_NOTIFY;
>>>>> }
>>>>> }
>>>>> +#ifdef CONFIG_NET_SWITCHDEV
>>>>> + if (tb[IFLA_SWITCH_PORT_CFG]) {
>>>>> + err = -EOPNOTSUPP;
>>>>> + if (!ops->ndo_switch_port_set_cfg)
>>>>> + goto errout;
>>>>> + if (!ops->ndo_switch_parent_id_get)
>>>>> + goto errout;
>>>>> + err = do_setswcfg(dev, tb[IFLA_SWITCH_PORT_CFG]);
>>>>> + if (err < 0)
>>>>> + goto errout;
>>>>> +
>>>>> + status |= DO_SETLINK_NOTIFY;
>>>>> + }
>>>>> +#endif
>>>>> err = 0;
>>>>>
>>>>> errout:
>>> --
>>> 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
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in the body
>> of a message to majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] enic: fix rx skb checksum
From: David Miller @ 2014-12-18 17:49 UTC (permalink / raw)
To: jay.vosburgh
Cc: eric.dumazet, _govind, netdev, ssujith, benve, jbenc, sassmann
In-Reply-To: <17951.1418924367@famine>
From: Jay Vosburgh <jay.vosburgh@canonical.com>
Date: Thu, 18 Dec 2014 09:39:27 -0800
> @@ -1694,6 +1694,7 @@ int __dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
>
> skb_scrub_packet(skb, true);
> skb->protocol = eth_type_trans(skb, dev);
> + skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);
>
> return 0;
> }
>
> I'd very much appreciate comments from someone who knows the
> checksum logic better than I do as to whether this is a reasonable thing
> to do.
This looks quite reasonable to me.
^ permalink raw reply
* Re: [PATCH v2 0/6] net-PPP: Deletion of a few unnecessary checks
From: SF Markus Elfring @ 2014-12-18 17:44 UTC (permalink / raw)
To: David Miller
Cc: Sergei Shtylyov, Paul Mackerras, linux-ppp, netdev, Eric Dumazet,
linux-kernel, kernel-janitors, Julia Lawall
In-Reply-To: <20141218.122556.2148647081075440879.davem@davemloft.net>
>> Now I find still that your data reorgansisation wish can not be resolved
>> in a simple way.
>
> I'm saying to leave the code alone.
It seems that there might be a misunderstanding between us.
> If it goes:
>
> var = foo_that_returns_ptr_err()
> if (IS_ERR(var))
> return PTR_ERR(var);
>
> p->bar = var;
>
> or whatever, simply keep it that way!
A simple return was not used by the mppe_alloc() function so far because
a bit of memory clean-up will also be useful after error detection,
won't it?
> I'm not engaging in this conversation any further, you have already
> consumed way too much of my limited time on this incredibly trivial matter.
It can occasionally happen that a safe clarification of specific implementation
details will need more efforts than you would like to invest at the moment.
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: changes for wireless
From: David Miller @ 2014-12-18 17:42 UTC (permalink / raw)
To: linville; +Cc: netdev, linux-wireless
In-Reply-To: <1418836025-9035-1-git-send-email-linville@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 17 Dec 2014 12:07:05 -0500
> http://marc.info/?l=linux-wireless&m=141883202530292&w=2
>
> This makes it official... :-)
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Applied, and thank you for all of your tireless work over the many
years that you have maintained the wireless code.
You have undoubtedly made my life easier and made things run much more
smoothly than they otherwise would have, and for that I am eternally
grateful.
Thank you!
^ permalink raw reply
* Re: [PATCH net] cxgb4: Fix decoding QSA module for ethtool get settings
From: David Miller @ 2014-12-18 17:39 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, nirranjan
In-Reply-To: <1418817960-17277-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Wed, 17 Dec 2014 17:36:00 +0530
> QSA module was getting decoded as QSFP module in ethtool get settings, this
> patch fixes it.
>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] enic: fix rx skb checksum
From: Jay Vosburgh @ 2014-12-18 17:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: Govindarajulu Varadarajan, davem, netdev, ssujith, benve,
Jiri Benc, Stefan Assmann
In-Reply-To: <1418920017.9773.80.camel@edumazet-glaptop2.roam.corp.google.com>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
>On Thu, 2014-12-18 at 15:58 +0530, Govindarajulu Varadarajan wrote:
>> Hardware always provides compliment of IP pseudo checksum. Stack expects
>> whole packet checksum without pseudo checksum if CHECKSUM_COMPLETE is set.
>>
>> This causes checksum error in nf & ovs.
>>
>> kernel: qg-19546f09-f2: hw csum failure
>> kernel: CPU: 9 PID: 0 Comm: swapper/9 Tainted: GF O-------------- 3.10.0-123.8.1.el7.x86_64 #1
>> kernel: Hardware name: Cisco Systems Inc UCSB-B200-M3/UCSB-B200-M3, BIOS B200M3.2.2.3.0.080820141339 08/08/2014
>> kernel: ffff881218f40000 df68243feb35e3a8 ffff881237a43ab8 ffffffff815e237b
>> kernel: ffff881237a43ad0 ffffffff814cd4ca ffff8829ec71eb00 ffff881237a43af0
>> kernel: ffffffff814c6232 0000000000000286 ffff8829ec71eb00 ffff881237a43b00
>> kernel: Call Trace:
>> kernel: <IRQ> [<ffffffff815e237b>] dump_stack+0x19/0x1b
>> kernel: [<ffffffff814cd4ca>] netdev_rx_csum_fault+0x3a/0x40
>> kernel: [<ffffffff814c6232>] __skb_checksum_complete_head+0x62/0x70
>> kernel: [<ffffffff814c6251>] __skb_checksum_complete+0x11/0x20
>> kernel: [<ffffffff8155a20c>] nf_ip_checksum+0xcc/0x100
>> kernel: [<ffffffffa049edc7>] icmp_error+0x1f7/0x35c [nf_conntrack_ipv4]
>> kernel: [<ffffffff814cf419>] ? netif_rx+0xb9/0x1d0
>> kernel: [<ffffffffa040eb7b>] ? internal_dev_recv+0xdb/0x130 [openvswitch]
>> kernel: [<ffffffffa04c8330>] nf_conntrack_in+0xf0/0xa80 [nf_conntrack]
>> kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
>> kernel: [<ffffffffa049e302>] ipv4_conntrack_in+0x22/0x30 [nf_conntrack_ipv4]
>> kernel: [<ffffffff815005ca>] nf_iterate+0xaa/0xc0
>> kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
>> kernel: [<ffffffff81500664>] nf_hook_slow+0x84/0x140
>> kernel: [<ffffffff81509380>] ? inet_del_offload+0x40/0x40
>> kernel: [<ffffffff81509dd4>] ip_rcv+0x344/0x380
>>
>> Hardware verifies IP & tcp/udp header checksum but does not provide payload
>> checksum, use CHECKSUM_UNNECESSARY. Set it only if its valid IP tcp/udp packet.
>>
>> Cc: Jiri Benc <jbenc@redhat.com>
>> Cc: Stefan Assmann <sassmann@redhat.com>
>> Reported-by: Sunil Choudhary <schoudha@redhat.com>
>> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
>> ---
>> drivers/net/ethernet/cisco/enic/enic_main.c | 12 ++++++++----
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
>> index 868d0f6..705f334 100644
>> --- a/drivers/net/ethernet/cisco/enic/enic_main.c
>> +++ b/drivers/net/ethernet/cisco/enic/enic_main.c
>> @@ -1060,10 +1060,14 @@ static void enic_rq_indicate_buf(struct vnic_rq *rq,
>> PKT_HASH_TYPE_L4 : PKT_HASH_TYPE_L3);
>> }
>>
>> - if ((netdev->features & NETIF_F_RXCSUM) && !csum_not_calc) {
>> - skb->csum = htons(checksum);
>> - skb->ip_summed = CHECKSUM_COMPLETE;
>> - }
>> + /* Hardware does not provide whole packet checksum. It only
>> + * provides pseudo checksum. Since hw validates the packet
>> + * checksum but not provide us the checksum value. use
>> + * CHECSUM_UNNECESSARY.
>> + */
>> + if ((netdev->features & NETIF_F_RXCSUM) && tcp_udp_csum_ok &&
>> + ipv4_csum_ok)
>> + skb->ip_summed = CHECKSUM_UNNECESSARY;
>>
>> if (vlan_stripped)
>> __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan_tci);
>
>Hmm.. this looks like CHECKSUM_COMPLETE could be kept for tunneling
>cases.
>
>Check commit f8c6455bb04b944e ("net/mlx4_en: Extend checksum offloading
>by CHECKSUM COMPLETE") for a start.
I've actually been looking into this "hw csum failure" (as it
appears with OVS and VXLAN) the last couple of days, and, at least on
the sky2 hardware I have, the problem doesn't appear to be the
hardware's CHECKSUM_COMPLETE checksumming. Instead, it appears that
when the encapsulated packet is decapsulated and forwarded to the guest
or container, the checksum isn't updated for the encapsulated ethernet
header. eth_type_trans does a pull for the ethernet header, but
skb->csum isn't updated.
I'm testing this patch, and it resolves the problem for me, but
I'm not yet entirely sure whether breaks something else:
diff --git a/net/core/dev.c b/net/core/dev.c
index f411c28..df755e5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1694,6 +1694,7 @@ int __dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
skb_scrub_packet(skb, true);
skb->protocol = eth_type_trans(skb, dev);
+ skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);
return 0;
}
I'd very much appreciate comments from someone who knows the
checksum logic better than I do as to whether this is a reasonable thing
to do.
I've also not tested it on enic hardware. Govindarajulu, would
you be able to test this against the unmodified enic driver and see if
it resolves the problem for you?
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply related
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