Bug 13063

Summary: 100% CPU load when X server launched with "-sharevts" option
Product: xorg Reporter: Pawel Moll <bugs>
Component: Protocol/CoreAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: elbeardmorez, freedesktop-bugzilla
Version: 7.2 (2007.02)   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 16399    
Attachments:
Description Flags
Configuration file none

Description Pawel Moll 2007-11-02 13:17:20 UTC
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.
Comment 1 Pawel Moll 2007-11-02 13:22:09 UTC
Created attachment 12318 [details]
Configuration file
Comment 2 Pawel Moll 2007-11-02 13:25:08 UTC
"but this time descriptor 3 is a virtual terminal..." "... and select(...) blocks".
Comment 3 Pawel Moll 2007-11-05 05:00:32 UTC
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...
Comment 4 Pawel Moll 2007-11-06 02:40:34 UTC
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 ;-)
Comment 5 Pawel Moll 2007-11-06 09:39:01 UTC
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.
Comment 6 Pawel Moll 2007-11-06 09:40:06 UTC
"as by default keyboard driver is connected to current VT..."
Comment 7 Pawel Moll 2007-11-07 14:10:11 UTC
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
Comment 8 Daniel Stone 2009-08-31 17:48:51 UTC
fix pushed, thanks.  note that the kbd driver is worse than useless with sharevts, though!
Comment 9 Daniel Stone 2009-08-31 21:09:57 UTC
(marking as fixed)
Comment 10 Daniel Stone 2009-08-31 21:10:41 UTC
*** 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.