Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am in the process of testing a fanless, atom based PC for use in an embedded application. I am running Voyage Linux version 0.7.5 on the machine. This distribution is derived from Debian Lenny. Everything works great except I can't get the shut down command to perform a reboot. This is important in this application because it provides us a way to perform a remote reset should that be needed.

Looking at the terminal, the last two messages on the screen show the following:

[ 219.974475] ehci_hcd 0000:00:1d.7: PCI INT D disabled
[ 219.974657] Restarting system.
[ 219.974754] machine restart

At this point, the machine sticks and will not reboot until I cut the power or perform a hardware reset. I recall seeing this sort of thing (at least with a shutdown) when running the OS under VirtualBox.

I really know very little about the interaction with the kernel and the machine at this point so I am asking if anyone knows if there are potential kernel configurations that cam cause this kind of problem.

Edit:

Having been asked if the system supports ACPI, I took a closer look at the boot log. I found the following message:

[   3.99748] ACPI: resource (null) [io 0x0480-0x04bf] conflicts with ACPI region PHO_ [io 0x4bc-0x4bc]
share|improve this question
3  
Is ACPI enabled on the system? –  rozcietrzewiacz Aug 24 '11 at 18:11
    
Looking at the boot log for the device, I can see "ACPI: ACPI bus type pnp unregistered". This is preceded by "pnp: PnP ACPI: found 14 devices". I can also see references to an ACPI "power" and "sleep" buttons. –  Jon Trauntvein Aug 24 '11 at 18:42

1 Answer 1

Very strange for the shutdown to get to that point and not work.

Things to try:

  • Apply any available BIOS updates to the board. Try also resetting BIOS options to default.
  • See if there is an updated kernel in your distribution. Might try compiling your own.
  • I think there's a kernel compiling option that tells the kernel not to overwrite the first 1Mbyte of RAM where the BIOS can possibly store information it needs for things. Perhaps you need to run a kernel with this enabled if it isn't already.
  • Find out what chipset is on your board and google it to see if there are any known incompatibilites or workarounds.
  • If all else fails, you might look into what kexec can do although it's not equivalent to a hardware reset.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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