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.


--
Carlin

Reply via email to