From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: RE: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing Date: Wed, 24 Mar 2010 08:24:16 +0000 Message-ID: <4BA9DA400200007800036ABB@vpn.id2.novell.com> References: <20100323193748.GW1878@reaktio.net> <20100323200515.GZ1878@reaktio.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: pasik@iki.fi, Dexuan Cui Cc: "xen-devel@lists.xensource.com" , Weidong Han , Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> "Cui, Dexuan" 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 =3D 0" message = when iommu=3Dverbose. Surely entry_header->length =3D=3D 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