[Top] [All Lists]

Re: mdadm/raid5 hung/d-state

To: Michael Tokarev <mjt@xxxxxxxxxx>
Subject: Re: mdadm/raid5 hung/d-state
From: David Greaves <david@xxxxxxxxxxxx>
Date: Sun, 04 Nov 2007 21:40:27 +0000
Cc: Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, linux-raid@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <472DDD78.7040002@xxxxxxxxxxxxxxxx>
References: <Pine.LNX.4.64.0711040658180.30831@xxxxxxxxxxxxxxxx> <472DBF8C.2060508@xxxxxxxxxxxxxxxx> <Pine.LNX.4.64.0711040750020.3956@xxxxxxxxxxxxxxxx> <472DDD78.7040002@xxxxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla-Thunderbird (X11/20071009)
Michael Tokarev wrote:
> Justin Piszcz wrote:
>> On Sun, 4 Nov 2007, Michael Tokarev wrote:
> []
>>> The next time you come across something like that, do a SysRq-T dump and
>>> post that.  It shows a stack trace of all processes - and in particular,
>>> where exactly each task is stuck.
>> Yes I got it before I rebooted, ran that and then dmesg > file.
>> Here it is:
>> [1172609.665902]  ffffffff80747dc0 ffffffff80747dc0 ffffffff80747dc0 
>> ffffffff80744d80
>> [1172609.668768]  ffffffff80747dc0 ffff81015c3aa918 ffff810091c899b4 
>> ffff810091c899a8
> That's only partial list.  All the kernel threads - which are most important
> in this context - aren't shown.  You ran out of dmesg buffer, and the most
> interesting entries was at the beginning.  If your /var/log partition is
> working, the stuff should be in /var/log/kern.log or equivalent.  If it's
> not working, there is a way to capture the info still, by stopping syslogd,
> cat'ing /proc/kmsg to some tmpfs file and scp'ing it elsewhere.

or netconsole is actually pretty easy and incredibly useful in this kind of
situation even if there's no disk at all :)


<Prev in Thread] Current Thread [Next in Thread>