3.0.4-rt14 "shutdown -h now" hangs on x86 32b

I have a couple of platforms (including the n450 dev board from kernel
summit) where an x86 32b build of 3.0.4-rt14 fails to shutdown with
"shutdown -h now". reboot works properly, and shutdown works with
maxcpus=1 (otherwise the n450 has 2 hardware threads).

The last messages to hit the console are:

e1000e 0000:04:00.0: PCI INT A disabled
ehci_hcd 0000:00:1d.7: PCI INT A disabled
ehci_hcd 0000:00:1a.7: PCI INT C disabled

I am booting from a USB stick. If I install to a SATA connected SSD, the
shutdown still fails, but I don't see the "INT X disabled" messages.

Has anyone run into this with a known workaround? Any thoughts on where
to start digging?

.config attached.
--

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

#
# Automatically generated make config: don't edit
# Linux/x86 3.0.4 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y

Re: 3.0.0-1-rt-amd64: Suspend hangs

Hello John,

On Fri, Sep 30, 2011 at 01:01:28AM +1000, johnohagan wrote:
> Running Debian testing on an HP Mini 5102 with non-RT kernel, suspend
> to ram, suspend to disk and resume work as expected. With the RT
> kernels from both testing and Sid, attempting to suspend may result in
> a lock-up, with a blank screen and high fan operation. Keyboard and
> Sysrq keys are unresponsive and a hard shutdown is necessary. This
> happens randomly AFAIKT, of the order of half the time, possibly more
> often if larger programs are running, but still occurs in single-user
> mode.
> 
> I ran the tests using /sys/power/pm_test described here:
> https://raw.github.com/torvalds/linux/master/Documentation/power/basic-pm-debugging.txt
> 
> The freeze occurs with pm_test set to "processors", but not with "platform". 
Can you please test the following two things:

 - Can you reproduce with the kernel parameter:

	maxcpus=1

   ?
 - Does onlining/offlining of the 2nd cpu work reliably? That is:

 	echo 0 > /sys/devices/system/cpu/cpu1/online
	echo 1 > /sys/devices/system/cpu/cpu1/online

Best regards
Uwe

0001-MIPS-Octeon-Mark-SMP-IPI-interrupt-as-IRQF_NO_THREAD.patch

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] MIPS: Octeon: Mark SMP-IPI interrupt as IRQF_NO_THREAD

From: Venkat Subbiah <venkat.subbiah <at> cavium.com>

This is to exclude it from force threading to allow RT patch set to work.
And while on this line
* Remove IRQF_DISABLED as as this flag is NOOP
* Add IRQF_PERCPU as this is a per cpu interrupt.

Signed-off-by: Venkat Subbiah <venkat.subbiah <at> cavium.com>
Acked-by: David Daney <david.daney <at> cavium.com>
---
 arch/mips/cavium-octeon/smp.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
index 8b60642..efcfff4 100644
--- a/arch/mips/cavium-octeon/smp.c
+++ b/arch/mips/cavium-octeon/smp.c
 <at>  <at>  -207,8 +207,9  <at>  <at>  void octeon_prepare_cpus(unsigned int max_cpus)
 	 * the other bits alone.
 	 */
 	cvmx_write_csr(CVMX_CIU_MBOX_CLRX(cvmx_get_core_num()), 0xffff);
-	if (request_irq(OCTEON_IRQ_MBOX0, mailbox_interrupt, IRQF_DISABLED,
-			"SMP-IPI", mailbox_interrupt)) {
+	if (request_irq(OCTEON_IRQ_MBOX0, mailbox_interrupt,
+			IRQF_PERCPU | IRQF_NO_THREAD, "SMP-IPI",
+			mailbox_interrupt)) {
 		panic("Cannot request_irq(OCTEON_IRQ_MBOX0)\n");
 	}
 }
--

-- 

Re: 0001-MIPS-Octeon-Mark-SMP-IPI-interrupt-as-IRQF_NO_THREAD.patch

On 10/03/2011 01:26 PM, Venkat Subbiah wrote:
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sorry for this empty message. Patch sent in another email.

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] MIPS: Octeon: Mark SMP-IPI interrupt as IRQF_NO_THREAD

On Mon, 3 Oct 2011, Venkat Subbiah wrote:

> From: Venkat Subbiah <venkat.subbiah <at> cavium.com>
> 
> This is to exclude it from force threading to allow RT patch set to work.
> And while on this line
> * Remove IRQF_DISABLED as as this flag is NOOP
> * Add IRQF_PERCPU as this is a per cpu interrupt.
> 
> 
> Signed-off-by: Venkat Subbiah <venkat.subbiah <at> cavium.com>
> Acked-by: David Daney <david.daney <at> cavium.com>

Acked-by: Thomas Gleixner <tglx <at> linutronix.de>

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] MIPS: Octeon: Mark octeon_wdt interrupt as IRQF_NO_THREAD

This is to exclude it from force threading to allow RT patch set to work.

The watchdog timers are per-CPU and the addresses of register that reset
the timer are calculated based on the current CPU.  Therefore we cannot
allow it to run on a thread on a different CPU.  Also we only do a
single register write, which is much faster than scheduling a handler
thread.

And while on this line remove IRQF_DISABLED as this flag is a NOP.

Signed-off-by: Venkat Subbiah <venkat.subbiah <at> cavium.com>
Acked-by: David Daney <david.daney <at> cavium.com>
---
 drivers/watchdog/octeon-wdt-main.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/watchdog/octeon-wdt-main.c b/drivers/watchdog/octeon-wdt-main.c
index 945ee83..7c0d863 100644
--- a/drivers/watchdog/octeon-wdt-main.c
+++ b/drivers/watchdog/octeon-wdt-main.c
 <at>  <at>  -402,7 +402,7  <at>  <at>  static void octeon_wdt_setup_interrupt(int cpu)
 	irq = OCTEON_IRQ_WDOG0 + core;

 	if (request_irq(irq, octeon_wdt_poke_irq,
-			IRQF_DISABLED, "octeon_wdt", octeon_wdt_poke_irq))
+			IRQF_NO_THREAD, "octeon_wdt", octeon_wdt_poke_irq))
 		panic("octeon_wdt: Couldn't obtain irq %d", irq);

 	cpumask_set_cpu(cpu, &irq_enabled_cpus);
--

-- 

Re: [PATCH] MIPS: Octeon: Mark octeon_wdt interrupt as IRQF_NO_THREAD

On 10/03/2011 04:30 PM, Venkat Subbiah wrote:
> This is to exclude it from force threading to allow RT patch set to work.
>
> The watchdog timers are per-CPU and the addresses of register that reset
> the timer are calculated based on the current CPU.  Therefore we cannot
> allow it to run on a thread on a different CPU.  Also we only do a
> single register write, which is much faster than scheduling a handler
> thread.
>
> And while on this line remove IRQF_DISABLED as this flag is a NOP.
>
>
> Signed-off-by: Venkat Subbiah<venkat.subbiah <at> cavium.com>
> Acked-by: David Daney<david.daney <at> cavium.com>
> ---
>   drivers/watchdog/octeon-wdt-main.c |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/watchdog/octeon-wdt-main.c b/drivers/watchdog/octeon-wdt-main.c
> index 945ee83..7c0d863 100644
> --- a/drivers/watchdog/octeon-wdt-main.c
> +++ b/drivers/watchdog/octeon-wdt-main.c
>  <at>  <at>  -402,7 +402,7  <at>  <at>  static void octeon_wdt_setup_interrupt(int cpu)
>   	irq = OCTEON_IRQ_WDOG0 + core;
>
>   	if (request_irq(irq, octeon_wdt_poke_irq,
> -			IRQF_DISABLED, "octeon_wdt", octeon_wdt_poke_irq))
> +			IRQF_NO_THREAD, "octeon_wdt", octeon_wdt_poke_irq))
>   		panic("octeon_wdt: Couldn't obtain irq %d", irq);
>

Re: 3.0.4-rt14 "shutdown -h now" hangs on x86 32b

Hi Darren,

i had the same problem on a Z530 with all RT kernels 3.0. I didn't 
search for the reason, however the problem went away when i used the 
"Intel Atom" at the "Processor family" option.

Best regards,
Simon

On 03.10.2011 20:15, Darren Hart wrote:
> I have a couple of platforms (including the n450 dev board from kernel
> summit) where an x86 32b build of 3.0.4-rt14 fails to shutdown with
> "shutdown -h now". reboot works properly, and shutdown works with
> maxcpus=1 (otherwise the n450 has 2 hardware threads).
>
> The last messages to hit the console are:
>
> e1000e 0000:04:00.0: PCI INT A disabled
> ehci_hcd 0000:00:1d.7: PCI INT A disabled
> ehci_hcd 0000:00:1a.7: PCI INT C disabled
>
> I am booting from a USB stick. If I install to a SATA connected SSD, the
> shutdown still fails, but I don't see the "INT X disabled" messages.
>
> Has anyone run into this with a known workaround? Any thoughts on where
> to start digging?
>
> .config attached.

Re: 3.0.4-rt14 "shutdown -h now" hangs on x86 32b

On Tue, 2011-10-04 at 09:52 +0200, Simon Sudler wrote: 
> Hi Darren,
> 
> i had the same problem on a Z530 with all RT kernels 3.0. I didn't 
> search for the reason, however the problem went away when i used the 
> "Intel Atom" at the "Processor family" option.

I see something similar at least on my Q6600 and E5620 boxen.

'poweroff' or shutting down from KDE doesn't always do so, sometimes
leaving boxen with a message saying it'll be halted immediately or such
on the screen, but requiring press/hold of power button to get box
really powered down.  I just tried Q6600 again to get exact quote, but
of course the little bugger powered down properly.

> On 03.10.2011 20:15, Darren Hart wrote:
> > I have a couple of platforms (including the n450 dev board from kernel
> > summit) where an x86 32b build of 3.0.4-rt14 fails to shutdown with
> > "shutdown -h now". reboot works properly, and shutdown works with
> > maxcpus=1 (otherwise the n450 has 2 hardware threads).
> >
> > The last messages to hit the console are:
> >
> > e1000e 0000:04:00.0: PCI INT A disabled
> > ehci_hcd 0000:00:1d.7: PCI INT A disabled
> > ehci_hcd 0000:00:1a.7: PCI INT C disabled
> >
> > I am booting from a USB stick. If I install to a SATA connected SSD, the
> > shutdown still fails, but I don't see the "INT X disabled" messages.
> >