Re: [REGRESSION] Hang during backup with rsync

[Duncan <1i5t5.duncan@cox.net>]

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