similar to: [Bug 75279] XCloseDisplay() takes one minute around nouveau_dri.so, freezing Firefox startup

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #17 from Karl Tomlinson <bugs.freedesktop at karlt.net> --- > Thread 1 (Thread 0x7f2d032c2740 (LWP 3445)): > #0 0x00007f2d02ebfa8d in read () from /usr/lib/libpthread.so.0 > #1 0x00007f2cfd97264a in mozilla::widget::GfxInfo::GetData() () > from /home/fred/T?l?chargements/firefox/libxul.so I wouldn't expect

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #28 from Frederic Bezies <fredbezies at gmail.com> --- Some progress with debug packages. But I think I'll need xf86-video-nouveau debug package too. At least, here is the log : (gdb) bt full #0 0x00007f364503a337 in sched_yield () from /usr/lib/libc.so.6 No symbol table info available. #1 0x00007f3632d0e411 in

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #19 from Benoit Jacob <bjacob at mozilla.com> --- A duplicate Mozilla bug has a stack with symbols: https://bugzilla.mozilla.org/show_bug.cgi?id=975512#c1 #0 0x0000003f3a2da007 in sched_yield () from /lib64/libc.so.6 #1 0x00007f1e003bb1d1 in nouveau_fence_wait () from /usr/lib64/dri/nouveau_dri.so #2 0x00007f1e0039d635

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #29 from Frederic Bezies <fredbezies at gmail.com> --- Looks like a NouVeau is triggered by Mozilla Firefox trunk code. I opened a bug on mozilla bugtracker, https://bugzilla.mozilla.org/show_bug.cgi?id=978439 Even if I find a "dirty workaround", valgrind logs are showing a NouVeau driver bug. I will attach both

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #31 from Frederic Bezies <fredbezies at gmail.com> --- Created attachment 95189 --> https://bugs.freedesktop.org/attachment.cgi?id=95189&action=edit Valgrind log with debug symbols for Mozilla Firefox trunk code. And log for mozilla Firefox trunk code. Always the same beginning : Invalid read of size 4 at

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #7 from Frederic Bezies <fredbezies at gmail.com> --- I'm the reporter on mozilla bugzilla tracker. Some technical infos on my computer. Using archlinux, 64 bits. Software versions ? Kernel upgraded less than an hour ago. [fred at fredo-arch ~]$ pacman -Si mesa | grep Version Version : 10.0.3-1 [fred at

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #8 from Frederic Bezies <fredbezies at gmail.com> --- Created attachment 94479 --> https://bugs.freedesktop.org/attachment.cgi?id=94479&action=edit glxinfo for my hardware. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #9 from Frederic Bezies <fredbezies at gmail.com> --- glxtest output : [fred at fredo-arch ~]$ ./glxtest VENDOR nouveau RENDERER Gallium 0.4 on NVA8 VERSION 3.0 Mesa 10.0.3 TFP TRUE Not a single hang. Will try seeing on full mozilla code if there is still a hang or not. -- You are receiving this mail because: You are the

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #11 from Frederic Bezies <fredbezies at gmail.com> --- (In reply to comment #10) > Emil tried the glxtest program earlier and didn't get a hang either. So at > least that's consistent. (I'm adding you to the CC list, hope that's OK, if > not, feel free to remove yourself.) I don't mind. I wanted to

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #15 from Frederic Bezies <fredbezies at gmail.com> --- (In reply to comment #14) > Frederic, would you be able to use top to identify the program using 100% > cpu, attach a debugger (gdb attach <pid>) while hanging, and get a stack > trace, please? Already done in mozilla bugzilla bug report. Adding this log

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #16 from Frederic Bezies <fredbezies at gmail.com> --- Created attachment 94625 --> https://bugs.freedesktop.org/attachment.cgi?id=94625&action=edit log asked for in comment #14. It is a copy of the log I produced on mozilla bugzilla report. -- You are receiving this mail because: You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #22 from Frederic Bezies <fredbezies at gmail.com> --- (In reply to comment #21) [...] > Frederic, can you say if you have any force-enabled prefs set in > about:config? None. All options are set with their default values. -- You are receiving this mail because: You are the assignee for the bug. -------------- next

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #23 from Frederic Bezies <fredbezies at gmail.com> --- Don't know if it is related, but I'm facing a plugin container hang and nouveau seems to be guilty in some way. Got this thread with gdb : Thread 1 (Thread 0x7f4dd7b37940 (LWP 2961)): #0 0x00007f4dd2294337 in sched_yield () from /usr/lib/libc.so.6 #1

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #26 from Frederic Bezies <fredbezies at gmail.com> --- (In reply to comment #24) [...] > > Seems to be stuck at the same spot with identical call stack, minus the > state tracker bits. > > The memory access message looks interesting, shame there is no indication of > what nouveau was doing to provoke this.

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #30 from Frederic Bezies <fredbezies at gmail.com> --- Created attachment 95188 --> https://bugs.freedesktop.org/attachment.cgi?id=95188&action=edit Valgrind log for glxtest Here is the valgrind log for Glx test -- You are receiving this mail because: You are the assignee for the bug. -------------- next part

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #43 from Frederic Bezies <fredbezies at gmail.com> --- Bug is fixed for good. Archlinux upgraded to Mesa 10.1.1 today, and after rebuilding firefox, no more freeze problem with nouveau. Thanks for the fix. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #13 from Benoit Jacob <bjacob at mozilla.com> --- The work-around that works for us, and that we're considering landing, is to avoid calling XCloseDisplay and, in this case, just calling XSync to handle any pending errors in glxtest. Digging in the Gecko codebase, I found at least another instance where we avoid calling

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #21 from Benoit Jacob <bjacob at mozilla.com> --- - Are you guys using multi-threaded gl ? Not here. We could be if Frederic was 1) using non-default preferences such as layers.acceleration.force-enabled and 2) viewing specific Web pages (e.g. using WebGL). But here we are talking about a startup hang occurring before this

https://bugs.freedesktop.org/show_bug.cgi?id=75279 --- Comment #25 from Emil Velikov <emil.l.velikov at gmail.com> --- (In reply to comment #21) [snip] > Sure. You need a Nightly build, but not a current one since we have landed a > work-around (avoiding to call XCloseDisplay here). This one, from Feb. 20, > should reproduce: > >

https://bugs.freedesktop.org/show_bug.cgi?id=75279 Emil Velikov <emil.l.velikov at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|dri-devel at lists.freedesktop |nouveau at lists.freedesktop.o |.org |rg QA Contact|