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. Cheers, Richard
