From: Arnd Bergmann <arnd@kernel.org>
To: Nikolai Zhubr <zhubr.2@gmail.com>
Cc: netdev <netdev@vger.kernel.org>
Subject: Re: Realtek 8139 problem on 486.
Date: Sun, 13 Jun 2021 23:52:38 +0200 [thread overview]
Message-ID: <CAK8P3a3W=njxgG-GzpW=XkcLjuo0-xsbzhZRcAYvRYT_S0uwsw@mail.gmail.com> (raw)
In-Reply-To: <60C611E0.5020908@gmail.com>
On Sun, Jun 13, 2021 at 4:00 PM Nikolai Zhubr <zhubr.2@gmail.com> wrote:
>
> 13.06.2021 1:41, Arnd Bergmann:
> > Or, to keep the change simpler, keep the inner loop in the tx
> > and rx processing, doing all rx events before moving on
> > to processing all tx events, but then looping back to try both
> > again, until either the budget runs out or no further events
> > are pending.
>
> Ok, made a new version: https://pastebin.com/3FUUrg7C
> It is much simpler and is very close to your patch now.
>
> All previous conditional defines are eliminated along with unnecessary
> code fragments, and here is TUNE8139_BIG_LOOP to introduce a top-level
> loop in poll function as you suggested above. But apparently it works
> well both with and without this loop. At least my testing did not show
> any substantial difference in performance. Therefore I think it could be
> completely removed for the sake of simplicity.
Ok, simpler is better in that case.
> One problem though is the kernel now always throws a traceback shortly
> after communication start:
> https://pastebin.com/VhwQ8wsU
> According to system.map it likely points to __local_bh_endble_ip() and
> there is one WARN_ON_ONCE() in it indeed, but I have no idea what it is
> and how to fix it.
There must be some call to spin_unlock_bh() or local_bh_enabled() or similar,
which is not allowed when interrupts are disabled with spin_lock_irqsave().
I don't see where exactly happens, but since nothing interesting is now
executed in hardirq context, I assume you can change tp->lock from
being called with _irq or _irqsave to using the _bh version that just
blocks the poll and start_xmit functions from happening, not the
hardirq.
> Yet another thing is that tp->rx_lock and tp->lock are now used within
> poll function in a way that possibly suggests one of them could be
> eliminated.
Agreed. I didn't want to change too much in my proposal, but I'm
sure these can be merged into a single lock, or possibly even
eliminated entirely.
Arnd
next prev parent reply other threads:[~2021-06-13 21:54 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-29 14:08 Realtek 8139 problem on 486 Nikolai Zhubr
2021-05-29 18:42 ` Heiner Kallweit
2021-05-29 21:44 ` tedheadster
2021-05-30 0:49 ` Nikolai Zhubr
2021-05-30 10:36 ` Nikolai Zhubr
2021-05-30 17:27 ` Nikolai Zhubr
2021-05-30 20:54 ` Arnd Bergmann
2021-05-30 23:17 ` Nikolai Zhubr
2021-05-31 16:53 ` Nikolai Zhubr
2021-05-31 18:39 ` Arnd Bergmann
2021-05-31 22:18 ` Nikolai Zhubr
2021-05-31 22:30 ` Heiner Kallweit
2021-06-01 7:20 ` Arnd Bergmann
2021-06-01 10:53 ` Nikolai Zhubr
2021-06-01 11:42 ` Heiner Kallweit
2021-06-01 16:09 ` Nikolai Zhubr
2021-06-01 21:48 ` Heiner Kallweit
2021-06-01 23:37 ` Nikolai Zhubr
2021-06-02 9:12 ` Arnd Bergmann
2021-06-07 23:07 ` Nikolai Zhubr
2021-06-08 7:44 ` Arnd Bergmann
2021-06-08 20:32 ` Nikolai Zhubr
2021-06-08 20:45 ` Arnd Bergmann
2021-06-08 22:07 ` Nikolai Zhubr
2021-06-09 7:09 ` Arnd Bergmann
2021-06-12 17:40 ` Nikolai Zhubr
2021-06-12 22:41 ` Arnd Bergmann
2021-06-13 14:10 ` Nikolai Zhubr
2021-06-13 21:52 ` Arnd Bergmann [this message]
2021-06-03 18:32 ` Maciej W. Rozycki
2021-06-04 7:36 ` Arnd Bergmann
2021-06-20 0:34 ` Thomas Gleixner
2021-06-20 10:19 ` Arnd Bergmann
2021-06-21 4:10 ` Maciej W. Rozycki
2021-06-21 11:22 ` Arnd Bergmann
2021-06-21 14:42 ` Maciej W. Rozycki
2021-06-21 15:20 ` Arnd Bergmann
2021-06-22 11:12 ` David Laight
2021-06-22 12:42 ` Nikolai Zhubr
2021-06-22 13:22 ` Arnd Bergmann
2021-06-22 18:42 ` Nikolai Zhubr
2021-06-22 19:26 ` Arnd Bergmann
2021-06-23 1:04 ` Maciej W. Rozycki
2021-06-24 17:56 ` Nikolai Zhubr
2021-06-24 18:25 ` Maciej W. Rozycki
2021-07-14 23:32 ` Maciej W. Rozycki
2021-07-15 7:32 ` Nikolai Zhubr
2021-07-16 23:48 ` Maciej W. Rozycki
2021-06-23 16:31 ` Nikolai Zhubr
2021-06-23 23:39 ` Maciej W. Rozycki
2021-06-24 8:28 ` Arnd Bergmann
2021-07-02 19:02 ` Nikolai Zhubr
2021-07-03 9:10 ` Arnd Bergmann
2021-07-08 19:21 ` Nikolai Zhubr
2021-07-09 7:31 ` Arnd Bergmann
2021-07-09 12:43 ` David Laight
2021-06-01 17:44 ` Maciej W. Rozycki
2021-06-02 15:14 ` Nikolai Zhubr
2021-06-02 15:28 ` Arnd Bergmann
2021-05-31 19:05 ` Heiner Kallweit
2021-05-31 18:29 ` Denis Kirjanov
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='CAK8P3a3W=njxgG-GzpW=XkcLjuo0-xsbzhZRcAYvRYT_S0uwsw@mail.gmail.com' \
--to=arnd@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=zhubr.2@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.