Tweet
Originally posted by c117152
View Post
-
Because in case of Windows Intel cares enough to implement workaround for this hardware issue. Actually they implemented workaround for Android too. -
Did they really? It seems to regress on android-x86 and really any linux disro with every other release so I assumed it's a few odd patches that sorta half work half don't by some non-Intel devs maintaining their own hardware and such.Originally posted by RussianNeuroMancer View Post
Anyhow, I'm currently reading through the Alpine docs regarding KVM and IGD pass-through. Looks easy enough. But I have no reason to think it will work...Comment
-
Yes, they really did it, but only for Android that preinstalled by vendors, and for Android-IA (not for Android x86 or upstream Linux).Originally posted by c117152 View Post
Comment
-
I'm aware of those and I still say it doesn't counts as a hardware bug if changing a few figures in the kernel drivers solves the issue without impacting performance. But I admit it's mostly semantics by now. In practice, it's a poorly documented unofficial errata they can't, or won't be bothered releasing.Originally posted by RussianNeuroMancer View Post
Btw, I tried alpine but while the usb boots and installs fine to mmcblk the system fails to boot. I'm guessing the kernel wasn't compiled with eMMC modules and only boots from the USB thanks to the modloop dumping everything in the RAM before initrd actually gets a chance to fail. [Edit: Seems to be missing CONFIG_PINCTRL_BAYTRAIL... Really strange it even booted to the USB]. Regardless, I'm too lazy to check it out so I'll just leave it for someone who cares specifically about getting alpine working on their baytrail. I guess it's back to debian\arch and trying to blacklist i965 to see if I can get away without limiting the cstate max? Followed by testing IGD pass-through to KVM... Meh. Maybe later
Last edited by c117152; 28 October 2017, 02:21 PM.Comment
Comment