Reboot hangs on Acer Aspire One ZG5 -- suggestions?

[philip]

Tinycore 4.1 won't reboot my Acer Aspire One netbook (the original, model ZG5). To isolate the issue, I choose "Exit to Prompt" from the menu in my flwm session to get right down to the console. There I type the command "sudo ./sbin/reboot". The TC scripts do all their work, and the line "Requesting system restart" appears on the console. Then the screen goes black, but the system doesn't restart.

By contrast, the shutdown command works fine. And Ubuntu can make the machine restart.

This is not a completely clean TC install: I upgraded from version 3.x by replacing just the kernel and initrd (from the distribution-files section of the downloads page), then running the application updater. The apps-audit now says my system is fully up-to-date.

I expect this problem might originate outside TC, but hope for yet one more example of smart TC people solving problems of a general nature. Any ideas? Thanks!

[2011-12-07: edited post title because issue appears hardware-specific.]

[Rich]

Hi philip
Does it still hang if you use:

Code: [Select]

sudo ./sbin/reboot -f

[Rich]

Hi philip
Even if the above suggestion works, this article might provide some better alternatives;
http://linux.koolsolutions.com/2009/08/04/howto-fix-linux-hangfreeze-during-reboots-and-restarts/

[philip]

Thanks a lot, Rich. Unfortunately neither your suggestion (the -f flag) nor the suggested reading (many options for the kernel command line) cracked this problem. The reference you supplied really got my hopes up, because it explained that the Intel Atom CPU might need an approach different from the Linux default. But, sadly, I am still in the same situation.

[Rich]

Hi philip
Not sure what else you can do at this point except maybe burn a 4.1 disc and boot it. Then see if
reboot works. This should tell you if it''s the new 3.0 kernel or the method used to upgrade.

[roberts]

Tiny Core running on several Intel Atom machines (Asus and Dell) here and no problem with reboot.
Have you tried just booting base norestore to eliminate the possibility it is caused by an extension?
Have your tried reboot -b   

[Rich]

Hi roberts
What's -b do? When I type  reboot --help all I get is:

BusyBox v1.17.2 (2010-09-24 12:19:23 PDT) multi-call binary.

Usage: reboot [-d DELAY] [-n] [-f]

Reboot the system

Options:
        -d      Delay interval for rebooting
        -n      No call to sync()
        -f      Force reboot (don't go through init)

[philip]

Thank you both. Indeed the command "sudo /sbin/reboot -b" triggers only the diagnostic message Rich quotes above, and I had been booting with "base norestore" for most (but not all) of my tests just to speed up the boot cycles.

I then tried comparing the kernel config files between TC and Ubuntu, but a simple diff indicated over 2800 lines that disagreed, and I gave up on trying to find the needle in a haystack that just might explain why one works and the other doesn't. I'm getting closer to just learning to live with this little hiccup: it doesn't prevent useful work getting done, after all. But if anyone has another good idea, I'm game to give it a try. Again, my thanks and warm regards.

[curaga]

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b49c78d4827be8d7e67e5b94adac6b30a4a9ad14

This commit says "reboot=bios" should work for the affected kernels.

edit:
https://bbs.archlinux.org/viewtopic.php?pid=974654

Arch says that doesn't work and the right fix is "reboot=k". YMMV.

[philip]

Thanks, will try this tonight.

PS for RobertS: I too have another Atom board where TC 4.1 reboots just fine. So my laptop situation must be pretty rare. Thanks for taking an interest.

[roberts]

Sorry I cannot reproduce your situation. I guess the reboot -b was from olden days! As I recall I had an odd celeron that required it.
Apparently that option is no more.

[philip]

YMMV? Indeed, MMDV (my mileage did vary) - unfortunately, it was 0 successes per N attempts. The discussion on the Arch Linux board is interesting, and it suggests that recompiling the kernel to revert some recent upstream patch may be the way to fix this. Let me take this issue offline as I compare the nuisance of the issue with the effort of such a major intervention. Thanks again.