Re: [LKP] [lkp-robot] [sched/fair] 6d46bd3d97: netperf.Throughput_tps -11.3% regression
by Joel Fernandes
Hi Mike,
On Sun, Sep 17, 2017 at 9:47 AM, Mike Galbraith <efault(a)gmx.de> wrote:
> On Sat, 2017-09-16 at 23:42 -0700, Joel Fernandes wrote:
>>
>> Yes I understand. However with my 'strong sync' patch, such a
>> balancing check could be useful which is what I was trying to do in a
>> different way in my patch - but it could be that my way is not good
>> enough and potentially the old wake_affine check could help here
>
> Help how? The old wake_affine() check contained zero concurrency
> information, it served to exclude excessive stacking, defeating the
> purpose of SMP. A truly synchronous wakeup has absolutely nothing to
> do with load balance in the general case: you can neither generate nor
> cure an imbalance by replacing one (nice zero) task with another. The
> mere existence of a load based braking mechanism speaks volumes.
This is the part I didn't get.. you said "neither generate an
imbalance", it is possible that a CPU with a high blocked load but
just happen to be running 1 task at the time and did a sync wake up
for another task. In this case dragging the task onto the waker's CPU
might hurt it since it will face more competition than if it were
woken up on its previous CPU which is possibly lighty loaded than the
waker's CPU?
Also the other thing I didn't fully get is why is concurrency a
discussion point here, in this case A wakes up B and goes to sleep,
and then B wakes up A. They never run concurrently. Could you let me
know what I am missing?
>> On systems with SMT, it may make more sense for
>> > sync wakeups to look for idle threads of the same
>> > core, than to have the woken task end up on the
>> > same thread, and wait for the current task to stop
>> > running.
>>
>> I am ok with additionally doing an select_idle_smt for the SMT cases.
>> However Mike shows that it doesn't necessarily cause a performance
>> improvement. But if there is consensus on checking for idle SMT
>> threads, then I'm Ok with doing that.
>
> select_idle_sibling() used to check thread first, that was changed to
> core first for performance reasons.
Oh I see. Ok.
>> > "Strong sync" wakeups like you propose would also
>> > change the semantics of wake_wide() and potentially
>> > other bits of code...
>> >
>>
>> I understand, I am not very confident that wake_wide does the right
>> thing anyway. Atleast for Android, wake_wide doesn't seem to mirror
>> the most common usecase of display pipeline well. It seems that we
>> have cases where the 'flip count' is really high and causes wake_wide
>> all the time and sends us straight to the wake up slow path causing
>> regressions in Android benchmarks.
>
> Hm. It didn't pull those counts out of the vacuum, it measured them.
> It definitely does not force Android into the full balance path, that
> is being done by Android developers, as SD_BALANCE_WAKE is off by
> default. It was briefly on by default, but was quickly turned back off
> because it... induced performance regressions.
>
> In any case, if you have cause to believe that wake_wide() is causing
> you grief, why the heck are you bending up the sync hint?
So its not just wake_wide causing the grief, even select_idle_sibling
doesn't seem to be doing the right thing. We really don't want to wake
up a task on an idle CPU if the current CPU is a better candidate.
Binder microbenchmarks should that (as you can see in the results in
this patch) it performs better to wake up on the current CPU (no wake
up from idle latency on a sibling etc). Perhaps we should fix
select_idle_sibling to also consider latency of CPU to come out of
idle? Using the sync hint was/is a way on the product kernel to
prevent both these paths. On current products, sync is ignored though
if the system is in an "overutilized" state (any of the CPUs are more
than 80% utilized) but otherwise the sync is used as a hard flag. This
is all probably wrong though - considering the concurrency point you
brought up..
>> Atleast with the sync flag, the caller provides a meaningful
>> indication and I think making that flag stronger / more preferred than
>> wake_wide makes sense from that perspective since its not a signal
>> that's guessed, but is rather an input request.
>
> Sort of, if you disregard the history I mentioned...
>
> https://www.youtube.com/watch?v=Yho1Eydh1mM :)
No no, definitely not disregarding anything :) - just trying to make
sense of it all (and the history). Thanks so much for sharing it and
all the current/previous discussion.
>
> Lacking solid concurrency information to base your decision on, you'll
> end up robbing Peter to pay Paul forever, you absolutely will stack
> non-synchronous tasks, inducing needless latency hits and injuring
> scalability. We've been down that road. $subject was a very small
> sample of what lies down this path <bang bang bang>.
Ok. That is pretty scary. I am going to spend some time first go
through all the previous emails in this and other threads on the
balance flag usages and try to work on a solution after that. I will
probably start to document somewhere all the usecases for my own
sanity :)
thanks,
- Joel
2 years, 6 months
Re: [LKP] [lkp-robot] [sched/fair] 6d46bd3d97: netperf.Throughput_tps -11.3% regression
by Joel Fernandes
Hi Mike,
Thanks a lot for sharing the history of this.
On Sun, Sep 10, 2017 at 7:55 PM, Mike Galbraith <efault(a)gmx.de> wrote:
> On Sun, 2017-09-10 at 09:53 -0700, Joel Fernandes wrote:
>>
>> Anyone know what in the netperf test triggers use of the sync flag?
>
> homer:..kernel/linux-master # git grep wake_up_interruptible_sync_poll net
> net/core/sock.c: wake_up_interruptible_sync_poll(&wq->wait, POLLIN | POLLPRI |
> net/core/sock.c: wake_up_interruptible_sync_poll(&wq->wait, POLLOUT |
> net/sctp/socket.c: wake_up_interruptible_sync_poll(&wq->wait, POLLIN |
> net/smc/smc_rx.c: wake_up_interruptible_sync_poll(&wq->wait, POLLIN | POLLPRI |
> net/tipc/socket.c: wake_up_interruptible_sync_poll(&wq->wait, POLLOUT |
> net/tipc/socket.c: wake_up_interruptible_sync_poll(&wq->wait, POLLIN |
> net/unix/af_unix.c: wake_up_interruptible_sync_poll(&wq->wait,
> net/unix/af_unix.c: wake_up_interruptible_sync_poll(&u->peer_wait,
>
> The same as metric tons of other stuff.
>
> Once upon a time, we had avg_overlap to help decide whether to wake
> core affine or not, on top of the wake_affine() imbalance constraint,
> but instrumentation showed it to be too error prone, so it had to die.
> These days, an affine wakeup generally means cache affine, and the
> sync hint gives you a wee bit more chance of migration near to tasty
> hot data being approved.
>
> The sync hint was born back in the bad old days, when communicating
> tasks not sharing L2 may as well have been talking over two tin cans
> and a limp string. These days, things are oodles better, but truly
> synchronous stuff could still benefit from core affinity (up to hugely
> for very fast/light stuff) if it weren't for all the caveats that can
> lead to tossing concurrency opportunities out the window.
Cool, thanks. For this test I suspect its the other way? I think the
reason why regresses is that the 'nr_running < 2' check is too weak of
a check to prevent sync in all bad situations ('bad' being pulling a
task to a crowded CPU). Could we maybe be having a situation for this
test where if the blocked load a CPU is high (many tasks recently were
running on it and went to sleep), then the nr_running < 2 is a false
positive and in such a scenario we listened to the sync flag when we
shouldn't have?
To make the load check more meaningful, I am thinking if using
wake_affine()'s balance check is a better thing to do than the
'nr_running < 2' check I used in this patch. Then again, since commit
3fed382b46baac ("sched/numa: Implement NUMA node level wake_affine()",
wake_affine() doesn't do balance check for CPUs within a socket so
probably bringing back something like the *old* wake_affine that
checked load between different CPUs within a socket is needed to avoid
a potentially disastrous sync decision? The commit I refer to was
added with the reason that select_idle_sibling was selecting cores
anywhere within a socket, but with my patch we're more specifically
selecting the waker's CPU on passing the sync flag. Could you share
your thoughts about this?
I will run some tracing on this netperf test and try to understand the
undesirable behavior better as well,
thanks,
-Joel
2 years, 6 months
[lkp-robot] [x86/mm/64] 7898f79654: WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush
by kernel test robot
FYI, we noticed the following commit:
commit: 7898f79654698dcea5a0876785796de67d527ee7 ("x86/mm/64: Fix an incorrect warning with CONFIG_DEBUG_VM=y, !PCID")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: boot
on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -m 360M
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+-------------------------------------------------------------+------------+------------+
| | 4dfc278803 | 7898f79654 |
+-------------------------------------------------------------+------------+------------+
| boot_successes | 8 | 4 |
| boot_failures | 0 | 4 |
| WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush | 0 | 4 |
| EIP:initialize_tlbstate_and_flush | 0 | 4 |
+-------------------------------------------------------------+------------+------------+
[ 0.000000] WARNING: CPU: 0 PID: 0 at arch/x86/mm/tlb.c:245 initialize_tlbstate_and_flush+0x49/0xef
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.13.0-10313-g7898f79 #1
[ 0.000000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[ 0.000000] task: b243f600 task.stack: b2436000
[ 0.000000] EIP: initialize_tlbstate_and_flush+0x49/0xef
[ 0.000000] EFLAGS: 00210046 CPU: 0
[ 0.000000] EAX: 00040690 EBX: b25a57e0 ECX: 00000080 EDX: 00000002
[ 0.000000] ESI: 00000000 EDI: 00000000 EBP: b2437f60 ESP: b2437f50
[ 0.000000] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[ 0.000000] CR0: 80050033 CR2: 00000000 CR3: 0277a000 CR4: 00040690
[ 0.000000] Call Trace:
[ 0.000000] cpu_init+0x98/0x17b
[ 0.000000] ? __native_set_fixmap+0x21/0x2a
[ 0.000000] trap_init+0x38/0x40
[ 0.000000] start_kernel+0x1f6/0x399
[ 0.000000] i386_start_kernel+0x95/0x99
[ 0.000000] startup_32_smp+0x164/0x166
[ 0.000000] Code: c5 42 b2 89 45 f0 8b 43 20 e8 3d fa ff ff 3b 45 f0 74 02 0f ff a1 a0 7d 6b b2 0f ba e0 11 73 0d a1 c8 3c 45 b2 0f ba e0 11 72 02 <0f> ff 8b 45 f0 ff 15 2c c5 42 b2 66 c7 05 c4 3c 45 b2 00 00 66
[ 0.000000] ---[ end trace be658dd14e22cef1 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
Thanks,
Xiaolong
2 years, 6 months
[lkp-robot] [ipmi_si] d830f6514c: WARNING:at_drivers/base/driver.c:#driver_unregister
by kernel test robot
FYI, we noticed the following commit:
commit: d830f6514cdf359bcd7201306ac792ffa27f7966 ("ipmi_si: Move platform device handling to another file")
https://github.com/cminyard/linux-ipmi master-ipmi-rebase
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-i386 -enable-kvm -m 256M
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+-------------------------------------------------------------+------------+------------+
| | f479f8111d | d830f6514c |
+-------------------------------------------------------------+------------+------------+
| boot_successes | 0 | 0 |
| boot_failures | 12 | 10 |
| WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush | 12 | 10 |
| EIP:initialize_tlbstate_and_flush | 12 | 10 |
| WARNING:at_drivers/base/driver.c:#driver_unregister | 0 | 10 |
| EIP:driver_unregister | 0 | 10 |
+-------------------------------------------------------------+------------+------------+
[ 2.815872] WARNING: CPU: 0 PID: 1 at drivers/base/driver.c:191 driver_unregister+0x1a/0x33
[ 2.817118] CPU: 0 PID: 1 Comm: swapper Tainted: G W 4.13.0-06701-gd830f651 #12
[ 2.817953] task: 8742e000 task.stack: 87430000
[ 2.818413] EIP: driver_unregister+0x1a/0x33
[ 2.818869] EFLAGS: 00210286 CPU: 0
[ 2.819223] EAX: 0000001d EBX: 7a116214 ECX: 00000006 EDX: 00000007
[ 2.819847] ESI: ffffffed EDI: 00000000 EBP: 87431f08 ESP: 87431f00
[ 2.820558] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[ 2.821095] CR0: 80050033 CR2: 00000000 CR3: 01904000 CR4: 00000690
[ 2.821718] Call Trace:
[ 2.821973] platform_driver_unregister+0xb/0xd
[ 2.822405] cleanup_ipmi_si+0x2a/0x73
[ 2.822775] init_ipmi_si+0x149/0x16a
[ 2.823126] ? ipmi_thread+0x18b/0x18b
[ 2.823488] do_one_initcall+0x7c/0x114
[ 2.823862] ? parse_args+0x135/0x1f7
[ 2.824227] ? kernel_init_freeable+0xba/0x156
[ 2.824674] kernel_init_freeable+0xdd/0x156
[ 2.825108] ? rest_init+0x108/0x108
[ 2.825460] kernel_init+0x8/0xcb
[ 2.825815] ret_from_fork+0x19/0x24
[ 2.826178] Code: dc ff 5d c3 55 8b 40 3c 89 e5 e8 32 eb dc ff 5d c3 55 85 c0 89 e5 53 74 08 83 78 3c 00 89 c3 75 0f 68 56 81 6b 79 e8 c6 dd d1 ff <0f> ff 58 eb 0f 8b 50 34 e8 cc ff ff ff 89 d8 e8 7a eb ff ff 8b
[ 2.828225] ---[ end trace aff8a0f3cdf046d6 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
Thanks,
Xiaolong
2 years, 6 months
[lkp-robot] [net/packet] d5013a2d16: BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/mutex.c
by kernel test robot
FYI, we noticed the following commit:
commit: d5013a2d162004f30b500d35a589cffd09e6d209 ("net/packet: fix race condition between fanout_add and __unregister_prot_hook")
url: https://github.com/0day-ci/linux/commits/nixiaoming/net-packet-fix-race-c...
in testcase: boot
on test machine: qemu-system-i386 -enable-kvm -m 360M
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+-----------------------------------------------------------------------------+------------+------------+
| | 66bed8465a | d5013a2d16 |
+-----------------------------------------------------------------------------+------------+------------+
| boot_successes | 37 | 2 |
| boot_failures | 2 | 6 |
| WARNING:at_arch/x86/include/asm/fpu/internal.h:#fpu__restore | 2 | |
| EIP:fpu__restore | 1 | |
| BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/mutex.c | 0 | 6 |
+-----------------------------------------------------------------------------+------------+------------+
[ 192.914933] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
[ 192.932004] in_atomic(): 1, irqs_disabled(): 0, pid: 305, name: trinity-main
[ 192.943993] Preemption disabled at:
[ 192.944029] [<c4ab243b>] packet_release+0x9b/0x340
[ 192.963051] CPU: 0 PID: 305 Comm: trinity-main Not tainted 4.13.0-rc7-02204-gd5013a2 #1
[ 192.976507] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[ 192.993969] Call Trace:
[ 193.000649] dump_stack+0x16/0x23
[ 193.009681] ___might_sleep+0x12f/0x180
[ 193.017231] ? packet_release+0x9b/0x340
[ 193.026055] ? packet_release+0x9b/0x340
[ 193.034027] __might_sleep+0x34/0x80
[ 193.040862] ? __might_sleep+0x34/0x80
[ 193.048214] mutex_lock+0x17/0x30
[ 193.056253] __unregister_prot_hook+0x1b/0x110
[ 193.064873] packet_release+0x2f1/0x340
[ 193.073205] ? dentry_free+0x3c/0x60
[ 193.080559] ? dentry_free+0x3c/0x60
[ 193.087429] sock_release+0x13/0x60
[ 193.094588] sock_close+0xb/0x10
[ 193.101074] __fput+0xa7/0x240
[ 193.108910] ____fput+0x8/0x10
[ 193.116661] task_work_run+0x67/0x90
[ 193.125994] do_exit+0x219/0xa20
[ 193.134063] ? preempt_schedule_common+0x72/0x80
[ 193.146020] do_group_exit+0x26/0xa0
[ 193.154611] get_signal+0x276/0x6a0
[ 193.164848] ? _copy_to_user+0x50/0x70
[ 193.173755] do_signal+0x1f/0x570
[ 193.181988] ? SyS_fstatat64+0x38/0x40
[ 193.190905] exit_to_usermode_loop+0x77/0xa0
[ 193.200461] do_fast_syscall_32+0x137/0x150
[ 193.210054] entry_SYSENTER_32+0x4e/0x7c
[ 193.219676] EIP: 0xb7f46cf5
[ 193.228848] EFLAGS: 00000292 CPU: 0
[ 193.237952] EAX: 00000000 EBX: 0000019f ECX: 0869f52b EDX: bfac5fb0
[ 193.250499] ESI: 00000100 EDI: b7f3aff4 EBP: 0000000c ESP: bfac5f90
[ 193.264660] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
[ 193.986909] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
[ 194.009983] in_atomic(): 1, irqs_disabled(): 0, pid: 305, name: trinity-main
[ 194.024691] Preemption disabled at:
[ 194.024727] [<c4ab243b>] packet_release+0x9b/0x340
[ 194.047543] CPU: 0 PID: 305 Comm: trinity-main Tainted: G W 4.13.0-rc7-02204-gd5013a2 #1
[ 194.068962] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[ 194.088992] Call Trace:
[ 194.099198] dump_stack+0x16/0x23
[ 194.107979] ___might_sleep+0x12f/0x180
[ 194.117769] ? packet_release+0x9b/0x340
[ 194.127715] ? packet_release+0x9b/0x340
[ 194.137238] __might_sleep+0x34/0x80
[ 194.146545] ? __might_sleep+0x34/0x80
[ 194.155740] mutex_lock+0x17/0x30
[ 194.164231] __unregister_prot_hook+0x1b/0x110
[ 194.174637] packet_release+0x2f1/0x340
[ 194.183681] ? dentry_free+0x3c/0x60
[ 194.193859] ? dentry_free+0x3c/0x60
[ 194.202442] sock_release+0x13/0x60
[ 194.210998] sock_close+0xb/0x10
[ 194.219686] __fput+0xa7/0x240
[ 194.227557] ____fput+0x8/0x10
[ 194.235434] task_work_run+0x67/0x90
[ 194.244704] do_exit+0x219/0xa20
[ 194.252864] ? preempt_schedule_common+0x72/0x80
[ 194.263042] do_group_exit+0x26/0xa0
[ 194.271602] get_signal+0x276/0x6a0
[ 194.281679] ? _copy_to_user+0x50/0x70
[ 194.290592] do_signal+0x1f/0x570
[ 194.298757] ? SyS_fstatat64+0x38/0x40
[ 194.307606] exit_to_usermode_loop+0x77/0xa0
[ 194.317878] do_fast_syscall_32+0x137/0x150
[ 194.327982] entry_SYSENTER_32+0x4e/0x7c
[ 194.337675] EIP: 0xb7f46cf5
[ 194.345841] EFLAGS: 00000292 CPU: 0
[ 194.354335] EAX: 00000000 EBX: 0000019f ECX: 0869f52b EDX: bfac5fb0
[ 194.366937] ESI: 00000100 EDI: b7f3aff4 EBP: 0000000c ESP: bfac5f90
[ 194.379475] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
[ 195.526777] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
[ 195.547006] in_atomic(): 1, irqs_disabled(): 0, pid: 305, name: trinity-main
[ 195.561033] Preemption disabled at:
[ 195.561266] [<c4ab243b>] packet_release+0x9b/0x340
[ 195.588514] CPU: 0 PID: 305 Comm: trinity-main Tainted: G W 4.13.0-rc7-02204-gd5013a2 #1
[ 195.609740] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[ 195.632654] Call Trace:
[ 195.640494] dump_stack+0x16/0x23
[ 195.649691] ___might_sleep+0x12f/0x180
[ 195.659870] ? packet_release+0x9b/0x340
[ 195.670014] ? packet_release+0x9b/0x340
[ 195.686710] __might_sleep+0x34/0x80
[ 195.696945] ? __might_sleep+0x34/0x80
[ 195.706701] mutex_lock+0x17/0x30
[ 195.715935] __unregister_prot_hook+0x1b/0x110
[ 195.725949] packet_release+0x2f1/0x340
[ 195.735567] ? dentry_free+0x3c/0x60
[ 195.759681] ? dentry_free+0x3c/0x60
[ 195.767720] sock_release+0x13/0x60
[ 195.776051] sock_close+0xb/0x10
[ 195.784924] __fput+0xa7/0x240
[ 195.793452] ____fput+0x8/0x10
[ 195.806022] task_work_run+0x67/0x90
[ 195.815457] do_exit+0x219/0xa20
[ 195.824630] ? preempt_schedule_common+0x72/0x80
[ 195.833374] do_group_exit+0x26/0xa0
[ 195.841182] get_signal+0x276/0x6a0
[ 195.848413] ? _copy_to_user+0x50/0x70
[ 195.861052] do_signal+0x1f/0x570
[ 195.878738] ? SyS_fstatat64+0x38/0x40
[ 195.888884] exit_to_usermode_loop+0x77/0xa0
[ 195.899518] do_fast_syscall_32+0x137/0x150
[ 195.910756] entry_SYSENTER_32+0x4e/0x7c
[ 195.920909] EIP: 0xb7f46cf5
[ 195.934703] EFLAGS: 00000292 CPU: 0
[ 195.943879] EAX: 00000000 EBX: 0000019f ECX: 0869f52b EDX: bfac5fb0
[ 195.957946] ESI: 00000100 EDI: b7f3aff4 EBP: 0000000c ESP: bfac5f90
[ 195.973044] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
Elapsed time: 210
initrds=(
/osimage/quantal/quantal-core-i386.cgz
/lkp/scheduled/vm-lkp-wsx03-quantal-i386-21/boot-1-quantal-core-i386.cgz-d5013a2d162004f30b500d35a589cffd09e6d209-20170916-39065-1cb9eeg-0.cgz
/lkp/lkp/lkp-i386.cgz
)
cat "${initrds[@]}" > /fs/sdc1/initrd-vm-lkp-wsx03-quantal-i386-21
kvm=(
qemu-system-i386
-enable-kvm
-kernel /pkg/linux/i386-randconfig-x0-09160554/gcc-6/d5013a2d162004f30b500d35a589cffd09e6d209/vmlinuz-4.13.0-rc7-02204-gd5013a2
-initrd /fs/sdc1/initrd-vm-lkp-wsx03-quantal-i386-21
-m 360
-smp 1
-device e1000,netdev=net0
-netdev user,id=net0
-boot order=nc
-no-reboot
-watchdog i6300esb
-watchdog-action debug
-rtc base=localtime
-pidfile /dev/shm/kboot/pid-vm-lkp-wsx03-quantal-i386-21
-serial file:/dev/shm/kboot/vm-lkp-wsx03-quantal-i386-21/serial
-serial file:/dev/shm/kboot/vm-lkp-wsx03-quantal-i386-21/kmsg
-daemonize
-display none
-monitor null
)
append=(
ip=::::vm-lkp-wsx03-quantal-i386-21::dhcp
root=/dev/ram0
user=lkp
job=/lkp/scheduled/vm-lkp-wsx03-quantal-i386-21/boot-1-quantal-core-i386.cgz-d5013a2d162004f30b500d35a589cffd09e6d209-20170916-39065-1cb9eeg-0.yaml
ARCH=i386
kconfig=i386-randconfig-x0-09160554
branch=linux-devel/devel-spot-201709160126
commit=d5013a2d162004f30b500d35a589cffd09e6d209
BOOT_IMAGE=/pkg/linux/i386-randconfig-x0-09160554/gcc-6/d5013a2d162004f30b500d35a589cffd09e6d209/vmlinuz-4.13.0-rc7-02204-gd5013a2
max_uptime=600
RESULT_ROOT=/result/boot/1/vm-lkp-wsx03-quantal-i386/quantal-core-i386.cgz/i386-randconfig-x0-09160554/gcc-6/d5013a2d162004f30b500d35a589cffd09e6d209/0
LKP_SERVER=inn
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0
printk.devkmsg=on
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err
ignore_loglevel
console=tty0
earlyprintk=ttyS0,115200
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
Thanks,
Xiaolong
2 years, 6 months
[lkp-robot] 6b9440d3d4: kernel_BUG_at_fs/namei.c
by kernel test robot
FYI, we noticed the following commit:
commit: 6b9440d3d4295adedb6c20062573f8e74241abd8 ("TODO")
https://git.kernel.org/cgit/linux/kernel/git/jpoimboe/linux.git clang-sp-clobber
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+------------------------------------------+------------+------------+
| | 01f117a351 | 6b9440d3d4 |
+------------------------------------------+------------+------------+
| boot_successes | 41 | 0 |
| boot_failures | 0 | 10 |
| kernel_BUG_at_fs/namei.c | 0 | 10 |
| invalid_opcode:#[##] | 0 | 10 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 10 |
+------------------------------------------+------------+------------+
[ 0.038013] kernel BUG at fs/namei.c:699!
[ 0.038616] invalid opcode: 0000 [#1] SMP
[ 0.039000] CPU: 1 PID: 17 Comm: kdevtmpfs Not tainted 4.13.0-11616-g6b9440d #1
[ 0.039000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[ 0.039000] task: ffff880000220000 task.stack: ffffc90000158000
[ 0.039000] RIP: 0010:unlazy_walk+0x14e/0x150
[ 0.039000] RSP: 0000:ffffc9000015bc48 EFLAGS: 00010297
[ 0.039000] RAX: ffff880000220000 RBX: ffffc9000015bd10 RCX: 0000000000000000
[ 0.039000] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000246
[ 0.039000] RBP: ffffc9000015bc60 R08: 00000000ffffffff R09: 0000000000000000
[ 0.039000] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
[ 0.039000] R13: ffff880000208948 R14: 0000000000000000 R15: 0000000000000000
[ 0.039000] FS: 0000000000000000(0000) GS:ffff88001d600000(0000) knlGS:0000000000000000
[ 0.039000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.039000] CR2: ffffc9000015c000 CR3: 0000000002269000 CR4: 00000000000006e0
[ 0.039000] Call Trace:
[ 0.039000] complete_walk+0x4d/0xc0
[ 0.039000] path_lookupat+0x155/0x2b0
[ 0.039000] ? kvm_sched_clock_read+0x25/0x40
[ 0.039000] ? sched_clock+0x9/0x10
[ 0.039000] filename_lookup+0xc9/0x190
[ 0.039000] ? sched_clock_local+0x17/0x90
[ 0.039000] ? follow_dotdot_rcu+0x139/0x340
[ 0.039000] ? alloc_pages_current+0x8e/0x130
[ 0.039000] ? strncpy_from_user+0x16d/0x210
[ 0.039000] ? slob_alloc_node+0x54/0x90
[ 0.039000] user_path_at_empty+0x40/0x50
[ 0.039000] ? user_path_at_empty+0x40/0x50
[ 0.039000] SyS_chdir+0x37/0xf0
[ 0.039000] ? SyS_mount+0xd4/0x120
[ 0.039000] devtmpfsd+0x9d/0x1c0
[ 0.039000] kthread+0x12b/0x170
[ 0.039000] ? handle_create+0x250/0x250
[ 0.039000] ? __kthread_create_on_node+0x1c0/0x1c0
[ 0.039000] ret_from_fork+0x25/0x30
[ 0.039000] Code: 08 00 00 00 00 e8 d3 21 f3 ff f6 43 39 20 75 a3 e8 c8 21 f3 ff 48 c7 43 20 00 00 00 00 eb 94 e8 b9 21 f3 ff 0f 0b e8 b2 21 f3 ff <0f> 0b 55 48 89 e5 41 55 41 54 53 48 89 fb e8 9f 21 f3 ff 44 8b
[ 0.039000] RIP: unlazy_walk+0x14e/0x150 RSP: ffffc9000015bc48
[ 0.059007] ---[ end trace b0f2ee79dde75b27 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
Thanks,
Xiaolong
2 years, 6 months
[lkp-robot] [kernfs, sysfs, cgroup, intel_rdt] 89e689f267: kernel_BUG_at_fs/super.c
by kernel test robot
FYI, we noticed the following commit:
commit: 89e689f267b2c144d7b071443e01fa718727b962 ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context")
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git mount-context
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-i386 -enable-kvm -m 256M
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+------------------------------------------+------------+------------+
| | a62d750e12 | 89e689f267 |
+------------------------------------------+------------+------------+
| boot_successes | 22 | 2 |
| boot_failures | 0 | 22 |
| kernel_BUG_at_fs/super.c | 0 | 22 |
| invalid_opcode:#[##] | 0 | 22 |
| EIP:vfs_get_tree | 0 | 22 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 22 |
+------------------------------------------+------------+------------+
[ 2.580515] kernel BUG at fs/super.c:1703!
[ 2.581033] invalid opcode: 0000 [#1]
[ 2.581372] CPU: 0 PID: 1 Comm: init Not tainted 4.13.0-rc1-00020-g89e689f #1
[ 2.581981] task: 8741e000 task.stack: 87420000
[ 2.582400] EIP: vfs_get_tree+0x4d/0xe1
[ 2.582736] EFLAGS: 00010246 CPU: 0
[ 2.583052] EAX: 00000000 EBX: 83d3a8c8 ECX: 83d3ccc4 EDX: 7970b580
[ 2.583599] ESI: 00000027 EDI: 00000000 EBP: 87421f28 ESP: 87421f20
[ 2.584150] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[ 2.584619] CR0: 80050033 CR2: 6feff588 CR3: 0bcd4000 CR4: 00000690
[ 2.585174] Call Trace:
[ 2.585400] do_mount+0x89e/0x8dc
[ 2.585694] ? strndup_user+0x27/0x3f
[ 2.586016] SyS_mount+0x52/0x76
[ 2.586317] do_int80_syscall_32+0x4c/0xd9
[ 2.586680] entry_INT80_32+0x2c/0x2c
[ 2.586998] EIP: 0x6fef6c3e
[ 2.587266] EFLAGS: 00000216 CPU: 0
[ 2.587581] EAX: ffffffda EBX: 0804a3a9 ECX: 0804a3a1 EDX: 0804a3a9
[ 2.588136] ESI: 0000000e EDI: 00000000 EBP: 77a30778 ESP: 77a306dc
[ 2.588689] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
[ 2.589176] Code: ff ff ff e9 aa 00 00 00 89 d8 ff d2 85 c0 79 e8 e9 9d 00 00 00 8b 13 89 d8 ff 52 18 85 c0 0f 88 8e 00 00 00 8b 43 08 85 c0 75 02 <0f> 0b 8b b0 94 00 00 00 83 be ac 00 00 00 00 75 02 0f ff 8b 43
[ 2.590882] EIP: vfs_get_tree+0x4d/0xe1 SS:ESP: 0068:87421f20
[ 2.591412] ---[ end trace 5e29087d876104ae ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
Thanks,
Xiaolong
2 years, 6 months
[lkp-robot] [drm/fb] a583bc678d: WARNING:at_kernel/workqueue.c:#flush_workqueue
by kernel test robot
FYI, we noticed the following commit:
commit: a583bc678d0a5e54844d3380e242dd9bb5fb0b00 ("drm/fb-helper: Allocate a drm_file")
url: https://github.com/0day-ci/linux/commits/Noralf-Tr-nnes/drm-fb-helper-Use...
base: git://people.freedesktop.org/~airlied/linux.git drm-next
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+------------------------------------------------+------------+------------+
| | 6b0c88fff7 | a583bc678d |
+------------------------------------------------+------------+------------+
| boot_successes | 66 | 0 |
| boot_failures | 0 | 77 |
| WARNING:at_kernel/workqueue.c:#flush_workqueue | 0 | 32 |
| kernel_BUG_at_lib/list_debug.c | 0 | 66 |
| invalid_opcode:#[##] | 0 | 66 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 77 |
| BUG:unable_to_handle_kernel | 0 | 11 |
| Oops:#[##] | 0 | 11 |
+------------------------------------------------+------------+------------+
[ 14.785867] WARNING: CPU: 0 PID: 5 at kernel/workqueue.c:2606 flush_workqueue+0x881/0x8b0
[ 14.798652] list_del corruption. prev->next should be ffff88001c459300, but was (null)
[ 14.798673] ------------[ cut here ]------------
[ 14.798674] kernel BUG at lib/list_debug.c:56!
[ 14.798677] invalid opcode: 0000 [#1] PREEMPT
[ 14.798679] CPU: 0 PID: 24 Comm: kworker/u2:1 Not tainted 4.13.0-rc5-01112-ga583bc6 #1
[ 14.798680] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[ 14.798686] task: ffff88001d31f0c0 task.stack: ffffc900000c0000
[ 14.798690] RIP: 0010:__list_del_entry_valid+0x155/0x160
[ 14.798691] RSP: 0000:ffffc900000c3e60 EFLAGS: 00010086
[ 14.798693] RAX: 0000000000000054 RBX: 0000000000000003 RCX: 0000000000000000
[ 14.798693] RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000046
[ 14.798694] RBP: ffffc900000c3e88 R08: 0000000000000000 R09: 0000000000000000
[ 14.798695] R10: ffff88001d31f110 R11: 000000006c756e28 R12: ffff88001c459300
[ 14.798696] R13: ffff88001c491cc0 R14: ffff88001d1bc030 R15: 0000000000000000
[ 14.798698] FS: 0000000000000000(0000) GS:ffffffff8422f000(0000) knlGS:0000000000000000
[ 14.798699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 14.798700] CR2: 00000000000000a8 CR3: 000000000420e000 CR4: 00000000000006f0
[ 14.798702] Call Trace:
[ 14.798707] worker_thread+0x1c5/0x810
[ 14.798709] kthread+0x187/0x190
[ 14.798711] ? process_one_work+0x7f0/0x7f0
[ 14.798712] ? __kthread_create_on_node+0x260/0x260
[ 14.798715] ret_from_fork+0x25/0x30
[ 14.798716] Code: 06 7e ff 0f 0b 4c 89 f2 4c 89 e6 48 c7 c7 c0 d9 db 83 e8 9f 06 7e ff 0f 0b 49 8b 16 4c 89 e6 48 c7 c7 f8 d9 db 83 e8 8b 06 7e ff <0f> 0b 90 90 90 90 90 90 90 90 90 55 48 89 f8 45 31 db 41 ba 01
[ 14.798741] RIP: __list_del_entry_valid+0x155/0x160 RSP: ffffc900000c3e60
[ 14.798746] ---[ end trace 22b1dffd04582160 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
Thanks,
Xiaolong
2 years, 6 months
[lkp-robot] [mm] c79b57e462: vm-scalability.throughput 25% improvement
by kernel test robot
Greeting,
FYI, we noticed a +25% improvement of vm-scalability.throughput due to commit:
commit: c79b57e462b5d2f47afa5f175cf1828f16e18612 ("mm: hugetlb: clear target sub-page last when clearing huge page")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: vm-scalability
on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with 128G memory
with following parameters:
runtime: 300s
size: 8T
test: anon-w-seq-mt
cpufreq_governor: performance
test-description: The motivation behind this suite is to exercise functions and regions of the mm/ of the Linux kernel which are of interest to us.
test-url: https://git.kernel.org/cgit/linux/kernel/git/wfg/vm-scalability.git/
Details are as below:
-------------------------------------------------------------------------------------------------->
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
testcase/path_params/tbox_group/run: vm-scalability/300s-8T-anon-w-seq-mt-performance/lkp-bdw-ep2
212925802454672e c79b57e462b5d2f47afa5f175c
---------------- --------------------------
%stddev change %stddev
\ | \
34081895 25% 42690377 vm-scalability.throughput
373299 24% 463391 vm-scalability.median
513295 22% 627873 vm-scalability.time.voluntary_context_switches
9548109 20% 11489781 vm-scalability.time.minor_page_faults
9.052e+09 20% 1.089e+10 vm-scalability.workload
8178 8349 vm-scalability.time.system_time
64389077 -4% 61913989 vm-scalability.time.maximum_resident_set_size
0.01 -4% 0.00 vm-scalability.free_time
6872 -9% 6273 vm-scalability.time.percent_of_cpu_this_job_got
12564 -16% 10595 vm-scalability.time.user_time
132010 -8% 120993 vmstat.system.in
12161911 -26% 8950198 interrupts.CAL:Function_call_interrupts
72723 27% 92011 pmeter.performance_per_watt
468 464 pmeter.Average_Active_Power
37.97 -3% 36.78 boot-time.boot
2996 -4% 2887 boot-time.idle
23.10 ± 4% -5% 21.96 boot-time.kernel_boot
19.97 ± 5% -5% 18.89 ± 3% boot-time.dhcp
0.57 ± 6% 36% 0.77 ± 11% perf-stat.node-store-miss-rate%
1.003e+09 32% 1.329e+09 perf-stat.node-loads
0.51 32% 0.67 perf-stat.ipc
169613 26% 212878 perf-stat.cpu-migrations
67010904 25% 83501581 perf-stat.iTLB-loads
2.42e+08 21% 2.929e+08 perf-stat.dTLB-load-misses
95290199 21% 1.152e+08 perf-stat.dTLB-store-misses
6.316e+12 21% 7.631e+12 perf-stat.dTLB-loads
2.945e+13 21% 3.555e+13 perf-stat.instructions
9.374e+12 21% 1.132e+13 perf-stat.branch-instructions
1.433e+09 21% 1.729e+09 perf-stat.branch-misses
2.432e+12 20% 2.926e+12 perf-stat.dTLB-stores
10269271 19% 12214968 perf-stat.minor-faults
10269275 19% 12214968 perf-stat.page-faults
5.543e+08 18% 6.559e+08 perf-stat.node-load-misses
1.064e+08 18% 1.257e+08 ± 3% perf-stat.iTLB-load-misses
3.017e+11 15% 3.458e+11 perf-stat.cache-references
35.58 -7% 33.05 perf-stat.node-load-miss-rate%
5.825e+13 -8% 5.337e+13 perf-stat.cpu-cycles
1.02e+11 -16% 8.544e+10 perf-stat.cache-misses
1.731e+10 -20% 1.381e+10 perf-stat.node-stores
1.98 -24% 1.50 perf-stat.cpi
33.80 -27% 24.70 perf-stat.cache-miss-rate%
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Xiaolong
2 years, 6 months
d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208
by kernel test robot
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
commit d57108d4f6791291e89d980e7f7a3566c32ab188
Author: Thomas Gleixner <tglx(a)linutronix.de>
AuthorDate: Tue Sep 12 21:37:11 2017 +0200
Commit: Ingo Molnar <mingo(a)kernel.org>
CommitDate: Thu Sep 14 11:41:06 2017 +0200
watchdog/core: Get rid of the thread teardown/setup dance
The lockup detector reconfiguration tears down all watchdog threads when
the watchdog is disabled and sets them up again when its enabled.
That's a pointless exercise. The watchdog threads are not consuming an
insane amount of resources, so it's enough to set them up at init time and
keep them in parked position when the watchdog is disabled and unpark them
when it is reenabled. The smpboot thread infrastructure takes care of
keeping the force parked threads in place even across cpu hotplug.
Aside of that the code implements the park/unpark facility of smp hotplug
threads on its own, which is even more pointless. We have functionality in
the smpboot thread code to do so.
Use the new thread management functions and get rid of the unholy mess.
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Don Zickus <dzickus(a)redhat.com>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Chris Metcalf <cmetcalf(a)mellanox.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Nicholas Piggin <npiggin(a)gmail.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Sebastian Siewior <bigeasy(a)linutronix.de>
Cc: Ulrich Obergfell <uobergfe(a)redhat.com>
Link: http://lkml.kernel.org/r/20170912194147.470370113@linutronix.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
2eb2527f84 watchdog/core: Create new thread handling infrastructure
d57108d4f6 watchdog/core: Get rid of the thread teardown/setup dance
57f9efe285 Merge branch 'WIP.x86/fpu'
+------------------------------------------+------------+------------+------------+
| | 2eb2527f84 | d57108d4f6 | 57f9efe285 |
+------------------------------------------+------------+------------+------------+
| boot_successes | 35 | 0 | 0 |
| boot_failures | 0 | 15 | 9 |
| BUG:unable_to_handle_kernel | 0 | 15 | 9 |
| Oops:#[##] | 0 | 15 | 9 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 15 | 9 |
+------------------------------------------+------------+------------+------------+
[ 0.030029] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes)
[ 0.033296] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[ 0.034018] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[ 0.035023] CPU: Intel Common KVM processor (family: 0xf, model: 0x6, stepping: 0x1)
[ 0.042302] Performance Events: unsupported Netburst CPU model 6 no PMU driver, software events only.
[ 0.051650] BUG: unable to handle kernel NULL pointer dereference at 0000000000000208
[ 0.052000] IP: perf_event_release_kernel+0x14/0x1ed
[ 0.052000] PGD 0 P4D 0
[ 0.052000] Oops: 0000 [#1]
[ 0.052000] CPU: 0 PID: 1 Comm: swapper Not tainted 4.13.0-11828-gd57108d #1
[ 0.052000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[ 0.052000] task: ffff88001e532000 task.stack: ffffc90000008000
[ 0.052000] RIP: 0010:perf_event_release_kernel+0x14/0x1ed
[ 0.052000] RSP: 0000:ffffc9000000be38 EFLAGS: 00010292
[ 0.052000] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 000000000313fa45
[ 0.052000] RDX: 0000000000000001 RSI: ffffffff828265e0 RDI: 0000000000000000
[ 0.052000] RBP: ffffc9000000beb8 R08: ffffc9000000bdc8 R09: 0000000000000000
[ 0.052000] R10: ffff88001e532000 R11: ffffc9000000bd68 R12: 0000000000000000
[ 0.052000] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 0.052000] FS: 0000000000000000(0000) GS:ffffffff8262f000(0000) knlGS:0000000000000000
[ 0.052000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.052000] CR2: 0000000000000208 CR3: 0000000002618000 CR4: 00000000000006b0
[ 0.052000] Call Trace:
[ 0.052000] ? trace_hardirqs_on_caller+0x162/0x198
[ 0.052000] hardlockup_detector_perf_cleanup+0x20/0x2d
[ 0.052000] __lockup_detector_cleanup+0x2c/0x2e
[ 0.052000] softlockup_update_smpboot_threads+0x48/0x4a
[ 0.052000] softlockup_reconfigure_threads+0x21/0x5a
[ 0.052000] lockup_detector_init+0x75/0x83
[ 0.052000] kernel_init_freeable+0x67/0xf0
[ 0.052000] ? rest_init+0x13a/0x13a
[ 0.052000] kernel_init+0xe/0xf8
[ 0.052000] ret_from_fork+0x2a/0x40
[ 0.052000] Code: df e8 0c b2 ff ff 4c 89 e7 e8 89 13 bd 00 41 5b 5b 41 5c 41 5d c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 89 fb 48 83 ec 58 <48> 83 bf 08 02 00 00 00 75 14 f6 87 8c 00 00 00 03 0f 84 9b 01
[ 0.052000] RIP: perf_event_release_kernel+0x14/0x1ed RSP: ffffc9000000be38
[ 0.052000] CR2: 0000000000000208
[ 0.052000] ---[ end trace ed0d2c92e47d08db ]---
[ 0.052000] Kernel panic - not syncing: Fatal exception
# HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD
git bisect start f2e99ca8b77c273bbdfdb8fde244eac3c906ac85 569dbb88e80deb68974ef6fdd6a13edb9d686261 --
git bisect good 05fbbb5abe5b8960120ec537339cdc4d670ed86b # 23:51 G 11 0 0 0 Merge 'rockchip/v4.14-armsoc/fixes64' into devel-catchup-201709141913
git bisect good 769ab76856cc29ad3c700b038689d39ef07de0cc # 00:42 G 11 0 0 0 Merge 'ipsec/master' into devel-catchup-201709141913
git bisect bad 209a6f71dbcae51351811b4ea0712b2705e64b68 # 01:06 B 0 3 15 0 Merge 'tip/master' into devel-catchup-201709141913
git bisect good 7f4be2d15edbc94fda928a05cdb2692cf6ce1109 # 03:08 G 11 0 0 0 Merge branch 'WIP.x86/fpu'
git bisect good 2eb2527f847d1bd8d8fb9db1e8139db5d6eddb36 # 03:34 G 10 0 0 0 watchdog/core: Create new thread handling infrastructure
git bisect bad 178b9f7a36d2c74a38274b66dd89f53611298a19 # 03:45 B 0 2 14 0 watchdog/hardlockup/perf: Implement init time perf validation
git bisect bad 51d4052b01ca555e0d1d5fe297b309beb6c64aa0 # 03:59 B 0 5 17 0 watchdog/sysctl: Get rid of the #ifdeffery
git bisect bad e8b62b2dd14f8f2427856ba24cb7db922bda9bfd # 04:29 B 0 5 19 2 watchdog/core: Further simplify sysctl handling
git bisect bad d57108d4f6791291e89d980e7f7a3566c32ab188 # 04:45 B 0 2 15 1 watchdog/core: Get rid of the thread teardown/setup dance
# first bad commit: [d57108d4f6791291e89d980e7f7a3566c32ab188] watchdog/core: Get rid of the thread teardown/setup dance
git bisect good 2eb2527f847d1bd8d8fb9db1e8139db5d6eddb36 # 05:06 G 30 0 0 0 watchdog/core: Create new thread handling infrastructure
# extra tests with CONFIG_DEBUG_INFO_REDUCED
git bisect bad d57108d4f6791291e89d980e7f7a3566c32ab188 # 05:19 B 0 4 18 2 watchdog/core: Get rid of the thread teardown/setup dance
# extra tests on HEAD of linux-devel/devel-catchup-201709141913
git bisect bad f2e99ca8b77c273bbdfdb8fde244eac3c906ac85 # 05:24 B 0 31 46 0 0day head guard for 'devel-catchup-201709141913'
# extra tests on tree/branch tip/master
git bisect bad 57f9efe2850368ea37ef1ed430dd948d0d143afe # 05:39 B 0 5 19 2 Merge branch 'WIP.x86/fpu'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/lkp Intel Corporation
2 years, 6 months