From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43953)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <richard.purdie@linuxfoundation.org>)
	id 1ZYqYN-00012Z-C2
	for qemu-devel@nongnu.org; Mon, 07 Sep 2015 03:09:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <richard.purdie@linuxfoundation.org>)
	id 1ZYqYJ-0007cQ-9m
	for qemu-devel@nongnu.org; Mon, 07 Sep 2015 03:09:23 -0400
Received: from 5751f4a1.skybroadband.com ([87.81.244.161]:54951
	helo=dan.rpsys.net) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <richard.purdie@linuxfoundation.org>)
	id 1ZYqYI-0007bq-Uh
	for qemu-devel@nongnu.org; Mon, 07 Sep 2015 03:09:19 -0400
Message-ID: <1441609742.24871.234.camel@linuxfoundation.org>
From: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Mon, 07 Sep 2015 08:09:02 +0100
In-Reply-To: <CAPokK=p=BdxE0XKqfH7AHJbFm-A35hsu-443kMSLL_VfakQ7PA@mail.gmail.com>
References: <1441362357.24871.155.camel@linuxfoundation.org>
	<CAFEAcA874VoaFLDU+5Ai1DgQ8ahgSrh6Xfkg6VSqHwZ0422PSA@mail.gmail.com>
	<1441365880.24871.164.camel@linuxfoundation.org>
	<CAFEAcA8ict1SFxpu4yb_y1Rvp6kTZn3xweMF_7Vw1H0Mc-w3iw@mail.gmail.com>
	<1441370585.24871.166.camel@linuxfoundation.org>
	<1441387258.24871.197.camel@linuxfoundation.org>
	<CAFEAcA9YWnhnc5eL8ST1bHjkBj1_UiVd7ZDET2GjKbV+BQ+igQ@mail.gmail.com>
	<CAPokK=p9GUx7OeJ7xNwbnJkzd7JMLVayhgOCf0XapHnW9M9JLA@mail.gmail.com>
	<1441549313.24871.218.camel@linuxfoundation.org>
	<CAPokK=qr6Rr+kPbZu=qbUgn0yHGzu8FbzMkSF4CSP92xdhgPrg@mail.gmail.com>
	<1441581997.24871.227.camel@linuxfoundation.org>
	<CAPokK=p=BdxE0XKqfH7AHJbFm-A35hsu-443kMSLL_VfakQ7PA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] Segfault using qemu-system-arm in smc91c111
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Crosthwaite <crosthwaitepeter@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, qemu-devel <qemu-devel@nongnu.org>

On Sun, 2015-09-06 at 17:48 -0700, Peter Crosthwaite wrote:
> On Sun, Sep 6, 2015 at 4:26 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Sun, 2015-09-06 at 11:37 -0700, Peter Crosthwaite wrote:
> > It seems can_receive isn't enough, we'd need to put some checks into
> > receive itself since once can_receive says "yes", multiple packets can
> > arrive to _receive without further checks of can_receive.
> 
> This doesn't sound right. There are other network controllers that
> rely of can_receive catching all cases properly. Is this a regression?
> Looking at logs, I see some refactoring of QEMU net framework around
> June timeframe, if you rewind to QEMU 2.3 (or earlier) does the bug go
> away?

We weren't seeing this problem until we upgraded to 2.4.

> 
> > I've either
> > messed up my previous test or been lucky.
> >
> > I tested an assert in _recieve() which confirms it can be called when
> > can_receive() says it isn't ready.
> >
> 
> A backtrace of this would be handy.
> 
> What is your replicator? I have core-image-minimal handy but it has no
> scp or sshd so all I can think of to stress network is wget, but that
> doesn't replicate.

I've been using a core-image-sato and using the "bitbake core-image-sato
-c testimage" which runs a set of tests against the target image. It
invariably crashes on the scp test when I put an assert in receive().

To make it simpler, if I just "runqemu qemuarm" to boot the
core-image-sato, then scp a 5MB file consisting of zeros into the image,
it hits the assert after around 2% transferred.

Cheers,

Richard