3

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.

  • 1
    Do the system logs say anything of relevance? – a CVn Jun 26 '13 at 9:53
  • 3
    @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 4 '13 at 21:25
  • @Bob same issue. – tshepang Jul 5 '13 at 7:50
2

There's a few ways:

sudo reboot
sudo init 6
sudo /sbin/reboot 

You may also like to give this a try

echo 1 > /proc/sys/kernel/sysrq

echo b > /proc/sysrq-trigger

If you've got freedesktop-compliant session manager, you can use DBus to invoke restart from inside the X session. The command goes:

dbus-send --system --dest=org.freedesktop.Hal --type=method_call \
    --print-reply /org/freedesktop/Hal/devices/computer \
    org.freedesktop.Hal.Device.SystemPowerManagement.Reboot int32:0

(this is probably more than necessary; works for me). I use this in a shell script. You don't need to run this from root, but you need to run it from inside an X session (f.e. in a terminal). You can find more on this topic at https://wiki.ubuntu.com/DebuggingGNOMEPowerManager

If you still get the problem , show the output of the last reboot command which will show a log of all reboots since the log file was created under Linux, enter:

# last reboot

I think the problem may be due to this bug and this bug . Try upgrading your kernel by following the method :

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

  • I don't run X, so no session manager. – tshepang Jul 1 '13 at 7:35
  • What about the other options ? Have you tried them all . And what is your output of last reboot – tusharmakkar08 Jul 1 '13 at 7: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 1 '13 at 7:56
  • I have also tried sudo init 6, and saw the same issue. Lemme try /sbin/reboot. – tshepang Jul 1 '13 at 7: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 1 '13 at 8:03
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!

1

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

  • 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 2 '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 5 '13 at 2:29
  • I updated the Question. – tshepang Jul 5 '13 at 8:00
  • @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 6 '13 at 13:16
1
+100

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

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.

0

Try init 6 instead of reboot.

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

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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.