On 11/13/2013 03:09 PM, Paul B. Henson wrote: >> From: Richard Yao [mailto:[email protected]] >> Sent: Wednesday, November 13, 2013 1:57 AM >> >> Gentoo does not actually provide users with a prebuilt kernel. Instead, >> we provide them with source code and asks them to compile it by hand. > > I'm actually a long time Gentoo user :), I meant the configuration file > kernel config, not the actual binary, ie, that a 'make defconfig' would > result in that option enabled in gentoo-sources as opposed to not enabled in > vanilla-sources.
gentoo-sources would have been untouched. What I was considering was just genkernel. >> However, I think I will consult the Gentoo kernel team about the wisdom >> of this before touching it in genkernel. The Gentoo kernel and genkernel >> teams are separate. > > I'd be curious as to what they say, it just seems you'd think upstream had a > reason for not enabling it by default :). > >> Do you know of any examples of devices that deviate >> from the specification in such a way that they have compatibility >> problems? A single example could present me with the opportunity to >> understand how a PCIe device itself can be incompatible with an IOMMU. > > I don't know that it's so much about particular devices, so much as buggy > BIOS DMAR implementations. We have an IBM x3550 box running Gentoo, and I/O > to the disks attached to be on board LSI SAS controller would occasionally > freeze requiring a hard reboot; the problem went away when we disabled Vt-D > in the BIOS. Although, we had not enabled the Intel IOMMU in the kernel, I'm > not sure if enabling that as opposed to disabling it in the BIOS would've > made a difference, I might need to go back and try that someday. I recently had issues with a Nvidia GPU on my new workstation build. It has a Supermicro X9SRA. Instead of turning off VT-d, I instead turned off "Over 4G Decoding", such that these devices were no longer being mapped into the 64-bit address space. My problems immediately disappeared. It could be that enabling VT-d in your BIOS enables memory mapped IO above 4G or that turning it off had the side effect of moving this particular device into the 4G region. There is also a possibility that turning on VT-d support in the kernel could have made your problem go away (particularly if the problem was caused by overlapping memory regions). Anyway, it is not clear to me from this example that keeping VT-d support off in the kernel is beneficial. >> I suspect that CONFIG_INTEL_IOMMU_DEFAULT_ON is the exception, rather >> than the rule. Other IOMMU providers (specifically AMD) do not appear to >> have a *_DEFAULT_ON option, which suggests to me that the default is to >> toggle them on when support is available. > > Which again makes me wonder why they are treating it differently and > somewhat leery about just turning it on without understanding the potential > repercussions ;). I was not aware of any repercussions until you brought the possibility of them to my attention. Now I am thinking about them.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
