Jan Beulich
2013-Jun-27 06:55 UTC
your IRC thread regarding a crash in __sanitize_i387_state()
Considering that you see XSAVE disabled in CPUID, is it possible that this is being enforced via CPUID masking or some such? If so, is the CPU supporting XSAVEOPT by chance? That CPUID flag would then also need to be masked, or else the kernel would get misled calling __sanitize_i387_state() from sanitize_i387_state() despite there not being anything to sanitize (which matches the fault address in the pointed to stack dump being 512 bytes ahead of %rbx). Jan
Matt Wilson
2013-Jun-27 07:00 UTC
Re: your IRC thread regarding a crash in __sanitize_i387_state()
On Thu, Jun 27, 2013 at 07:55:57AM +0100, Jan Beulich wrote:> Considering that you see XSAVE disabled in CPUID, is it possible that > this is being enforced via CPUID masking or some such?Yup, I''m pretty sure this was a config problem with masking.> If so, is the CPU supporting XSAVEOPT by chance? That CPUID flag > would then also need to be masked, or else the kernel would get > misled calling __sanitize_i387_state() from sanitize_i387_state() > despite there not being anything to sanitize (which matches the > fault address in the pointed to stack dump being 512 bytes ahead > of %rbx).xsaveopt was listed in /proc/cpuinfo. I didn''t check the results of the cpuid instruction, but I''m guessing that it wasn''t appropriately masked. This makes sense. Thanks for following up! --msw