Ulrich Weigand wrote:
>
> [snip]
>
> > I' not familiar with 386 assembler, but some expert from this list might
> > have a clue. Does plex86 change an interrupt vector and not restore it properly?
>
> Well, int $0x80 is simply what Linux uses as system call; if this did not work,
> you'd crash *far* earlier ;-)
>
> The problem is the *particular* system call that X executes here: the vm86old
> call asks the kernel to switch the processor to VM86 (virtual 8086) mode and
> execute some code there. (Presumably X wants to call some real-mode code
> from the video card BIOS ...)
>
> Now why this should be broken after plex86 runs, I have no idea.
[snip]
Perhaps plex86 adjusts IOPL to below 3 but X windows likes it at 3 so
that it can run the video BIOS without worrying about emulating CLI/STI
etc.? Or perhaps plex86 or X windows are incompatible in another way:
could be that X windows is using VME or PVI, two formerly undocumented
modes that were introduced with the pentium (if they're used by x
windows, that would explain it).
Finally, it could be that the TSS that the linux kernel uses is being
messed with.
I assume Linux does LTR once and only once (it's more efficient that
way) just to be able to have an I/O map and to have an SS and ESP for
switches to higher privilige levels from lower ones (thus if you do mov
ESP,1 | PUSH EAX at CPL 3, instead of performing a hardware reset the
CPU knows where to reload SS and ESP when generating the stack fault).
IMHO, the most likely situation is IOPL, since X windows is (evidently)
using the (real) BIOS to set a VBE video mode. To elliminate the
possibility of the problem being VME/PVI, make sure DOSEMU stops working
when it tries to use the BIOS to set a video mode (or another program).
If that (or another program that doesn't use VME/PVI) fails, we know
that's not the problem.
