- 15 Dec, 2016 1 commit
-
-
Ross Lagerwall authored
BugLink: http://bugs.launchpad.net/bugs/1649821 The following commit: 1fb3a8b2 ("xen/spinlock: Fix locking path engaging too soon under PVHVM.") ... moved the initalization of the kicker interrupt until after native_cpu_up() is called. However, when using qspinlocks, a CPU may try to kick another CPU that is spinning (because it has not yet initialized its kicker interrupt), resulting in the following crash during boot: kernel BUG at /build/linux-Ay7j_C/linux-4.4.0/drivers/xen/events/events_base.c:1210! invalid opcode: 0000 [#1] SMP ... RIP: 0010:[<ffffffff814c97c9>] [<ffffffff814c97c9>] xen_send_IPI_one+0x59/0x60 ... Call Trace: [<ffffffff8102be9e>] xen_qlock_kick+0xe/0x10 [<ffffffff810cabc2>] __pv_queued_spin_unlock+0xb2/0xf0 [<ffffffff810ca6d1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [<ffffffff81052936>] ? check_tsc_warp+0x76/0x150 [<ffffffff81052aa6>] check_tsc_sync_source+0x96/0x160 [<ffffffff81051e28>] native_cpu_up+0x3d8/0x9f0 [<ffffffff8102b315>] xen_hvm_cpu_up+0x35/0x80 [<ffffffff8108198c>] _cpu_up+0x13c/0x180 [<ffffffff81081a4a>] cpu_up+0x7a/0xa0 [<ffffffff81f80dfc>] smp_init+0x7f/0x81 [<ffffffff81f5a121>] kernel_init_freeable+0xef/0x212 [<ffffffff81817f30>] ? rest_init+0x80/0x80 [<ffffffff81817f3e>] kernel_init+0xe/0xe0 [<ffffffff8182488f>] ret_from_fork+0x3f/0x70 [<ffffffff81817f30>] ? rest_init+0x80/0x80 To fix this, only send the kick if the target CPU's interrupt has been initialized. This check isn't racy, because the target is waiting for the spinlock, so it won't have initialized the interrupt in the meantime. Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Juergen Gross <jgross@suse.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Cc: xen-devel@lists.xenproject.org Signed-off-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit 707e59ba) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
- 14 Dec, 2016 6 commits
-
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1642368Signed-off-by:
Robert Hooker <robert.hooker@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1642368 Prevent staging drivers from being loadable in a secure boot environment. Signed-off-by:
-
Michael Pobega authored
BugLink: http://bugs.launchpad.net/bugs/1648279 The Dell Latitude 3350's ethernet card attempts to use a reserved IRQ (18), resulting in ACPI being unable to enable the ethernet. Adding it to acpi_rev_dmi_table[] helps to work around this problem. Signed-off-by:
Michael Pobega <mpobega@neverware.com> [ rjw: Changelog ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (backported from commit 708f5dcc) Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
-
Eric Dumazet authored
CAP_NET_ADMIN users should not be allowed to set negative sk_sndbuf or sk_rcvbuf values, as it can lead to various memory corruptions, crashes, OOM... Note that before commit 82981930 ("net: cleanups in sock_setsockopt()"), the bug was even more serious, since SO_SNDBUF and SO_RCVBUF were vulnerable. This needs to be backported to all known linux kernels. Again, many thanks to syzkaller team for discovering this gem. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit b98b0bc8) CVE-2016-9793 Signed-off-by:
John Donnelly <john.donnelly@canonical.com> Acked-by:
Steve Beattie <sbeattie@ubuntu.com>
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1400319 When we crash from NMI context (e.g. after NMI injection from host when 'sysctl -w kernel.unknown_nmi_panic=1' is set) we hit kernel BUG at mm/vmalloc.c:1530! as vfree() is denied. While the issue could be solved with in_nmi() check instead I opted for skipping vfree on all sorts of crashes to reduce the amount of work which can cause consequent crashes. We don't really need to free anything on crash. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit a9f61ca7) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1636656 The Hyper-V netvsc driver was looking at the incorrect status bits in the checksum info. It was setting the receive checksum unnecessary flag based on the IP header checksum being correct. The checksum flag is skb is about TCP and UDP checksum status. Because of this bug, any packet received with bad TCP checksum would be passed up the stack and to the application causing data corruption. The problem is reproducible via netcat and netem. This had a side effect of not doing receive checksum offload on IPv6. The driver was also also always doing checksum offload independent of the checksum setting done via ethtool. Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
- 12 Dec, 2016 1 commit
-
-
Luis Henriques authored
Ignore: yes Signed-off-by:
-
- 09 Dec, 2016 3 commits
-
-
Brad Figg authored
Signed-off-by: -
Brad Figg authored
Signed-off-by: -
Brad Figg authored
Ignore: yes Signed-off-by:
-
- 08 Dec, 2016 29 commits
-
-
Brad Figg authored
Signed-off-by: -
Nicolas Dichtel authored
BugLink: http://bugs.launchpad.net/bugs/1593235 The function geneve_dev_create_fb() (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: e305ac6c ("geneve: Add support to collect tunnel metadata.") CC: Pravin B Shelar <pshelar@nicira.com> CC: Jesse Gross <jesse@nicira.com> CC: Thomas Graf <tgraf@suug.ch> Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <thadeu.cascardo@canonical.com> Acked-by:
-
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 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:
-
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:
-
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:
-
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:
-
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 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:
-
