On Thu, 2014-03-20 at 10:45 +0100, Daniel Vetter wrote: > I'd agree that this would be nice, but my maintainer time is not > endless and when I have users screaming "regression" I do have to do > something. And yeah with the track record set of some of the earliest > vtd+gfx chips I'm fairly aggressive with just disabling features,
It's not just the earlier vtd+gfx chips. To my knowledge we've *never* shipped a chip without egregious hardware bugs with VT-d. > especially when the original bug report is against a recent platform > like ivb (so presumably issues on olders exist, too). Yes, by all means disable it for current and old chipsets. But please not newer ones. I want it to show up when the validation folks use Linux to test the hardware. And if we *do* have to subsequently bump the check to include the next revision of the hardware, I want someone's head on a plate. As I commented in private, this is the first time we've used intel_iommu_gfx_mapped to disable a feature without a check for specific hardware revisions. Please don't do that. > Now this very likely is some fumble in our code, after all the bios > managed to set things up. Maybe not; sometimes it's just that Linux does a little bit more with the hardware and happens to tickle the bug. The superpage screwup I've recently been chasing, for example, is blatantly a hardware issue but didn't show up with the BIOS framebuffer. And *does* with the Linux framebuffer in stolen memory. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
