Il 19/02/2013 20:39, David Woodhouse ha scritto: > We'd need to fix SeaBIOS to use the 0xcf9 reset too; currently it'll sit > in an endless loop of keyboard-induced *soft* resets anyway, because it > tries that before 0xcf9. > > And in fact it probably shouldn't use the hard-coded 0xcf9 reset; it > should use the one indicated by the ACPI RESET_REG field (which *is* > 0xcf9... or should be).
We should implement this: http://mjg59.dreamwidth.org/3561.html > A while back I did some tests with Windows running on top of qemu. > This is a great way to evaluate OS behaviour, because you've got > complete control of what's handed to the OS and what the OS tries to > do to the hardware. And what I discovered was a little surprising. In > the absence of an ACPI reboot vector, Windows will hit the keyboard > controller, wait a while, hit it again and then give up. If an ACPI > reboot vector is present, windows will poke it, try the keyboard > controller, poke the ACPI vector again and try the keyboard > controller one more time. > > This turns out to be important. The first thing it means is that it > generates two writes to the ACPI reboot vector. The second is that it > leaves a gap between them while it's fiddling with the keyboard > controller. And, shockingly, it turns out that on most systems the > ACPI reboot vector points at 0xcf9 in system IO space. Even though > most implementations nominally require two different values be > written, it seems that this isn't a strict requirement and the ACPI > method works. Paolo
