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

RE: [Xen-devel] RE: [Xen-changelog] [xen-unstable]vt-d: Fixpanic in msi_msg_read_remap_rte with acpi=off

Keir Fraser wrote:
> On 19/10/2009 12:51, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:
>>> Got a backtrace and Xen boot params? If you pass acpi=off, then
>>> disable_acpi() is invoked, and this sets acpi_disabled. If
>>> acpi_disabled=1, then iommu_setup() sets iommu_enabled=0. If
>>> iommu_enabled=0 then I think all the update_ire_from_* and similar
>>> hooks get disabled in the callers. So something unexpected must be
>>> happening. 
>> Hmmm, perhaps this could be an early boot-time crash before
>> iommu_setup() is even called? Perhaps moving the if(acpi_disabled)
>> iommu_enabled=0 somewhere early-ish in setup.c:__start_xen(), with a
>> warning message, would be the right thing to do in that case (e.g.,
>> immediately after the call to cmdline_parse()).
> After some more hmmm'ing I have to admit your original patch was
> actually the best way to go. :-)
> All other callers of acpi_find_matched_drhd_unit() that you didn't
> patch already check for NULL return, so it's presumably expected as a
> possibility. And it is okay for msi_msg_{read,write}_remap_rte() to
> bail silently if they cannot determine there's any work to do, since
> they operate as potential modifiers to operations which are primarily
> implemented in their callers. 
> So sorry about that. I'll revert Dexuan's patch.
>  -- Keir

But, can't you reproduce the crash I mentioned before?
Please see the attached crash log -- I'm using c/s 20341:ea34183c5c11 and with 
"iommu=1 acpi=off" and I use a DQ35 host.

Actually what I care is the " if ( acpi_disabled ) iommu_enabled = 0".

-- Dexuan

Attachment: crash.log
Description: crash.log

Xen-devel mailing list



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