I have an additional PCI graphics card in my PC (Fedora 7), connected to small LCD touch screen. I am trying to drive it using independent X server (vesa driver), with "-novtswitch -sharevts" options. Invocation line: /usr/bin/Xorg :1 -config xorg.conf.flat -auth /opt/mollp/status.xauth -novtswitch -sharevts It generally works fine, with one exception - it load CPU for 100%!!! Quick investigation revealed the problem: $ strace -p <pid> (...) select(256, [1 3 5 9 10 11], NULL, NULL, {2, 188000}) = 1 (in [3], left {2, 188000}) rt_sigprocmask(SIG_BLOCK, [IO], [], 8) = 0 read(3, "", 64) = 0 rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0 gettimeofday({1194025555, 827261}, NULL) = 0 gettimeofday({1194025555, 827320}, NULL) = 0 select(256, [1 3 5 9 10 11], NULL, NULL, {2, 187000}) = 1 (in [3], left {2, 187000}) rt_sigprocmask(SIG_BLOCK, [IO], [], 8) = 0 read(3, "", 64) = 0 rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0 gettimeofday({1194025555, 827750}, NULL) = 0 gettimeofday({1194025555, 827809}, NULL) = 0 select(256, [1 3 5 9 10 11], NULL, NULL, {2, 187000}) = 1 (in [3], left {2, 187000}) rt_sigprocmask(SIG_BLOCK, [IO], [], 8) = 0 read(3, "", 64) = 0 rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0 gettimeofday({1194025555, 828203}, NULL) = 0 gettimeofday({1194025555, 828264}, NULL) = 0 select(256, [1 3 5 9 10 11], NULL, NULL, {2, 186000}) = 1 (in [3], left {2, 186000}) rt_sigprocmask(SIG_BLOCK, [IO], [], 8) = 0 read(3, "", 64) = 0 rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0 gettimeofday({1194025555, 828642}, NULL) = 0 gettimeofday({1194025555, 828701}, NULL) = 0 select(256, [1 3 5 9 10 11], NULL, NULL, {2, 186000}) = 1 (in [3], left {2, 186000}) (...) This is some kind of "while (1);" loop. Opened descriptors: $ ls -l /proc/<pid>/fd total 0 l-wx------ 1 root root 64 2007-11-02 17:46 0 -> /var/log/Xorg.1.log lrwx------ 1 root root 64 2007-11-02 17:46 1 -> socket:[11991] lrwx------ 1 root root 64 2007-11-02 17:46 10 -> socket:[12148] lrwx------ 1 root root 64 2007-11-02 17:46 11 -> socket:[12184] lrwx------ 1 root root 64 2007-11-02 17:46 2 -> /dev/pts/0 lrwx------ 1 root root 64 2007-11-02 17:46 3 -> /proc/bus/pci/05/0e.0 l-wx------ 1 root root 64 2007-11-02 17:46 4 -> /proc/mtrr lrwx------ 1 root root 64 2007-11-02 17:46 5 -> socket:[12079] lr-x------ 1 root root 64 2007-11-02 17:46 6 -> /etc/touchscreen.cal lrwx------ 1 root root 64 2007-11-02 17:46 7 -> /dev/hiddev0 lrwx------ 1 root root 64 2007-11-02 17:46 8 -> /dev/ttyS0 lrwx------ 1 root root 64 2007-11-02 17:46 9 -> socket:[12143] When launched without "-sharevts" X server behave properly, doing the same thing (select(...) read(3, ...)), but this time descriptor 3 is a virtual terminal... I have tested this using "glint" driver as well (this card is some 3D Labs product) and situation is exactly the same, so either there is the same bug in both drivers or it is core problem... I will attach configuration file.
Created attachment 12318 [details] Configuration file
"but this time descriptor 3 is a virtual terminal..." "... and select(...) blocks".
I have checked the case again, and when X server is launch without "sharevts", its idle loop looks like this: $ sudo strace -p 3443 Process 3443 attached - interrupt to quit select(256, [1 3 6 10 11 12 13], NULL, NULL, {0, 150000}) = 0 (Timeout) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 gettimeofday({1194266716, 332062}, NULL) = 0 gettimeofday({1194266716, 332120}, NULL) = 0 select(256, [1 3 6 10 11 12 13], NULL, NULL, {2, 420000}) = ? ERESTARTNOHAND (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 sigreturn() = ? (mask now []) gettimeofday({1194266716, 352426}, NULL) = 0 gettimeofday({1194266716, 352481}, NULL) = 0 select(256, [1 3 6 10 11 12 13], NULL, NULL, {2, 400000}) = 0 (Timeout) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 gettimeofday({1194266718, 752045}, NULL) = 0 File descriptors: $ ls -l total 0 l-wx------ 1 root root 64 2007-11-05 12:44 0 -> /var/log/Xorg.1.log lrwx------ 1 root root 64 2007-11-05 12:44 1 -> socket:[11502] lrwx------ 1 root root 64 2007-11-05 12:44 10 -> socket:[11641] lrwx------ 1 root root 64 2007-11-05 12:44 11 -> socket:[11646] lrwx------ 1 root root 64 2007-11-05 12:44 12 -> socket:[11679] lrwx------ 1 root root 64 2007-11-05 12:44 13 -> socket:[11685] lrwx------ 1 root root 64 2007-11-05 12:44 2 -> /dev/pts/0 lrwx------ 1 root root 64 2007-11-05 12:44 3 -> /dev/tty9 lrwx------ 1 root root 64 2007-11-05 12:44 4 -> /proc/bus/pci/05/0e.0 l-wx------ 1 root root 64 2007-11-05 12:44 5 -> /proc/mtrr lrwx------ 1 root root 64 2007-11-05 12:44 6 -> socket:[11630] lr-x------ 1 root root 64 2007-11-05 12:44 7 -> /etc/touchscreen.cal lrwx------ 1 root root 64 2007-11-05 12:44 8 -> /dev/hiddev0 lrwx------ 1 root root 64 2007-11-05 12:44 9 -> /dev/ttyS0 So again all descriptors but 3 the select is called on are sockets... But in that case 3 is /dev/tty9, not /proc/bus/pci/05/0e.0... As for me it looks like the descriptor 3 is hardcoded somewhere. (!?!?) And when virtual terminal is not being opened the PCI proc file is opened as no 3...
Well... I just made an experiment. Using GDB I have modified AllSymbols variable... It was 0xc0a (which was [1 3 5 9 10 11 12] fd set). I have removed fd 3 from the set (0xc02) and voila! $ sudo strace -p 3592 Process 3592 attached - interrupt to quit select(256, [1 5 9 10 11 12], NULL, NULL, {3, 840000}) = 0 (Timeout) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 gettimeofday({1194344788, 85107}, NULL) = 0 stat64("/etc/touchscreen.cal", {st_mode=S_IFREG|0644, st_size=222, ...}) = 0 gettimeofday({1194344788, 85388}, NULL) = 0 gettimeofday({1194344788, 85472}, NULL) = 0 select(256, [1 5 9 10 11 12], NULL, NULL, {5, 0}) = ? ERESTARTNOHAND (To be restarted) Everything seems to works fine now and CPU is not loaded at all ;-)
I have just found a source of the problem. It is the keyboard device (kbd). I left its configuration default: Section "InputDevice" Identifier "Keyboard1" Driver "kbd" EndSection During initialization VT device is opened for a while. Probably the file descriptor is remembered somewhere, as by default keyboard driver is connected ... Of course when VT is shared this device is closed. Then, InitAndStartDevices() calls EnableDevice() on keyboard driver which uses the previously recorded fd. Unfortunately the PCI proc file is opened in the meantime... The rest you already know ;-) As a workaround I configured the driver to use some fake device, eg.: Section "InputDevice" Identifier "Keyboard1" Driver "kbd" Option "Device" "/dev/tty38" EndSection Symptoms disappeared then, but of course the source of problem stays.
"as by default keyboard driver is connected to current VT..."
A short update: the problem was already reported on Ubuntu - https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/33611 There is even a patch that is claimed to fix the problem - http://launchpadlibrarian.net/1633429/999_lepton_sharevts_bug.diff
fix pushed, thanks. note that the kbd driver is worse than useless with sharevts, though!
(marking as fixed)
*** Bug 16172 has been marked as a duplicate of this bug. ***
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.