Bug 212625
| Summary: | QEMU always crashes | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Stephen Tweedie <sct> |
| Component: | kernel-xen | Assignee: | Don Zickus <dzickus> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.0 | CC: | riel, xen-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 5.0.0 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-11-28 21:31:11 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 210422 | ||
| Bug Blocks: | |||
|
Description
Stephen Tweedie
2006-10-27 19:14:21 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion. QE ack for RHEL5B2. *** Bug 212588 has been marked as a duplicate of this bug. *** OK, after a lot of testing last night, I've got some results: First of all, I can no longer reproduce the bug reported in #200382. Even using that same pre-fc6 rawhide kernel, with a recompiled hypervisor to get past the flood of timer messages that the original 1.2439 kernel+HV swamps the console with, everything works fine. I really don't know what precisely was the trigger for hitting the exec_limit:=~0UL path, but I can't reproduce it now, although I can definitely trigger the execshield GPF path in general. But I can force that path to be taken by setting limit to -1 by force when this path is taken. Doing so, with the #200382 patch otherwise completely reverted, I can reproduce exactly the GPF exec_limit=0xffffffff fixups that used to cause problems: #GPF fixup (0[seg:0]) at 00110918, CPU#1. exec_limit: ffffffff, user_cs: 0000ffff/00cffb00, CPU_cs: 000004f4/00c0fb00. and this succeeds just fine, on a RHEL-5 kernel+hypervisor. Furthermore, on the exact GPF infinite loops that we were getting before: #GPF fixup (0[seg:0]) at 080c76e1, CPU#0. exec_limit: ffffffff, user_cs: 0000ffff/00cffb00, CPU_cs: 000067ff/00cffb00. we were trying to change the limit to 0xfffff from 0xf67ff, with all other bits of current and intended CS the same; so even the new proposed patch to test only the limit bits wouldn't actually make the slightest difference to the problem that was happening in bug 200382. In short, I think we need to simply remove the linux-2.6-xen-execshield-lazy-exec-limit.patch entirely --- the fixed form cannot possibly fix the problem that it was initially generated for, and I have tested that the unpatched RHEL-5 kernel is just as effective as the "fixed" one at not crashing qemu/mono etc. Please change bugzilla status to POST once the removal of linux-2.6-xen-execshield-lazy-exec-limit.patch is posted to rhkernel-list. in kernel-2.6.18-1.2744.el5 |