[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <22e5e2e1-fd64-1a75-a80c-332a34266717@virtuozzo.com>
Date: Thu, 8 Feb 2018 19:23:44 +0300
From: Andrey Ryabinin <aryabinin@...tuozzo.com>
To: Jan Kara <jack@...e.cz>, Dmitry Vyukov <dvyukov@...gle.com>
Cc: Andi Kleen <ak@...ux.intel.com>,
syzbot <syzbot+283c3c447181741aea28@...kaller.appspotmail.com>,
Andrew Morton <akpm@...ux-foundation.org>, jlayton@...hat.com,
LKML <linux-kernel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
Mel Gorman <mgorman@...hsingularity.net>,
Ingo Molnar <mingo@...nel.org>, rgoldwyn@...e.com,
syzkaller-bugs@...glegroups.com, linux-fsdevel@...r.kernel.org
Subject: Re: INFO: task hung in sync_blockdev
On 02/08/2018 07:18 PM, Jan Kara wrote:
>> By "full kernel crashdump" you mean kdump thing, or something else?
>
> Yes, the kdump thing (for KVM guest you can grab the memory dump also from
> the host in a simplier way and it should be usable with the crash utility
> AFAIK).
>
In QEMU monitor 'dump-guest-memory' command:
(qemu) help dump-guest-memory
dump-guest-memory [-p] [-d] [-z|-l|-s] filename [begin length] -- dump guest memory into file 'filename'.
-p: do paging to get guest's memory mapping.
-d: return immediately (do not wait for completion).
-z: dump in kdump-compressed format, with zlib compression.
-l: dump in kdump-compressed format, with lzo compression.
-s: dump in kdump-compressed format, with snappy compression.
begin: the starting physical address.
length: the memory size, in bytes
Powered by blists - more mailing lists