On Fri, 4 Feb 2005, Ian Pratt wrote:
If it occurred just under the 'vesa' X server I'd be very suspicious
that we had an FP save/restore bug in the vm86 support code. I'm not
sure whether the savage server uses vm86 or not. Probably not.
It doesn't, according to strace.
On the assumption that this _is_ an FP save/restore bug, I was trying to
find the FP save/restore code in the xen-patched kernel. I'm not familiar
with low-level kernel issues like this. What I am trying to find is, where
does fxrstor (or whatever) get invoked from, when the kernel is doing a
normal user-process-to-user-process context switch? As far as I can tell,
the idea seems to be that you don't bother to restore the FPU state
immediately - if and when the new process tries to access the FPU for the
first time, the CPU automatically generates a trap, and only then does
Linux restore the saved FPU state for that process - apparently in
arch/xen/i386/kernel/entry.S under ENTRY(device_no_available), if my guess
is right.
Is that correct?
If that's the case, then, again still working on the assumption that it's
an FPU state bug, looks like it could only be one of the following:
1. Something leaves the FPU in a state where it has bogus data in it,
but it won't trap to tell the kernel to restore the old, correct data
2. Something forgets to save the FPU state when context-switching from
one userland process to another
3. Something is overwriting the saved fpu state with bogus data (seems
unlikely)
4. Something in the kernel or in xen is using the FPU (extremely
unlikely, since both appear to now be compiled with soft-math).
Is my reasoning sound? I'm a _little_ out of my depth here!
--
Robin
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home