[Nouveau] [Bug 90482] New: Xorg take 100% CPU when using multiple independent screen configuration

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=90482

            Bug ID: 90482
           Summary: Xorg take 100% CPU when using multiple independent
                    screen configuration
           Product: xorg
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: dura at duradsl.duckdns.org
        QA Contact: xorg-team at lists.x.org

Created attachment 115835
  --> https://bugs.freedesktop.org/attachment.cgi?id=115835&action=edit
my xorg.conf

My xorg setup is based on two independent screen (see attached xorg.conf). Most
of the time the Xorg process eat 100% of one CPU core.

I will try to explain what I think is the problem and the fix (or workaround) I
made to the nouveau code.

Basically, the problem is that nouveau add a socket to the xorg socket list but
does not register a handler that will be able to deal with it. When data is
received on this socket the Select call in xorg-server/os/WaitFor.c will return
but the data will not be read. When Select is called again it returns
immediately because data was not read, and again, and again, resulting in 100%
CPU core consumption.

Now, some details (based on xf86-video-nouveau-1.0.11 source code)
To add a socket in the xorg server list AddGeneralSocket is used.
In src/drmmode_display.c AddGeneralSocket is called in two places: line 1605
(via drmmode_uevent_init and line 1554) and 1610. If line 1608 condition is not
meet, a socket is added without an handler so drmmode_wakeup_handler will never
be called with correct data.

My solution is to add a new handler that will only handle the udev part when
line 1608 condition is not meet. See attached patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20150516/c563f453/attachment.html>