[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e2ca38ba-41c5-5f3a-849a-340a3ac76b6d@redhat.com>
Date: Wed, 3 Jan 2018 12:14:00 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Guillaume Tucker <guillaume.tucker@...labora.com>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>,
Ingo Molnar <mingo@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
kernel-build-reports@...ts.linaro.org,
Matt Hart <matthew.hart@...aro.org>, stable@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, qemu-devel@...gnu.org
Subject: Re: stable/linux-4.14.y boot: 108 boots: 0 failed, 107 passed with 1
conflict (v4.14.11)
On 03/01/2018 11:36, Thomas Gleixner wrote:
> On Wed, 3 Jan 2018, Guillaume Tucker wrote:
>> On 03/01/18 09:48, Thomas Gleixner wrote:
>>>> 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
>
> So it's a qemu issue. Added qemu folks on Cc.
Reproduced, thanks. I will look into it.
Paolo
Powered by blists - more mailing lists