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.

tshepang
  • 65,642

7 Answers7

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

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!

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
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.

tshepang
  • 65,642
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

slm
  • 369,824
  • 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
  • I updated the Question. – tshepang Jul 05 '13 at 08: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 06 '13 at 13:16
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

neonzeon
  • 400
0

Try init 6 instead of reboot.

slm
  • 369,824
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!