On Wed, 2016-03-09 at 23:12 -0500, Bruce Ashfield wrote: > On 2016-03-09 4:23 PM, Richard Purdie wrote: > > On Wed, 2016-03-09 at 13:53 -0500, Bruce Ashfield wrote: > > > As another follow up. The thread can be summarized as "It doesn't > > > look like it should have worked before, and qemu's pat emulation > > > may be the issue'. > > > > > > The suggestion is to run with 'nopat', which is what Richard > > > originally > > > did. > > > > > > So I'm going to prep a patch that drops the kernel patch, and > > > leaves > > > nopat enabled on the qemu command line. That should get us put > > > back > > > together in a semi-permanent way. > > > > How sure are we this is a bug in QEMU's pat emulation? If that is > > the > > case we should file a bug against qemu and try and fix it rather > > than > > work around it... > > It could still be something that the kernel can work around, Toshi > did say: > > There is a matter of how qemu emulates CPU features. There is no > such > Intel CPU that supports PAT w/o MTRR. This is why the current code > assumes this dependency. > > Which is likely the trigger, we've send information about the cpu to > him, and with that there's a chance for a pat fix. > > He repeated our thought of running with 'nopat' while a fix is > considered. > > It may be some time before that happens, and I was going to test > with the kernel patch dropped, and nopat in the qemu boot args. If > that works, I'd rather run with that, and then revisit when (if) > there's more changes upstream.
Reading the other thread, it looks like if MTRR is disabled, PAT needs to be disabled too. That sounds like a simple enough patch which is going upstream imminently so I think the preferred solution is to get that into our kernels and then drop my patch? Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
