Bug 1087810
| Summary: | BUG: scheduling while atomic: swapper/0/0/0x00000002 on Compaq ProLiant DL360 G2 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alexander Todorov <atodorov> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | rawhide | CC: | gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-11-06 00:04:22 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Alexander Todorov
2014-04-15 11:19:20 UTC
Is this the first kernel in the 3.15 series that you hit this issue with? If not, would it be possible to try using older 3.15 kernel builds in koji and seeing which is the first to hit this problem? (In reply to Josh Boyer from comment #3) > Is this the first kernel in the 3.15 series that you hit this issue with? I think yes. I see it only on one particular system with the Fedora-rawhide-20140414 snapshot. I've checked the history for that system but the error doesn't appear in older jobs. I've also checked other aborted jobs for all trees in the last 2 weeks and didn't find the same error with older snapshots. > If not, would it be possible to try using older 3.15 kernel builds in koji > and seeing which is the first to hit this problem? I don't think I can easily do that anyway. It looks like we hit this error while initially booting the installer from PXE. I'm not aware of any way to update the kernel used in installation images without creating new installation media. The -rc2 build I started this morning has the suspected fix for this issue from Ingo included in it. It would be great if you could test that out and let us know if the problem is resolved. Did you get a chance to test a newer snapshot? (In reply to Josh Boyer from comment #8) > Did you get a chance to test a newer snapshot? Josh, see comment #9. Both jobs still failed but console.log shows that installation was able to start. In one case anaconda died with a python traceback in stage2, the other died before starting stage 2 but was still able to boot the installer images. Moving to VERIFIED b/c the original issue is most likely fixed. I will investigate the reported anaconda failures a bit more and file bugs against anaconda if needed. |