Martin Steigerwald posted on Fri, 01 May 2015 12:13:55 +0200 as excerpted: > Am Freitag, 1. Mai 2015, 01:48:23 schrieb Duncan: >> Martin Steigerwald posted on Thu, 30 Apr 2015 19:29:57 +0200 as > excerpted: >> > The hang was: Mouse pointer in KDE not movable anymore, Ctrl-Alt-F1 >> > had no effect. I waited for a minute at least. Maybe it would have >> > reacted after a longer time, but I wanted my machine back. Disks >> > where idle, if I remember correctly. After reboot both filesystems >> > mount okay. >> >> This response is in regard to what to do at an apparent hang, and has >> nothing directly to do with btrfs... >> >> Two comments: >> >> 1) Depending on your graphics hardware and driver config, a modern >> "KMS" (kernel modesetting) setup is more likely to "soft" hang in X >> mode and not switch back to text mode, even when the system is >> otherwise not hung and a VT switch would have worked fine pre-KMS-era. >> >> So no response at an attempted VT switch (your ctrl-alt-F1) doesn't >> mean what it used to... > > I never read this. Also it is not obvious to me why a hardware reset > would be needed if the embedded Intel gfx is initialized properly > already. I do not believe that it was the GPU that hang. I did say nothing directly to do with btrfs... My target here was thus broader than btrfs triggered hangs, and in my experience, speaking in general, graphics, or hung X, is indeed a reasonably frequent hang trigger. When it happens, the system in general may be fine and responsive, only X and the display being hung, such that a VT switch doesn't change what's displayed and a graphics reset of some sort is necessary. Tho for those with multiple networked machines and ssh or the like running, remote access can often be used to get into a (seemingly) crashed machine that's actually only (local) graphics frozen, as well. (In that case, for magic-srq, it's possible to echo the appropriate letter into /proc/sysrq-trigger, since the actual sysrq key, and thus sequences using it, are local-only. AFAIK this technique can also be used on exotic keyboard layouts too, since I /think/ it's hardware keycodes otherwise, with the letters based on the US layout, but generated by other letters where they don't correspond to the same US layout keys.) > I assume a simpler explaination: that X.org process was in D state and > thus not able to respond to the keypress anymore. As I said, this was intended more as a generic guide... >> 2) Along the same lines, there's the kernel's magic-sysrequest >> (sysrq/srq) functionality. > Thank you for your detailed explaination. I may just print your mail as > a reference :) Something I mentioned just above but forgot in the original reply... I /think/ the sequences are based on hardware keycodes, and the letters may be different if the layout isn't US standard. However, echoing the appropriate letter into /proc/sysrq-trigger should work, regardless, and unlike the literal srq sequences, that can be done remotely too. =:^) > While I do think that these key combination can be helpful for further > debugging I doubt they would have done anything for ensuring data > integrity, cause… BTRFS was hung. As I said, think generically. This was intended for cases where it isn't the filesystem, or where you don't know what it is. However, while it won't help save the data, knowing whether the kernel is actually still alive and able to at least respond to the B/reboot sequence, can provide at least some information you might not otherwise have. Plus, if you're at the keyboard already, it's easier than actually hitting the reset switch, tho of course unlike the physical reset switch, if the kernel is clobbered the srq-b sequence won't work and you'll have to reset anyway. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
