Bug 214161
| Summary: | The Xen is in panic when specifying "maxmem =" in domVTI-config. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Akio Takebe <takebe_akio> | ||||||
| Component: | kernel-xen | Assignee: | Aron Griffis <agriffis> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 5.0 | CC: | bstein, clalance, katzj, sakaia | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | ia64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | beta2 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2006-12-23 02:04:53 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: | |||||||||
| Attachments: |
|
||||||||
|
Description
Akio Takebe
2006-11-06 11:17:44 UTC
Created attachment 140451 [details]
fix this maxmem isshue by changing from max_pages to tot_pages.
domVTi don't support maxmem.
So I change from max_pages to tot_pages.
I make a patch for rhel5beta2.
(forwarding on some comments from the IT): I'm a little bit confused here. The upstream patch that you reference does indeed change VMX_CONFIG_PAGES from #define VMX_CONFIG_PAGES(d) ((d)->max_pages - VMX_SYS_PAGES) to #define VMX_CONFIG_PAGES(d) ((d)->tot_pages - VMX_SYS_PAGES) However, the patch that is attached here and in the Bugzilla do this, and also comment out: ASSERT(d->max_pages == d->tot_pages); Why is there a discrepancy between the patches posted here and upstream? Chris Lalancette Matsuya-san, This issue is occurred in the case of max_pages != tot_pages. If debug=n at compile time, ASSERT() is nop. But If debug=y at compile time (as RedHat), ASSERT occurre panic. So I left the ASSERT for debug in community, but I'd like to remove this ASSERT to avoid this issue in sources of RH. If you want to remove it in community, I'll make a patch soon. Best Regards, Akio Takebe Yes, we much prefer to have the patch go upstream first, so that upstream can review it and make sure it is sound. Please patch it upstream, and then we can pull it back into RHEL-5. Thanks, Chris Lalancette I submitted a patch. Please see the below. http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=c10d4c6df482 Best Regards, Akio Takebe 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. Per discussion with Prarit and Aron, Treat as a bug. Patch is available per comment #6 above -> it's in xen/arch/ia64/vmx/vmx_init.c. Aron, please ACK for devel; QA please ACK/NAK as appropriate. QE ack for RHEL5. Ping devel.......... Please ACK and put bug in ASSIGNED state. Escalating for RHEL5.0 consideration per Thursday's RHEL5 meeting. We need a DEVEL ACK (Aron/Prarit or your management). Patch available. Changing bug to ASSIGNED. devel ACK Created attachment 142784 [details] kernel-2.6.18-1.2747.el5-xen-ia64-maxmem.patch Here are the two changesets ported to kernel-2.6.18-1.2747.el5 (This was the beta2rc release) This patch presently depends on the xen/ia64 patch in bug 210637 to apply without conflicts. in 2.6.18-1.2839.el5 A package has been built which should help the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. |