From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Peter Crosthwaite <crosthwaitepeter@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Segfault using qemu-system-arm in smc91c111
Date: Mon, 07 Sep 2015 08:47:28 +0100 [thread overview]
Message-ID: <1441612048.24871.248.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAPokK=p=BdxE0XKqfH7AHJbFm-A35hsu-443kMSLL_VfakQ7PA@mail.gmail.com>
On Sun, 2015-09-06 at 17:48 -0700, Peter Crosthwaite wrote:
> 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?
I did find an interesting comment in this commit:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=625de449fc5597f2e1aff9cb586e249e198f03c9
"""
Since commit 6e99c63 "net/socket: Drop net_socket_can_send" and friends,
net queues need to be explicitly flushed after qemu_can_send_packet()
returns false, because the netdev side will disable the polling of fd.
"""
smc91x111 is calling flush functions when it knows can_receive
would/should return false. I believe that is the bug here.
I suspect the driver needs:
* can_receive to actually return the right value
* the locations of the flush calls to be when there is receive space
This could explain what changed to break this and why moving the flush
calls works in my patch.
Cheers,
Richard
next prev parent reply other threads:[~2015-09-07 7:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-04 10:25 [Qemu-devel] Segfault using qemu-system-arm in smc91c111 Richard Purdie
2015-09-04 10:45 ` Peter Maydell
2015-09-04 11:24 ` Richard Purdie
2015-09-04 11:31 ` Peter Maydell
2015-09-04 12:43 ` Richard Purdie
2015-09-04 17:20 ` Richard Purdie
2015-09-04 17:30 ` Peter Maydell
2015-09-05 20:30 ` Peter Crosthwaite
2015-09-06 14:21 ` Richard Purdie
2015-09-06 18:37 ` Peter Crosthwaite
2015-09-06 23:26 ` Richard Purdie
2015-09-07 0:48 ` Peter Crosthwaite
2015-09-07 7:09 ` Richard Purdie
2015-09-07 18:05 ` Peter Crosthwaite
2015-09-07 7:18 ` Richard Purdie
2015-09-07 7:47 ` Richard Purdie [this message]
2015-09-07 9:21 ` Peter Maydell
2015-09-07 18:12 ` Peter Crosthwaite
2015-09-08 9:55 ` Jason Wang
2015-09-07 18:42 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1441612048.24871.248.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=crosthwaitepeter@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).