| Summary: | Kernel oops on qemuarm boot | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Mihail Stanciu <stanciux.mihail> | ||||||
| Component: | core | Assignee: | Aníbal Limón <anibal.limon> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | Mihail Stanciu <stanciux.mihail> | ||||||
| Severity: | normal | ||||||||
| Priority: | Medium+ | CC: | benjamin.esquivel, bruce.ashfield, meta.mr.watcher, meta.watcher, richard.purdie | ||||||
| Version: | 2.0 | ||||||||
| Target Milestone: | 2.1 M1 | ||||||||
| Hardware: | x86 | ||||||||
| OS: | Multiple | ||||||||
| Whiteboard: | |||||||||
| OS type for building Yocto: | --- | Type of Regression: | Unknown (Hard to categorize) | ||||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||||
| Attachments: |
|
||||||||
|
Description
Mihail Stanciu
2015-11-06 13:52:08 UTC
(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 |