Dear Rosen,
On Fri, Sep 4, 2020 at 10:50 PM Rosen Penev wrote:
>
> On Fri, Sep 4, 2020 at 7:01 AM Jaap Buurman wrote:
> >
> > Dear all,
> >
> > Is there a reason the "ramips: ethernet: fix to interrupt handling"
> > patch never was included in the
On Fri, Sep 4, 2020 at 7:01 AM Jaap Buurman wrote:
>
> Dear all,
>
> Is there a reason the "ramips: ethernet: fix to interrupt handling"
> patch never was included in the master branch or 19.07 branch?:
>
> https://patchwork.ozlabs.org/project/openwrt/patch/20191029
Dear all,
Is there a reason the "ramips: ethernet: fix to interrupt handling"
patch never was included in the master branch or 19.07 branch?:
https://patchwork.ozlabs.org/project/openwrt/patch/20191029172328.85861-2-ros...@gmail.com/
There are many interrupt errors on my mt7621 d
the upstream kernel. the function mtk_napi_rx always be called if it have
packet to receive. it doesn't check status register.
but on openwrt code. check the status register first. then call fe_poll_rx.
if you clear status register. fe_poll_rx will will not be called next time.
Rosen Penev 於 2019
From: NeilBrown
The current code acknowledged interrupts *after* polling.
This is the wrong way around, and could cause an interrupt to
be missed.
This is not likely to be fatal as another packet, and so another
interrupt, should come along soon. But maybe it is causing
problems, so let's fix it
On Wed, Mar 6, 2019 at 12:37 AM Mingyu Li wrote:
>
> the original code use status register to keep there still have some
> pkts in buffer.
> need next napi call to receive it.
>
> if 128 packets in buffer. you clear status first. because napi max
> handle 64 packets in buffer.
> so 64 packets need
the original code use status register to keep there still have some
pkts in buffer.
need next napi call to receive it.
if 128 packets in buffer. you clear status first. because napi max
handle 64 packets in buffer.
so 64 packets need to handle in next napi poll. if no new packet
comming. the statu
From: NeilBrown
The current code acknowledged interrupts *after* polling.
This is the wrong way around, and could cause an interrupt to
be missed.
This is not likely to be fatal as another packet, and so another
interrupt, should come along soon. But maybe it is causing
problems, so let's fix it
