Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1595103 > unrolled thread

Re: [lkp-robot] [locking/ww_mutex] 857811a371: INFO:task_blocked_for_more_than#seconds

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [lkp-robot] [locking/ww_mutex]  857811a371:  INFO:task_blocked_for_more_than#seconds Chris Wilson <chris@chris-wilson.co.uk> - 2017-03-08 13:20 +0100
    Re: [lkp-robot] [locking/ww_mutex]  857811a371:  INFO:task_blocked_for_more_than#seconds Fengguang Wu <fengguang.wu@intel.com> - 2017-03-08 16:30 +0100
    Re: [locking/ww_mutex] 857811a371 INFO: task swapper/0:1 blocked for  more than 120 seconds. Boqun Feng <boqun.feng@gmail.com> - 2017-03-10 10:50 +0100

#1595103 — Re: [lkp-robot] [locking/ww_mutex] 857811a371: INFO:task_blocked_for_more_than#seconds

On Wed, Mar 08, 2017 at 09:08:54AM +0800, kernel test robot wrote:
> 
> FYI, we noticed the following commit:
> 
> commit: 857811a37129f5d2ba162d7be3986eff44724014 ("locking/ww_mutex: Adjust the lock number for stress test")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> in testcase: boot
> 
> on test machine: qemu-system-i386 -enable-kvm -m 320M
> 
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):

Now the test is running, it takes too long. :)

wait_for_completion_interruptible() would stop the hung task check? That
leaves NMI watchdog to check if we hit a deadlock between the workers.

And add a timeout to the stress test.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[toc] | [next] | [standalone]

#1595278

On Wed, Mar 08, 2017 at 12:13:12PM +0000, Chris Wilson wrote:
>On Wed, Mar 08, 2017 at 09:08:54AM +0800, kernel test robot wrote:
>>
>> FYI, we noticed the following commit:
>>
>> commit: 857811a37129f5d2ba162d7be3986eff44724014 ("locking/ww_mutex: Adjust the lock number for stress test")
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>>
>> in testcase: boot
>>
>> on test machine: qemu-system-i386 -enable-kvm -m 320M
>>
>> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>Now the test is running, it takes too long. :)

Sorry that's right. Up to now the 0day robot still cannot guarantee
the timely reporting of a runtime regression, nor can it guarantee
bisecting of a new regression even when some test actually triggered
the bug.

One fundamental challenge is, there are ~50,000 runtime "regressions"
queued for bisect. Obviously there is no way to bisect them all. So a
large portion of real regressions never get a chance to be bisected.
Not to mention the problem of bisect reliability and efficiency.

Most of the test "regressions" may be duplicates to each other (eg. a
bug in mainline kernel will also show up in various developer trees).
A great portion of them may also be random noises (eg. performance
fluctuations). We've tried various approaches to improve the
de-duplicate, filtering, prioritize etc. algorithms. Together with
increased test coverage, they have been reflected in our slowly
increasing report numbers. However there is still a long way to go.

Thanks,
Fengguang

[toc] | [prev] | [next] | [standalone]

#1596922 — Re: [locking/ww_mutex] 857811a371 INFO: task swapper/0:1 blocked for more than 120 seconds.

[Multipart message — attachments visible in raw view] — view raw

On Fri, Mar 10, 2017 at 11:07:46AM +0800, Boqun Feng wrote:
> On Fri, Mar 10, 2017 at 10:56:49AM +0800, Fengguang Wu wrote:
> > Hi Boqun,
> > 
> 
> Hello Fengguang,
> 
> > FYI here is another bisect result. I report it once again since the
> > attached reproduce-* may be more handy for debug. :)
> > 
> 
> That's very helpful! lkp is a bit difficult for me to set up ;-)
> 

Hmm... hit this when run the reproduce script:

early console in setup code
KVM internal error. Suberror: 3
extra data[0]: 80000306
extra data[1]: 31
RAX=0000000000000000 RBX=ffffffff800c0038 RCX=1ffffffff0d8c301 RDX=dffffc0000000000
RSI=0000000000000001 RDI=ffffffff86c61e78 RBP=ffffffff800c0028 RSP=ffffffff800c0000
R8 =0000000000000001 R9 =0000000000000001 R10=ffffffff85e07bd0 R11=ffffffff85e079d7
R12=0000000000000006 R13=0000000000000003 R14=00000000000199a0 R15=0000000000000001
RIP=ffffffff84a84715 RFL=00010046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 0000000000000000 ffffffff 00000000
CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA]
SS =0000 0000000000000000 ffffffff 00000000
DS =0000 0000000000000000 ffffffff 00000000
FS =0000 0000000000000000 ffffffff 00000000
GS =0000 ffffffff8737a000 ffffffff 00000000
LDT=0000 0000000000000000 ffffffff 00000000
TR =0020 0000000000000000 00000fff 00808b00 DPL=0 TSS64-busy
GDT=     ffffffff8738c000 0000007f
IDT=     ffffffff877ad000 00000fff
CR0=80050033 CR2=ffff880000014200 CR3=0000000007567000 CR4=000000a0
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000d01
Code=00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 88 47 a8 84 ff <ff> ff ff 07 67 72 81 ff ff ff ff d0 7a b6 86 ff ff ff ff 79 84 4e 81 ff ff ff ff 8b 25 d2

Using reproduce script for some other kernel is fine. Any idea?

My host is ArchLinux with kernel 4.9.11-1-ARCH.

Regards,
Boqun

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web