[PATCH] x86_64: Avoid NMI Watchdog and/or long wait in setup_APIC_timer

In setup_APIC_timer with the HPET in use, a condition can arise while waiting for the next irq slice to expire on the HPET which will either cause an NMI watchdog to fire or a 3 minute busy loop if the NMI watchdog is disabled. The HPET comparator and the counter keep incrementing during its

[PATCH] x86_64: Avoid NMI Watchdog and/or long wait in setup_APIC_timer

In setup_APIC_timer with the HPET in use, a condition can arise while waiting for the next irq slice to expire on the HPET which will either cause an NMI watchdog to fire or a 3 minute busy loop if the NMI watchdog is disabled. The HPET comparator and the counter keep incrementing during its

Re: [PATCH] x86_64: Avoid NMI Watchdog and/or long wait in setup_APIC_timer

On 8/8/07, Andi Kleen [EMAIL PROTECTED] wrote: On Thursday 09 August 2007 01:17:19 Aaron Durbin wrote: In setup_APIC_timer with the HPET in use, a condition can arise while waiting for the next irq slice to expire on the HPET which will either cause an NMI watchdog to fire or a 3 minute

[PATCH] x86_64: Avoid NMI Watchdog and/or long wait in setup_APIC_timer

the end of the tick slice. Signed-off-by: Aaron Durbin [EMAIL PROTECTED] --- This time w/ the 'Signed-off-by' line. I swear I am not trying to spam. diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c index 900ff38..06797e2 100644 --- a/arch/x86_64/kernel/apic.c +++ b/arch/x86_64

Re: [PATCH] x86_64: Avoid NMI Watchdog and/or long wait in setup_APIC_timer

On 8/9/07, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 8 Aug 2007 16:17:19 -0700 Aaron Durbin [EMAIL PROTECTED] wrote: In setup_APIC_timer with the HPET in use, a condition can arise while waiting for the next irq slice to expire on the HPET which will either cause an NMI watchdog

Re: [PATCH] i386/x86_64: Insert HPET firmware resource after PCI enumeration has completed

On 7/6/07, Andi Kleen [EMAIL PROTECTED] wrote: On Friday 06 July 2007 00:27:24 Aaron Durbin wrote: Insert HPET resources after pci probing has been completed in order to avoid resource conflicts with PCI resource reservation. With this change the HPET firmware resources will be identified

[PATCH] i386/x86_64: Insert HPET firmware resource after PCI enumeration has completed

enumeration cannot reserve the resources. Signed-off-by: Aaron Durbin [EMAIL PROTECTED] --- arch/i386/kernel/acpi/boot.c | 36 1 files changed, 36 insertions(+), 0 deletions(-) diff --git a/arch/i386/kernel/acpi/boot.c b/arch/i386/kernel/acpi/boot.c index

[PATCH] ACPI: Add reboot mechanism

Add the ability to reset the machine using the RESET_REG in ACPI's FADT table. Signed-off-by: Aaron Durbin [EMAIL PROTECTED] --- diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index d4336f1..c9906a5 100644 --- a/drivers/acpi/Makefile +++ b/drivers/acpi/Makefile @@ -21,7 +21,7 @@ obj

[PATCH] x86_64: Add ACPI reboot option

Add the ability to reboot an x86_64 based machine using the RESET_REG in the FADT ACPI table. Signed-off-by: Aaron Durbin [EMAIL PROTECTED] This patch relies on the ACPI reboot mechanism patch. diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt

[PATCH] x86_64: Make ACPI the default reset option

Make ACPI be the default reset method for x86_64. If the reset mechanism fails using ACPI, it will default to using the keyboard controller. Signed-off-by: Aaron Durbin [EMAIL PROTECTED] --- This patch relies on the ACPI reboot mechanism patch. diff --git a/Documentation/x86_64/boot

Re: [PATCH] ACPI: Add reboot mechanism

On 7/16/07, Arjan van de Ven [EMAIL PROTECTED] wrote: On Mon, 2007-07-16 at 11:00 -0700, Aaron Durbin wrote: Add the ability to reset the machine using the RESET_REG in ACPI's FADT table. Signed-off-by: Aaron Durbin [EMAIL PROTECTED] --- diff --git a/drivers/acpi/Makefile b/drivers/acpi

Re: [PATCH] ACPI: Add reboot mechanism

On 7/16/07, Shaohua Li [EMAIL PROTECTED] wrote: On Tue, 2007-07-17 at 02:00 +0800, Aaron Durbin wrote: Add the ability to reset the machine using the RESET_REG in ACPI's FADT table. We could have another command for 'reboot' kernel command line. I did this in a separate patch for x86_64

Re: [PATCH] ACPI: Add reboot mechanism

On 7/17/07, Yinghai Lu [EMAIL PROTECTED] wrote: On 7/17/07, Andi Kleen [EMAIL PROTECTED] wrote: On Monday 16 July 2007 20:00:19 Aaron Durbin wrote: Add the ability to reset the machine using the RESET_REG in ACPI's FADT table. Why? I had such a patch at some point as experiment

Re: [PATCH] ACPI: Add reboot mechanism

On 7/17/07, Andi Kleen [EMAIL PROTECTED] wrote: On Monday 16 July 2007 20:00:19 Aaron Durbin wrote: Add the ability to reset the machine using the RESET_REG in ACPI's FADT table. Why? I had such a patch at some point as experiment, but it never helped actually fix a box. I have a box here

Re: [PATCH] x86_64: Make ACPI the default reset option

On 7/17/07, Andi Kleen [EMAIL PROTECTED] wrote: On Monday 16 July 2007 20:02:21 Aaron Durbin wrote: Make ACPI be the default reset method for x86_64. If the reset mechanism fails using ACPI, it will default to using the keyboard controller. Again why? You really can't just throw out

Re: [PATCH] ACPI: Add reboot mechanism

On 7/17/07, Andi Kleen [EMAIL PROTECTED] wrote: On Tuesday 17 July 2007 17:08:19 Aaron Durbin wrote: This is true if SMIs are still flowing, and the SMI handler correctly handles the reset properly. I have seen cases where the SMI handler is broken which causes the system to perpetually hang

[PATCH] mmconfig x86_64/i386 : Insert unclaimed MMCONFIG resources.

. Signed-off-by: Aaron Durbin [EMAIL PROTECTED] --- diff --git a/arch/i386/pci/mmconfig-shared.c b/arch/i386/pci/mmconfig-shared.c index 747d8c6..c85a5f7 100644 --- a/arch/i386/pci/mmconfig-shared.c +++ b/arch/i386/pci/mmconfig-shared.c @@ -24,6 +24,9 @@ #define MMCONFIG_APER_MAX (256 * 1024*10

[PATCH] mmconfig x86_64/i386 : Insert unclaimed MMCONFIG resources.

. Signed-off-by: Aaron Durbin [EMAIL PROTECTED] --- Updated to reflect comments from [EMAIL PROTECTED] diff --git a/arch/i386/pci/mmconfig-shared.c b/arch/i386/pci/mmconfig-shared.c index 747d8c6..f5267c7 100644 --- a/arch/i386/pci/mmconfig-shared.c +++ b/arch/i386/pci/mmconfig-shared.c @@ -24,6 +24,9

[PATCH] acpi: Fix potential call to a freed memory section.

/ CONFIG_HOTPLUG_CPU=n - cat /sys/devices/system/node/node*/distance This will cause an oops by calling into a freed memory section. In particular, on x86_64, __node_distance calls node_to_pxm(). Signed-off-by: Aaron Durbin [EMAIL PROTECTED] --- diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c index

Re: [PATCH] acpi: Fix potential call to a freed memory section.

On 5/16/07, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 16 May 2007 09:09:11 -0700 Aaron Durbin [EMAIL PROTECTED] wrote: Strip __cpuinit[data] from Node - PXM routines and supporting data structures. Also make pxm_to_node_map and node_to_pxm_map local to the numa acpi module. This fixes

Re: [PATCH] Input: elan_i2c - do not clobber interrupt trigger on x86

hromebooks. > */ > - irqflags = dev->of_node ? 0 : IRQF_TRIGGER_FALLING; > + irqflags = irq_get_trigger_type(client->irq); > + if (!irqflags) > + irqflags = IRQF_TRIGGER_FALLING; > > error = devm_request_threaded_irq(dev, client->irq, NULL, elan_isr, > irqflags | IRQF_ONESHOT, > -- > 2.14.2.822.g60be5d43e6-goog Reviewed-by: Aaron Durbin <adur...@chromium.org>

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

On Wed, Mar 14, 2018 at 10:38 AM, Andy Shevchenko wrote: > On Wed, Mar 14, 2018 at 6:29 PM, Daniel Kurtz wrote: >> On Wed, Mar 14, 2018 at 4:54 AM Ricardo Ribalda Delgado < >> ricardo.riba...@gmail.com> wrote: >>> On Wed, Mar 14, 2018 at 1:36 AM,

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

On Fri, Apr 6, 2018 at 7:47 AM, Alan Cox wrote: >> But we don't have the full ACPI interpreter up in the early part of >> the kernel. All these 'early' devices have their own setup/config >> which is the source of the issue. Or maybe I am wrong about the full >>

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox wrote: >> Sadly, this situation >> is not unique to this hardware. There is hardware all over that does >> not meet the current assumptions being made in the early uart drivers >> within the kernel. > > Is there any

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

On Thu, Mar 29, 2018 at 6:34 AM, Alan Cox <gno...@lxorguk.ukuu.org.uk> wrote: > On Mon, 26 Mar 2018 20:56:45 -0600 > Aaron Durbin <adur...@chromium.org> wrote: > >> On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox <gno...@lxorguk.ukuu.org.uk> >> wrote: >>

Re: [PATCH v2] earlycon: Allow specifying a uartclk in options

On Thu, Mar 1, 2018 at 1:02 PM, Andy Shevchenko wrote: > On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz wrote: >> On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko >> wrote: > >> "earlycon simply does not utilize the

Re: [PATCH v2] earlycon: Allow specifying a uartclk in options

On Sat, Mar 3, 2018 at 8:38 AM, Andy Shevchenko <andy.shevche...@gmail.com> wrote: > On Thu, Mar 1, 2018 at 11:24 PM, Aaron Durbin <adur...@chromium.org> wrote: >> On Thu, Mar 1, 2018 at 1:02 PM, Andy Shevchenko >> <andy.shevche...@gmail.com> wrote: >>> On

Re: [PATCH v2] earlycon: Allow specifying a uartclk in options

On Sat, Mar 3, 2018 at 8:56 AM, Andy Shevchenko wrote: > On Fri, Mar 2, 2018 at 8:35 PM, Daniel Kurtz wrote: >> On Thu, Mar 1, 2018 at 1:02 PM Andy Shevchenko >> wrote: >>> On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz

[PATCH] mmconfig x86_64/i386 : Insert unclaimed MMCONFIG resources.

. Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]> --- diff --git a/arch/i386/pci/mmconfig-shared.c b/arch/i386/pci/mmconfig-shared.c index 747d8c6..c85a5f7 100644 --- a/arch/i386/pci/mmconfig-shared.c +++ b/arch/i386/pci/mmconfig-shared.c @@ -24,6 +24,9 @@ #define MMCONFIG_APER_MAX (256 * 1

[PATCH] mmconfig x86_64/i386 : Insert unclaimed MMCONFIG resources.

. Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]> --- Updated to reflect comments from [EMAIL PROTECTED] diff --git a/arch/i386/pci/mmconfig-shared.c b/arch/i386/pci/mmconfig-shared.c index 747d8c6..f5267c7 100644 --- a/arch/i386/pci/mmconfig-shared.c +++ b/arch/i386/pci/mmconfig-shared.c @@

[PATCH] acpi: Fix potential call to a freed memory section.

ured w/ CONFIG_HOTPLUG_CPU=n - cat /sys/devices/system/node/node*/distance This will cause an oops by calling into a freed memory section. In particular, on x86_64, __node_distance calls node_to_pxm(). Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]> --- diff --git a/drivers/acpi/numa.c b/drivers/acpi/

Re: [PATCH] acpi: Fix potential call to a freed memory section.

On 5/16/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Wed, 16 May 2007 09:09:11 -0700 Aaron Durbin <[EMAIL PROTECTED]> wrote: > Strip __cpuinit[data] from Node <-> PXM routines and supporting data structures. > Also make pxm_to_node_map and node_to_pxm_map local

[PATCH] ACPI: Add reboot mechanism

Add the ability to reset the machine using the RESET_REG in ACPI's FADT table. Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]> --- diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index d4336f1..c9906a5 100644 --- a/drivers/acpi/Makefile +++ b/drivers/acpi/Makefile @@ -21,7

[PATCH] x86_64: Add ACPI reboot option

Add the ability to reboot an x86_64 based machine using the RESET_REG in the FADT ACPI table. Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]> This patch relies on the ACPI reboot mechanism patch. diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-optio

[PATCH] x86_64: Make ACPI the default reset option

Make ACPI be the default reset method for x86_64. If the reset mechanism fails using ACPI, it will default to using the keyboard controller. Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]> --- This patch relies on the ACPI reboot mechanism patch. diff --git a/Documentation/x86_6

Re: [PATCH] ACPI: Add reboot mechanism

On 7/16/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote: On Mon, 2007-07-16 at 11:00 -0700, Aaron Durbin wrote: > Add the ability to reset the machine using the RESET_REG in ACPI's FADT table. > > Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]> > --- > > diff -

Re: [PATCH] ACPI: Add reboot mechanism

On 7/16/07, Shaohua Li <[EMAIL PROTECTED]> wrote: On Tue, 2007-07-17 at 02:00 +0800, Aaron Durbin wrote: > > Add the ability to reset the machine using the RESET_REG in ACPI's > FADT table. We could have another command for 'reboot' kernel command line. I did this in a

Re: [PATCH] ACPI: Add reboot mechanism

On 7/17/07, Yinghai Lu <[EMAIL PROTECTED]> wrote: On 7/17/07, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Monday 16 July 2007 20:00:19 Aaron Durbin wrote: > > > > Add the ability to reset the machine using the RESET_REG in ACPI's FADT table. > > Why?

Re: [PATCH] ACPI: Add reboot mechanism

On 7/17/07, Andi Kleen <[EMAIL PROTECTED]> wrote: On Monday 16 July 2007 20:00:19 Aaron Durbin wrote: > > Add the ability to reset the machine using the RESET_REG in ACPI's FADT table. Why? I had such a patch at some point as experiment, but it never helped actually fix a box.

Re: [PATCH] x86_64: Make ACPI the default reset option

On 7/17/07, Andi Kleen <[EMAIL PROTECTED]> wrote: On Monday 16 July 2007 20:02:21 Aaron Durbin wrote: > > Make ACPI be the default reset method for x86_64. If the reset mechanism fails > using ACPI, it will default to using the keyboard controller. Again why? You really can't

Re: [PATCH] ACPI: Add reboot mechanism

On 7/17/07, Andi Kleen <[EMAIL PROTECTED]> wrote: On Tuesday 17 July 2007 17:08:19 Aaron Durbin wrote: > This is true if SMIs are still flowing, and the SMI handler correctly handles > the reset properly. I have seen cases where the SMI handler is broken which > causes the system

[PATCH] i386/x86_64: Insert HPET firmware resource after PCI enumeration has completed

enumeration cannot reserve the resources. Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]> --- arch/i386/kernel/acpi/boot.c | 36 1 files changed, 36 insertions(+), 0 deletions(-) diff --git a/arch/i386/kernel/acpi/boot.c b/arch/i386/kernel/acpi/boot.c

Re: [PATCH] i386/x86_64: Insert HPET firmware resource after PCI enumeration has completed

On 7/6/07, Andi Kleen <[EMAIL PROTECTED]> wrote: On Friday 06 July 2007 00:27:24 Aaron Durbin wrote: > > Insert HPET resources after pci probing has been completed in order to avoid > resource conflicts with PCI resource reservation. With this change the > HPET

[PATCH] x86_64: Avoid NMI Watchdog and/or long wait in setup_APIC_timer

In setup_APIC_timer with the HPET in use, a condition can arise while waiting for the next irq slice to expire on the HPET which will either cause an NMI watchdog to fire or a 3 minute busy loop if the NMI watchdog is disabled. The HPET comparator and the counter keep incrementing during its

[PATCH] x86_64: Avoid NMI Watchdog and/or long wait in setup_APIC_timer

In setup_APIC_timer with the HPET in use, a condition can arise while waiting for the next irq slice to expire on the HPET which will either cause an NMI watchdog to fire or a 3 minute busy loop if the NMI watchdog is disabled. The HPET comparator and the counter keep incrementing during its

Re: [PATCH] x86_64: Avoid NMI Watchdog and/or long wait in setup_APIC_timer

On 8/8/07, Andi Kleen <[EMAIL PROTECTED]> wrote: > On Thursday 09 August 2007 01:17:19 Aaron Durbin wrote: > > In setup_APIC_timer with the HPET in use, a condition can arise while > > waiting for the next irq slice to expire on the HPET which will either > > cause an

[PATCH] x86_64: Avoid NMI Watchdog and/or long wait in setup_APIC_timer

the end of the tick slice. Signed-off-by: Aaron Durbin <[EMAIL PROTECTED]> --- This time w/ the 'Signed-off-by' line. I swear I am not trying to spam. diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c index 900ff38..06797e2 100644 --- a/arch/x86_64/kernel/apic.c +++ b/arch/

Re: [PATCH] x86_64: Avoid NMI Watchdog and/or long wait in setup_APIC_timer

On 8/9/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 8 Aug 2007 16:17:19 -0700 > Aaron Durbin <[EMAIL PROTECTED]> wrote: > > > In setup_APIC_timer with the HPET in use, a condition can arise while > > waiting for the next irq slice to expire on the HPET w

Re: [PATCH v2] earlycon: Allow specifying a uartclk in options

On Thu, Mar 1, 2018 at 1:02 PM, Andy Shevchenko wrote: > On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz wrote: >> On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko >> wrote: > >> "earlycon simply does not utilize the information". >> >> earlycon parses iotype, mapbase and baud (from options).

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

On Wed, Mar 14, 2018 at 10:38 AM, Andy Shevchenko wrote: > On Wed, Mar 14, 2018 at 6:29 PM, Daniel Kurtz wrote: >> On Wed, Mar 14, 2018 at 4:54 AM Ricardo Ribalda Delgado < >> ricardo.riba...@gmail.com> wrote: >>> On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz >> wrote: > >> In fact, the

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox wrote: >> Sadly, this situation >> is not unique to this hardware. There is hardware all over that does >> not meet the current assumptions being made in the early uart drivers >> within the kernel. > > Is there any fundamental reason you can't just

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

On Fri, Apr 6, 2018 at 7:47 AM, Alan Cox wrote: >> But we don't have the full ACPI interpreter up in the early part of >> the kernel. All these 'early' devices have their own setup/config >> which is the source of the issue. Or maybe I am wrong about the full >> interpreter and the early drivers

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

On Thu, Mar 29, 2018 at 6:34 AM, Alan Cox wrote: > On Mon, 26 Mar 2018 20:56:45 -0600 > Aaron Durbin wrote: > >> On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox >> wrote: >> >> Sadly, this situation >> >> is not unique to this hardware. There

Re: [PATCH v2] earlycon: Allow specifying a uartclk in options

On Sat, Mar 3, 2018 at 8:38 AM, Andy Shevchenko wrote: > On Thu, Mar 1, 2018 at 11:24 PM, Aaron Durbin wrote: >> On Thu, Mar 1, 2018 at 1:02 PM, Andy Shevchenko >> wrote: >>> On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz wrote: >>>> On Thu, Mar 1, 2018 at

Re: [PATCH v2] earlycon: Allow specifying a uartclk in options

On Sat, Mar 3, 2018 at 8:56 AM, Andy Shevchenko wrote: > On Fri, Mar 2, 2018 at 8:35 PM, Daniel Kurtz wrote: >> On Thu, Mar 1, 2018 at 1:02 PM Andy Shevchenko >> wrote: >>> On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz wrote: >>> > On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko < >>

Re: [PATCH] Input: elan_i2c - do not clobber interrupt trigger on x86

de ? 0 : IRQF_TRIGGER_FALLING; > + irqflags = irq_get_trigger_type(client->irq); > + if (!irqflags) > + irqflags = IRQF_TRIGGER_FALLING; > > error = devm_request_threaded_irq(dev, client->irq, NULL, elan_isr, > irqflags | IRQF_ONESHOT, > -- > 2.14.2.822.g60be5d43e6-goog Reviewed-by: Aaron Durbin