On 09/07/2015 05:21 PM, Peter Maydell wrote:
> CCing the net maintainers on this thread seems like it would
> be a good idea...
>
> On 7 September 2015 at 08:47, Richard Purdie
> wrote:
>> On Sun, 2015-09-06 at 17:48 -0700, Peter Crosthwaite wrote:
>>> This doesn't sound right. There are other n
On 6 September 2015 at 19:37, Peter Crosthwaite
wrote:
> This could still cause the same issue here though I think. The guest
> can release first (case 5) without a corresponding fifo pop (case 3),
> which actually means that the first patch idea might be the winner as
> it catches this issue too.
On Mon, Sep 7, 2015 at 2:21 AM, Peter Maydell wrote:
> CCing the net maintainers on this thread seems like it would
> be a good idea...
>
> On 7 September 2015 at 08:47, Richard Purdie
> wrote:
>> On Sun, 2015-09-06 at 17:48 -0700, Peter Crosthwaite wrote:
>>> This doesn't sound right. There are
On Mon, Sep 7, 2015 at 12:09 AM, Richard Purdie
wrote:
> On Sun, 2015-09-06 at 17:48 -0700, Peter Crosthwaite wrote:
>> On Sun, Sep 6, 2015 at 4:26 PM, Richard Purdie
>> wrote:
>> > On Sun, 2015-09-06 at 11:37 -0700, Peter Crosthwaite wrote:
>> > It seems can_receive isn't enough, we'd need to pu
CCing the net maintainers on this thread seems like it would
be a good idea...
On 7 September 2015 at 08:47, Richard Purdie
wrote:
> 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 al
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 r
On Sun, 2015-09-06 at 17:48 -0700, Peter Crosthwaite wrote:
> On Sun, Sep 6, 2015 at 4:26 PM, Richard Purdie
> wrote:
> > On Sun, 2015-09-06 at 11:37 -0700, Peter Crosthwaite wrote:
> > I tested an assert in _recieve() which confirms it can be called when
> > can_receive() says it isn't ready.
> >
On Sun, 2015-09-06 at 17:48 -0700, Peter Crosthwaite wrote:
> On Sun, Sep 6, 2015 at 4:26 PM, Richard Purdie
> 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 s
On Sun, Sep 6, 2015 at 4:26 PM, Richard Purdie
wrote:
> On Sun, 2015-09-06 at 11:37 -0700, Peter Crosthwaite wrote:
>> On Sun, Sep 6, 2015 at 7:21 AM, Richard Purdie
>> wrote:
>> > On Sat, 2015-09-05 at 13:30 -0700, Peter Crosthwaite wrote:
>> >> On Fri, Sep 4, 2015 at 10:30 AM, Peter Maydell
>
On Sun, 2015-09-06 at 11:37 -0700, Peter Crosthwaite wrote:
> On Sun, Sep 6, 2015 at 7:21 AM, Richard Purdie
> wrote:
> > On Sat, 2015-09-05 at 13:30 -0700, Peter Crosthwaite wrote:
> >> On Fri, Sep 4, 2015 at 10:30 AM, Peter Maydell
> >> wrote:
> >> > On 4 September 2015 at 18:20, Richard Purdi
On Sun, Sep 6, 2015 at 7:21 AM, Richard Purdie
wrote:
> On Sat, 2015-09-05 at 13:30 -0700, Peter Crosthwaite wrote:
>> On Fri, Sep 4, 2015 at 10:30 AM, Peter Maydell
>> wrote:
>> > On 4 September 2015 at 18:20, Richard Purdie
>> > wrote:
>> >> On Fri, 2015-09-04 at 13:43 +0100, Richard Purdie w
On Sat, 2015-09-05 at 13:30 -0700, Peter Crosthwaite wrote:
> On Fri, Sep 4, 2015 at 10:30 AM, Peter Maydell
> wrote:
> > On 4 September 2015 at 18:20, Richard Purdie
> > wrote:
> >> On Fri, 2015-09-04 at 13:43 +0100, Richard Purdie wrote:
> >>> On Fri, 2015-09-04 at 12:31 +0100, Peter Maydell w
On Fri, Sep 4, 2015 at 10:30 AM, Peter Maydell wrote:
> On 4 September 2015 at 18:20, Richard Purdie
> wrote:
>> On Fri, 2015-09-04 at 13:43 +0100, Richard Purdie wrote:
>>> On Fri, 2015-09-04 at 12:31 +0100, Peter Maydell wrote:
>>> > On 4 September 2015 at 12:24, Richard Purdie
>>> > wrote:
>>
On 4 September 2015 at 18:20, Richard Purdie
wrote:
> On Fri, 2015-09-04 at 13:43 +0100, Richard Purdie wrote:
>> On Fri, 2015-09-04 at 12:31 +0100, Peter Maydell wrote:
>> > On 4 September 2015 at 12:24, Richard Purdie
>> > wrote:
>> > > So just based on that, yes, seems that the rx_fifo looks t
On Fri, 2015-09-04 at 13:43 +0100, Richard Purdie wrote:
> On Fri, 2015-09-04 at 12:31 +0100, Peter Maydell wrote:
> > On 4 September 2015 at 12:24, Richard Purdie
> > wrote:
> > > So just based on that, yes, seems that the rx_fifo looks to be
> > > overrunning. I can add the asserts but I think i
On Fri, 2015-09-04 at 12:31 +0100, Peter Maydell wrote:
> On 4 September 2015 at 12:24, Richard Purdie
> wrote:
> > So just based on that, yes, seems that the rx_fifo looks to be
> > overrunning. I can add the asserts but I think it would just confirm
> > this.
>
> Yes, the point of adding assert
On 4 September 2015 at 12:24, Richard Purdie
wrote:
> So just based on that, yes, seems that the rx_fifo looks to be
> overrunning. I can add the asserts but I think it would just confirm
> this.
Yes, the point of adding assertions is to confirm a hypothesis.
>> Also, do you have a more specific
On Fri, 2015-09-04 at 11:45 +0100, Peter Maydell wrote:
> On 4 September 2015 at 11:25, Richard Purdie
> wrote:
> > We're seeing repeated segfaults in qemu-system-arm when we heavily use
> > the network. I have a coredump backtrace:
>
> > (gdb) print s->tx_fifo_done
> > $1 = {99614720, 99614720,
On 4 September 2015 at 11:25, Richard Purdie
wrote:
> We're seeing repeated segfaults in qemu-system-arm when we heavily use
> the network. I have a coredump backtrace:
> (gdb) print s->tx_fifo_done
> $1 = {99614720, 99614720, 99614720, 99614720}
> (gdb) print s->tx_fifo_done_len
> $2 = 99614719
19 matches
Mail list logo
