From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from 7.mo69.mail-out.ovh.net ([46.105.50.32]:39081 "EHLO 7.mo69.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752930AbdAFOIt (ORCPT ); Fri, 6 Jan 2017 09:08:49 -0500 Received: from player696.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo69.mail-out.ovh.net (Postfix) with ESMTP id DDB93FB9C for ; Fri, 6 Jan 2017 14:52:41 +0100 (CET) Date: Fri, 6 Jan 2017 14:52:35 +0100 From: Greg Kurz To: Al Viro Cc: Tuomas Tynkkynen , linux-fsdevel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [V9fs-developer] 9pfs hangs since 4.7 Message-ID: <20170106145235.51630baf@bahia.lan> In-Reply-To: <20170104230101.GG1555@ZenIV.linux.org.uk> References: <20161124215023.02deb03c@duuni> <20170102102035.7d1cf903@duuni> <20170102162309.GZ1555@ZenIV.linux.org.uk> <20170104013355.4a8923b6@duuni> <20170104014753.GE1555@ZenIV.linux.org.uk> <20170104220447.74f2265d@duuni> <20170104230101.GG1555@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, 4 Jan 2017 23:01:01 +0000 Al Viro wrote: > > Here's logs that should be complete this time: > > > > https://gist.githubusercontent.com/dezgeg/08629d4c8ca79da794bc087e5951e518/raw/a1a82b9bc24e5282c82beb43a9dc91974ffcf75a/9p.qemu.log > > https://gist.githubusercontent.com/dezgeg/1d5f1cc0647e336c59989fc62780eb2e/raw/d7623755a895b0441c608ddba366d20bbf47ab0b/9p.dmesg.log > > Fun. All requests prior to > [ 360.110282] dd-1899 1.... 18497262us : 9p_client_req: client 18446612134390128640 request P9_TWALK tag 25 > line in dmesg had been seen by the servers; all requests starting with that > one had not. Replies to earlier requests kept arriving just fine. > Looking at the tag numbers, I think we're hitting the hardcoded limit of 128 simultaneous requests in QEMU (which doesn't produce any error, new requests are silently dropped). Tuomas, can you change MAX_REQ to some higher value (< 65535 since tag is 2-byte and 0xffff is reserved) to confirm ? > >From the server side, everything looks nice and sane - it has processed > all requests it had seen, and aside of slight difference in the arrival > order server-side and client-side logs match, except for the last 26 > requests the client claims to have sent and the server has never seen. > > All traffic for another client (there had been less of it) has ceased long > before that point, so we can't really tell if it's just this client that > got buggered. Interesting... > > Looking at the tracepoints, those requests got through p9_client_prepare_req(); > we have no idea whether it got through p9_virtio_request(). OTOH, AFAICS > nothing had been sleeping in there... > > FWIW, it might be interesting to try > WARN_ON(!virtqueue_kick(chan->vq)); > in p9_virtio_request() (instead of blind virtqueue_kick(chan->vq)) and see > if it triggers. Incidentally, it looks like p9_virtio_request() ought to > return an error if that happens... > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > V9fs-developer mailing list > V9fs-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/v9fs-developer