Re: [PATCH 5.2 000/413] 5.2.3-stable review
Built and booted on my x86_64 test system. No dmesg regressions. Thank you Bharath
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Fri, Jul 26, 2019 at 12:18:54AM -0600, Kelsey Skunberg wrote: > On Wed, Jul 24, 2019 at 09:14:51PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.2.3 release. > > There are 413 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.3-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.2.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Compiled and booted with no regressions on my system. Great, thanks for testing and letting me know. greg k-h
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Wed, Jul 24, 2019 at 09:14:51PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.2.3 release. > There are 413 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.3-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.2.y > and the diffstat can be found below. > > thanks, > > greg k-h Compiled and booted with no regressions on my system. Cheers, Kelsey
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On 25/07/19 22:57, Sean Christopherson wrote: > On Thu, Jul 25, 2019 at 03:19:33PM -0500, Dan Rue wrote: >> I would still prefer to run the latest tests against all kernel versions >> (but better control when we upgrade it). Like I said, we can handle >> expected failures, and it would even help to validate backports for >> fixes that do get backported. I'm afraid on your behalf that snapping >> (and maintaining) branches per kernel branch is going to be a lot to >> manage. > > Having the branches would be beneficial for kernel developers as well, > e.g. on multiple occasions I've spent time hunting down non-existent KVM > bugs, only to realize my base kernel was stale with respect to kvm-unit-tests. > > My thought was to have a mostly-unmaintained branch for each major kernel > version, e.g. snapshot a working version of kvm_unit_tests when the KVM > pull request for the merge window is sent, and for the most part leave it > at that. I don't think it would introduce much overhead, but then again, > I'm not the person who would be maintaining this :-) > Yes, I agree. Stable backports that have fixes in kvm-unit-tests are relatively rare, so the branch would hardly move after a release is cut. Paolo
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Thu, Jul 25, 2019 at 03:19:33PM -0500, Dan Rue wrote: > I would still prefer to run the latest tests against all kernel versions > (but better control when we upgrade it). Like I said, we can handle > expected failures, and it would even help to validate backports for > fixes that do get backported. I'm afraid on your behalf that snapping > (and maintaining) branches per kernel branch is going to be a lot to > manage. Having the branches would be beneficial for kernel developers as well, e.g. on multiple occasions I've spent time hunting down non-existent KVM bugs, only to realize my base kernel was stale with respect to kvm-unit-tests. My thought was to have a mostly-unmaintained branch for each major kernel version, e.g. snapshot a working version of kvm_unit_tests when the KVM pull request for the merge window is sent, and for the most part leave it at that. I don't think it would introduce much overhead, but then again, I'm not the person who would be maintaining this :-)
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Thu, Jul 25, 2019 at 07:06:19PM +0200, Paolo Bonzini wrote: > On 25/07/19 18:39, Dan Rue wrote: > > To your point Paolo - reporting 'fail' because of a missing kernel > > feature is a generic problem we see across test suites, and causes tons > > of pain and misery for CI people. As a general rule, I'd avoid > > submodules, and even branches that track specific kernels. Rather, and I > > don't know if it's possible in this case, but the best way to manage it > > from both a test author and a test runner POV is to wrap the test in > > kernel feature checks, kernel version checks, kernel config checks, etc. > > Report 'skip' if the environment in which the test is running isn't > > sufficient to run the test. Then, you only have to maintain one version > > of the test suite, users can always use the latest, and critically: all > > failures are actual failures. > > Note that kvm-unit-tests are not really testing new kernel features; > those are covered by tools/testing/selftests/kvm. For some of these > kvm-unit-tests there are some CPU features that we can check from the > virtual machine, but those are easy to handle and they produce SKIP > results just fine. > > The problematic ones are tests that cover emulation accuracy. These are > effectively bugfixes, so the failures you see _are_ actual failures. At > the same time, the bugs are usually inoffensive(*), while the fixes are > invasive and a bad source of cause conflicts in older Linux versions. > This combines so that backporting to stable is not feasible. In this case, a fail result seems correct then. The thing we're doing that we need to fix is to run against a pinned version of kvm-unit-tests and upgrade it independently so that we can identify such failures and mark them as known issues. > > Passing the host kernel version would be really ugly because 1) the > tests can run on other hypervisor or emulators or even bare metal, and > of course the host kernel version has no bearing if you're using > userspace emulation 2) there are thousands of tests that would be > littered with kernel version checks of little significance. > > So this is why I suggested a submodule: using a submodule effectively > ignores all tests that were added after a given Linus release, and thus > all the failures for which backports are just not going to happen. > However, if Sean's idea of creating a linux-M.N branch in > kvm-unit-tests.git works for you, we can also do that as a stopgap > measure to ease your testing. I would still prefer to run the latest tests against all kernel versions (but better control when we upgrade it). Like I said, we can handle expected failures, and it would even help to validate backports for fixes that do get backported. I'm afraid on your behalf that snapping (and maintaining) branches per kernel branch is going to be a lot to manage. In any case, _thank you so much_ for jumping on this and helping us run these tests. Is there anything else we can do to make this better for you? Dan > > Thanks, > > Paolo > > (*) if they aren't, we *do* mark them for backport! -- Linaro - Kernel Validation
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Thu, Jul 25, 2019 at 10:04:43AM +0100, Jon Hunter wrote: > > On 24/07/2019 20:14, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.2.3 release. > > There are 413 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.3-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.2.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > All tests are passing for Tegra ... > > Test results for stable-v5.2: > 12 builds:12 pass, 0 fail > 22 boots: 22 pass, 0 fail > 38 tests: 38 pass, 0 fail > > Linux version:5.2.3-rc1-gdb628fe0e67f > Boards tested:tegra124-jetson-tk1, tegra186-p2771-, > tegra194-p2972-, tegra20-ventana, > tegra210-p2371-2180, tegra30-cardhu-a04 > Great, thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Thu, Jul 25, 2019 at 09:35:09AM -0600, shuah wrote: > On 7/24/19 1:14 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.2.3 release. > > There are 413 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.3-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.2.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On 25/07/19 18:39, Dan Rue wrote: > To your point Paolo - reporting 'fail' because of a missing kernel > feature is a generic problem we see across test suites, and causes tons > of pain and misery for CI people. As a general rule, I'd avoid > submodules, and even branches that track specific kernels. Rather, and I > don't know if it's possible in this case, but the best way to manage it > from both a test author and a test runner POV is to wrap the test in > kernel feature checks, kernel version checks, kernel config checks, etc. > Report 'skip' if the environment in which the test is running isn't > sufficient to run the test. Then, you only have to maintain one version > of the test suite, users can always use the latest, and critically: all > failures are actual failures. Note that kvm-unit-tests are not really testing new kernel features; those are covered by tools/testing/selftests/kvm. For some of these kvm-unit-tests there are some CPU features that we can check from the virtual machine, but those are easy to handle and they produce SKIP results just fine. The problematic ones are tests that cover emulation accuracy. These are effectively bugfixes, so the failures you see _are_ actual failures. At the same time, the bugs are usually inoffensive(*), while the fixes are invasive and a bad source of cause conflicts in older Linux versions. This combines so that backporting to stable is not feasible. Passing the host kernel version would be really ugly because 1) the tests can run on other hypervisor or emulators or even bare metal, and of course the host kernel version has no bearing if you're using userspace emulation 2) there are thousands of tests that would be littered with kernel version checks of little significance. So this is why I suggested a submodule: using a submodule effectively ignores all tests that were added after a given Linus release, and thus all the failures for which backports are just not going to happen. However, if Sean's idea of creating a linux-M.N branch in kvm-unit-tests.git works for you, we can also do that as a stopgap measure to ease your testing. Thanks, Paolo (*) if they aren't, we *do* mark them for backport!
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Wed, Jul 24, 2019 at 09:14:51PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.2.3 release. > There are 413 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > Anything received after that time might be too late. > Build results: total: 159 pass: 159 fail: 0 Qemu test results: total: 364 pass: 364 fail: 0 Guenter
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Thu, Jul 25, 2019 at 06:30:10PM +0200, Paolo Bonzini wrote: > On 25/07/19 18:20, Sean Christopherson wrote: > > On Thu, Jul 25, 2019 at 06:10:37PM +0200, Paolo Bonzini wrote: > >> On 25/07/19 18:09, Sean Christopherson wrote: > This investigation confirms it is a new test code failure on stable-rc > 5.2.3 > >>> No, it only confirms that kvm-unit-tests/master fails on 5.2.*. To > >>> confirm > >>> a new failure in 5.2.3 you would need to show a test that passes on 5.2.2 > >>> and fails on 5.2.3. > >> > >> I think he meant "a failure in new test code". :) > > > > Ah, that does appear to be the case. So just to be clear, we're good, > > right? > > Yes. I'm happy to gather ideas on how to avoid this (i.e. 1) if a > submodule would be useful; 2) where to stick it). As a starting point, what about adding "stable" branches for each kernel release to kvm-unit-tests, e.g. linux-5.2.y? I assume we'd need something similar for the submodules anyways.
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Thu, Jul 25, 2019 at 06:30:10PM +0200, Paolo Bonzini wrote: > On 25/07/19 18:20, Sean Christopherson wrote: > > On Thu, Jul 25, 2019 at 06:10:37PM +0200, Paolo Bonzini wrote: > >> On 25/07/19 18:09, Sean Christopherson wrote: > This investigation confirms it is a new test code failure on stable-rc > 5.2.3 > >>> No, it only confirms that kvm-unit-tests/master fails on 5.2.*. To > >>> confirm > >>> a new failure in 5.2.3 you would need to show a test that passes on 5.2.2 > >>> and fails on 5.2.3. > >> > >> I think he meant "a failure in new test code". :) > > > > Ah, that does appear to be the case. So just to be clear, we're good, > > right? > > Yes. I'm happy to gather ideas on how to avoid this (i.e. 1) if a > submodule would be useful; 2) where to stick it). Hi! First, to be clear: from LKFT perspective there are no kernel regressions here. To your point Paolo - reporting 'fail' because of a missing kernel feature is a generic problem we see across test suites, and causes tons of pain and misery for CI people. As a general rule, I'd avoid submodules, and even branches that track specific kernels. Rather, and I don't know if it's possible in this case, but the best way to manage it from both a test author and a test runner POV is to wrap the test in kernel feature checks, kernel version checks, kernel config checks, etc. Report 'skip' if the environment in which the test is running isn't sufficient to run the test. Then, you only have to maintain one version of the test suite, users can always use the latest, and critically: all failures are actual failures. Dan > > Paolo -- Linaro - Kernel Validation
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On 25/07/19 18:20, Sean Christopherson wrote: > On Thu, Jul 25, 2019 at 06:10:37PM +0200, Paolo Bonzini wrote: >> On 25/07/19 18:09, Sean Christopherson wrote: This investigation confirms it is a new test code failure on stable-rc 5.2.3 >>> No, it only confirms that kvm-unit-tests/master fails on 5.2.*. To confirm >>> a new failure in 5.2.3 you would need to show a test that passes on 5.2.2 >>> and fails on 5.2.3. >> >> I think he meant "a failure in new test code". :) > > Ah, that does appear to be the case. So just to be clear, we're good, right? Yes. I'm happy to gather ideas on how to avoid this (i.e. 1) if a submodule would be useful; 2) where to stick it). Paolo
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Thu, Jul 25, 2019 at 06:10:37PM +0200, Paolo Bonzini wrote: > On 25/07/19 18:09, Sean Christopherson wrote: > >> This investigation confirms it is a new test code failure on stable-rc > >> 5.2.3 > > No, it only confirms that kvm-unit-tests/master fails on 5.2.*. To confirm > > a new failure in 5.2.3 you would need to show a test that passes on 5.2.2 > > and fails on 5.2.3. > > I think he meant "a failure in new test code". :) Ah, that does appear to be the case. So just to be clear, we're good, right?
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On 25/07/19 18:09, Sean Christopherson wrote:
>> This investigation confirms it is a new test code failure on stable-rc 5.2.3
> No, it only confirms that kvm-unit-tests/master fails on 5.2.*. To confirm
> a new failure in 5.2.3 you would need to show a test that passes on 5.2.2
> and fails on 5.2.3.
I think he meant "a failure in new test code". :)
Paolo
> As Paolo suspected, kvm-unit-tests/master fails on 5.2.* and passes if
> commit 95d6d2c ("nVMX: Test Host Segment Registers and Descriptor Tables on
> vmentry of nested guests") is reverted (from kvm-unit-tests).
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Thu, Jul 25, 2019 at 07:35:13PM +0530, Naresh Kamboju wrote:
> Paolo,
>
> On Thu, 25 Jul 2019 at 19:17, Paolo Bonzini wrote:
> >
> > On 25/07/19 13:34, Greg Kroah-Hartman wrote:
> > > Any chance you can run 'git bisect' to find the offending patch? Or
> > > just try reverting a few, you can ignore the ppc ones, so that only
> > > leaves you 7 different commits.
> > >
> > > Does this same test pass in 5.3-rc1?
>
> Yes. same test pass on 5.3-rc1
> kvm unit test always fetching master branch and at tip
> runs the latest test code on all branches
> mainline 5.3-rc1 and stable-rc-5.2 branch
>
> >
> > Anders, are you running the same kvm-unit-tests commit that passed for
> > 5.2.2? My suspicion is that your previous test didn't have this commit
>
> No.
> I see two extra test code commits for 5.2.3
> Re-tested 5.2.2 with tip of kvm unit tests sources and vmx test FAILED [1].
>
> Greg,
> This investigation confirms it is a new test code failure on stable-rc 5.2.3
No, it only confirms that kvm-unit-tests/master fails on 5.2.*. To confirm
a new failure in 5.2.3 you would need to show a test that passes on 5.2.2
and fails on 5.2.3.
As Paolo suspected, kvm-unit-tests/master fails on 5.2.* and passes if
commit 95d6d2c ("nVMX: Test Host Segment Registers and Descriptor Tables on
vmentry of nested guests") is reverted (from kvm-unit-tests).
The failures are quite clearly in the new test(s).
PASS: HOST_SEL_CS 8: vmlaunch succeeds
FAIL: HOST_SEL_CS 9: vmlaunch fails
FAIL: HOST_SEL_CS c: vmlaunch fails
PASS: HOST_SEL_SS 10: vmlaunch succeeds
FAIL: HOST_SEL_SS 11: vmlaunch fails
FAIL: HOST_SEL_SS 14: vmlaunch fails
PASS: HOST_SEL_DS 10: vmlaunch succeeds
FAIL: HOST_SEL_DS 11: vmlaunch fails
FAIL: HOST_SEL_DS 14: vmlaunch fails
PASS: HOST_SEL_ES 10: vmlaunch succeeds
FAIL: HOST_SEL_ES 11: vmlaunch fails
FAIL: HOST_SEL_ES 14: vmlaunch fails
PASS: HOST_SEL_FS 10: vmlaunch succeeds
FAIL: HOST_SEL_FS 11: vmlaunch fails
FAIL: HOST_SEL_FS 14: vmlaunch fails
PASS: HOST_SEL_GS 10: vmlaunch succeeds
FAIL: HOST_SEL_GS 11: vmlaunch fails
FAIL: HOST_SEL_GS 14: vmlaunch fails
PASS: HOST_SEL_TR 80: vmlaunch succeeds
FAIL: HOST_SEL_TR 81: vmlaunch fails
KVM: entry failed, hardware error 0x8021
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On 7/24/19 1:14 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.2.3 release. There are 413 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.3-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 5.2 000/413] 5.2.3-stable review
Paolo, On Thu, 25 Jul 2019 at 19:17, Paolo Bonzini wrote: > > On 25/07/19 13:34, Greg Kroah-Hartman wrote: > > Any chance you can run 'git bisect' to find the offending patch? Or > > just try reverting a few, you can ignore the ppc ones, so that only > > leaves you 7 different commits. > > > > Does this same test pass in 5.3-rc1? Yes. same test pass on 5.3-rc1 kvm unit test always fetching master branch and at tip runs the latest test code on all branches mainline 5.3-rc1 and stable-rc-5.2 branch > > Anders, are you running the same kvm-unit-tests commit that passed for > 5.2.2? My suspicion is that your previous test didn't have this commit No. I see two extra test code commits for 5.2.3 Re-tested 5.2.2 with tip of kvm unit tests sources and vmx test FAILED [1]. Greg, This investigation confirms it is a new test code failure on stable-rc 5.2.3 > since the symptoms match and the corresponding fix was made in 5.3. Thanks for your findings. > Paolo - Naresh [1] https://lkft.validation.linaro.org/scheduler/job/837811
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On 25/07/19 13:34, Greg Kroah-Hartman wrote: > Any chance you can run 'git bisect' to find the offending patch? Or > just try reverting a few, you can ignore the ppc ones, so that only > leaves you 7 different commits. > > Does this same test pass in 5.3-rc1? Anders, are you running the same kvm-unit-tests commit that passed for 5.2.2? My suspicion is that your previous test didn't have this commit commit 95d6d2c3228891537ee8e35d2e2984964ee0cf6b Author: Krish Sadhukhan AuthorDate: Fri Jun 28 18:14:47 2019 -0400 Commit: Paolo Bonzini CommitDate: Thu Jul 11 14:26:53 2019 +0200 nVMX: Test Host Segment Registers and Descriptor Tables on vmentry of nested guests since the symptoms match and the corresponding fix was made in 5.3. I think Linaro's tests would be helped by making kvm-unit-tests.git a submodule of Linux, but I'm a bit wary since it would be the first submodule and I wouldn't know where to put it... Paolo
Re: [PATCH 5.2 000/413] 5.2.3-stable review
> > Regressions (compared to build v5.2.2) > > > > > > x86: > > kvm-unit-tests: > > * vmx > > > > > > TESTNAME=vmx TIMEOUT=90s ACCEL= ./x86/run x86/vmx.flat -smp 1 -cpu > > host,+vmx -append \"-exit_monitor_from_l2_test -ept_access* -vmx_smp* > > -vmx_vmcs_shadow_test\" > > [ 155.670748] kvm [6062]: vcpu0, guest rIP: 0x4050cb ... > > [ 158.479030] nested_vmx_exit_reflected failed vm entry 7 > > [ 161.044379] set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state. > > FAIL vmx (timeout; duration=90s) > > > > kernel-config: > > http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-stable-rc-5.2/14/config > > Full log: https://lkft.validation.linaro.org/scheduler/job/836289#L1597 > > Ick. > > Any chance you can run 'git bisect' to find the offending patch? Or > just try reverting a few, you can ignore the ppc ones, so that only > leaves you 7 different commits. We have started 'git bisect' please allow sometime. > Does this same test pass in 5.3-rc1? yes. kvm-unit-tests: vmx test getting PASS on 5.3-rc1 mainline kernel [1]. ref: [1] https://qa-reports.linaro.org/lkft/linux-mainline-oe/tests/kvm-unit-tests/vmx - Naresh > > thanks, > > greg k-h
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Thu, Jul 25, 2019 at 01:16:19PM +0200, Anders Roxell wrote: > On Wed, 24 Jul 2019 at 21:25, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.2.3 release. > > There are 413 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.3-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.2.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Results from Linaro’s test farm. > Regressions detected. > > Summary > > > kernel: 5.2.3-rc1 > git repo: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > git branch: linux-5.2.y > git commit: db628fe0e67ff8c66e8c6ba76e5e4becfa75fe21 > git describe: v5.2.2-414-gdb628fe0e67f > Test details: > https://qa-reports.linaro.org/lkft/linux-stable-rc-5.2-oe/build/v5.2.2-414-gdb628fe0e67f > > Regressions (compared to build v5.2.2) > > > x86: > kvm-unit-tests: > * vmx > > > TESTNAME=vmx TIMEOUT=90s ACCEL= ./x86/run x86/vmx.flat -smp 1 -cpu > host,+vmx -append \"-exit_monitor_from_l2_test -ept_access* -vmx_smp* > -vmx_vmcs_shadow_test\" > [ 155.670748] kvm [6062]: vcpu0, guest rIP: 0x4050cb > kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop > [ 155.681027] kvm [6062]: vcpu0, guest rIP: 0x408911 > kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x3, nop > [ 155.690749] kvm [6062]: vcpu0, guest rIP: 0x40bb39 > kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop > [ 155.700595] kvm [6062]: vcpu0, guest rIP: 0x4089b2 > kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x3, nop > [ 158.349308] nested_vmx_exit_reflected failed vm entry 7 > [ 158.363737] nested_vmx_exit_reflected failed vm entry 7 > [ 158.378010] nested_vmx_exit_reflected failed vm entry 7 > [ 158.392480] nested_vmx_exit_reflected failed vm entry 7 > [ 158.406920] nested_vmx_exit_reflected failed vm entry 7 > [ 158.421390] nested_vmx_exit_reflected failed vm entry 7 > [ 158.435795] nested_vmx_exit_reflected failed vm entry 7 > [ 158.450276] nested_vmx_exit_reflected failed vm entry 7 > [ 158.464674] nested_vmx_exit_reflected failed vm entry 7 > [ 158.479030] nested_vmx_exit_reflected failed vm entry 7 > [ 161.044379] set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state. > FAIL vmx (timeout; duration=90s) > > kernel-config: > http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-stable-rc-5.2/14/config > Full log: https://lkft.validation.linaro.org/scheduler/job/836289#L1597 Ick. Any chance you can run 'git bisect' to find the offending patch? Or just try reverting a few, you can ignore the ppc ones, so that only leaves you 7 different commits. Does this same test pass in 5.3-rc1? thanks, greg k-h
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On Wed, 24 Jul 2019 at 21:25, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.2.3 release. > There are 413 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.3-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.2.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. Regressions detected. Summary kernel: 5.2.3-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.2.y git commit: db628fe0e67ff8c66e8c6ba76e5e4becfa75fe21 git describe: v5.2.2-414-gdb628fe0e67f Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.2-oe/build/v5.2.2-414-gdb628fe0e67f Regressions (compared to build v5.2.2) x86: kvm-unit-tests: * vmx TESTNAME=vmx TIMEOUT=90s ACCEL= ./x86/run x86/vmx.flat -smp 1 -cpu host,+vmx -append \"-exit_monitor_from_l2_test -ept_access* -vmx_smp* -vmx_vmcs_shadow_test\" [ 155.670748] kvm [6062]: vcpu0, guest rIP: 0x4050cb kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop [ 155.681027] kvm [6062]: vcpu0, guest rIP: 0x408911 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x3, nop [ 155.690749] kvm [6062]: vcpu0, guest rIP: 0x40bb39 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop [ 155.700595] kvm [6062]: vcpu0, guest rIP: 0x4089b2 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x3, nop [ 158.349308] nested_vmx_exit_reflected failed vm entry 7 [ 158.363737] nested_vmx_exit_reflected failed vm entry 7 [ 158.378010] nested_vmx_exit_reflected failed vm entry 7 [ 158.392480] nested_vmx_exit_reflected failed vm entry 7 [ 158.406920] nested_vmx_exit_reflected failed vm entry 7 [ 158.421390] nested_vmx_exit_reflected failed vm entry 7 [ 158.435795] nested_vmx_exit_reflected failed vm entry 7 [ 158.450276] nested_vmx_exit_reflected failed vm entry 7 [ 158.464674] nested_vmx_exit_reflected failed vm entry 7 [ 158.479030] nested_vmx_exit_reflected failed vm entry 7 [ 161.044379] set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state. FAIL vmx (timeout; duration=90s) kernel-config: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/intel-corei7-64/lkft/linux-stable-rc-5.2/14/config Full log: https://lkft.validation.linaro.org/scheduler/job/836289#L1597 No fixes (compared to build v5.2.2) Ran 22506 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * network-basic-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-fs-tests * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 5.2 000/413] 5.2.3-stable review
On 24/07/2019 20:14, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.2.3 release. > There are 413 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.3-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.2.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests are passing for Tegra ... Test results for stable-v5.2: 12 builds: 12 pass, 0 fail 22 boots: 22 pass, 0 fail 38 tests: 38 pass, 0 fail Linux version: 5.2.3-rc1-gdb628fe0e67f Boards tested: tegra124-jetson-tk1, tegra186-p2771-, tegra194-p2972-, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Cheers Jon -- nvpublic
Re: [PATCH 5.2 000/413] 5.2.3-stable review
stable-rc/linux-5.2.y boot: 139 boots: 1 failed, 136 passed with 1 offline, 1 untried/unknown (v5.2.2-414-ga4059e390eb8) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.2.y/kernel/v5.2.2-414-ga4059e390eb8/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.2.y/kernel/v5.2.2-414-ga4059e390eb8/ Tree: stable-rc Branch: linux-5.2.y Git Describe: v5.2.2-414-ga4059e390eb8 Git Commit: a4059e390eb842ee95dcb0b856eee5cc422a815b Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 81 unique boards, 28 SoC families, 17 builds out of 209 Boot Failure Detected: arm64: defconfig: gcc-8: meson-gxl-s905x-nexbox-a95x: 1 failed lab Offline Platforms: arm64: defconfig: gcc-8 meson-gxbb-odroidc2: 1 offline lab --- For more info write to
[PATCH 5.2 000/413] 5.2.3-stable review
This is the start of the stable review cycle for the 5.2.3 release. There are 413 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri 26 Jul 2019 07:13:35 PM UTC. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.3-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 5.2.3-rc1 Junxiao Bi dm bufio: fix deadlock with loop device Mike Snitzer dm thin metadata: check if in fail_io mode when setting needs_check Bjorn Andersson phy: qcom-qmp: Correct READY_STATUS poll break condition Norbert Manthey pstore: Fix double-free in pstore_mkfile() failure path Josua Mayer dt-bindings: allow up to four clocks for orion-mdio Josua Mayer net: mvmdio: allow up to four clocks to be specified for orion-mdio Tejun Heo blkcg: update blkcg_print_stat() to handle larger outputs Tejun Heo blk-iolatency: clear use_delay when io.latency is set to zero Peng Fan clk: imx: imx8mm: correct audio_pll2_clk to audio_pll2_out Konstantin Khlebnikov blk-throttle: fix zero wait time for iops throttled group Lee, Chiasheng usb: Handle USB3 remote wakeup for LPM enabled devices correctly Matthew Wilcox (Oracle) dax: Fix missed wakeup with PMD faults Szymon Janc Bluetooth: Add SMP workaround Microsoft Surface Precision Mouse bug Alexander Shishkin intel_th: msu: Fix single mode with disabled IOMMU YueHaibing intel_th: msu: Remove set but not used variable 'last' liaoweixiong mtd: spinand: read returns badly if the last page has bitflips Xiaolei Li mtd: rawnand: mtk: Correct low level time calculation of r/w cycle Dan Carpenter eCryptfs: fix a couple type promotion bugs Jorge Ramirez-Ortiz mmc: sdhci-msm: fix mutex while in spinlock Nathan Lynch powerpc/pseries: Fix oops in hotplug memory notifier Greg Kurz powerpc/pseries: Fix xive=off command line Alexey Kardashevskiy powerpc/powernv: Fix stale iommu table base after VFIO Athira Rajeev powerpc/powernv/idle: Fix restore of SPRN_LDBAR for POWER9 stop state. Greg Kurz powerpc/powernv/npu: Fix reference leak Ravi Bangoria powerpc/watchpoint: Restore NV GPRs while returning from exception Andreas Schwab powerpc/mm/32s: fix condition that is always true Christophe Leroy powerpc/32s: fix suspend/resume when IBATs 4-7 are used Helge Deller parisc: Fix kernel panic due invalid values in IAOQ0 or IAOQ1 Helge Deller parisc: Avoid kernel panic triggered by invalid kprobe Helge Deller parisc: Ensure userspace privilege for ptraced processes in regset functions Steve Longerbeam gpu: ipu-v3: ipu-ic: Fix saturation bit offset in TPMEM Nadav Amit resource: fix locking in find_next_iomem_res() Drew Davenport include/asm-generic/bug.h: fix "cut here" for WARN_ON for __WARN_TAINT architectures Jan Harkes coda: pass the host file in vma->vm_file on mmap Henry Burns mm/z3fold.c: lock z3fold page before __SetPageMovable() Yafang Shao mm/memcontrol: fix wrong statistics in memory.stat Dan Williams libnvdimm/pfn: fix fsdax-mode namespace info-block zero-fields Aneesh Kumar K.V mm/nvdimm: add is_ioremap_addr and use that to check ioremap address Kuo-Hsin Yang mm: vmscan: scan anonymous pages on file refaults Aaron Armstrong Skomra HID: wacom: correct touch resolution x/y typo Aaron Armstrong Skomra HID: wacom: generic: Correct pad syncing Aaron Armstrong Skomra HID: wacom: generic: only switch the mode on devices with LEDs Danit Goldberg IB/mlx5: Report correctly tag matching rendezvous capability Filipe Manana Btrfs: add missing inode version, ctime and mtime updates when punching hole Filipe Manana Btrfs: fix fsync not persisting dentry deletions due to inode evictions Filipe Manana Btrfs: fix data loss after inode eviction, renaming it, and fsync it Johannes Thumshirn btrfs: correctly validate compression type Niklas Cassel PCI: qcom: Ensure that PERST is asserted for at least 100 ms Mika Westerberg PCI: Do not poll for PME if the device is in D3cold Dexuan Cui PCI: hv: Fix a use-after-free bug in hv_eject_device_work() Alexander Shishkin intel_th: pci: Add Ice Lake NNPI support Jason Gunthorpe RDMA/odp: Fix missed unlock in non-blocking invalidate_start Bart Van Assche RDMA/srp: Accept again source addresses that do not have a port number Damien Le Moal block: Fix potential overflow in blk_report_zones() Damien Le Moal block:
