This shows you the differences between two versions of the page.
|
internal:kernel-big-lock-reboot [2010/02/20 12:04] solar clarified that the "keyboard controller" being referred to is the one on the motherboard, not the one in the keyboard (so a keyboard is not required for this to work) |
internal:kernel-big-lock-reboot [2010/09/23 12:23] (current) solar added a "shell command version" of the program |
||
|---|---|---|---|
| Line 14: | Line 14: | ||
| </code> | </code> | ||
| - | This program is asking the PC AT keyboard controller on the motherboard to pulse the reset line, as described, for example, [[http://stanislavs.org/helppc/8042.html|here]]. This is specific to PC-compatible x86 systems indeed. The machine we actually used this trick on was fairly modern - it had the [[http://www.supermicro.com/products/motherboard/xeon1333/5000V/X7DVL-E.cfm|Supermicro X7DVL-E motherboard]], which uses the Intel 5000V (Blackford VS) chipset and can run up to two quad-core Xeon CPUs. There's no longer a separate 8042 chip, yet the functionality remained. | + | Alternatively: |
| + | |||
| + | <code> | ||
| + | echo -en '\xfe' | dd of=/dev/port seek=100 bs=1 count=1 | ||
| + | </code> | ||
| + | |||
| + | This program/command is asking the PC AT keyboard controller on the motherboard to pulse the reset line, as described, for example, [[http://stanislavs.org/helppc/8042.html|here]]. This is specific to PC-compatible x86 systems indeed. The machine we actually used this trick on was fairly modern - it had the [[http://www.supermicro.com/products/motherboard/xeon1333/5000V/X7DVL-E.cfm|Supermicro X7DVL-E motherboard]], which uses the Intel 5000V (Blackford VS) chipset and can run up to two quad-core Xeon CPUs. There's no longer a separate 8042 chip, yet the functionality remained. | ||
| The "official" ways to reboot would not work because the reboot(2) syscall starts by trying to acquire the Big Kernel Lock, so it would get stuck. Yet, despite of the Big Kernel Lock, it was possible to SSH into the server, stop most processes, and remount the filesystems read-only. All of this was with an OpenVZ kernel from their "rhel5" branch, and it shows that recent kernel versions make very little use of the Big Kernel Lock (they use fine-grained locking or data structures not requiring locking instead). | The "official" ways to reboot would not work because the reboot(2) syscall starts by trying to acquire the Big Kernel Lock, so it would get stuck. Yet, despite of the Big Kernel Lock, it was possible to SSH into the server, stop most processes, and remount the filesystems read-only. All of this was with an OpenVZ kernel from their "rhel5" branch, and it shows that recent kernel versions make very little use of the Big Kernel Lock (they use fine-grained locking or data structures not requiring locking instead). | ||
| Also relevant is the fact that this specific Linux system had ''kernel.panic_on_oops'' set to 0. This is the default with mainstream Linux kernels, but Red Hat (and thus official OpenVZ kernels based on Red Hat's) are changing the default to 1. If ''kernel.panic_on_oops'' were 1 and ''kernel.panic'' was 0 (the default), the server would get stuck and we would not be able to recover it remotely on our own. On the other hand, if ''kernel.panic_on_oops'' was set to 1 and ''kernel.panic'' to non-zero, the server would reboot on its own (after the specified number of seconds). | Also relevant is the fact that this specific Linux system had ''kernel.panic_on_oops'' set to 0. This is the default with mainstream Linux kernels, but Red Hat (and thus official OpenVZ kernels based on Red Hat's) are changing the default to 1. If ''kernel.panic_on_oops'' were 1 and ''kernel.panic'' was 0 (the default), the server would get stuck and we would not be able to recover it remotely on our own. On the other hand, if ''kernel.panic_on_oops'' was set to 1 and ''kernel.panic'' to non-zero, the server would reboot on its own (after the specified number of seconds). | ||