On Mon, 22 Nov 2021 00:42:42 -0800
Samuel Sieb <samuel@xxxxxxxx> wrote:
> On 11/21/21 13:38, stan via test wrote:
> > Compiled the server, xinit, and xauth packages locally, made no
> > difference. I think that lets glibc off the hook. The line that is
> > different from when an X start succeeds is:
> > xf86EnableIOPorts: failed to set IOPL for I/O (Operation not
> > permitted) Don't know where that is coming from, will have to track
> > it down.
>
> xinit isn't likely to be the problem since it's just a script.
> You're seeing an error from X itself. It's a little hard to figure
> out the X log since the copy and paste is rather messed up. It looks
> like the last line from the X server is "(II) [KMS] Kernel
> modesetting enabled". Maybe related to the kernel DRM changes.
> Have you tried booting an older kernel?
> What driver is your X server trying to use?
> Have you checked the journal for error messages?
Yeah, after it fails, the virtual console it is run from doesn't work
properly. It doesn't show output, and it doesn't do line feeds.
I said in another message that the problem was not glibc, but further
research seems to indicate it at least starts in glibc.
The key line is
xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
This is from xserver program xfree86. In that program it tries to set
permissions for X I/O using the iopl call from glibc.
<code>
static Bool
hwEnableIO(void)
{
if (ioperm(0, 1024, 1) || iopl(3)) {
ErrorF("xf86EnableIOPorts: failed to set IOPL for I/O (%s)\n",
strerror(errno));
return FALSE;
}
#if !defined(__alpha__)
/* XXX: this is actually not trapping anything because of iopl(3)
* above */
ioperm(0x40, 4, 0); /* trap access to the timer chip */
ioperm(0x60, 4, 0); /* trap access to the keyboard
controller */ #endif
return TRUE;
}
</code>
The iopl call is from <sys/io.h> in glibc. So is the ioperm call.
Since glibc was updated just before the problem, it is a good place to
start. It might be that something else has disallowed permissions for
this call. The man page says it is
iopl() changes the I/O privilege level of the calling process, as
specified by the two least significant bits in level.
This call is necessary to allow 8514-compatible X servers to run
under Linux. Since these X servers require access to all 65536
I/O ports, the ioperm(2) call is not sufficient.
I will open a bugzilla against glibc, if there isn't already one opened.
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
