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