On Fri, Aug 7, 2015 at 5:01 AM, Liu Bo wrote:
> Hi,
>
> On Wed, Aug 05, 2015 at 10:28:05AM +0200, Elias Probst wrote:
>> I can reproduce a hard btrfs lockup (process issuing the ioctl() is in
>> D-state, same goes for btrfs-transacti process) on Kernel 4.2.0-rc5.
>>
>> I had the same issue on 4.1,
On 08/08/2015 01:29 AM, Elias Probst wrote:
> On 08/07/2015 06:01 AM, Liu Bo wrote:
>> Could you do 'echo w > /proc/sysrq-trigger' to gather the whole hang call
>> stack?
>
> Thanks a lot for the feedback. Full call stack output is attached
> (pasting inline makes no sense due to the size of 2423
On 08/07/2015 06:01 AM, Liu Bo wrote:
> Could you do 'echo w > /proc/sysrq-trigger' to gather the whole hang call
> stack?
Thanks a lot for the feedback. Full call stack output is attached
(pasting inline makes no sense due to the size of 2423 lines/135k).
In case VGER will strip attachments of
Hi,
On Wed, Aug 05, 2015 at 10:28:05AM +0200, Elias Probst wrote:
> I can reproduce a hard btrfs lockup (process issuing the ioctl() is in
> D-state, same goes for btrfs-transacti process) on Kernel 4.2.0-rc5.
>
> I had the same issue on 4.1, so it's unlikely a regression introduced in
> 4.2.
>
I can reproduce a hard btrfs lockup (process issuing the ioctl() is in
D-state, same goes for btrfs-transacti process) on Kernel 4.2.0-rc5.
I had the same issue on 4.1, so it's unlikely a regression introduced in
4.2.
## With the following steps, I can reproduce the problem:
1. Create a new clea
