Next time, please test with the -133 kernel on the same host before adding the regression keyword. Can you do this test now? I don't think Xen was ever tested with such huge hosts, it's very likely that this is a different bug.
(In reply to comment #6) > Next time, please test with the -133 kernel on the same host before adding the > regression keyword. Can you do this test now? > > I don't think Xen was ever tested with such huge hosts, it's very likely that > this is a different bug. Indeed. Has anyone every tried what I suggested in bug 524624 comment 42? Which is to specify mem=512G on the xen.gz command line? The HV can only use up to 512G of memory, so there's a chance it just gets confused if there's more.
tried with mem=256G on xen.gz command line, and turn off ballooning, guest still crash (host: 2.6.18-238.el5xen 64bit, guest: 2.6.18-194.el5xen 32bit). tried to boot up -133 kernel on the host, host crash during boot. I'll try to find other machines to have a check with above issues.
Using a machine that really has only 256G of memory, and not just trying to use mem=256G on a 1T machine works for my rhel5.6-beta (2.6.18-229.el5xen) guest. I don't believe we have a regression here. We're just attempting to test on hardware that hasn't been attempted before.
My comment 9 was for 64-bit guests. Sorry, I missed that this bug was also for 32-bit guests. Since the host has >=168G then this is really a dup of bug 616827. We don't need to go all the way back to fixing the >=64G issue. As bug 616827 is still ON_QA, I'll dup this over there to clean things up a bit. I have found that I can no longer install rhel5 32-bit guests on the same 256G machine that I previously verified that other bug on, so I'm looking into the issue. See further comments in that bug. *** This bug has been marked as a duplicate of bug 616827 ***