[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] x86/AMD: Nested hvm crashes in 4.3

>>> On 27.06.13 at 12:24, Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx> 
>>> wrote:
> On 6/27/2013 5:08 AM, Jan Beulich wrote:
>>>>> On 27.06.13 at 11:20, Suravee Suthikulpanit 
>>>>> <suravee.suthikulpanit@xxxxxxx> wrote:
>>> On 6/27/2013 3:22 AM, Jan Beulich wrote:
>>>> We had issues exposed by this patch before, but any such issue
>>>> would just have been masked before that patch (and would
>>>> surface on a system with more than 5Tb of memory anyway).
>>> The system I am having the issue has 48GB of memory.
>> Which is why you're seeing the problem only with the debugging
>> code enabled.
> Is the "debugging" enabled by default?  I didn't specify any debug when 
> building.
> How can I check and disable debugging?


debug := n

close to the top of ./Config.mk.

>> (And of course I didn't really expect you to have
>> tried this on a huge memory system - they're just too rare still
>> for this to be likely.)
>>>> So it is very unlikely for the patch itself to be at fault.
>>> I have traced the issue and found that the system crashing starts from this
>>> commit id and onward.
>>> (i.e. The system does not crash with commit id
>>> ed759d20249197cf87b338ff0ed328052ca3b8e7)
>>> So, I am still believe that this patch has somehow triggered the issue.
>> As said - I'm pretty certain this merely unmasked an already
>> lurking issue.
> I'm not quite sure what you meant here.  Are you saying that this 
> "crashing" is a known issue?

No, I'm unaware of any issue similar to what you describe.

>>   And that's what the purpose of that patch is.
> This patch is crashing the system. What do you mean by "And that's what 
> the purpose of that patch is"?

The finding of bugs that otherwise would surface only once
indeed running on a huge memory system. If on such a system
this would result in crashing the host, so be it with this
debugging code even on "normal" systems (as long as not
running in production mode). The alternative would be to keep
the bug masked until someone really tried to run Xen on such
a huge system, and the debugging of this then would be quite
a bit more expensive (if nothing else then in the amount of
electrical power needed).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.