|Summary:||Display freeze when starting League of Legends (Wine)|
|Product:||xorg||Reporter:||Detlev Casanova <detlev.casanova>|
|Component:||Driver/nouveau||Assignee:||Nouveau Project <nouveau>|
|Status:||RESOLVED MOVED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
Description Detlev Casanova 2015-05-21 15:13:47 UTC
Created attachment 115953 [details] Nouveau error log - 1 Up until recently, I was able to play League of Legends on Linux with Wine, using the open source driver nouveau. And that was with great performances. Since an upgrade of the game (I cannot go back to the old version though), everytime the game starts, The display freezes (sometimes after up to 5 seconds but it always does). The cursor is still moving but typing commands blindly doesn't seem to work. The network and SSH deamon being still running, I was able to collect some Kernel logs. I attach them. I also tried to go back to an older version of the Kernel in case the problem was in there but that did not help (So I can't bissect the kernel to find the possible bug) I am not sure if the game is doing something nasty or if there is a bug in the opensource driver. Logs show all kind of error messages I could find.
Comment 1 Detlev Casanova 2015-05-21 15:14:31 UTC
Created attachment 115954 [details] Nouveau error log - 2
Comment 2 Detlev Casanova 2015-05-21 15:14:56 UTC
Created attachment 115955 [details] Nouveau error log - 3
Comment 3 Ilia Mirkin 2015-05-21 16:03:03 UTC
The first error messages are the most informative. Can you provide a full dmesg log from boot until some of those errors happen? Also, what version of mesa are you using? If not the latest, please try with the latest.
Comment 4 Detlev Casanova 2015-05-25 08:13:50 UTC
Hello, thanks for your response. The version of mesa was just updated by my distro (archlinux) to version : OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.5.6 OpenGL version string: 3.0 Mesa 10.5.6 OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.5.6 I'll attach a log that shows the journal when the game freezes. I just realized that only the game freezes. Once it's been killed by SSH, I get the control of the system back.
Comment 5 Detlev Casanova 2015-05-25 08:14:25 UTC
Created attachment 116019 [details] Nouveau log from beginning
Comment 6 Samuel Pitoiset 2015-05-25 09:18:26 UTC
Created attachment 116021 [details] [review] 0001-nvc0-prevent-using-unvalidated-vertex-programs.patch Hello Detlev, Did you test with mesa git? In any cases, could you please try this attached patch ? I'm absolutely not sure it will fix your issue but let's try. :-)
Comment 7 Detlev Casanova 2015-05-25 19:01:05 UTC
Mesa git won't solve the issue. I'm trying the patch as soon as possible :)
Comment 8 Detlev Casanova 2015-05-25 19:53:43 UTC
Unfortunately, the patch did not fix the problem. Though now, I can Alt-Tab to switch to other windows and even kill the app with Ctrl-Alt-Esc. I attach the log for the start of the game.
Comment 9 Detlev Casanova 2015-05-25 19:54:54 UTC
Created attachment 116032 [details] begining of errors with mesa git and nvc0 shader validation patch
Comment 10 Ilia Mirkin 2015-05-25 19:56:06 UTC
Are you using libdrm 2.4.60? If so, don't. Either use 2.4.59 or 2.4.61.
Comment 11 Detlev Casanova 2015-05-25 20:25:30 UTC
No, this is libdrm 2.4.61, the latest version in archlinux.
Comment 12 Ilia Mirkin 2015-05-25 20:31:09 UTC
OK, well this is phenomenally bad then: nouveau E[League of Legen] Unknown handle 0x00000017 nouveau E[League of Legen] validate_init nouveau E[League of Legen] validate: -2 And in your earlier logs: nouveau E[League of Legen] Unknown handle 0x0000020e nouveau E[League of Legen] validate_init nouveau E[League of Legen] validate: -2 nouveau E[League of Legen] multiple instances of buffer 3 on validation list nouveau E[League of Legen] validate_init nouveau E[League of Legen] validate: -22 I guess the earlier log may have happened with 2.4.60 -- that one would trigger the "multiple instances" error. Unknown handle is really really bad though. Ben (or anyone)? I don't see how this can happen... Are we not holding on to some buffer that we should be? Should pushbuf_refn take a ref on the bo? Detlev, could you create an apitrace that reproduces the issue? I think that could ease debugging. (https://github.com/apitrace/apitrace)
Comment 13 Detlev Casanova 2015-05-25 20:36:44 UTC
I'll get that in place tomorrow. Note that the first bug could have been reported using 2.4.60, I upgrade packages almost everyday. For the rest, this is out of my comprehension scope :) I'll do my best to give you all you need :)
Comment 14 Detlev Casanova 2015-05-26 16:02:07 UTC
I am not sure I will be able to get a trace, the game automatically starts different programs when setting up the game in wine. The behavior today is quite random: * Sometimes the game crashes * Sometimes it freezes while loading * Sometimes it freeze when the game starts * Sometimes I loose control (keyboard and GUI not responding but mouse still moving) I haven't been able to reproduce the bug with Wine running through apitrace. I'll try again.
Comment 15 Detlev Casanova 2015-05-26 18:12:45 UTC
First of all, that trace program is awesome ! I did some testing and couldn't fine the trace file. I then realized that it was located in the folder of the executable. So, I now have a 65MB trace file. I suppose that only the end is interresting but I'm not even sure that this is true. Is there any official way to give you that file ? If not, I will uploaded to my google drive and make it available to you. Thanks in advance :)
Comment 16 Ilia Mirkin 2015-05-26 18:17:41 UTC
(In reply to Detlev Casanova from comment #15) > First of all, that trace program is awesome ! > I did some testing and couldn't fine the trace file. I then realized that it > was located in the folder of the executable. > > So, I now have a 65MB trace file. I suppose that only the end is > interresting but I'm not even sure that this is true. Is there any official > way to give you that file ? If not, I will uploaded to my google drive and > make it available to you. > > Thanks in advance :) Does replaying that trace ('glretrace $file') cause the issues to occur? If so, xz -9 the trace, and make it available somehow. Google drive is a common such mechanism. Just make it readable by anyone.
Comment 17 Detlev Casanova 2015-05-26 18:43:59 UTC
The bug doesn't seem to be logged in the journal and the screen doesnt freeze whet replayed. though some messages like: 91596 @1 glXSwapIntervalMESA(interval = 1) = 0 91596: warning: unsupported glXSwapIntervalMESA call 107191: message: api issue 1: FBO incomplete: driver marked FBO as incomplete [-1] [repeated] are shown. anyway, if it helps, here is the compressed trace: https://drive.google.com/folderview?id=0B9ElNtcsRXKbfk1zZ0N0cDdPQW1ZRnRmR1NHdnRIMldQUjBQdkhUdHRtaGxGX082dXA5NkE&usp=sharing#list
Comment 18 Samuel Pitoiset 2015-05-26 20:50:21 UTC
Thanks for the trace, but we can't reproduce the issue. That's strange. Could you try to generate a new trace and make sure the issue occurs when you replay it, please?
Comment 19 Ilia Mirkin 2015-05-26 20:52:41 UTC
By the way I just noticed that League of Legends is a free game, so I'm going to check it out tonight. Detlev, I've never played this game -- what do I need to do in order to make the freeze occur?
Comment 20 Detlev Casanova 2015-05-27 05:31:57 UTC
I'm not sure you can do it with a new account, the game is very restrictive. The bug occurs with every type of game. To avoid being banned for leaving an actual game (that's not fair because i would leave a team with 4 against 5), I create a custom game with bots: Launch -> login -> play -> select Custom -> Normal -> Create game -> Team size: 1 -> Create game -> Add Bot in team 2 -> Start game -> click yes -> select a champion -> Lock In -> Wait for freeze. To generate the trace, I ran playonlinux within apitrace32. I recommand installing league of legends from playonlinux. I'll try to generate a new trace tonight.
Comment 21 Detlev Casanova 2015-05-27 15:08:20 UTC
I haven't been able to reproduce the issue with a trace, I tried multiple ones. I realized that when retracing, with verbose output, I get this in the end: 451252 @0 glEnable(cap = GL_BLEND) // incomplete 453956 @1 glFenceSync(condition = GL_SYNC_GPU_COMMANDS_COMPLETE, flags = 0) // incomplete apitrace: warning: caught signal 11 453956: error: caught an unhandled exception glretrace+0x2a637c /usr/lib/libpthread.so.0+0x1065f glretrace+0x217db2 glretrace+0xf363 glretrace+0xb2d5 glretrace+0xb8eb /usr/lib/libpthread.so.0+0x7353 /usr/lib/libc.so.6: clone+0x6c ? apitrace: info: taking default action for signal 11 Erreur de segmentation (core dumped) The last 2 calls seem incomplete (not completely traced by apitrace ?) and then, glretrace crashes. Is there a way to end apitrace32 to properly generate the end of the trace ?
Comment 22 Samuel Pitoiset 2015-05-27 16:19:05 UTC
What version of apitrace do you use? If you use the archlinux package, you should perhaps try to build your own apitrace from the repo.
Comment 23 Detlev Casanova 2015-05-27 19:58:25 UTC
Archlinux ships apitrace version 6.1. With the latest git version, it doesn't seem to segfault but the kernel errors are not reproducible... I don't know what else I can do :/
Comment 24 Ilia Mirkin 2015-05-27 20:05:42 UTC
Quick update. I didn't get to this last night, and won't be able to look at it until mid to late June. (Doesn't mean someone else can't look at it though.)
Comment 25 Ilia Mirkin 2015-06-21 23:15:46 UTC
(In reply to Detlev Casanova from comment #21) > I haven't been able to reproduce the issue with a trace, I tried multiple > ones. > > I realized that when retracing, with verbose output, I get this in the end: > > 451252 @0 glEnable(cap = GL_BLEND) // incomplete > 453956 @1 glFenceSync(condition = GL_SYNC_GPU_COMMANDS_COMPLETE, flags = 0) > // incomplete This is the same issue that supertuxkart 0.9 was having, it'd die in a glFenceSync. I believe I tracked down the underlying issue and sent a patch to fix it: http://patchwork.freedesktop.org/patch/52425/ Please try applying that patch to your mesa build and see if it helps.
Comment 26 Martin Peres 2019-12-04 08:59:51 UTC
-- 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/driver/xf86-video-nouveau/issues/192.