Feature #7058

Updated by Joshua M. Clulow over 4 years ago

 If the system panics, a crash dump is (hopefully) written to disk. Systems with a large quantity of DRAM can take a considerable period of time to dump to disk, during which the operator may not interact with the machine to determine its status. 

 If the system is configured to use the VGA console, when the operator views that console via a monitor or some remote KVM facility, the fact that the system is writing a crash dump is easy to see. A progress update is drawn to the screen each time one percent of progress is made toward completion. 

 For systems with a large quantity of memory, it can take many seconds or even minutes to write even one percent of the dump: one percent of 200GB is 2GB, and polled I/O is not especially fast. The operator would be forgiven for thinking that the passage of a minute or two without a progress update could signal that the system has hung while trying to dump. 

 Ironically, the use of the generally superior IPMI SOL support in the BMC to attach to the serial console of the machine actually further obscures dump activity. The operator can generally only see text emitted _after_ after attaching; infrequent updates mean that the operator may see _nothing_ nothing for minutes. 

 In order to alleviate these issues, we should take a two-pronged approach: 

 * liveliness will be signalled to the operator by drawing the progress display not just when the completion percentage changes, but also if a whole second has passed without an update 
 * operators with the good fortune to be able to use the serial console (and the impeccable taste to _choose_ choose to do so) will know that the system is dumping because we will prepend @dumping:@ dumping: to each redraw of the progress report