Created attachment 127463 [details] xorg.log for a crash Hi, I have multi-head configuration (5 monitors). One of the monitor is a HDTV Samsung TV connected via HDMI to the intel skylake. Everything is working fine until I try to turn that HDTV monitor ON. When X server is started with the TV turned ON, it is also ok (until i turn it off and on again). In other words: the problem triggers only during turning ON that monitor/tv. Note: I don't suspect that this TV is failing, it was working for years connected to nvidia on similar hardware. When xinerama is enabled - in the moment of turning it on the server is crashing. GDB backtrace is in the attachment (backtrace-crash.log). The xorg log for that part is Xorg-crash.log It may be also relevant: that when I disable xinerama, then in the same moment (when I turn on the TV), instead of Xserver crash I've got some endless loop which is burning 100% of one of my core. The process which is doing it is the Xorg. In the same time when I am starting that TV (and it starts to eat the cpu) I can see in the xorg.log that it is trying to re-probe all EDID from all connected monitors, and I've got a plenty of lines like: [ 65543.926] (II) NOUVEAU(2): EDID vendor "FUS", prod id 1818 [ 65543.926] (II) NOUVEAU(2): Using EDID range info for horizontal sync [ 65543.926] (II) NOUVEAU(2): Using EDID range info for vertical refresh [ 65543.926] (II) NOUVEAU(2): Printing DDC gathered Modelines: Lines for intel don't show up because I disabled the probing on intel with option "HotPlug" "false" in hope that it will not eat the cpu (no luck). In the same time I can normally work - no artifacts on screen, all seems working fine, but Xorg eats 100% of my cpu (until xorg restart). When I switch VT to console - it still doing this endless loop. To obtain some additional info I connected to xorg in such state from remote machine and I attached to the xorg to obtain a backtrace. Also some stepping was recorded by me. The full session is in backtrace-100_cpu.log and the corresponding log is Xorg-100cpu.log.
Created attachment 127464 [details] backtrace for 100% cpu (from remote machine)
Created attachment 127465 [details] backtrace for crash situation (from core)
Created attachment 127466 [details] Xorg.log for the 100% cpu
Created attachment 127467 [details] xorg.conf
Please also see the https://bugs.freedesktop.org/show_bug.cgi?id=90482 if it isn't related with my problem.
The 100% CPU usage is gone when I applied a dura patch from BUG #90482 (https://bugs.freedesktop.org/show_bug.cgi?id=90482) So at least the patch cures the 100% cpu usage problem, but it doesn't help to the server crash with xinerama enabled.
Hello again, Guys, recently I switched to the recent Xorg and nouveau from git. The 100% cpu problem seems to be gone (at least so far), but the nouveau is still crashing the xserver. I still has to apply the following patch: diff --git a/src/drmmode_display.c b/src/drmmode_display.c index dd9fa27..a468223 100644 --- a/src/drmmode_display.c +++ b/src/drmmode_display.c @@ -1542,7 +1542,7 @@ drmmode_handle_uevents(ScrnInfoPtr scrn) if (!dev) return; - RRGetInfo(xf86ScrnToScreen(scrn), TRUE); + //RRGetInfo(xf86ScrnToScreen(scrn), TRUE); udev_device_unref(dev); } #endif Otherwise - when I turn on the TV on other Xorg instance (with intel driver), the xorg is crashing. Maybe nouveau is trying to do something wrong with the randr event on other xorg instance? It is now over a five months from the time when I reported it. Is it really so hard to cooperate with me to get rid of this bug? I can try your patches, give you additional debug information, I have programming skills.
(In reply to Mariusz Białończyk from comment #7) > It is now over a five months from the time when I reported it. Is it really > so hard to cooperate with me to get rid of this bug? I can try your patches, > give you additional debug information, I have programming skills. A few things to consider: 1. nouveau is largely volunteer-driven. Volunteers tend to do the things that interest them, not the things that interest non-contributors. (Which means that the end user may have to persuade that their problem is more worthwhile to work on, and stomping your foot on the ground isn't the best way to achieve that.) 2. You initially filed the bug against a component that no nouveau developer monitors 3. If you want to get help figuring this out yourself, you may want to try #nouveau and #dri-devel on freenode.
Fixed with: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=e9418e434311336e905b70553a5ed740838d90ad As for the 100% cpu endless loop - I cannot reproduce it anymore, so maybe it is now fixed with some other unknown commit, besides it has its own bug report: https://bugs.freedesktop.org/show_bug.cgi?id=90482, so don't mix it up. Thank you, Ilia!
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.