| Summary: | Perf/kernel-devsrc race | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Ross Burton <ross.burton> | ||||
| Component: | kernel | Assignee: | Bruce Ashfield <bruce.ashfield> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium | CC: | bruce.ashfield, richard.purdie, sgw, tom.zanussi | ||||
| Version: | 1.8 | ||||||
| Target Milestone: | 2.2 M3 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | Waiting for 4.7 release | ||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
|
Description
Ross Burton
2015-03-06 16:42:46 UTC
accepting this. But without being able to reproduce it here, we'll need a generic solution that likely makes a copy of these files earlier on in the process. This should be fixed when: "[PATCH] kernel.bbclass: Fix race condition" is merged to oe-core [YOCTO: 7321]. Bumping to 1.9, since that's where that patch will land. We actually have a couple more problems with perf and kernel-devsrc. Firstly, the sed changes in perf do_configure may or may not make it into the kernel-devsrc tarball depending on the task execution order. Examples would be the CC changes to Makefile. Secondly, the sed changes can apply multiple times for util/debug.h. See my attached screenshot which has repackaged builds a few times. Created attachment 2544 [details]
Showing difference in kernel-devsrc rootfs contents
I'll revisit this change with the 4.1 kernel update. I knew the sed changes would be applied multiple times, it just wasn't clear if it would cause issues. We can add a detect, and only do the modification if the change hasn't already been made. Being unable to patch the kernel to fix perf issues .. is definitely a pain. (In reply to comment #4) > Created attachment 2544 [details] > Showing difference in kernel-devsrc rootfs contents ross: are we still seeing this periodically on the autobuilder ? The race that causes failures appears to have been fixed, but Richard has evidence that there's a number of non-fatal races remaining. (In reply to comment #7) > The race that causes failures appears to have been fixed, but Richard has > evidence that there's a number of non-fatal races remaining. Are there pointers to the new logs ? I've never seen this in any form in my builds. I'm not able to reproduce this, and am looking for a pointer to any new logs. Ross: is this the same as #9182 ? I'll consolidate them if you agree that it looks similar .. or is this really centred around install and not a race in the build/link steps ? They're definitely distinct, 9182 is a strict compile race where two compiles are running on the same object, this is more "interesting". ok. moving back to "in design", which means "Bruce is trying to see if he can make it happen" :) Doing a quick bounce on this bug to find out if it is still being seen. We can retest against the 4.7+ kernel, when it becomes the 2.2 default. I don't recall seeing this for a while now. We are going to take this opportunity and close this for now. Magic isn't good, but since we haven't seen it in a while, and we didn't reproduce it .. I'm going to close it. When (if) it comes back .. we'll obviously revisit it. |