Nouveau - Jun 2014 - [Bug 79823] New: Mozilla apps freeze on startup with nouveau-dri-10.2.1 libs on dual-screen

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

          Priority: medium
            Bug ID: 79823
          Assignee: nouveau at lists.freedesktop.org
           Summary: Mozilla apps freeze on startup with nouveau-dri-10.2.1
                    libs on dual-screen
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: natrio at list.ru
          Hardware: x86 (IA32)
            Status: NEW
           Version: unspecified
         Component: Drivers/DRI/nouveau
           Product: Mesa

Created attachment 100709
  --> https://bugs.freedesktop.org/attachment.cgi?id=100709&action=edit
Htop sreenshot

All tested mozilla apps (firefox, thunderbird and seamonkey) freeze on startup
with nouveau-dri-10.2.1 libraries. If nouveau-dri libraries downgraded to
10.1.4, freezes gone, even without restarting x-server.

Freeze localized in forked mozilla process (with ~100% cpu eating), killing
this process can be restore mozilla's startup.

This bug detected only in nouveau dual-screen configuration. Intel dual-screen
works nornally, nouveau single-screen works too.

Arch linux, i686
Linux kernels: 3.14.6-1 and 3.10.42-1 (LTS)
Hardware: GeForce FX5200

/etc/X11/xorg.conf.d/21-nouveau.conf :
Section "ServerLayout"
    Identifier     "dual"
    Screen      0  "Screen0"
    Screen      1  "Screen1" RightOf "Screen0"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Plug-n-play"
    DisplaySize     323    244
    HorizSync       30.0 - 69.0
    VertRefresh     50.0 - 160.0
    Option         "DPMS"
EndSection

Section "Monitor"
    Identifier     "Monitor1"
    VendorName     "Unknown"
    ModelName      "TV-0"
    DisplaySize     200    150
EndSection

Section "Device"
    Identifier     "Videocard0"
    Driver         "nouveau"
    BusID          "PCI:1:0:0"
    Screen          0
    Option          "ZaphodHeads" "VGA-1"
EndSection

Section "Device"
    Identifier     "Videocard1"
    Driver         "nouveau"
    BusID          "PCI:1:0:0"
    Screen          1
    Option          "ZaphodHeads" "TV-1"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Videocard0"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
    Modes       "1024x768_85"
    EndSubSection
EndSection

Section "Screen"
    Identifier     "Screen1"
    Device         "Videocard1"
    Monitor        "Monitor1"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
    Modes       "720x576"
    EndSubSection
EndSection

-- 
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/20140609/5fd414a4/attachment.html>

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

Natrio <natrio at list.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #100709|text/plain                  |image/png
          mime type|                            |

-- 
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/20140609/6dbb7198/attachment-0001.html>

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

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Mozilla apps freeze on      |[NV30/gallium] Mozilla apps
                   |startup with                |freeze on startup with
                   |nouveau-dri-10.2.1 libs on  |nouveau-dri-10.2.1 libs on
                   |dual-screen                 |dual-screen

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
There haven't been too many changes between 10.1 and 10.2 to the nv30
driver.
Mind doing a bisect? It seems reasonable to restrict it to
src/gallium/drivers/nouveau/nv30.

By the way, why are you using zaphod heads + 2 separate screens (and no
xinerama I assume) instead of randr and having it all in one screen and
dynamically configurable.

-- 
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/20140609/9f48a298/attachment.html>

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

--- Comment #2 from Natrio <natrio at list.ru> ---
(In reply to comment #1)
> There haven't been too many changes between 10.1 and 10.2 to the nv30
> driver. Mind doing a bisect? It seems reasonable to restrict it to
> src/gallium/drivers/nouveau/nv30.
I've never done a bisect before, but I have an strace log from mozilla start
?
with and without freeze. The freeze log is so big (9MB), but if it helps, I
will post it tomorrow.
> By the way, why are you using zaphod heads + 2 separate screens (and no
> xinerama I assume) instead of randr and having it all in one screen and
> dynamically configurable.
I don't need a joint dynamic screen for two monitors. The second strictly
dedicated screen used only for video playback on TV, and the first regular
screen on monitor used for everything else.

-- 
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/20140609/f58cbdaf/attachment.html>

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

--- Comment #3 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #2)
> (In reply to comment #1)
> > There haven't been too many changes between 10.1 and 10.2 to the
nv30
> > driver. Mind doing a bisect? It seems reasonable to restrict it to
> > src/gallium/drivers/nouveau/nv30.
> I've never done a bisect before, but I have an strace log from mozilla
start
> ? with and without freeze. The freeze log is so big (9MB), but if it helps,
> I will post it tomorrow.
strace log is not that useful. It's probably sitting around waiting for
something to happen, which never happens. Bisecting is fairly easy... there are
a bunch of guides online. I'd recommend installing into some scratch
location
and using LD_LIBRARY_PATH to pick up your new lib, so that you don't mess up
your system install.

-- 
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/20140609/99f3407c/attachment.html>

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

--- Comment #4 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > There haven't been too many changes between 10.1 and 10.2 to
the nv30
> > > driver. Mind doing a bisect? It seems reasonable to restrict it
to
> > > src/gallium/drivers/nouveau/nv30.
> > I've never done a bisect before, but I have an strace log from
mozilla start
> > ? with and without freeze. The freeze log is so big (9MB), but if it
helps,
> > I will post it tomorrow.
> 
> strace log is not that useful. It's probably sitting around waiting for
> something to happen, which never happens. Bisecting is fairly easy... there
> are a bunch of guides online. I'd recommend installing into some
scratch
> location and using LD_LIBRARY_PATH to pick up your new lib, so that you
> don't mess up your system install.
Oh, and you can find some build instructions at
http://nouveau.freedesktop.org/wiki/InstallNouveau/#mesa

-- 
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/20140609/9db417fd/attachment-0001.html>

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

--- Comment #5 from Natrio <natrio at list.ru> ---
(In reply to comment #3)
> strace log is not that useful. It's probably sitting around waiting for
> something to happen, which never happens. Bisecting is fairly easy... there
> are a bunch of guides online. I'd recommend installing into some
scratch
> location and using LD_LIBRARY_PATH to pick up your new lib, so that you
> don't mess up your system install.
It's not exactly "sitting around and waiting", it cycling around
(up to 100%
CPU used) and keeps repeating the same action, probably with nouveau-dri
library.

(In reply to comment #4)
> Oh, and you can find some build instructions at
> http://nouveau.freedesktop.org/wiki/InstallNouveau/#mesa
Thank you, I will try to do it.

-- 
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/20140609/8bec3fd5/attachment.html>

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

--- Comment #6 from Natrio <natrio at list.ru> ---
>From freeze strace log:
 # Device opened:
open("/dev/dri/card0", O_RDWR|O_CLOEXEC) = 5
 ...
close(5)                    = 0
 # device /dev/dri/card0 closed, but trying to use already closed descriptor:
fstat64(5, 0xbfa97f60)      = -1 EBADF (Bad file descriptor)
ioctl(5, 0xc0406481, 0xbfa97fc0) = -1 EBADF (Bad file descriptor)
write(2, "nouveau: kernel rejected pushbuf"..., 54) = 54
write(2, "nouveau: ch0: krec 0 pushes 1 bu"..., 46) = 46
write(2, "nouveau: ch0: buf 00000000 00000"..., 63) = 63
write(2, "nouveau: ch0: psh 00000000 00000"..., 49) = 49
write(2, "nouveau: \t0x0008fd6c\n", 21) = 21
write(2, "nouveau: \t0x00000000\n", 21) = 21
write(2, "nouveau: \t0x00000003\n", 21) = 21
write(2, "nouveau: \t0x00020000\n", 21) = 21
write(2, "nouveau: \t0x00000000\n", 21) = 21

 # Cycling infinitely
sched_yield()               = 0
sched_yield()               = 0
sched_yield()               = 0
 ...

-- 
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/20140610/2a7f86f7/attachment.html>

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

--- Comment #7 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #6)
> From freeze strace log:
> 
>  # Device opened:
> open("/dev/dri/card0", O_RDWR|O_CLOEXEC) = 5
>  ...
> close(5)                    = 0
>  # device /dev/dri/card0 closed, but trying to use already closed
descriptor:
> fstat64(5, 0xbfa97f60)      = -1 EBADF (Bad file descriptor)
> ioctl(5, 0xc0406481, 0xbfa97fc0) = -1 EBADF (Bad file descriptor)
> write(2, "nouveau: kernel rejected pushbuf"..., 54) = 54
Curious. Do you have a dmesg from that? And the full output that was written
out to stderr?

A bisect will still be the most effective way of tracking down the issue.

-- 
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/20140610/32c67b53/attachment.html>

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

--- Comment #8 from Natrio <natrio at list.ru> ---
(In reply to comment #7)
> Curious. Do you have a dmesg from that? And the full output that was
written
> out to stderr?
No messages in any system log at this time.
No stderr output ? a library sends output to descriptor #2, but mozilla was
opened it as /dev/null.
> A bisect will still be the most effective way of tracking down the issue.
Bisecting in progress, 2 steps from 10.

-- 
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/20140611/f941dbcf/attachment.html>

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

--- Comment #9 from Natrio <natrio at list.ru> ---
Bisecting not finished yet, but I think about that:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=507f0230d4ca2238c818006499e21abb4c133203

-- 
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/20140611/075a4fa3/attachment-0001.html>

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

--- Comment #10 from Natrio <natrio at list.ru> ---
Bisect complete, I was right.

507f0230d4ca2238c818006499e21abb4c133203 is the first bad commit
commit 507f0230d4ca2238c818006499e21abb4c133203
Author: Ilia Mirkin <imirkin at alum.mit.edu>
Date:   Wed Mar 5 22:25:55 2014 -0500

    nouveau: fix fence waiting logic in screen destroy

    nouveau_fence_wait has the expectation that an external entity is
    holding onto the fence being waited on, not that it is merely held onto
    by the current pointer. Fixes a use-after-free in nouveau_fence_wait
    when used on the screen's current fence.

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75279
    Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
    Reviewed-by: Christoph Bumiller <e0425955 at student.tuwien.ac.at>
    Cc: "9.2 10.0 10.1" <mesa-stable at lists.freedesktop.org>

:040000 040000 46ad31dd95db1695a8c91fffbf38ee7822d8a31f
cdf816d872018460b33f69949010f09dcdcbf38e M src

-- 
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/20140611/8f201cc5/attachment.html>

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

--- Comment #11 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Hm, that's funny. You said 10.1.4 worked, which contains that commit... I
suspected that commit as well until I saw that you said 10.1.4 was fine.
I'll
think about it.

-- 
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/20140611/5419401b/attachment.html>

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

--- Comment #12 from Natrio <natrio at list.ru> ---
(In reply to comment #11)
> Hm, that's funny. You said 10.1.4 worked, which contains that commit...
I
> suspected that commit as well until I saw that you said 10.1.4 was fine.
> I'll think about it.
I said 10.1.4 WAS fine, already builded (21.06.2014) and downloaded from Arch
Linux repository.
But in current building environment, all revisions since bisected commit seems
buggy on nv30.

I will try to revert this patch on tomorrow.

-- 
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/20140611/efc8eeb1/attachment.html>

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

--- Comment #13 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #12)
> (In reply to comment #11)
> > Hm, that's funny. You said 10.1.4 worked, which contains that
commit... I
> > suspected that commit as well until I saw that you said 10.1.4 was
fine.
> > I'll think about it.
> 
> I said 10.1.4 WAS fine, already builded (21.06.2014) and downloaded from
> Arch Linux repository.
Yes, that was my implication as well.
> But in current building environment, all revisions since bisected commit
> seems buggy on nv30.
> 
> I will try to revert this patch on tomorrow.
There's probably some additional interaction with a patch that hadn't
made it
to 10.1... perhaps the screen sharing change to better support
NV_vdpau_interop, but I don't really see how that could cause issues either.

-- 
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/20140611/47610974/attachment.html>

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

--- Comment #14 from Natrio <natrio at list.ru> ---
The version 10.2.1 tested: no freeze with reverted patch for nv30_screen.c

-- 
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/20140614/a892a738/attachment.html>

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

--- Comment #15 from Natrio <natrio at list.ru> ---
Bug not only with mozilla, but glxinfo:

-- Version 10.2.1:
 freeze afrer end of (normal) output, and print this to stderr:
nouveau: kernel rejected pushbuf: Bad file descriptor
nouveau: ch0: krec 0 pushes 1 bufs 1 relocs 0
nouveau: ch0: buf 00000000 00000002 00000004 00000004 00000000
nouveau: ch0: psh 00000000 0000000140 0000000154
nouveau:        0x0008fd6c
nouveau:        0x00000000
nouveau:        0x00000004
nouveau:        0x00020000
nouveau:        0x00000000

-- Version 10.2.1 (reverted patch):
 seems to bee ok.

-- Version 10.1.4 (from repository):
 segfault after (normal) output, in dmesg:
glxinfo[9715]: segfault at 88 ip b6d88829 sp bffa4420 error 4 in
nouveau_dri.so[b6a37000+64a000]

-- Last revision before bisected commit:
 seems to bee ok.

-- Bisected commit:
 freeze, stderr:
nouveau: kernel rejected pushbuf: Bad file descriptor
nouveau: ch0: krec 0 pushes 1 bufs 1 relocs 0
nouveau: ch0: buf 00000000 00000002 00000004 00000004 00000000
nouveau: ch0: psh 00000000 0000000140 0000000154
nouveau:        0x0008fd6c
nouveau:        0x00000000
nouveau:        0x00000004
nouveau:        0x00020000
nouveau:        0x00000000

-- 
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/20140616/1217fde4/attachment.html>

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

--- Comment #16 from Natrio <natrio at list.ru> ---
glxtest (from bug #94465):

-- Version 10.1.4 (from repository):
VENDOR
nouveau
RENDERER
Gallium 0.4 on NV34
VERSION
1.5 Mesa 10.1.4
TFP
TRUE

-- Version 10.2.1:
nouveau: kernel rejected pushbuf: Bad file descriptor
nouveau: ch0: krec 0 pushes 1 bufs 1 relocs 0
nouveau: ch0: buf 00000000 00000002 00000004 00000004 00000000
nouveau: ch0: psh 00000000 000000012c 0000000140
nouveau:        0x0008fd6c
nouveau:        0x00000000
nouveau:        0x00000003
nouveau:        0x00020000
nouveau:        0x00000000
 (freeze)

-- Version 10.2.1 (reverted patch):
VENDOR
nouveau
RENDERER
Gallium 0.4 on NV34
VERSION
1.5 Mesa 10.2.1
TFP
TRUE

-- Last revision before bisected commit:
VENDOR
nouveau
RENDERER
Gallium 0.4 on NV34
VERSION
1.5 Mesa 10.2.0-devel (git-5bf90cb)
TFP
TRUE

-- Bisected commit:
nouveau: kernel rejected pushbuf: Bad file descriptor
nouveau: ch0: krec 0 pushes 1 bufs 1 relocs 0
nouveau: ch0: buf 00000000 00000002 00000004 00000004 00000000
nouveau: ch0: psh 00000000 000000012c 0000000140
nouveau:        0x0008fd6c
nouveau:        0x00000000
nouveau:        0x00000003
nouveau:        0x00020000
nouveau:        0x00000000
 (freeze)

-- 
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/20140616/08f19c60/attachment.html>

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

--- Comment #17 from Natrio <natrio at list.ru> ---
Sorry, glxtest is from bug #75279, of course.

-- 
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/20140616/e0310321/attachment.html>

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

--- Comment #18 from Ilia Mirkin <imirkin at alum.mit.edu> ---
What happens if you add

screen->base.pushbuf->user_priv = NULL

right before the if (screen->base.fence.current) check in
nv30_screen_destroy?

-- 
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/20140616/2725891d/attachment.html>

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

--- Comment #19 from Natrio <natrio at list.ru> ---
(In reply to comment #18)
> What happens if you add
> 
> screen->base.pushbuf->user_priv = NULL
> 
> right before the if (screen->base.fence.current) check in
> nv30_screen_destroy?
No effect.

After llvm,llvm-libs update 3.4.1 -> 3.4.2 also glxgears starting to freeze
instead of normal exit by ESC:

Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
2469 frames in 5.0 seconds = 493.688 FPS
2476 frames in 5.0 seconds = 495.177 FPS
nouveau: kernel rejected pushbuf: Bad file descriptor
nouveau: ch0: krec 0 pushes 1 bufs 1 relocs 0
nouveau: ch0: buf 00000000 00000004 00000004 00000004 00000000
nouveau: ch0: psh 00000000 0000025e84 0000025e98
nouveau:        0x0008fd6c
nouveau:        0x00000000
nouveau:        0x00001437
nouveau:        0x00020000
nouveau:        0x00000000
 (freeze)

-- 
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/20140617/90c8b98d/attachment.html>

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

--- Comment #20 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #19)
> (In reply to comment #18)
> > What happens if you add
> > 
> > screen->base.pushbuf->user_priv = NULL
> > 
> > right before the if (screen->base.fence.current) check in
> > nv30_screen_destroy?
> 
> No effect.
Well, I've been unable to reproduce the "kernel rejected pushbuf"
+ hang
behaviour, although I've only been testing with a NV43.

However I did observe the issue that I thought I would observe due to that line
not being there... here's a slightly more correct version than my previous
suggestion:

http://patchwork.freedesktop.org/patch/28050/

And another patch which I think is unlikely to affect what you're seeing,
but
who knows:

http://patchwork.freedesktop.org/patch/28049/

Assuming these don't help, could you run that glxtest application inside
valgrind, and let me know if you see any illegal accesses. (Note that the first
one of those patches will in fact prevent one such illegal access.)

-- 
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/20140618/5d2b756f/attachment.html>

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

--- Comment #21 from Natrio <natrio at list.ru> ---
Both patches are not works for me.

See valgrind log in attachment.

-- 
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/20140618/e2542b09/attachment.html>

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

--- Comment #22 from Natrio <natrio at list.ru> ---
Created attachment 101283
  --> https://bugs.freedesktop.org/attachment.cgi?id=101283&action=edit
Valgrind glxtest logs

Valgrind glxtest logs:
10.2.1 (clear);
10.2.1-reverted (without bisectred patch);
10.2.1-bufctx (avoid dangling... patch);
10.2.1-leaks (plug some memory leaks... patch);
10.2.1-bufctx_leaks (both patches)

-- 
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/20140618/c8b04ba3/attachment-0001.html>

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

--- Comment #23 from Ilia Mirkin <imirkin at alum.mit.edu> ---
OK, well, I can't repro this, but clearly the device is getting closed
_somehow_. It appears that you're relatively able at debugging things, let
me
know if I've misunderstood.

Can you load up glxtest in gdb (with my fixes), and do

break main
r
break close
break nv30_screen_destroy
c

and look at what happens. The first couple of closes will actually be at
creation time because it opens/closes some config files, continue past those.

This is what I see:

(gdb) c
Continuing.

Breakpoint 2, nv50_screen_destroy (pscreen=0x633c60) at nv50/nv50_screen.c:295
295        struct nv50_screen *screen = nv50_screen(pscreen);
(gdb) n
297        if (!nouveau_drm_screen_unref(&screen->base))
(gdb) p screen->base.device->fd
$1 = 8
(gdb) c
Continuing.

Breakpoint 3, 0x00007ffff6db23d0 in close () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff6db23d0 in close () from /lib64/libc.so.6
#1  0x00007ffff643797a in dri2DestroyScreen (base=0x618c50) at dri2_glx.c:712
#2  0x00007ffff63fcdb5 in FreeScreenConfigs (priv=0x615600) at glxext.c:208
#3  0x00007ffff63fce3f in glx_display_free (priv=0x615600) at glxext.c:231
#4  0x00007ffff63fd01a in __glXCloseDisplay (dpy=0x6070f0, codes=0x615688)
    at glxext.c:279
#5  0x00007ffff78bc0c2 in XCloseDisplay () from /usr/lib64/libX11.so.6
#6  0x00000000004011be in glxtest () at glxtest.cpp:202
#7  0x000000000040120a in main (argc=1, argv=0x7fffffffdda8) at glxtest.cpp:211
(gdb) up
#1  0x00007ffff643797a in dri2DestroyScreen (base=0x618c50) at dri2_glx.c:712
712        close(psc->fd);
(gdb) p psc->fd
$2 = 8
(gdb) c
Continuing.

Breakpoint 3, 0x00007ffff6db23d0 in close () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff6db23d0 in close () from /lib64/libc.so.6
#1  0x00007ffff6abddee in xcb_disconnect () from /usr/lib64/libxcb.so.1
#2  0x00007ffff78bc0f7 in XCloseDisplay () from /usr/lib64/libX11.so.6
#3  0x00000000004011be in glxtest () at glxtest.cpp:202
#4  0x000000000040120a in main (argc=1, argv=0x7fffffffdda8) at glxtest.cpp:211
(gdb) c

[this is actually with nv50, but the nv30 flow should be no different]

You must be getting something else, otherwise how is that fd getting closed
already.

-- 
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/20140618/f51f223e/attachment.html>

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

--- Comment #24 from Natrio <natrio at list.ru> ---
Created attachment 101333
  --> https://bugs.freedesktop.org/attachment.cgi?id=101333&action=edit
GDB log witn reverted patch

GDB log witn reverted (bisected) 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/20140619/560b3e0f/attachment.html>

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

--- Comment #25 from Natrio <natrio at list.ru> ---
Created attachment 101336
  --> https://bugs.freedesktop.org/attachment.cgi?id=101336&action=edit
GDB log witn clear mesa-10.2.1

 Before close:
$ ls -l /proc/7967/fd/
total 0
lrwx------ 1 user users 64 Jun 19 11:41 0 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 11:41 1 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 11:41 2 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 11:41 3 -> socket:[899028]
lrwx------ 1 user users 64 Jun 19 11:41 4 -> /dev/dri/card0
lrwx------ 1 user users 64 Jun 19 11:41 5 -> /dev/dri/card0
 after close:
$ ls -l /proc/7967/fd/
total 0
lrwx------ 1 user users 64 Jun 19 11:41 0 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 11:41 1 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 11:41 2 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 11:41 3 -> socket:[899028]
lrwx------ 1 user users 64 Jun 19 11:41 5 -> /dev/dri/card0

-- 
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/20140619/8bf816ee/attachment.html>

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

--- Comment #26 from Natrio <natrio at list.ru> ---
Created attachment 101338
  --> https://bugs.freedesktop.org/attachment.cgi?id=101338&action=edit
GDB log with "avoid dangling..." patch

/dev/dri/card0 on fd #4 closed,
/dev/dri/card0 on fd #5 remained open.

-- 
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/20140619/81c7575d/attachment.html>

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

--- Comment #27 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #26)
> Created attachment 101338 [details]
> GDB log with "avoid dangling..." patch
> 
> /dev/dri/card0 on fd #4 closed,
> /dev/dri/card0 on fd #5 remained open.
So... for some *unknown* reason, the thing decides to create two screens. Fine.
Now we have this thing which reuses screens for the same device... makes sense.
But after it tries to close one of the screens, it also closes the fd that it
used to create the screen with. Reasonable enough. However that fd is the one
that's being used by the device.

Perhaps it should be dup'ing the fd and doing all the ioctl's on that,
so that
this sort of thing doesn't happen. Maarten, thoughts?

-- 
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/20140619/01dba4de/attachment-0001.html>

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

--- Comment #28 from Natrio <natrio at list.ru> ---
Created attachment 101339
  --> https://bugs.freedesktop.org/attachment.cgi?id=101339&action=edit
GDB log with both patches

All as previous two passes ? device on fd #5 still opened after freeze.

-- 
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/20140619/0c275e18/attachment.html>

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

--- Comment #29 from Natrio <natrio at list.ru> ---
But with reverted (bisected) patch both fd #4,#5 opened and closed
successfully.

-- 
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/20140619/1a8ec325/attachment.html>

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

--- Comment #30 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Mind testing out http://patchwork.freedesktop.org/patch/28219/ ?

-- 
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/20140619/d4dbaa8a/attachment.html>

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

--- Comment #31 from Natrio <natrio at list.ru> ---
Created attachment 101350
  --> https://bugs.freedesktop.org/attachment.cgi?id=101350&action=edit
GDB log with "dup fd..." patch

It works!

 Before first close:
$ ls -l /proc/29981/fd/
total 0
lrwx------ 1 user users 64 Jun 19 13:20 0 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 13:20 1 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 13:20 2 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 13:20 3 -> socket:[1333878]
lrwx------ 1 user users 64 Jun 19 13:20 4 -> /dev/dri/card0
lrwx------ 1 user users 64 Jun 19 13:20 5 -> /dev/dri/card0
lrwx------ 1 user users 64 Jun 19 13:20 6 -> /dev/dri/card0

 After first close:
$ ls -l /proc/29981/fd/
total 0
lrwx------ 1 user users 64 Jun 19 13:20 0 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 13:20 1 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 13:20 2 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 13:20 3 -> socket:[1333878]
lrwx------ 1 user users 64 Jun 19 13:20 5 -> /dev/dri/card0
lrwx------ 1 user users 64 Jun 19 13:20 6 -> /dev/dri/card0

 After second close:
$ ls -l /proc/29981/fd/
total 0
lrwx------ 1 user users 64 Jun 19 13:20 0 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 13:20 1 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 13:20 2 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 13:20 3 -> socket:[1333878]
lrwx------ 1 user users 64 Jun 19 13:20 6 -> /dev/dri/card0

 After third close:
$ ls -l /proc/29981/fd/
total 0
lrwx------ 1 user users 64 Jun 19 13:20 0 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 13:20 1 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 13:20 2 -> /dev/pts/0
lrwx------ 1 user users 64 Jun 19 13:20 3 -> socket:[1333878]

-- 
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/20140619/0b385a5e/attachment.html>

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

Maarten Lankhorst <bugs at mblankhorst.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zeccav at gmail.com

--- Comment #32 from Maarten Lankhorst <bugs at mblankhorst.nl> ---
*** Bug 79946 has been marked as a duplicate of this bug. ***

-- 
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/20140619/9e91feac/attachment.html>

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

--- Comment #33 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #31)
> Created attachment 101350 [details]
> GDB log with "dup fd..." patch
> 
> It works!
Great! Also I just figured out why this is happening to you and not to anyone
else. It's the dual screens! (Who uses separate screens anyways...)

src/glx/glxext.c allocates a screen per... screen. And then when it cleans up,
it deletes the screens in the same order it created them. So it's precisely
the
scenario I outlined, where by the time the second screen goes to be destroyed,
the fd it relies on (which is the first one) has already been closed.

I'll push this patch out and tag it for 10.2.

-- 
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/20140619/03b90922/attachment.html>

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

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #34 from Ilia Mirkin <imirkin at alum.mit.edu> ---
A (very slightly) improved version of the patch is now in mesa master.
Hopefully it'll get backported to 10.2.2, but if not, it'll be in
10.2.3.

-- 
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/20140624/1ae556b0/attachment.html>

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

--- Comment #35 from Natrio <natrio at list.ru> ---
(In reply to comment #34)
> A (very slightly) improved version of the patch is now in mesa master.
> Hopefully it'll get backported to 10.2.2, but if not, it'll be in
10.2.3.
An improved patch
http://cgit.freedesktop.org/mesa/mesa/commit/?id=a59f2bb17bcc78e09653391748549e7973990798
was tested and also works for me.

-- 
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/20140625/6f2b0b91/attachment.html>