From 6e4f16b5e7a6fe12875869edf20fab64cf2d9177 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Thu, 20 Mar 2014 01:38:57 +0000 Subject: [PATCH] 3.10-stable patches added patches: acpi-resources-ignore-invalid-acpi-device-resources.patch arm-7991-1-sa1100-fix-compile-problem-on-collie.patch cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch genirq-remove-racy-waitqueue_active-check.patch regulator-core-replace-direct-ops-enable-usage.patch usb-add-device-quirk-for-logitech-hd-pro-webcams-c920-and-c930e.patch usb-make-delay_init-quirk-wait-100ms-between-get-configuration-requests.patch x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch x86-fix-compile-error-due-to-x86_trap_nmi-use-in-asm-files.patch x86-ignore-nmis-that-come-in-during-early-boot.patch --- ...ignore-invalid-acpi-device-resources.patch | 71 ++++++++++++++++ ...sa1100-fix-compile-problem-on-collie.patch | 44 ++++++++++ ...on-in-__cpuset_node_allowed_softwall.patch | 33 ++++++++ ...q-remove-racy-waitqueue_active-check.patch | 61 ++++++++++++++ ...core-replace-direct-ops-enable-usage.patch | 67 +++++++++++++++ queue-3.10/series | 10 +++ ...gitech-hd-pro-webcams-c920-and-c930e.patch | 39 +++++++++ ...s-between-get-configuration-requests.patch | 39 +++++++++ ...ge-quirk-to-assign-correct-numa-node.patch | 41 +++++++++ ...due-to-x86_trap_nmi-use-in-asm-files.patch | 51 ++++++++++++ ...-nmis-that-come-in-during-early-boot.patch | 83 +++++++++++++++++++ 11 files changed, 539 insertions(+) create mode 100644 queue-3.10/acpi-resources-ignore-invalid-acpi-device-resources.patch create mode 100644 queue-3.10/arm-7991-1-sa1100-fix-compile-problem-on-collie.patch create mode 100644 queue-3.10/cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch create mode 100644 queue-3.10/genirq-remove-racy-waitqueue_active-check.patch create mode 100644 queue-3.10/regulator-core-replace-direct-ops-enable-usage.patch create mode 100644 queue-3.10/usb-add-device-quirk-for-logitech-hd-pro-webcams-c920-and-c930e.patch create mode 100644 queue-3.10/usb-make-delay_init-quirk-wait-100ms-between-get-configuration-requests.patch create mode 100644 queue-3.10/x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch create mode 100644 queue-3.10/x86-fix-compile-error-due-to-x86_trap_nmi-use-in-asm-files.patch create mode 100644 queue-3.10/x86-ignore-nmis-that-come-in-during-early-boot.patch diff --git a/queue-3.10/acpi-resources-ignore-invalid-acpi-device-resources.patch b/queue-3.10/acpi-resources-ignore-invalid-acpi-device-resources.patch new file mode 100644 index 00000000000..d98db2ba5ad --- /dev/null +++ b/queue-3.10/acpi-resources-ignore-invalid-acpi-device-resources.patch @@ -0,0 +1,71 @@ +From b355cee88e3b1a193f0e9a81db810f6f83ad728b Mon Sep 17 00:00:00 2001 +From: Zhang Rui +Date: Thu, 27 Feb 2014 11:37:15 +0800 +Subject: ACPI / resources: ignore invalid ACPI device resources + +From: Zhang Rui + +commit b355cee88e3b1a193f0e9a81db810f6f83ad728b upstream. + +ACPI table may export resource entry with 0 length. +But the current code interprets this kind of resource in a wrong way. +It will create a resource structure with +res->end = acpi_resource->start + acpi_resource->len - 1; + +This patch fixes a problem on my machine that a platform device fails +to be created because one of its ACPI IO resource entry (start = 0, +end = 0, length = 0) is translated into a generic resource with +start = 0, end = 0xffffffff. + +Signed-off-by: Zhang Rui +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/resource.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/acpi/resource.c ++++ b/drivers/acpi/resource.c +@@ -77,18 +77,24 @@ bool acpi_dev_resource_memory(struct acp + switch (ares->type) { + case ACPI_RESOURCE_TYPE_MEMORY24: + memory24 = &ares->data.memory24; ++ if (!memory24->address_length) ++ return false; + acpi_dev_get_memresource(res, memory24->minimum, + memory24->address_length, + memory24->write_protect); + break; + case ACPI_RESOURCE_TYPE_MEMORY32: + memory32 = &ares->data.memory32; ++ if (!memory32->address_length) ++ return false; + acpi_dev_get_memresource(res, memory32->minimum, + memory32->address_length, + memory32->write_protect); + break; + case ACPI_RESOURCE_TYPE_FIXED_MEMORY32: + fixed_memory32 = &ares->data.fixed_memory32; ++ if (!fixed_memory32->address_length) ++ return false; + acpi_dev_get_memresource(res, fixed_memory32->address, + fixed_memory32->address_length, + fixed_memory32->write_protect); +@@ -144,12 +150,16 @@ bool acpi_dev_resource_io(struct acpi_re + switch (ares->type) { + case ACPI_RESOURCE_TYPE_IO: + io = &ares->data.io; ++ if (!io->address_length) ++ return false; + acpi_dev_get_ioresource(res, io->minimum, + io->address_length, + io->io_decode); + break; + case ACPI_RESOURCE_TYPE_FIXED_IO: + fixed_io = &ares->data.fixed_io; ++ if (!fixed_io->address_length) ++ return false; + acpi_dev_get_ioresource(res, fixed_io->address, + fixed_io->address_length, + ACPI_DECODE_10); diff --git a/queue-3.10/arm-7991-1-sa1100-fix-compile-problem-on-collie.patch b/queue-3.10/arm-7991-1-sa1100-fix-compile-problem-on-collie.patch new file mode 100644 index 00000000000..82f0ad6bf4f --- /dev/null +++ b/queue-3.10/arm-7991-1-sa1100-fix-compile-problem-on-collie.patch @@ -0,0 +1,44 @@ +From 052450fdc55894a39fbae93d9bbe43947956f663 Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Tue, 25 Feb 2014 22:41:41 +0100 +Subject: ARM: 7991/1: sa1100: fix compile problem on Collie + +From: Linus Walleij + +commit 052450fdc55894a39fbae93d9bbe43947956f663 upstream. + +Due to a problem in the MFD Kconfig it was not possible to +compile the UCB battery driver for the Collie SA1100 system, +in turn making it impossible to compile in the battery driver. +(See patch "mfd: include all drivers in subsystem menu".) + +After fixing the MFD Kconfig (separate patch) a compile error +appears in the Collie battery driver due to the +implicitly requiring through +via prior to commit +40ca061b "ARM: 7841/1: sa1100: remove complex GPIO interface". + +Fix this up by including the required header into +. + +Cc: Andrea Adami +Cc: Dmitry Eremin-Solenikov +Signed-off-by: Linus Walleij +Signed-off-by: Russell King +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/mach-sa1100/include/mach/collie.h | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/arm/mach-sa1100/include/mach/collie.h ++++ b/arch/arm/mach-sa1100/include/mach/collie.h +@@ -13,6 +13,8 @@ + #ifndef __ASM_ARCH_COLLIE_H + #define __ASM_ARCH_COLLIE_H + ++#include "hardware.h" /* Gives GPIO_MAX */ ++ + extern void locomolcd_power(int on); + + #define COLLIE_SCOOP_GPIO_BASE (GPIO_MAX + 1) diff --git a/queue-3.10/cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch b/queue-3.10/cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch new file mode 100644 index 00000000000..56de75904d9 --- /dev/null +++ b/queue-3.10/cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch @@ -0,0 +1,33 @@ +From 99afb0fd5f05aac467ffa85c36778fec4396209b Mon Sep 17 00:00:00 2001 +From: Li Zefan +Date: Thu, 27 Feb 2014 18:19:36 +0800 +Subject: cpuset: fix a race condition in __cpuset_node_allowed_softwall() + +From: Li Zefan + +commit 99afb0fd5f05aac467ffa85c36778fec4396209b upstream. + +It's not safe to access task's cpuset after releasing task_lock(). +Holding callback_mutex won't help. + +Signed-off-by: Li Zefan +Signed-off-by: Tejun Heo +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/cpuset.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/cpuset.c ++++ b/kernel/cpuset.c +@@ -2422,9 +2422,9 @@ int __cpuset_node_allowed_softwall(int n + + task_lock(current); + cs = nearest_hardwall_ancestor(task_cs(current)); ++ allowed = node_isset(node, cs->mems_allowed); + task_unlock(current); + +- allowed = node_isset(node, cs->mems_allowed); + mutex_unlock(&callback_mutex); + return allowed; + } diff --git a/queue-3.10/genirq-remove-racy-waitqueue_active-check.patch b/queue-3.10/genirq-remove-racy-waitqueue_active-check.patch new file mode 100644 index 00000000000..cac8443aca1 --- /dev/null +++ b/queue-3.10/genirq-remove-racy-waitqueue_active-check.patch @@ -0,0 +1,61 @@ +From c685689fd24d310343ac33942e9a54a974ae9c43 Mon Sep 17 00:00:00 2001 +From: Chuansheng Liu +Date: Mon, 24 Feb 2014 11:29:50 +0800 +Subject: genirq: Remove racy waitqueue_active check + +From: Chuansheng Liu + +commit c685689fd24d310343ac33942e9a54a974ae9c43 upstream. + +We hit one rare case below: + +T1 calling disable_irq(), but hanging at synchronize_irq() +always; +The corresponding irq thread is in sleeping state; +And all CPUs are in idle state; + +After analysis, we found there is one possible scenerio which +causes T1 is waiting there forever: +CPU0 CPU1 + synchronize_irq() + wait_event() + spin_lock() + atomic_dec_and_test(&threads_active) + insert the __wait into queue + spin_unlock() + if(waitqueue_active) + atomic_read(&threads_active) + wake_up() + +Here after inserted the __wait into queue on CPU0, and before +test if queue is empty on CPU1, there is no barrier, it maybe +cause it is not visible for CPU1 immediately, although CPU0 has +updated the queue list. +It is similar for CPU0 atomic_read() threads_active also. + +So we'd need one smp_mb() before waitqueue_active.that, but removing +the waitqueue_active() check solves it as wel l and it makes +things simple and clear. + +Signed-off-by: Chuansheng Liu +Cc: Xiaoming Wang +Link: http://lkml.kernel.org/r/1393212590-32543-1-git-send-email-chuansheng.liu@intel.com +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/irq/manage.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/kernel/irq/manage.c ++++ b/kernel/irq/manage.c +@@ -802,8 +802,7 @@ static irqreturn_t irq_thread_fn(struct + + static void wake_threads_waitq(struct irq_desc *desc) + { +- if (atomic_dec_and_test(&desc->threads_active) && +- waitqueue_active(&desc->wait_for_threads)) ++ if (atomic_dec_and_test(&desc->threads_active)) + wake_up(&desc->wait_for_threads); + } + diff --git a/queue-3.10/regulator-core-replace-direct-ops-enable-usage.patch b/queue-3.10/regulator-core-replace-direct-ops-enable-usage.patch new file mode 100644 index 00000000000..83b3d5d50d0 --- /dev/null +++ b/queue-3.10/regulator-core-replace-direct-ops-enable-usage.patch @@ -0,0 +1,67 @@ +From 30c219710358c5cca2f8bd2e9e547c6aadf7cf8b Mon Sep 17 00:00:00 2001 +From: Markus Pargmann +Date: Thu, 20 Feb 2014 17:36:03 +0100 +Subject: regulator: core: Replace direct ops->enable usage + +From: Markus Pargmann + +commit 30c219710358c5cca2f8bd2e9e547c6aadf7cf8b upstream. + +There are some direct ops->enable in the regulator core driver. This is +a potential issue as the function _regulator_do_enable() handles gpio +regulators and the normal ops->enable calls. These gpio regulators are +simply ignored when ops->enable is called directly. + +One possible bug is that boot-on and always-on gpio regulators are not +enabled on registration. + +This patch replaces all ops->enable calls by _regulator_do_enable. + +[Handle missing enable operations -- broonie] + +Signed-off-by: Markus Pargmann +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + + +--- + drivers/regulator/core.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +--- a/drivers/regulator/core.c ++++ b/drivers/regulator/core.c +@@ -919,6 +919,8 @@ static int machine_constraints_voltage(s + return 0; + } + ++static int _regulator_do_enable(struct regulator_dev *rdev); ++ + /** + * set_machine_constraints - sets regulator constraints + * @rdev: regulator source +@@ -975,10 +977,9 @@ static int set_machine_constraints(struc + /* If the constraints say the regulator should be on at this point + * and we have control then make sure it is enabled. + */ +- if ((rdev->constraints->always_on || rdev->constraints->boot_on) && +- ops->enable) { +- ret = ops->enable(rdev); +- if (ret < 0) { ++ if (rdev->constraints->always_on || rdev->constraints->boot_on) { ++ ret = _regulator_do_enable(rdev); ++ if (ret < 0 && ret != -EINVAL) { + rdev_err(rdev, "failed to enable\n"); + goto out; + } +@@ -3790,9 +3791,8 @@ int regulator_suspend_finish(void) + struct regulator_ops *ops = rdev->desc->ops; + + mutex_lock(&rdev->mutex); +- if ((rdev->use_count > 0 || rdev->constraints->always_on) && +- ops->enable) { +- error = ops->enable(rdev); ++ if (rdev->use_count > 0 || rdev->constraints->always_on) { ++ error = _regulator_do_enable(rdev); + if (error) + ret = error; + } else { diff --git a/queue-3.10/series b/queue-3.10/series index afd3b72ee6a..bec976a209f 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -32,3 +32,13 @@ alsa-usb-audio-add-quirk-for-logitech-webcam-c500.patch alsa-hda-added-inverted-digital-mic-handling-for-acer-travelmate-8371.patch alsa-hda-add-missing-loopback-merge-path-for-ad1884-1984-codecs.patch powerpc-align-p_dyn-p_rela-and-p_st-symbols.patch +arm-7991-1-sa1100-fix-compile-problem-on-collie.patch +regulator-core-replace-direct-ops-enable-usage.patch +x86-ignore-nmis-that-come-in-during-early-boot.patch +x86-fix-compile-error-due-to-x86_trap_nmi-use-in-asm-files.patch +x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch +usb-add-device-quirk-for-logitech-hd-pro-webcams-c920-and-c930e.patch +usb-make-delay_init-quirk-wait-100ms-between-get-configuration-requests.patch +genirq-remove-racy-waitqueue_active-check.patch +cpuset-fix-a-race-condition-in-__cpuset_node_allowed_softwall.patch +acpi-resources-ignore-invalid-acpi-device-resources.patch diff --git a/queue-3.10/usb-add-device-quirk-for-logitech-hd-pro-webcams-c920-and-c930e.patch b/queue-3.10/usb-add-device-quirk-for-logitech-hd-pro-webcams-c920-and-c930e.patch new file mode 100644 index 00000000000..483bbd40836 --- /dev/null +++ b/queue-3.10/usb-add-device-quirk-for-logitech-hd-pro-webcams-c920-and-c930e.patch @@ -0,0 +1,39 @@ +From e0429362ab15c46ea4d64c3f8c9e0933e48a143a Mon Sep 17 00:00:00 2001 +From: Julius Werner +Date: Tue, 4 Mar 2014 10:52:39 -0800 +Subject: usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e + +From: Julius Werner + +commit e0429362ab15c46ea4d64c3f8c9e0933e48a143a upstream. + +We've encountered a rare issue when enumerating two Logitech webcams +after a reboot that doesn't power cycle the USB ports. They are spewing +random data (possibly some leftover UVC buffers) on the second +(full-sized) Get Configuration request of the enumeration phase. Since +the data is random this can potentially cause all kinds of odd behavior, +and since it occasionally happens multiple times (after the kernel +issues another reset due to the garbled configuration descriptor), it is +not always recoverable. Set the USB_DELAY_INIT quirk that seems to work +around the issue. + +Signed-off-by: Julius Werner +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/core/quirks.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/usb/core/quirks.c ++++ b/drivers/usb/core/quirks.c +@@ -46,6 +46,10 @@ static const struct usb_device_id usb_qu + /* Microsoft LifeCam-VX700 v2.0 */ + { USB_DEVICE(0x045e, 0x0770), .driver_info = USB_QUIRK_RESET_RESUME }, + ++ /* Logitech HD Pro Webcams C920 and C930e */ ++ { USB_DEVICE(0x046d, 0x082d), .driver_info = USB_QUIRK_DELAY_INIT }, ++ { USB_DEVICE(0x046d, 0x0843), .driver_info = USB_QUIRK_DELAY_INIT }, ++ + /* Logitech Quickcam Fusion */ + { USB_DEVICE(0x046d, 0x08c1), .driver_info = USB_QUIRK_RESET_RESUME }, + diff --git a/queue-3.10/usb-make-delay_init-quirk-wait-100ms-between-get-configuration-requests.patch b/queue-3.10/usb-make-delay_init-quirk-wait-100ms-between-get-configuration-requests.patch new file mode 100644 index 00000000000..0138f497928 --- /dev/null +++ b/queue-3.10/usb-make-delay_init-quirk-wait-100ms-between-get-configuration-requests.patch @@ -0,0 +1,39 @@ +From d86db25e53fa69e3e97f3b55dd82a70689787c5d Mon Sep 17 00:00:00 2001 +From: Julius Werner +Date: Tue, 4 Mar 2014 11:27:38 -0800 +Subject: usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests + +From: Julius Werner + +commit d86db25e53fa69e3e97f3b55dd82a70689787c5d upstream. + +The DELAY_INIT quirk only reduces the frequency of enumeration failures +with the Logitech HD Pro C920 and C930e webcams, but does not quite +eliminate them. We have found that adding a delay of 100ms between the +first and second Get Configuration request makes the device enumerate +perfectly reliable even after several weeks of extensive testing. The +reasons for that are anyone's guess, but since the DELAY_INIT quirk +already delays enumeration by a whole second, wating for another 10th of +that isn't really a big deal for the one other device that uses it, and +it will resolve the problems with these webcams. + +Signed-off-by: Julius Werner +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/core/config.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/usb/core/config.c ++++ b/drivers/usb/core/config.c +@@ -718,6 +718,10 @@ int usb_get_configuration(struct usb_dev + result = -ENOMEM; + goto err; + } ++ ++ if (dev->quirks & USB_QUIRK_DELAY_INIT) ++ msleep(100); ++ + result = usb_get_descriptor(dev, USB_DT_CONFIG, cfgno, + bigbuffer, length); + if (result < 0) { diff --git a/queue-3.10/x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch b/queue-3.10/x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch new file mode 100644 index 00000000000..bf578a0fc7c --- /dev/null +++ b/queue-3.10/x86-amd-numa-fix-northbridge-quirk-to-assign-correct-numa-node.patch @@ -0,0 +1,41 @@ +From 847d7970defb45540735b3fb4e88471c27cacd85 Mon Sep 17 00:00:00 2001 +From: Daniel J Blueman +Date: Thu, 13 Mar 2014 19:43:01 +0800 +Subject: x86/amd/numa: Fix northbridge quirk to assign correct NUMA node + +From: Daniel J Blueman + +commit 847d7970defb45540735b3fb4e88471c27cacd85 upstream. + +For systems with multiple servers and routed fabric, all +northbridges get assigned to the first server. Fix this by also +using the node reported from the PCI bus. For single-fabric +systems, the northbriges are on PCI bus 0 by definition, which +are on NUMA node 0 by definition, so this is invarient on most +systems. + +Tested on fam10h and fam15h single and multi-fabric systems and +candidate for stable. + +Signed-off-by: Daniel J Blueman +Acked-by: Steffen Persvold +Acked-by: Borislav Petkov +Link: http://lkml.kernel.org/r/1394710981-3596-1-git-send-email-daniel@numascale.com +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/quirks.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/quirks.c ++++ b/arch/x86/kernel/quirks.c +@@ -529,7 +529,7 @@ static void quirk_amd_nb_node(struct pci + return; + + pci_read_config_dword(nb_ht, 0x60, &val); +- node = val & 7; ++ node = pcibus_to_node(dev->bus) | (val & 7); + /* + * Some hardware may return an invalid node ID, + * so check it first: diff --git a/queue-3.10/x86-fix-compile-error-due-to-x86_trap_nmi-use-in-asm-files.patch b/queue-3.10/x86-fix-compile-error-due-to-x86_trap_nmi-use-in-asm-files.patch new file mode 100644 index 00000000000..ee67c44ab6c --- /dev/null +++ b/queue-3.10/x86-fix-compile-error-due-to-x86_trap_nmi-use-in-asm-files.patch @@ -0,0 +1,51 @@ +From b01d4e68933ec23e43b1046fa35d593cefcf37d1 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Fri, 7 Mar 2014 18:58:40 -0800 +Subject: x86: fix compile error due to X86_TRAP_NMI use in asm files + +From: Linus Torvalds + +commit b01d4e68933ec23e43b1046fa35d593cefcf37d1 upstream. + +It's an enum, not a #define, you can't use it in asm files. + +Introduced in commit 5fa10196bdb5 ("x86: Ignore NMIs that come in during +early boot"), and sadly I didn't compile-test things like I should have +before pushing out. + +My weak excuse is that the x86 tree generally doesn't introduce stupid +things like this (and the ARM pull afterwards doesn't cause me to do a +compile-test either, since I don't cross-compile). + +Cc: Don Zickus +Cc: H. Peter Anvin +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/head_32.S | 2 +- + arch/x86/kernel/head_64.S | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/head_32.S ++++ b/arch/x86/kernel/head_32.S +@@ -567,7 +567,7 @@ ENDPROC(early_idt_handlers) + ENTRY(early_idt_handler) + cld + +- cmpl $X86_TRAP_NMI,(%esp) ++ cmpl $2,(%esp) # X86_TRAP_NMI + je is_nmi # Ignore NMI + + cmpl $2,%ss:early_recursion_flag +--- a/arch/x86/kernel/head_64.S ++++ b/arch/x86/kernel/head_64.S +@@ -343,7 +343,7 @@ early_idt_handlers: + ENTRY(early_idt_handler) + cld + +- cmpl $X86_TRAP_NMI,(%rsp) ++ cmpl $2,(%rsp) # X86_TRAP_NMI + je is_nmi # Ignore NMI + + cmpl $2,early_recursion_flag(%rip) diff --git a/queue-3.10/x86-ignore-nmis-that-come-in-during-early-boot.patch b/queue-3.10/x86-ignore-nmis-that-come-in-during-early-boot.patch new file mode 100644 index 00000000000..bcc84e863b8 --- /dev/null +++ b/queue-3.10/x86-ignore-nmis-that-come-in-during-early-boot.patch @@ -0,0 +1,83 @@ +From 5fa10196bdb5f190f595ebd048490ee52dddea0f Mon Sep 17 00:00:00 2001 +From: "H. Peter Anvin" +Date: Fri, 7 Mar 2014 15:05:20 -0800 +Subject: x86: Ignore NMIs that come in during early boot + +From: "H. Peter Anvin" + +commit 5fa10196bdb5f190f595ebd048490ee52dddea0f upstream. + +Don Zickus reports: + +A customer generated an external NMI using their iLO to test kdump +worked. Unfortunately, the machine hung. Disabling the nmi_watchdog +made things work. + +I speculated the external NMI fired, caused the machine to panic (as +expected) and the perf NMI from the watchdog came in and was latched. +My guess was this somehow caused the hang. + + ---- + +It appears that the latched NMI stays latched until the early page +table generation on 64 bits, which causes exceptions to happen which +end in IRET, which re-enable NMI. Therefore, ignore NMIs that come in +during early execution, until we have proper exception handling. + +Reported-and-tested-by: Don Zickus +Link: http://lkml.kernel.org/r/1394221143-29713-1-git-send-email-dzickus@redhat.com +Signed-off-by: H. Peter Anvin +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/head_32.S | 7 ++++++- + arch/x86/kernel/head_64.S | 6 +++++- + 2 files changed, 11 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/head_32.S ++++ b/arch/x86/kernel/head_32.S +@@ -566,6 +566,10 @@ ENDPROC(early_idt_handlers) + /* This is global to keep gas from relaxing the jumps */ + ENTRY(early_idt_handler) + cld ++ ++ cmpl $X86_TRAP_NMI,(%esp) ++ je is_nmi # Ignore NMI ++ + cmpl $2,%ss:early_recursion_flag + je hlt_loop + incl %ss:early_recursion_flag +@@ -616,8 +620,9 @@ ex_entry: + pop %edx + pop %ecx + pop %eax +- addl $8,%esp /* drop vector number and error code */ + decl %ss:early_recursion_flag ++is_nmi: ++ addl $8,%esp /* drop vector number and error code */ + iret + ENDPROC(early_idt_handler) + +--- a/arch/x86/kernel/head_64.S ++++ b/arch/x86/kernel/head_64.S +@@ -343,6 +343,9 @@ early_idt_handlers: + ENTRY(early_idt_handler) + cld + ++ cmpl $X86_TRAP_NMI,(%rsp) ++ je is_nmi # Ignore NMI ++ + cmpl $2,early_recursion_flag(%rip) + jz 1f + incl early_recursion_flag(%rip) +@@ -405,8 +408,9 @@ ENTRY(early_idt_handler) + popq %rdx + popq %rcx + popq %rax +- addq $16,%rsp # drop vector number and error code + decl early_recursion_flag(%rip) ++is_nmi: ++ addq $16,%rsp # drop vector number and error code + INTERRUPT_RETURN + ENDPROC(early_idt_handler) + -- 2.47.3