On Mon, Sep 7, 2015 at 12:09 AM, Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > On Sun, 2015-09-06 at 17:48 -0700, Peter Crosthwaite wrote: >> On Sun, Sep 6, 2015 at 4:26 PM, Richard Purdie >> <richard.pur...@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. >
I can't replicate. The 5MB scp works for me. Can you bisect qemu? Regards, Peter > Cheers, > > Richard >
