From: Weidong Han <weidong.han@intel.com>
To: "Nadolski, Ed" <Ed.Nadolski@lsi.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Keir Fraser <keir.fraser@eu.citrix.com>,
Jan Beulich <JBeulich@novell.com>,
"Cui, Dexuan" <dexuan.cui@intel.com>
Subject: Re: Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing
Date: Wed, 07 Apr 2010 09:43:39 +0800 [thread overview]
Message-ID: <4BBBE34B.8090007@intel.com> (raw)
In-Reply-To: <8115AF16522A3D4383C1FF753036713F9B49CCBE@cosmail01.lsi.com>
Nadolski, Ed wrote:
>>> I'm also seeing a hang on boot with 4.0.0-rc7, but I am not clear if
>>>
>> this is the same issue. Here is the tail end of the trace:
>>
>>> [ 4.802862] NetLabel: unlabeled traffic allowed by default
>>> [ 4.808653] DMAR:Host address width 40
>>> [ 4.812310] DMAR:DRHD base: 0x000000dfffe000 flags: 0x0
>>> [ 4.817604] IOMMU dfffe000: ver 1:0 cap c90780106f0462 ecap f020fe
>>> [ 4.823816] DMAR:DRHD base: 0x000000fedc0000 flags: 0x1
>>> [ 4.829105] IOMMU fedc0000: ver 1:0 cap c90780106f0462 ecap f020f6
>>> [ 4.835325] DMAR:RMRR base: 0x000000dbe58000 end: 0x000000dbe6ffff
>>> [ 4.841556] DMAR:ATSR flags: 0x0
>>> [ 4.844844] DMAR:ATSR flags: 0x0
>>> [ 4.848133] Not all IO-APIC's listed under remapping hardware
>>> [ 4.854028] IOMMU 0xdfffe000: using Queued invalidation
>>> [ 4.859217] IOMMU 0xfedc0000: using Queued invalidation
>>> [ 4.864493] IOMMU: Setting RMRR:
>>> [ 4.867778] IOMMU: Setting identity map for device 0000:00:1d.0
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.876053] IOMMU: Setting identity map for device 0000:00:1d.1
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.884264] IOMMU: Setting identity map for device 0000:00:1d.2
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.892485] IOMMU: Setting identity map for device 0000:00:1d.7
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.900709] IOMMU: Setting identity map for device 0000:00:1a.0
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.908928] IOMMU: Setting identity map for device 0000:00:1a.1
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.917150] IOMMU: Setting identity map for device 0000:00:1a.2
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.925390] IOMMU: Setting identity map for device 0000:00:1a.7
>>>
>> [0xdbe58000 - 0xdbe70000]
>>
>>> [ 4.933612] IOMMU: Prepare 0-16MiB unity mapping for LPC
>>> [ 4.938938] IOMMU: Setting identity map for device 0000:00:1f.0
>>>
>> [0x0 - 0x1000000]
>>
>>> [ 4.946651] VT-d detected invalid descriptor: low=11, high=0
>>>
>>> Then it hangs. This is on a Dell T7500 quad-core Xeon with the latest
>>>
>> Dell BIOS (rev. A03). Should I try the suggested patch, or any
>> particular command line or build options? Should I dump the DMAR
>> tables?
>>
>> Your issue is different. It's caused by enabling VT-d in pv-ops dom0.
>> but pv-ops dom0 should not see DMAR table because its signature is
>> zapped after xen enables it. Pls have a try with turn off VT-d in
>> pvops config (# CONFIG_DMAR is not set) , it should solve your issue. But we
>> need to find why pv-ops dom0 still sees DMAR table in ACPI. Pls dump
>> DMAR tables.
>>
>
> Changing CONFIG_DMAR as you say fixes the hang. I've also attached the DMAR table dump as you requested, does this look OK?
>
> Thanks again,
> Ed
>
>
When use "iasl" to disassemble attached file, it prompted:
Loading Acpi table from file DellT7500_BIOS_A03-dmar.bin
Table signature [DMAR] is invalid or not supported
Could not get table from the file
Did you dump it on dom0 (not native Linux)? if so, that means DMAR
signature is already zapped, dom0 should not detect it and won't go to
enable it.
Regards,
Weidong
>
>
>
>
>
next prev parent reply other threads:[~2010-04-07 1:43 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-23 14:27 Xen 4.0.0-rc7 problem/hang with vt-d DMAR parsing Pasi Kärkkäinen
2010-03-23 14:40 ` Jan Beulich
2010-03-23 14:40 ` Pasi Kärkkäinen
2010-03-23 14:48 ` Keir Fraser
2010-03-23 19:37 ` Pasi Kärkkäinen
2010-03-23 19:54 ` Keir Fraser
2010-03-23 20:05 ` Pasi Kärkkäinen
2010-03-24 0:40 ` Weidong Han
2010-03-24 1:52 ` Cui, Dexuan
2010-03-24 8:24 ` Jan Beulich
2010-03-24 8:54 ` Cui, Dexuan
2010-03-24 9:02 ` Weidong Han
2010-03-24 9:10 ` Pasi Kärkkäinen
2010-03-24 9:46 ` Jan Beulich
2010-03-24 11:00 ` Weidong Han
2010-03-24 11:11 ` Jan Beulich
2010-03-25 0:55 ` Weidong Han
2010-03-25 8:43 ` Jan Beulich
2010-03-25 9:05 ` Weidong Han
2010-03-25 9:16 ` Jan Beulich
2010-03-25 9:21 ` Weidong Han
2010-03-25 9:30 ` Jan Beulich
2010-03-25 9:34 ` Pasi Kärkkäinen
2010-03-25 9:44 ` Keir Fraser
2010-03-26 19:20 ` Pasi Kärkkäinen
2010-03-29 6:42 ` Cui, Dexuan
2010-03-24 17:34 ` Nadolski, Ed
2010-03-25 0:04 ` Weidong Han
2010-04-05 18:00 ` Nadolski, Ed
2010-04-07 1:43 ` Weidong Han [this message]
2010-03-24 8:50 ` Pasi Kärkkäinen
2010-03-26 19:45 ` Pasi Kärkkäinen
2010-03-29 6:48 ` Cui, Dexuan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BBBE34B.8090007@intel.com \
--to=weidong.han@intel.com \
--cc=Ed.Nadolski@lsi.com \
--cc=JBeulich@novell.com \
--cc=dexuan.cui@intel.com \
--cc=keir.fraser@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).