Re: stable/linux-4.14.y boot: 108 boots: 0 failed, 107 passed with 1 conflict (v4.14.11)

On Wed, 3 Jan 2018, Guillaume Tucker wrote:

On 03/01/18 03:11, kernelci.org bot wrote:

...

stable/linux-4.14.y boot: 108 boots: 0 failed, 107 passed with 1 conflict (v4.14.11)

Full Boot Summary: https://kernelci.org/boot/all/job/stable/branch/linux-4.14.y/kernel/v4.14.11... Full Build Summary: https://kernelci.org/build/stable/branch/linux-4.14.y/kernel/v4.14.11/

Tree: stable Branch: linux-4.14.y Git Describe: v4.14.11 Git Commit: 0d59679df5b53755c00ea0292df696f97bfc950d Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Tested: 59 unique boards, 23 SoC families, 16 builds out of 185

Boot Regressions Detected:

x86:

 x86_64_defconfig:
     qemu:
         lab-mhart: new failure (last pass: v4.14.10)

Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)

x86:

 x86_64_defconfig:
     qemu:
         lab-mhart: FAIL
         lab-collabora: PASS

Well, it turns out this is not exactly a conflict as there's a subtle difference between the qemu devices in lab-mhart and in lab-collabora. The ones in lab-collabora are configured to use KVM, and it looks like the ones in lab-mhart aren't.

So this job with KVM enabled passes in lab-collabora:

https://lava.collabora.co.uk/scheduler/job/1032358

but it fails if I tell LAVA (qemu) to disable KVM:

https://lava.collabora.co.uk/scheduler/job/1032359

with the same panic as in lab-mhart. It seems like it's failing to return from an interrupt:

http://lava.streamtester.net/scheduler/job/87308

[ 2.678828] ? native_iret+0x7/0x7 [ 2.679208] WARNING: can't dereference iret registers at 00000000ffc66068 for ip page_fault+0x11/0x60

This triggered an automated bisection on kernelci.org, please see the results below.

I may run another bisection with this config enabled earlier in the history to track down the actual change in the code that introduced the issue, let me know if it's worth doing.

No, because before that commit not all pieces are in place.

Can you please try the failing kernel with pti=off on the command line?

I'll start a test instance here as well.

Thanks,

tglx