[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". Thanks, -- Dexuan Attachment:
crash.log _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |