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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/01/18 09:48, Thomas Gleixner wrote:
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?

It does boot with pti=off (and KVM disabled):

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

I'll start a test instance here as well.

Thanks,

	tglx



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]