On 07/25/2014 11:38 PM, Vivek Goyal wrote:
On Fri, Jul 25, 2014 at 11:25:25PM +0530, Hari Bathini wrote:
> Vivek, currently after saving dump, we do reboot in fadump case too.
> "Fadump Operational Flow" section in fadump-howto.txt summarizes the same.
> In failure case, fadump also depends on existing error handling mechanism
> in kexec-tools package. So, as of now, all the configuration options in
> /etc/kdump.conf file apply to fadump as well.
Documentation/firmware-assisted-dump.txt says following.
Comparing with kdump or other strategies, firmware-assisted
dump offers several strong, practical advantages:
-- Unlike kdump, the system has been reset, and loaded
with a fresh copy of the kernel. In particular,
PCI and I/O devices have been reinitialized and are
in a clean, consistent state.
-- Once the dump is copied out, the memory that held the dump
is immediately available to the running kernel. And therefore,
unlike kdump, fadump doesn't need a 2nd reboot to get back
the system to the production configuration.
So seocond advantage is no more there in this implementation. The only
thing we are looking at is that IO devices have been quiesced by
firmware so potentially it can offer more reliability as compared to kdump
Vivek, both the advantages mentioned above stand true but we are yet
to work on advantage two. That is something we plan to do..