Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Method 6: return to 16-bit mode, call interrupt 0x19 (not if you're on efi).

Method 7: return to 16-bit mode, set cs to 0xf000 and jump to 0xfff0.

Linux used to use method 6, but it wasn't reliable either. Something tells me returning to 16-bit mode might not be possible for some hardware / driver combinations.



Method 7 is available for 32-bit systems, and actually pretty reliable. But going from 64-bit to 16-bit just to reboot is more pain than anyone really wanted to go through.


Jumping to the BIOS is not a reliable reboot method either (method 7). Because the BIOS assumes hardware in a hardware-reset state, and the OS left it in some other state.

Tried to get an OS on a PC to soft-reboot, failed, because it is not actually possible to return all hardware to the reset state in some cases - they have an initial power-on state and once programmed can never return there unless hard-reset.

And why does the BIOS require hardware in the hard-reset state? Because a BIOS is never tested in a soft-reset scenarios, because Windows doesn't require it. And "if you haven't tried it, it doesn't work".


Note that this way of rebooting was common in DOS though.


Could you explain in more detail how these trigger a reboot? From writing a 32-bit kernel I understand how the triple fault method is supposed to work, for example, but would love to know a little more about these methods.


int 19 should just execute code in the BIOS that triggers a reboot. Setting CS and jumping is re-entering the BIOS at the same entry point as at power-on. The BIOS should then reinit all the hardware.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: