Bug 214161 - The Xen is in panic when specifying "maxmem =" in domVTI-config.
The Xen is in panic when specifying "maxmem =" in domVTI-config.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
5.0
ia64 Linux
high Severity high
: ---
: ---
Assigned To: Aron Griffis
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-06 06:17 EST by Akio Takebe
Modified: 2010-10-22 02:50 EDT (History)
4 users (show)

See Also:
Fixed In Version: beta2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-22 21:04:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
fix this maxmem isshue by changing from max_pages to tot_pages. (1.01 KB, patch)
2006-11-06 06:30 EST, Akio Takebe
no flags Details | Diff
kernel-2.6.18-1.2747.el5-xen-ia64-maxmem.patch (2.06 KB, patch)
2006-12-04 17:51 EST, Aron Griffis
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
XenSource 800 None None None Never

  None (edit)
Description Akio Takebe 2006-11-06 06:17:44 EST
+++ 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@jp.fujitsu.com on 2006-11-06 05:23 EST -
-
I fix this issue.
http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=1eb880e9ff94
Comment 1 Akio Takebe 2006-11-06 06:30:23 EST
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.
Comment 2 Chris Lalancette 2006-11-08 11:22:29 EST
(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
Comment 3 Chris Lalancette 2006-11-08 11:23:28 EST
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
Comment 4 Chris Lalancette 2006-11-08 11:24:34 EST
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
Comment 6 Akio Takebe 2006-11-14 22:56:41 EST
I submitted a patch. Please see the below.
http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=c10d4c6df482

Best Regards,

Akio Takebe
Comment 7 RHEL Product and Program Management 2006-11-20 10:00:37 EST
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.
Comment 8 Larry Troan 2006-11-20 14:15:15 EST
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.
Comment 9 Jay Turner 2006-11-20 15:42:20 EST
QE ack for RHEL5.
Comment 10 Larry Troan 2006-11-28 09:48:25 EST
Ping devel.......... Please ACK and put bug in ASSIGNED state.
Comment 11 Larry Troan 2006-12-03 17:51:12 EST
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.
Comment 12 Aron Griffis 2006-12-04 17:31:19 EST
devel ACK
Comment 13 Aron Griffis 2006-12-04 17:51:22 EST
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.
Comment 15 Don Zickus 2006-12-06 18:04:38 EST
in 2.6.18-1.2839.el5
Comment 16 RHEL Product and Program Management 2006-12-22 21:04:53 EST
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.

Note You need to log in before you can comment on or make changes to this bug.