The device goes into a permanent input-ready state causing X's WaitForSomething to never actually wait. open("/dev/vga_arbiter", O_RDWR) = 10 read(10, "count:1,PCI:0000:00:02.0,decodes"..., 64) = 64 write(10, "target PCI:0000:00:02.0", 23) = 23 read(10, "count:1,PCI:0000:00:02.0,decodes"..., 64) = 64 ... select(256, [1 5 9 10 12 13 14 15 16 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52], NULL, NULL, {89, 869000}) = 1 (in [10], left {89, 868993}) clock_gettime(CLOCK_MONOTONIC, {17445, 90572053}) = 0 ioctl(10, TCFLSH, 0x2) = -1 EIO (Input/output error) <repeat ad infinitum> Even more annoying this is on a laptop with only a single igfx and no expansion capabilities... Hopefully this in fact an old bug and already fixed.
This is a tad out of my area of expertise, but it smells like this might be kernel related. When did you start seeing this issue? What kernel version doi you have? Doing a google search for TCFLSH EIO returns some possibly similar results: https://bugzilla.redhat.com/show_bug.cgi?id=475890 https://bugzilla.redhat.com/show_bug.cgi?id=529224 https://bugzilla.redhat.com/show_bug.cgi?id=619889 https://qa.mandriva.com/show_bug.cgi?id=63522 but those all look like an EIO of a TCFLSH of /dev/tty* 1) we should "deal" with the EIO elegantly in src/os/WaitFor.c 2) What can cause us to EIO /dev/vga_arbiter? Will that occur if some other process open(2)s it? Also, I'm a bit confused why we're select(2)ing the /dev/vga_arbiter descriptor in X's WaitForSomething. I don't see how that descriptor is exposed by libpciacces. I don't see "vgaarb_fd" in the server source, and I don't see a way in libpciaccess to add that descriptor to an fd_set. AFAICT, that descriptor is *owned* by libpciaccess, so the server should not have it in its read fd_set. Am I missing something here?
Let's take care of #1 (handle EIO properly) in xserver-1.12, but I'm still perplexed about why that descriptor is in our fd_set ...
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/248.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.