Crash after shutdown

[warped-rudi]

When shutting down the system people experience a crash like this:

    [ 4535.825460] reboot: Power down
    [ 4535.832833] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
    [ 4535.832833]
    [ 4539.724102] ------------[ cut here ]------------
    [ 4539.728768] WARNING: CPU: 0 PID: 1 at kernel/time/tick-broadcast.c:604 tick_handle_oneshot_broadcast+0x1d8/0x200()
    [ 4539.739125] Modules linked in: bnep bluetooth 6lowpan_iphc brcmfmac brcmutil cfg80211 rfkill joydev ir_lirc_codec c
    [ 4539.765959] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.14.14-cubox-i #1
    [ 4539.773234] [<80015478>] (unwind_backtrace) from [<80011620>] (show_stack+0x10/0x14)
    [ 4539.781010] [<80011620>] (show_stack) from [<806ea118>] (dump_stack+0x84/0x94)
    [ 4539.788269] [<806ea118>] (dump_stack) from [<8002b964>] (warn_slowpath_common+0x70/0x8c)
    [ 4539.796387] [<8002b964>] (warn_slowpath_common) from [<8002ba1c>] (warn_slowpath_null+0x1c/0x24)
    [ 4539.805200] [<8002ba1c>] (warn_slowpath_null) from [<8007eed4>] (tick_handle_oneshot_broadcast+0x1d8/0x200)
    [ 4539.814974] [<8007eed4>] (tick_handle_oneshot_broadcast) from [<800221b8>] (mxc_timer_interrupt+0x2c/0x34)
    [ 4539.824665] [<800221b8>] (mxc_timer_interrupt) from [<8006c33c>] (handle_irq_event_percpu+0x54/0x180)
    [ 4539.833911] [<8006c33c>] (handle_irq_event_percpu) from [<8006c4ac>] (handle_irq_event+0x44/0x64)
    [ 4539.842807] [<8006c4ac>] (handle_irq_event) from [<8006f430>] (handle_fasteoi_irq+0x80/0x158)
    [ 4539.851354] [<8006f430>] (handle_fasteoi_irq) from [<8006bb04>] (generic_handle_irq+0x2c/0x3c)
    [ 4539.859991] [<8006bb04>] (generic_handle_irq) from [<8000eb80>] (handle_IRQ+0x40/0x90)
    [ 4539.867929] [<8000eb80>] (handle_IRQ) from [<800084e8>] (gic_handle_irq+0x2c/0x5c)
    [ 4539.875528] [<800084e8>] (gic_handle_irq) from [<806efb40>] (__irq_svc+0x40/0x50)
    [ 4539.883022] Exception stack(0xdc093dc0 to 0xdc093e08)
    [ 4539.888095] 3dc0: 0001ae04 ffffffff 00000182 802b3d88 00000057 80a336a4 00000ed8 00000fa0
    [ 4539.896291] 3de0: 00000000 80a601f0 00000000 dc0a0000 00000000 dc093e08 806e6e40 802b3db8
    [ 4539.904480] 3e00: 200f0013 ffffffff
    [ 4539.908000] [<806efb40>] (__irq_svc) from [<802b3db8>] (__loop_delay+0x0/0x10)
    [ 4539.915236] ---[ end trace 2755275968036b0d ]---

It does no harm, since the file system has already been closed. I did not yet find out the root cause, but it only happens, when the kernel receives LINUX_REBOOT_CMD_POWER_OFF. It does not happen on LINUX_REBOOT_CMD_HALT. Looking at the code I stumbled over commit d3e1746 (ENGR00243120). This add a default power off handler, which causes the kernel to call machine_power_off() instead of machine_halt(). The main difference between the two is, that the latter does not return while the first one does. The crash happens after the return and looking here and here we are not the only people having problems with this.
The question is how to fix it. The power off handler introduced by ENGR00243120 seems to have no effect on most iMX boards. So I don't think it should be installed by default. Maybe this could be controlled by a *.dts entry. Furthermore I don't really understand the difference in behavior between machine_halt() and machine_power_off(). I would have expected both to behave identically in case the power off function does not what it is supposed to do. Also I'm wondering if the ARM has something like Intel's HLT instruction to replace the busy loop in order to reduce power consumption in this state.

[linux4kix]

I have accepted that upstream patch because as you know the Cubox-i and
hummingboard do not power off. I need to hook into machine_power_off so I
can then put the machine in the safest, lowest power mode possible while
still on.

The crash is trivial and happens because local irqs have been disabled but
not all drivers have disabled their interrupts properly. It is on my list
but not a priority because we get far enough into the halt that nothing bad
can become of it.

On Mon, Sep 15, 2014 at 11:22 AM, Rudi Ihle [email protected]
wrote:

When shutting down the system people experience a crash like this:

[ 4535.825460] reboot: Power down
[ 4535.832833] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[ 4535.832833]
[ 4539.724102] ------------[ cut here ]------------
[ 4539.728768] WARNING: CPU: 0 PID: 1 at kernel/time/tick-broadcast.c:604 tick_handle_oneshot_broadcast+0x1d8/0x200()
[ 4539.739125] Modules linked in: bnep bluetooth 6lowpan_iphc brcmfmac brcmutil cfg80211 rfkill joydev ir_lirc_codec c
[ 4539.765959] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 3.14.14-cubox-i #1
[ 4539.773234] [<80015478>] (unwind_backtrace) from [<80011620>] (show_stack+0x10/0x14)
[ 4539.781010] [<80011620>] (show_stack) from [<806ea118>] (dump_stack+0x84/0x94)
[ 4539.788269] [<806ea118>] (dump_stack) from [<8002b964>] (warn_slowpath_common+0x70/0x8c)
[ 4539.796387] [<8002b964>] (warn_slowpath_common) from [<8002ba1c>] (warn_slowpath_null+0x1c/0x24)
[ 4539.805200] [<8002ba1c>] (warn_slowpath_null) from [<8007eed4>] (tick_handle_oneshot_broadcast+0x1d8/0x200)
[ 4539.814974] [<8007eed4>] (tick_handle_oneshot_broadcast) from [<800221b8>] (mxc_timer_interrupt+0x2c/0x34)
[ 4539.824665] [<800221b8>] (mxc_timer_interrupt) from [<8006c33c>] (handle_irq_event_percpu+0x54/0x180)
[ 4539.833911] [<8006c33c>] (handle_irq_event_percpu) from [<8006c4ac>] (handle_irq_event+0x44/0x64)
[ 4539.842807] [<8006c4ac>] (handle_irq_event) from [<8006f430>] (handle_fasteoi_irq+0x80/0x158)
[ 4539.851354] [<8006f430>] (handle_fasteoi_irq) from [<8006bb04>] (generic_handle_irq+0x2c/0x3c)
[ 4539.859991] [<8006bb04>] (generic_handle_irq) from [<8000eb80>] (handle_IRQ+0x40/0x90)
[ 4539.867929] [<8000eb80>] (handle_IRQ) from [<800084e8>] (gic_handle_irq+0x2c/0x5c)
[ 4539.875528] [<800084e8>] (gic_handle_irq) from [<806efb40>] (__irq_svc+0x40/0x50)
[ 4539.883022] Exception stack(0xdc093dc0 to 0xdc093e08)
[ 4539.888095] 3dc0: 0001ae04 ffffffff 00000182 802b3d88 00000057 80a336a4 00000ed8 00000fa0
[ 4539.896291] 3de0: 00000000 80a601f0 00000000 dc0a0000 00000000 dc093e08 806e6e40 802b3db8
[ 4539.904480] 3e00: 200f0013 ffffffff
[ 4539.908000] [<806efb40>] (__irq_svc) from [<802b3db8>] (__loop_delay+0x0/0x10)
[ 4539.915236] ---[ end trace 2755275968036b0d ]---

It does no harm, since the file system has already been closed. I did not
yet find out the root cause, but it only happens, when the kernel receives
LINUX_REBOOT_CMD_POWER_OFF. It does not happen on LINUX_REBOOT_CMD_HALT.
Looking at the code I stumbled over commit d3e1746
d3e1746
(ENGR00243120). This add a default power off handler, which causes the
kernel to call machine_power_off()
https://github.com/linux4kix/linux-linaro-stable-mx6/blob/linux-linaro-lsk-v3.14-mx6/arch/arm/kernel/process.c#L215
instead of machine_halt()
https://github.com/linux4kix/linux-linaro-stable-mx6/blob/linux-linaro-lsk-v3.14-mx6/arch/arm/kernel/process.c#L200.
The main difference between the two is, that the latter does not return
while the first one does. The crash happens after the return and looking
here
http://lists.infradead.org/pip%20ermail/linux-arm-kernel/2012-August/114864.html
and here https://lkml.org/lkml/2014/3/24/299 we are not the only people
having problems with this.
The question is how to fix it. The power off handler introduced by
ENGR00243120 seems to have no effect on most iMX boards. So I don't think
it should be installed by default. Maybe this could be controlled by a
*.dts entry. Furthermore I don't really understand the difference in
behavior between machine_halt() and machine_power_off(). I would have
expected both to behave identically in case the power off function does not
what it is supposed to do. Also I'm wondering if the ARM has something like
Intel's HLT instruction to replace the busy loop in order to reduce power
consumption in this state.

—
Reply to this email directly or view it on GitHub
#17.

[warped-rudi]

The oops can probably be avoided by stopping the GPT. But to me it appears that when machine_power_off() or machine_halt() return to their callers we do get this 'Attempted to kill init' panic.

BTW, here is a slightly improved version of the patch. Do you want a PR?