- 08 Dec, 2016 27 commits
-
-
Nicolas Dichtel authored
BugLink: http://bugs.launchpad.net/bugs/1593235 The function gretap_fb_dev_create() (only used by ovs) never calls rtnl_configure_link(). The consequence is that dev->rtnl_link_state is never set to RTNL_LINK_INITIALIZED. During the deletion phase, the function rollback_registered_many() sends a RTM_DELLINK only if dev->rtnl_link_state is set to RTNL_LINK_INITIALIZED. Fixes: b2acd1dc ("openvswitch: Use regular GRE net_device instead of vport") CC: Thomas Graf <tgraf@suug.ch> CC: Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit da6f1da8) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
Thadeu Lima de Souza Cascardo <thadeu.cascardo@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Nicolas Dichtel authored
BugLink: http://bugs.launchpad.net/bugs/1593235 The function vxlan_dev_create() (only used by ovs) never calls rtnl_configure_link(). The consequence is that dev->rtnl_link_state is never set to RTNL_LINK_INITIALIZED. During the deletion phase, the function rollback_registered_many() sends a RTM_DELLINK only if dev->rtnl_link_state is set to RTNL_LINK_INITIALIZED. Note that the function vxlan_dev_create() is moved after the rtnl stuff so that vxlan_dellink() can be called in this function. Fixes: dcc38c03 ("openvswitch: Re-add CONFIG_OPENVSWITCH_VXLAN") CC: Thomas Graf <tgraf@suug.ch> CC: Pravin B Shelar <pshelar@nicira.com> Signed-off-by:
-
Nicolas Dichtel authored
BugLink: http://bugs.launchpad.net/bugs/1593235 After ipgre_newlink()/geneve_configure() call, the netdev is registered. Fixes: 7e059158 ("vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices") CC: David Wragg <david@weave.works> Signed-off-by:
-
Jiri Olsa authored
BugLink: http://bugs.launchpad.net/bugs/1648088 Frank reported kernel panic when he disabled several cores in BIOS via following option: Core Disable Bitmap(Hex) [0] with number 0xFFE, which leaves 16 CPUs in system (out of 48). The kernel panic below goes along with following messages: smpboot: Max logical packages: 2^M smpboot: APIC(0) Converting physical 0 to logical package 0^M smpboot: APIC(20) Converting physical 1 to logical package 1^M smpboot: APIC(40) Package 2 exceeds logical package map^M smpboot: CPU 8 APICId 40 disabled^M smpboot: APIC(60) Package 3 exceeds logical package map^M smpboot: CPU 12 APICId 60 disabled^M ... general protection fault: 0000 [#1] SMP^M Modules linked in:^M CPU: 15 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc5+ #1^M Hardware name: SGI UV300/UV300, BIOS SGI UV 300 series BIOS 05/25/2016^M task: ffff8801673e0000 ti: ffff8801673ac000 task.ti: ffff8801673ac000^M RIP: 0010:[<ffffffff81014d54>] [<ffffffff81014d54>] uncore_change_context+0xd4/0x180^M ... [<ffffffff810158ac>] uncore_event_init_cpu+0x6c/0x70^M [<ffffffff81d8c91c>] intel_uncore_init+0x1c2/0x2dd^M [<ffffffff81d8c75a>] ? uncore_cpu_setup+0x17/0x17^M [<ffffffff81002190>] do_one_initcall+0x50/0x190^M [<ffffffff810ab193>] ? parse_args+0x293/0x480^M [<ffffffff81d87365>] kernel_init_freeable+0x1a5/0x249^M [<ffffffff81d86a35>] ? set_debug_rodata+0x12/0x12^M [<ffffffff816dc19e>] kernel_init+0xe/0x110^M [<ffffffff816e93bf>] ret_from_fork+0x1f/0x40^M [<ffffffff816dc190>] ? rest_init+0x80/0x80^M The reason for the panic is wrong value of __max_logical_packages, which lets logical_package_map uninitialized and the uncore code relying on this map being properly initialized (maybe we should add some safety checks there as well). The __max_logical_packages is computed as: DIV_ROUND_UP(total_cpus, ncpus); - ncpus being number of cores With above BIOS setup we get total_cpus == 16 which set __max_logical_packages to 2 (ncpus is 12). Once topology_update_package_map processes CPU with logical pkg over 2 we display above messages and fail to initialize the physical_to_logical_pkg map, which makes the uncore code crash. The fix is to remove logical_package_map bitmap completely and keep and update the logical_packages number instead. After we enumerate all the present CPUs, we check if the enumerated logical packages count is within its computed maximum from BIOS data. If it's not the case, we set this maximum to the new enumerated value and freeze any new addition of logical packages. The freeze is because lot of init code like uncore/rapl/cqm depends on having maximum logical package value set to allocate their data, so we can't change it later on. Prarit Bhargava tested the patch and confirms that it solves the problem: From dmidecode: Core Count: 24 Core Enabled: 24 Thread Count: 48 Orig kernel boot log: [ 0.464981] smpboot: Max logical packages: 19 [ 0.469861] smpboot: APIC(0) Converting physical 0 to logical package 0 [ 0.477261] smpboot: APIC(40) Converting physical 1 to logical package 1 [ 0.484760] smpboot: APIC(80) Converting physical 2 to logical package 2 [ 0.492258] smpboot: APIC(c0) Converting physical 3 to logical package 3 1. nr_cpus=8, should stop enumerating in package 0: [ 0.533664] smpboot: APIC(0) Converting physical 0 to logical package 0 [ 0.539596] smpboot: Max logical packages: 19 2. max_cpus=8, should still enumerate all packages: [ 0.526494] smpboot: APIC(0) Converting physical 0 to logical package 0 [ 0.532428] smpboot: APIC(40) Converting physical 1 to logical package 1 [ 0.538456] smpboot: APIC(80) Converting physical 2 to logical package 2 [ 0.544486] smpboot: APIC(c0) Converting physical 3 to logical package 3 [ 0.550524] smpboot: Max logical packages: 19 3. nr_cpus=49 ( 2 socket + 1 core on 3rd socket), should stop enumerating in package 2: [ 0.521378] smpboot: APIC(0) Converting physical 0 to logical package 0 [ 0.527314] smpboot: APIC(40) Converting physical 1 to logical package 1 [ 0.533345] smpboot: APIC(80) Converting physical 2 to logical package 2 [ 0.539368] smpboot: Max logical packages: 19 4. maxcpus=49, should still enumerate all packages: [ 0.525591] smpboot: APIC(0) Converting physical 0 to logical package 0 [ 0.531525] smpboot: APIC(40) Converting physical 1 to logical package 1 [ 0.537547] smpboot: APIC(80) Converting physical 2 to logical package 2 [ 0.543579] smpboot: APIC(c0) Converting physical 3 to logical package 3 [ 0.549624] smpboot: Max logical packages: 19 5. kdump (nr_cpus=1) works as well. Reported-by:
Frank Ramsay <framsay@redhat.com> Tested-by:
Prarit Bhargava <prarit@redhat.com> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Reviewed-by:
Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20160815101700.GA30090@kravaSigned-off-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit 7b0501b1) Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Craig Magina authored
BugLink: https://launchpad.net/bugs/1625222 Ubuntu builds the uas and xhci-plat-hcd usb drivers as modules, these module are needed for d-i to use usb in the installer on the merlin platform. Signed-off-by:
Craig Magina <craig.magina@canonical.com> Acked-by:
-
Michal Schmidt authored
BugLink: http://bugs.launchpad.net/bugs/1616107 Since implementing VLAN filtering in commit 05cc5a39 ("bnx2x: add vlan filtering offload") bnx2x refuses to add a VLAN while the interface is down: # ip link add link enp3s0f0 enp3s0f0_10 type vlan id 10 RTNETLINK answers: Bad address and in dmesg (with bnx2x.debug=0x20): bnx2x: [bnx2x_vlan_rx_add_vid:12941(enp3s0f0)]Ignoring VLAN configuration the interface is down Other drivers have no problem with this. Fix this peculiar behavior in the following way: - Accept requests to add/kill VID regardless of the device state. Maintain the requested list of VIDs in the bp->vlan_reg list. - If the device is up, try to configure the VID list into the hardware. If we run out of VLAN credits or encounter a failure configuring an entry, fall back to accepting all VLANs. If we successfully configure all entries from the list, turn the fallback off. - Use the same code for reconfiguring VLANs during NIC load. Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Acked-by:
Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1646857 During a PCI error recovery, like the ones provoked by EEH in the ppc64 platform, all IO to the device must be blocked while the recovery is completed. Current 8250_pci implementation only suspends the port instead of detaching it, which doesn't prevent incoming accesses like TIOCMGET and TIOCMSET calls from reaching the device. Those end up racing with the EEH recovery, crashing it. Similar races were also observed when opening the device and when shutting it down during recovery. This patch implements a more robust IO blockage for the 8250_pci recovery by unregistering the port at the beginning of the procedure and re-adding it afterwards. Since the port is detached from the uart layer, we can be sure that no request will make through to the device during recovery. This is similar to the solution used by the JSM serial driver. I thank Peter Hurley <peter@hurleysoftware.com> for valuable input on this one over one year ago. Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from linux-next commit f209fa03) Signed-off-by:
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1645591 These devices are handled by vendor driver ubuntu/xr-usb-serial. Signed-off-by:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Acked-by:
-
Darren Wu authored
BugLink: https://launchpad.net/bugs/1645591 Add an interface for mode switching between RS232 and RS422/485. Signed-off-by:
Darren Wu <darren.wu@canonical.com> Signed-off-by:
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1645591 Import USB UART driver from https://www.exar.com/design-tools/software-drivers Product Family: USB UART Part Numbers: XR21V1410, XR21V1412, XR21V1414, XR21B1411, XR21B1420, XR21B1422, XR21B1424, XR22801, XR22802, XR22804 Operating system: Linux 3.6.x and newer Driver version: 1A Release date: January 2015 Signed-off-by:
-
Mauricio Faria de Oliveira authored
BugLink: http://bugs.launchpad.net/bugs/1633128 Use the DMA_ATTR_NO_WARN attribute for the dma_map_sg() call of the nvme driver that returns BLK_MQ_RQ_QUEUE_BUSY (not for BLK_MQ_RQ_QUEUE_ERROR). Link: http://lkml.kernel.org/r/1470092390-25451-4-git-send-email-mauricfo@linux.vnet.ibm.com Signed-off-by: Mauricio Faria de Oliveira <mauricfo at linux.vnet.ibm.com> Reviewed-by: Gabriel Krisman Bertazi <krisman at linux.vnet.ibm.com> Cc: Keith Busch <keith.busch at intel.com> Cc: Jens Axboe <axboe at fb.com> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org> Cc: Michael Ellerman <mpe at ellerman.id.au> Cc: Krzysztof Kozlowski <k.kozlowski at samsung.com> Signed-off-by: Andrew Morton <akpm at linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org> (back ported from commit 2b6b535d) Acked-by:
-
Mauricio Faria de Oliveira authored
BugLink: http://bugs.launchpad.net/bugs/1633128 Add support for the DMA_ATTR_NO_WARN attribute on powerpc iommu code. Link: http://lkml.kernel.org/r/1470092390-25451-3-git-send-email-mauricfo@linux.vnet.ibm.com Signed-off-by: Mauricio Faria de Oliveira <mauricfo at linux.vnet.ibm.com> Acked-by: Michael Ellerman <mpe at ellerman.id.au> Cc: Keith Busch <keith.busch at intel.com> Cc: Jens Axboe <axboe at fb.com> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org> Cc: Krzysztof Kozlowski <k.kozlowski at samsung.com> Signed-off-by: Andrew Morton <akpm at linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org> (back ported from commit af8a2498) Acked-by:
-
Mauricio Faria de Oliveira authored
BugLink: http://bugs.launchpad.net/bugs/1633128 Introduce the DMA_ATTR_NO_WARN attribute, and document it. Link: http://lkml.kernel.org/r/1470092390-25451-2-git-send-email-mauricfo@linux.vnet.ibm.com Signed-off-by: Mauricio Faria de Oliveira <mauricfo at linux.vnet.ibm.com> Cc: Keith Busch <keith.busch at intel.com> Cc: Jens Axboe <axboe at fb.com> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org> Cc: Michael Ellerman <mpe at ellerman.id.au> Cc: Krzysztof Kozlowski <k.kozlowski at samsung.com> Signed-off-by: Andrew Morton <akpm at linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org> (back ported from commit a9a62c93) Acked-by:
-
Ben Gamari authored
BugLink: http://bugs.launchpad.net/bugs/1571530 Here we introduce logic in alps_identify to set the ALPS_DUALPOINT flag for touchpad hardware responding to E7 report with 73 03 28, as is found in the Dell Latitude E7470. Tested-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
Ben Gamari <ben@smart-cactus.org> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> (cherry picked from commit aeaa881f) Signed-off-by:
Phidias Chiang <phidias.chiang@canonical.com> Acked-by:
-
Ben Gamari authored
BugLink: http://bugs.launchpad.net/bugs/1571530 The SS5 hardware can report this. Tested-by:
-
Ben Gamari authored
BugLink: http://bugs.launchpad.net/bugs/1571530 While a button is held SS5 hardware will give us single-finger packets with x, y, and pressure equal to zero. This causes annoying jumps in pointer position if a touch is released while the button is held. Handle this by claiming zero contacts to ensure that no position events are provided to the user. Reviewed-by:
Pali Rohár <pali.rohar@gmail.com> Tested-by:
-
Ben Gamari authored
BugLink: http://bugs.launchpad.net/bugs/1571530 Add touchstick support for the so-called SS5 hardware, which uses a variant of the SS4 protocol. Reviewed-by:
-
Gavin Shan authored
BugLink: http://bugs.launchpad.net/bugs/1645826 commit 59ae8c6d ("powerpc/eeh: Fix invalid cached PE primary bus") was wrongly backporting upstream commit a3aa256b: It should clear the PE's flag (EEH_PE_PRI_BUS) in full hotplug instead of partial hotplug scenario. This fixes the issue by clearing EEH_PE_PRI_BUS in full hotplug scenario only. Fixes: 59ae8c6d ("powerpc/eeh: Fix invalid cached PE primary bus") Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
-
Martin Schwidefsky authored
BugLink: http://bugs.launchpad.net/bugs/1644505 It is possible to specify a user offset for the TOD clock, e.g. +2 hours. The TOD clock will carry this offset even if the clock is synchronized with STP. This makes the time stamps acquired with get_sync_clock() useless as another LPAR migth use a different TOD offset. Use the PTFF instrution to get the TOD epoch difference and subtract it from the TOD clock value to get a physical timestamp. As the epoch difference contains the sync check delta as well the LPAR offset value to the physical clock needs to be refreshed after each clock synchronization. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit 40277891) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Martin Schwidefsky authored
BugLink: http://bugs.launchpad.net/bugs/1644505 The PTFF instruction is not a function of ETR, rename and move the PTFF definitions from etr.h to timex.h. Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
-
Martin Schwidefsky authored
BugLink: http://bugs.launchpad.net/bugs/1644505 The sync clock operation of the channel subsystem call for STP delivers the TOD clock difference as a result. Use this TOD clock difference instead of the difference between the TOD timestamps before and after the sync clock operation. Signed-off-by:
-
Luis Henriques authored
UBUNTU: [Config] Increase the NR_CPUS to 512 for amd64 to support systems with a large number of cores. BugLink: http://bugs.launchpad.net/bugs/1579205Signed-off-by:
-
Dan Streetman authored
BugLink: http://bugs.launchpad.net/bugs/1648449 The NVMe driver currently configures a single MSI/MSIX interrupt for its admin queue, then later after initializing the NVMe controller and detecting the number of queues the controller can handle, the driver releases its MSI/MSIX interrupt and immediately re-configures enough MSI/MSIX interrupts for all the queues. However, on Amazon AWS instances with passthrough NVMe drives, this MSI/MSIX release/request causes failures of some of the interrupts, resulting in some (usually all but one or two but sometimes none) of the NVMe drive(s) failing to initialize. This combines the MSI/MSIX configurations, so all the MSI/MSIX configuration is done once. This avoids the interrupt failures, but it also results in more MSI/MSIX interrupts being configured than are needed. Signed-off-by:
Dan Streetman <dan.streetman@canonical.com> Signed-off-by:
Brad Figg <brad.figg@canonical.com>
-
Brad Figg authored
Signed-off-by: -
Luis Henriques authored
Signed-off-by: -
Dan Streetman authored
BugLink: http://bugs.launchpad.net/bugs/1647887 Commit 90c9712f ("NVMe: Always use MSI/MSI-x interrupts") changed the NVMe driver to always use MSI/MSI-x interrupts. However, later commit 30d6592f ("NVMe: Don't unmap controller registers on reset") as well as commit e9820e41 ("UBUNTU: (fix) NVMe: Don't unmap controller registers on reset") accidentally reverted part of the original commit, which reverted the NVMe driver to using GSI interrupts instead of always using MSI/MSI-x interrupts. This un-reverts the accidental reversion, to restore the NVMe driver to always use MSI/MSI-x interrupts. Signed-off-by:
-
Luis Henriques authored
Ignore: yes Signed-off-by:
-
- 07 Dec, 2016 1 commit
-
-
Luis Henriques authored
Signed-off-by:
-
- 06 Dec, 2016 12 commits
-
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1646643 Update to latest upstream driver version, from: http://support.huawei.com/enterprise/SoftwareVersionActionNew!showVDetailNew?lang=en&idAbsPath=fixnode01%7C7919749%7C9856522%7C9856629%7C21242728&pid=21242728&vrc=21243470%7C21243471%7C21243473%7C21992501&from=soft&tab=bz&bz_vr=21243471&bz_vrc=&nbz_vr=nullSigned-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1633577Signed-off-by:
-
Andrey Smetanin authored
BugLink: https://bugs.launchpad.net/bugs/1644394 Actually kvm_arch_irq_routing_update() should be kvm_arch_post_irq_routing_update() as it's called at the end of irq routing update. This renaming frees kvm_arch_irq_routing_update function name. kvm_arch_irq_routing_update() weak function which will be used to update mappings for arch-specific irq routing entries (in particular, the upcoming Hyper-V synthetic interrupts). Signed-off-by:
Andrey Smetanin <asmetanin@virtuozzo.com> Reviewed-by:
Roman Kagan <rkagan@virtuozzo.com> Signed-off-by:
Denis V. Lunev <den@openvz.org> CC: Gleb Natapov <gleb@kernel.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Roman Kagan <rkagan@virtuozzo.com> CC: Denis V. Lunev <den@openvz.org> CC: qemu-devel@nongnu.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit abdb080f) Signed-off-by:
Steve Rutherford <srutherford@google.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1645453Signed-off-by:
-
Anders K. Pedersen authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit a8b1e36d upstream. With HZ=100 element timeout in dynamic sets (i.e. flow tables) is 10 times higher than configured. Add proper conversion to/from jiffies, when interacting with userspace. I tested this on Linux 4.8.1, and it applies cleanly to current nf and nf-next trees. Fixes: 22fe54d5 ("netfilter: nf_tables: add support for dynamic set updates") Signed-off-by:
Anders K. Pedersen <akp@cohaesio.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Mark Bloch authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 9db0ff53 upstream. When there is a CM id object that has port assigned to it, it means that the cm-id asked for the specific port that it should go by it, but if that port was removed (hot-unplug event) the cm-id was not updated. In order to fix that the port keeps a list of all the cm-id's that are planning to go by it, whenever the port is removed it marks all of them as invalid. This commit fixes a kernel panic which happens when running traffic between guests and we force reboot a guest mid traffic, it triggers a kernel panic: Call Trace: [<ffffffff815271fa>] ? panic+0xa7/0x16f [<ffffffff8152b534>] ? oops_end+0xe4/0x100 [<ffffffff8104a00b>] ? no_context+0xfb/0x260 [<ffffffff81084db2>] ? del_timer_sync+0x22/0x30 [<ffffffff8104a295>] ? __bad_area_nosemaphore+0x125/0x1e0 [<ffffffff81084240>] ? process_timeout+0x0/0x10 [<ffffffff8104a363>] ? bad_area_nosemaphore+0x13/0x20 [<ffffffff8104aabf>] ? __do_page_fault+0x31f/0x480 [<ffffffff81065df0>] ? default_wake_function+0x0/0x20 [<ffffffffa0752675>] ? free_msg+0x55/0x70 [mlx5_core] [<ffffffffa0753434>] ? cmd_exec+0x124/0x840 [mlx5_core] [<ffffffff8105a924>] ? find_busiest_group+0x244/0x9f0 [<ffffffff8152d45e>] ? do_page_fault+0x3e/0xa0 [<ffffffff8152a815>] ? page_fault+0x25/0x30 [<ffffffffa024da25>] ? cm_alloc_msg+0x35/0xc0 [ib_cm] [<ffffffffa024e821>] ? ib_send_cm_dreq+0xb1/0x1e0 [ib_cm] [<ffffffffa024f836>] ? cm_destroy_id+0x176/0x320 [ib_cm] [<ffffffffa024fb00>] ? ib_destroy_cm_id+0x10/0x20 [ib_cm] [<ffffffffa034f527>] ? ipoib_cm_free_rx_reap_list+0xa7/0x110 [ib_ipoib] [<ffffffffa034f590>] ? ipoib_cm_rx_reap+0x0/0x20 [ib_ipoib] [<ffffffffa034f5a5>] ? ipoib_cm_rx_reap+0x15/0x20 [ib_ipoib] [<ffffffff81094d20>] ? worker_thread+0x170/0x2a0 [<ffffffff8109b2a0>] ? autoremove_wake_function+0x0/0x40 [<ffffffff81094bb0>] ? worker_thread+0x0/0x2a0 [<ffffffff8109aef6>] ? kthread+0x96/0xa0 [<ffffffff8100c20a>] ? child_rip+0xa/0x20 [<ffffffff8109ae60>] ? kthread+0x0/0xa0 [<ffffffff8100c200>] ? child_rip+0x0/0x20 Fixes: a977049d ("[PATCH] IB: Add the kernel CM implementation") Signed-off-by:
Mark Bloch <markb@mellanox.com> Signed-off-by:
Erez Shitrit <erezsh@mellanox.com> Reviewed-by:
Maor Gottlieb <maorg@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Tariq Toukan authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 5b810a24 upstream. The real QP is destroyed in case of the ref count reaches zero, but for XRC target QPs this call was missed and caused to QP leaks. Let's call to destroy for all flows. Fixes: 0e0ec7e0 ('RDMA/core: Export ib_open_qp() to share XRC...') Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
Noa Osherovich <noaos@mellanox.com> Signed-off-by:
-
Mark Bloch authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 3c7ba576 upstream. sg_alloc_table gets unsigned int as parameter while the driver returns it as size_t. Check npages isn't greater than maximum unsigned int. Fixes: eeb8461e ("IB: Refactor umem to use linear SG table") Signed-off-by:
-
Eli Cohen authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit dbaaff2a upstream. When an internal error condition is detected, make sure to set the device inactive after dispatching the event so ULPs can get a notification of this event. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
Eli Cohen <eli@mellanox.com> Signed-off-by:
Mohamad Haj Yahia <mohamad@mellanox.com> Signed-off-by:
-
Daniel Jurgens authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 16b0e069 upstream. When creating kernel CQs use 128B CQE stride if the cache line size is 128B, 64B otherwise. This prevents multiple CQEs from residing in a 128B cache line, which can cause retries when there are concurrent read and writes in one cache line. Tested with IPoIB on PPC64, saw ~5% throughput improvement. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
-
Matan Barak authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 593ff73b upstream. Currently, if ib_copy_to_udata fails, the CQ won't be deleted from the radix tree and the HW (HW2SW). Fixes: 225c7b1f ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters') Signed-off-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
-
Daniel Jurgens authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 37995116 upstream. Check the returned GID index value and return an error if it is invalid. Fixes: 5070cd22 ('IB/mlx4: Replace mechanism for RoCE GID management') Signed-off-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
-
