On Wed, 2010-03-17 at 23:26 +0100, Samuel Thibault wrote: > Adam Jackson, le Wed 17 Mar 2010 17:44:34 -0400, a écrit : > > On Sat, 2010-03-13 at 02:26 +0100, Samuel Thibault wrote: > > > - ioperm(0x40,4,0); /* trap access to the timer chip */ > > > - ioperm(0x60,4,0); /* trap access to the keyboard controller */ > > > > I'm not sold on this. You really do not want to be bashing these ports > > directly if the kernel also is. > > Sure. The issue is that some VESA BIOS do need it. > > > If this _is_ right, then it almost certainly needs to be done for all > > platforms. > > Well, actually only Linux and Hurd used to do it. Since Linux also > set iopl to 3 to be able to access to ports >= 0x400, the I/O bitmask > set by ioperm() is just completely ignored, and the same two lines in > the Linux code don't have any effect.
Ah, I get it. x86emu is dutifully emulating the I/O port cycle, but since the kernel removed your permission to touch those ports, you SIGILL. If you were using vm86 the same thing would happen; you'd trap to the server to handle the I/O cycle, which would then proxy it on, which would then SIGILL. Well in that case, the ioperm() is definitely bogus on all platforms, since all it can do is make us crash. But it indicates that the int10 wrapper needs to do a better job of emulating those ports, since the kernel is definitely going to be using them. Of course, Hurd doesn't have a kernel interface for PCI config space, so you're already racing with the kernel all over the place. (Gedankenexperiment: Kernel and X attempt a config space cycle at the same time. Kernel writes to 0xCF8. X writes to 0xCF8. Kernel reads or writes to 0xCFC. What garbage does the kernel get now?) So this is clearly a race you can win most of the time, but still. > > Do you have a link to a bug that this is solving? > > http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00037.html A copy of the VBIOS would be useful here: # dd if=/dev/mem of=/tmp/vbios bs=64k skip=12 count=1 - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
