On Fri, Jan 4, 2013 at 1:34 PM, Yinghai Lu <ying...@kernel.org> wrote: > On Fri, Jan 4, 2013 at 9:50 AM, Shuah Khan <shuahk...@gmail.com> wrote: >> >> This change doesn't take into account what swiolb was when >> pci_swiotlb_detect_override() is called. Instead of returning >> use_swiotlb like the original code did, it returns swiotlb which could >> be zero, if !enough_mem_for_swiotlb(). >> >> Might work fine on Intel platforms, but not on systems where the IOMMU >> driver wants to enable swiotlb for some devices as in the case of AMD. >> >> AMD IOMMU driver enables swiotlb for devices that are not specified in >> IVRs and/or not in the AMD IOMMU scope, after it successfully >> initializes IOMMU. It will explicitely set switolb=1 to make sure >> reserved swiotlb memory is not released. This change will break that >> case. > > in that case, we have to panic.... > > please check attached patch. > > Also for those kind of systems, users must specify crashkernel_low=72M or > what ever for kdump.
Pani'cing the system doesn't sound like a good option to me in this case. This change to disable swiotlb is made for kdump. However, with this change several system fail to boot, unless crashkernel_low=72M is specified. I would the say the right approach to solve this would be to not change the current pci_swiotlb_detect_override() behavior and treat swiotlb =1 upon entry equivalent to swiotlb_force set. Thanks, -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
