On Sun, 8 Jan 2017 05:46:39 +
Al Viro wrote:
> On Sat, Jan 07, 2017 at 06:15:23PM +, Al Viro wrote:
> > On Sat, Jan 07, 2017 at 05:19:10PM +, Al Viro wrote:
> >
> > > released) simply trigger virtio_queue_notify_vq() again? It *is* a bug
> > > (if we get a burst filling a previous
On Mon, Jan 09, 2017 at 08:39:31PM +0200, Tuomas Tynkkynen wrote:
> Yes, this does seem to be related to this or otherwise MAX_REQ related!
> - Bumping MAX_REQ up to 1024 makes the hang go away (on 4.7).
> - Dropping it to 64 makes the same hang happen on kernels where it worked
> before (I trie
On Sat, 7 Jan 2017 17:19:10 +
Al Viro wrote:
> On Sat, Jan 07, 2017 at 04:10:45PM +0100, Greg Kurz wrote:
> > > virtqueue_push(), but pdu freeing is delayed until v9fs_flush() gets woken
> > > up. In the meanwhile, another request arrives into the slot of freed by
> > > that virtqueue_push()
On Sat, 7 Jan 2017 17:19:10 +
Al Viro wrote:
> On Sat, Jan 07, 2017 at 04:10:45PM +0100, Greg Kurz wrote:
> > > virtqueue_push(), but pdu freeing is delayed until v9fs_flush() gets woken
> > > up. In the meanwhile, another request arrives into the slot of freed by
> > > that virtqueue_push()
On Sat, Jan 07, 2017 at 06:15:23PM +, Al Viro wrote:
> On Sat, Jan 07, 2017 at 05:19:10PM +, Al Viro wrote:
>
> > released) simply trigger virtio_queue_notify_vq() again? It *is* a bug
> > (if we get a burst filling a previously empty queue all at once, there won't
> > be any slots becomi
On Sat, Jan 07, 2017 at 05:19:10PM +, Al Viro wrote:
> released) simply trigger virtio_queue_notify_vq() again? It *is* a bug
> (if we get a burst filling a previously empty queue all at once, there won't
> be any slots becoming freed
Umm... Nope, even in that scenario we'll have all reques
On Sat, Jan 07, 2017 at 04:10:45PM +0100, Greg Kurz wrote:
> > virtqueue_push(), but pdu freeing is delayed until v9fs_flush() gets woken
> > up. In the meanwhile, another request arrives into the slot of freed by
> > that virtqueue_push() and we are out of pdus.
> >
>
> Indeed. Even if this doe
On Sat, 7 Jan 2017 06:26:47 +
Al Viro wrote:
> On Fri, Jan 06, 2017 at 02:52:35PM +0100, Greg Kurz wrote:
>
> > 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 dropp
On Fri, Jan 06, 2017 at 02:52:35PM +0100, Greg Kurz wrote:
> 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
On Wed, 4 Jan 2017 23:01:01 +
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/1d5f1cc064
10 matches
Mail list logo