I wrote about some of this in 2011 (https://mjg59.livejournal.com/137313.html https://mjg59.livejournal.com/137313.html), but even in 2003 this wasn't great adv

I wrote about some of this in 2011 (https://mjg59.livejournal.com/137313.html https://mjg59.livejournal.com/137313.html), but even in 2003 this wasn't great advice - attempting to reboot a system like this would probably work most of the time, but it certainly wasn't guaranteed. The key point is that you're simply jumping back to the initialisation code, not actually resetting anything. If that code makes assumptions about hardware state then you'll end up with bad outcomes. The traditional way to reset PC-class machines for decades was to perform some register writes to the keyboard controller, which in turn would assert the reset line to the CPU. More modern systems don't necessarily even bother emulating a keyboard controller so that doesn't work so well, so instead there's an address on the motherboard chipset that'll usually trigger a reset, and this can be exposed via ACPI tables (although see the blog post I linked for more details). But while it's not a great idea, would it still work on modern x86 that doesn't even have BIOS? Great question, but I suspect not. The CPU is still going to start reading instructions from the same address, but these days CPU state at the point of reading the first instruction is rather more complicated than it used to be. For instance, if you have an Intel system that has Boot Guard enabled, before the CPU starts reading anything from the reset vector it's already pulled an Authenticated Code Module out of flash and run that, and that's going to have set up Cache As RAM and enabled various other things, and it's much easier for modern firmware to make assumptions about that state than it would be if the OS just handed control back there. You're also going to be dealing with graphics hardware that's way more complicated than it used to be, and the question of whether the firmware driver for your graphics card is going to be able to reinitialise it from whatever state your OS left it in. But more importantly - modern hardware has a whole bunch of "write once" bits, and if you simply jump back to init code without asserting reset, those aren't going to be cleared. Firmware code is going to expect to be able to access resources that it's no longer allowed to access, because those protection bits have been set and never cleared. A big part of that is System Management Mode, a bunch of protected code that runs on the main CPU but which can't be accessed by the OS. Jumping to firmware init isn't going to unlock access to the SMM region, and anything that's mediated by SMM is probably going to be inaccessible, so the firmware's going to have an extremely bad time. I don't want to be too critical of the original post, which would probably work most of the time in 2003 (although even then a bunch of systems would probably break if you tried). But these days you really shouldn't have any expectation that this will work, simply because systems today are really pretty different to 20 years ago.