Tested on master: fc45deac89ef63ca1c44e763c38ced7dfd72cbe1 OS: OpenSUSE During DISTRO tests the qemuarm buildset failed with kernel oops: Internal error: Oops: 17 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 42 Comm: jbd2/vda-8 Not tainted 4.1.8-yocto-standard #1 Hardware name: ARM-Versatile PB task: c7223300 ti: c725e000 task.ti: c725e000 PC is at blk_mq_tag_to_rq+0x24/0x78 LR is at bt_for_each+0x70/0xc4 pc : [<c0364458>] lr : [<c0368118>] psr: 20000113 sp : c725fa18 ip : c725fa30 fp : c725fa2c r10: c0365ce0 r9 : 00000020 r8 : c7104200 r7 : c70ee5ac r6 : 00000001 r5 : 00000021 r4 : c7122da0 r3 : c7104000 r2 : 00000000 r1 : 00000021 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 00093177 Table: 072f4000 DAC: 00000017 Process jbd2/vda-8 (pid: 42, stack limit = 0xc725e190) Stack: (0xc725fa18 to 0xc7260000) Suspect this was a hardware failure on the machine, due to not being able to reproduce issue so far. Left several buildsets to run over the weekend and if issue does not repeat will close bug.
(In reply to comment #0) > During DISTRO tests the qemuarm buildset failed with kernel oops: Correction, buildset was nightly-arm.
Was unable to reproduce problem. Will continue to run builds for another day or two.
Been running builds since this first happened. Haven't been able to reproduce this as of yet. Will continue to run builds at least for a few more days.
So far have run 15 back-to-back builds and I haven't been able to reproduce this.
Seems to be that this bug didn't happen again. So if the issue comes again please re-open the bug with panic information and core dump.
These bugs happen intermittently so I don't think closing this is appropriate. Equally, a full kernel stack trace would go a long way to helping try and figure this issue out or at least allow it to be compared with other bugs. Was the error message pasted here to only information available from the crash? NEEDINFO might be a better status for the bug.
Set to NEEDINFO waiting for new information.
I can provide access to the machine this was running on at the time it failed, but I don't think I can still recover the core dump for this, since the machine has been running other tests on it in the mean time and it has been subjected to at least 1 upgrade/reboot cycle.
It would be good to have a logic that stops when a given test fails for debugging, I believe that is not a feature of our current testing framework, right Mihail?
(In reply to comment #9) > It would be good to have a logic that stops when a given test fails for > debugging, I believe that is not a feature of our current testing framework, > right Mihail? As far as I know, we don't have this feature in our framework. This machine in particular is running tests under an Autobuilder setup, so having something like this wouldn't have helped all that much, since it was scheduled to run several buildsets in sequence. To be clear, the logs for the failure are still there and can be accessed, however I'm not sure if the kernel dump (if there is one from qemu) still exists.
Created attachment 2867 [details] fail log
(In reply to comment #11) > Created attachment 2867 [details] > fail log With this log i started investigation...
I found a patch [1] that seems to solve the issue but it didn't apply directly to our linux-yocto-4.1. I started to review the code for figure out if backport the patch is viable. https://github.com/torvalds/linux/commit/0048b4837affd153897ed1222283492070027aa9
Created attachment 2876 [details] blk-mq: fix race between timeout and freeing request I backported the patch and test into qemux86 and qemuarm running testimage for sato.
Patch integrated into linux-yocto [1], waiting for SRCREV recipe updates. [1]http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.1/commit/?h=standard/base&id=2c30f87db7824e90b0b096eee3a5b7f93c84b079
Merge at, http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=c093fd8bd2fbf070728f5401ce3e6cf951fa820d
Verified on 2.1 M1: 5e3e2e0cbb0a49986f4653e64c4c8d2b5461645e