+++ This bug was initially created as a clone of Bug #212500 +++ Description of problem: The Xen kept outputting a trace log when specifying "maxmem = " in domVTI- config. ( This problem did not happen when specifying same or less value of "memory = " for "memmax =".) In domU's case, the following message was displayed. # xm create -c domU-config Using config file "./domU-config Xend has probably crashed! Invalid or missing HTTP status I met same issue in the Xen-ia64-unstable. My domVTI's config is the below. --------------------------------------------------------------------------- kernel = "/boot/Flash.fd" builder = "hvm" memory = 256 maxmem = 1024 vcpus = 2 vif = [ 'type=ioemu, bridge=xenbr2' ] name = "vm1" disk = [ 'file:/xen/xen-test/image/rhel4_vti1.img,ioemu:hda,w' ] device_model = "/usr/lib/xen/bin/qemu-dm" memmap = "/usr/lib/xen/boot/mem-map.sxp" sdl = 0 vnc = 0 vncviewer = 0 nographic = 1 serial = "pty" --------------------------------------------------------------------------- Version-Release number of selected component (if applicable): xen-3.0.2-44 kernel-xen-2.6.18-1.2784.fc6 How reproducible: Always Steps to Reproduce: 1. create VTI-domain with maxmem = value (not same as memory =). 2. 3. Actual results: Xen is in panic. Expected results: domVTI normaly start without Xen panic. Additional info: -- Additional comment from takebe_akio.com on 2006-11-06 05:23 EST - - I fix this issue. http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=1eb880e9ff94
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.