Rebooting fails randomly

Question

That is, the following command fails at times:

$ sudo reboot

The last message on terminal, after which the machine gets stuck, requiring a power cycle:

Restarting system.

I tried the following reboot= boot parameters (source) without success:

warm
cold
triple
acpi
force
efi

As advised on that page, I verified by running the following command to ensure the changes took effect:

$ cat /proc/cmdline

In case it might be helpful, here's a list of kernel modules:

$ lsmod 
Module                  Size  Used by
ppp_generic            16680  0 
slhc                    4055  1 ppp_generic
ath9k_htc              50685  0 
mac80211              231186  1 ath9k_htc
ath9k_common            1720  1 ath9k_htc
ath9k_hw              338115  2 ath9k_htc,ath9k_common
ath                    13793  3 ath9k_htc,ath9k_common,ath9k_hw
cfg80211              158343  3 ath9k_htc,mac80211,ath
compat                 29364  5 ath9k_htc,mac80211,ath9k_common,ath9k_hw,cfg80211

This is on an ARM system, running a custom-built Linux 2.6.35. Also, there is no X server installed, so no Desktop Environment.

@Tshepang - you could try one of the kernel "reboot=" parameters (many similar cases are "cured" with reboot=pci; YMMV). — don_crissti, Jun 26 '13 at 10:30
@MichaelKjörling Which logs must I look at? /var/log/syslog looks fine. — tshepang, Jun 26 '13 at 11:18
Just wondering: does "sudo shutdown -r now" work the same (i.e. doesn't work :)? — Boris Burkov, Jul 04 '13 at 21:25
This could be (sound like) a BIOS bug. Did you try to upgrade your BIOS to latest version? — F. Hauri - Give Up GitHub, Jul 05 '13 at 18:18

score 2 · Answer 1 · edited Apr 13 '17 at 12:22

2

There's a few ways:

sudo reboot

sudo init 6

sudo /sbin/reboot

Upgrade of the kernel in Debian or Ubuntu Linux

Use apt-get command. First find your kernel version:

$ uname -r

Next find available kernel images:

$ apt-cache search linux-image

Now install kernel by explicitly specifying version number:

# apt-get install linux-image-x.x.x-xx

OR

$ sudo apt-get install linux-image-x.x.x-xx

update:

After doing this you may also try setting the reboot=pci kernel boot flag . To make the change permanent, add the rebooot=pci flag to the GRUB_CMDLINE_LINUX line of /etc/default/grub. For more information check out this link and this link

edited Apr 13 '17 at 12:22

Community

1

answered Jul 01 '13 at 07:28

tusharmakkar08

1,845

I don't run X, so no session manager. – tshepang Jul 01 '13 at 07:35
What about the other options ? Have you tried them all . And what is your output of last reboot – tusharmakkar08 Jul 01 '13 at 07:44
last reboot gets me entries looking like reboot system boot 2.6.35.3-1129-g6 Mon Jul 1 07:54 - 07:55 (00:00), whether or not I had a failing reboot. – tshepang Jul 01 '13 at 07:56
I have also tried sudo init 6, and saw the same issue. Lemme try /sbin/reboot. – tshepang Jul 01 '13 at 07:58
Basically last reboot shows that whether your previous reboot was successful or not .That is it tells at what time and date last successful reboot was done . – tusharmakkar08 Jul 01 '13 at 08:03
/sbin/reboot fails too. – tshepang Jul 01 '13 at 08:04
In that case, last reboot claims the reboot was successful, even though it wasn't. – tshepang Jul 01 '13 at 08:56
@Tshepang : I think the problem is due to a bug.Try Upgrading the kernel using the method . Do check the updated answer. – tusharmakkar08 Jul 01 '13 at 09:13
let us continue this discussion in chat – tshepang Jul 01 '13 at 09:29

neonzeon · Answer 2 · 2013-07-05T18:11:21.120

2

It might be time to consider grabbing the bull by the horns and learn some kernel debugging.

First, find a JTAG probe that's compatible with gdb-remote. You're using an ARM, so you should have many options, for example see http://openocd.sourceforge.net/doc/html/Debug-Adapter-Hardware.html

Secondly, there's work... "man up" on Kernel Debugging. Google is your friend, but this one provides an excellent initial overview and some search terms: http://www.elinux.org/DebuggingTheLinuxKernelUsingGdb

You could have many new concepts to absorb. This video provides a good high-level view of the process: http://www.youtube.com/watch?v=q07VvWS1qBc

http://www.wikihow.com/Solve-a-Problem has great advice on solving tough problems. GL!

edited Jul 05 '13 at 18:11

answered Jul 04 '13 at 20:15

neonzeon

400

Thanks for the encouragement. Me loves the man and bull references :) – tshepang Jul 05 '13 at 07:52
1

@Tshepang haha - that "man" has more to do with "manual" :) Also, you might find the linux-arm-kernel mailing list handy http://www.arm.linux.org.uk/mailinglists/lists.php Also, take a look at this http://unix.stackexchange.com/questions/64280/what-is-the-difference-between-reboot-init-6-and-shutdown-r-now – neonzeon Jul 05 '13 at 18:17

tshepang · Accepted Answer · 2013-11-05T18:45:17.720

1

There is actually an age-old fix for this particular issue of mine. I wish I could have (magically) known about it before ~~wasting~~ spending so much time on it.

As a sidenote, the system is a VAB-800, which uses a Freescale i.MX537 Cortex-A8 SoC.

edited Nov 05 '13 at 18:45

answered Jun 27 '13 at 08:17

tshepang

65,642

score 1 · Answer 4 · answered Jul 02 '13 at 06:12

Here's something to explore/check. I found this bit in a commit log for the ARM Tegra commit log for kernel version 2.6.39:

Simon Glass (1):
ARM: tegra: Fix hang on reboot

I think this is the patch that Simon's commit, titled: [PATCH 7/7] ARM: tegra: fix hang on reboot, is referring to:

From: Simon Glass <sjg@...>

We cannot use writel() here since the resulting wmb() calls l2x0_cache_sync()
which uses a spinlock and L1 cache may be off at this point.

Signed-off-by: Simon Glass <sjg@...>
Signed-off-by: Olof Johansson <olof@...>
---
 arch/arm/mach-tegra/common.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index 34559d1..b1ecf60 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
 <at>  <at>  -41,7 +41,7  <at>  <at>  void tegra_assert_system_reset(char mode, const char *cmd)

    reg = readl(reset);
    reg |= 0x04;
-   writel(reg, reset);
+   writel_relaxed(reg, reset);
 }

 static __initdata struct tegra_clk_init_table common_clk_init_table[] = {
--

I think you'll either need to backport this change to 2.6.35 or move up to the newer kernel.

References

Index » linux : Commit 375b19

Sadly, I don't have such a directory. My system has a Freescale i.MX537 Cortex-A8 processor. Searching the kernel sources, there is not even a write1_relaxed function. — tshepang, Jul 02 '13 at 10:22
@Tshepang - Can you provide us with a list of the kernel modules you have loaded? I'm thinking that one of these drivers is the culprit. — slm, Jul 05 '13 at 02:29
@Tshepang - does the problem persist if you manually unload the ath9k* modules? If wouldn't mind testing out this hypothesis I'd appreciate it. You'll need to manually unload it each time you're about to test this. — slm, Jul 06 '13 at 13:16

score 1 · Answer 5 · answered Jul 06 '13 at 20:59

1

See Freescale application note "Using Open Source Debugging Tools for Linux on i.MX Processors" http://cache.freescale.com/files/32bit/doc/app_note/AN4553.pdf

Especially Chapter 8 - "First Steps for Using KGDB for Linux Kernel Debug"

There is a patch for Freescale Linux kernel which allows serial port kernel debugging - https://gist.github.com/bikeNomad/4033368.

Some kernel hackers swear they can figure anything with printk. See http://www.linuxchix.org/content/courses/kernel_hacking/lesson5

answered Jul 06 '13 at 20:59

neonzeon

400

Tshepang - were you able to hunt down the bug? – neonzeon Jul 19 '13 at 07:17
http://unix.stackexchange.com/a/80855 – tshepang Nov 05 '13 at 18:40

score 0 · Answer 6 · edited Jul 02 '13 at 05:45

0

Try init 6 instead of reboot.

edited Jul 02 '13 at 05:45

slm

369,824

answered Jun 26 '13 at 21:38

dperry1973

319

I see the same problem... it fails to reboot sometimes, forcing a power cycle. – tshepang Jun 27 '13 at 06:53

score 0 · Answer 7 · answered Jul 05 '13 at 19:33

This could be a BIOS issue.

You may try to

upgrade your BIOS (from constructor website)
run linux in disabling some bios features at boot command line, like noapic, vga=0x0f00, pci=nobios or else...

To find whats' wrong, browsing log are usefull, but not only the logs where the system hangs, but reading logs where all was perfect could help too:

One way could be to run a kind of loop, where you

reboot
mark the kernel.log : echo >>kernlogpos.lst $(wc -l </var/log/kern.log) Ok|Bad
loop

After some loop with and without bug you may obtain a trace file that look like:

19845 first
20451 Ok
21057 Ok
21676 Bad
22282 Ok
22888 Ok

Than you could search for difference (using bash):

diff <(
  sed -ne </var/log/kern.log '21057,21676{s/^.\{15\}\s\S\+\skernel:\s\[\S\+\]\s//p;}'
  ) <(
sed -ne </var/log/kern.log '21676,22282{s/^.\{15\}\s\S\+\skernel:\s\[\S\+\]\s//p;}'
)

Good luck!

Rebooting fails randomly

7 Answers7

Upgrade of the kernel in Debian or Ubuntu Linux

update:

References