On Fri, 27 May 2016 16:18:48 +0200, David Coppa <[email protected]> wrote:
> On Fri, 27 May 2016, Carlin Bingham wrote: > > > On Fri, May 27, 2016 at 01:07:09AM +0200, Theo Buehler wrote: > > > On Thu, May 26, 2016 at 05:54:30PM -0400, Andre Smagin wrote: > > > > On Sat, 14 May 2016 21:01:29 +0200 (CEST) > > > > [email protected] wrote: > > > > > > > > > >Synopsis: radeon(4) drm crashing on current/amd64 > > > > [...] > > > > > drm:pid77501:radeon_fence_wait_empty_locked *ERROR* error > > > > > waiting for ring[3] to become idle (-1601868) > > > > > > > > > > > > I am seeing the same issue, very infrequently (may be once > > > > every week or two): > > > > > > > > drm:pid55825:radeon_fence_wait_empty_locked *ERROR* error > > > > waiting for ring[3] to become idle (-6007676) i3(49392): > > > > syscall 97 "inet" > > > > > > > > Not sure what happens to i3 as X crashes, but I get that pledge > > > > message every time. (Previously mentioned i3 to dcoppa, but > > > > before realizing it was related to radeon issue.) > > > > > > I combed through the i3 source code hoping to get an indication > > > what might be the cause for that socket(2) call breaking a pledge > > > promise i3. I couldn't find anything: all socket calls are with > > > AF_LOCAL that should be covered by the "unix" pledge. > > > > > > Without seeing a ktrace output, I don't think I can make any > > > progress here. > > > > > > > i3's restore_xcb_check_cb() (src/restore_layout.c), if it sees that > > the connection to X has been lost, it calls restore_connect() which > > calls libxcb's xcb_connect(). > > > > In libxcb that calls xcb_connect_to_display_with_auth_info() which > > calls _xcb_open(), which calls _xcb_open_unix() and ususally that > > would be it, but if opening the unix socket fails (beause X has > > fallen over) it tries again to connect by calling _xcb_open_tcp() > > which sets up an AF_INET addrinfo and passes that to > > _xcb_socket()... and you can probably guess what happens next. > > Fallback code could be removed with no (imho) dramatic consequences. So I've been running with this code since saturday, no issue. It just died again and now I have at the end of my dmesg: drm:pid29592:radeon_fence_wait_empty_locked *ERROR* error waiting for ring[3] to become idle (-1352594) xhci0: NULL xfer pointer So no more i3 pledge call :) FWIW, I was just browsing with chrome (and ironically, I was actually looking for a *ring* (I hope my gf doesn't read this ml :3)), with a bunch of terminator and with an instance of smplayer. Code run is -current, checked out and compiled about 5 hours ago. > Index: src/xcb_util.c > =================================================================== > RCS file: /cvs/xenocara/dist/libxcb/src/xcb_util.c,v > retrieving revision 1.11 > diff -u -p -u -p -r1.11 xcb_util.c > --- src/xcb_util.c 2 Feb 2016 18:42:22 -0000 1.11 > +++ src/xcb_util.c 27 May 2016 14:18:23 -0000 > @@ -297,11 +297,6 @@ static int _xcb_open(const char *host, c > fd = _xcb_open_unix(protocol, file); > free(file); > > - if (fd < 0 && !protocol && *host == '\0') { > - unsigned short port = X_TCP_PORT + display; > - fd = _xcb_open_tcp(host, protocol, port); > - } > - > return fd; > #endif /* !_WIN32 */ > return -1; /* if control reaches here then something has gone > wrong */ >
