WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing

>>> "Cui, Dexuan" <dexuan.cui@xxxxxxxxx> 24.03.10 02:52 >>>
>Pasi K?rkk?inen wrote:
>> Hmm.. wondering if the patch Jan just sent will help with that.
>> Sounds like it might help :)
>I guess Jan's patch helps here in a very interesting way:

I think reference was to a patch I sent yesterday, which I don't think
would help here (as the box would have to crash for it to help).

>I suspect your BIOS doesn't construct the DMAR properly, e.g., in 
>acpi_parse_dmar(),  entry_header->length is always 0, so xen'll hang in the 
>while loop and continue printing the "dmaru->address = 0" message when 
>iommu=verbose.

Surely entry_header->length == 0 (or really
entry_header->length < sizeof(struct acpi_table_XXX)) should be
considered invalid, and hence get checked for? Linux at least has
a check against zero here...

>Without verbose message outputing, the loop runs even faster and in 
>acpi_parse_one_drhd(),  xmalloc(struct acpi_drhd_unit) would NULL in a short 
>periof of time and hence VT-d is got disabled... :-)

Why would you expect xmalloc() to fail soon? This is only to be expected
on a 32-bit system (which I doubt this one is).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>