From: Arnd Bergmann <arnd@kernel.org>
To: Nikolai Zhubr <zhubr.2@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
netdev <netdev@vger.kernel.org>, Jeff Garzik <jgarzik@pobox.com>
Subject: Re: Realtek 8139 problem on 486.
Date: Wed, 2 Jun 2021 11:12:47 +0200 [thread overview]
Message-ID: <CAK8P3a0iwVpU_inEVH9mwkMkBxrxbGsXAfeR9_bOYBaNP4Wx5g@mail.gmail.com> (raw)
In-Reply-To: <60B6C4B2.1080704@gmail.com>
On Wed, Jun 2, 2021 at 1:27 AM Nikolai Zhubr <zhubr.2@gmail.com> wrote:
> 02.06.2021 0:48, Heiner Kallweit:
> > Driver 8139too has no maintainer.
>
> Ups, indeed. I just looked at the header and supposed it has. Sorry.
> (I do not touch kernel development much, usually)
It was apparently maintained by Jeff Garzik until 2007, but he already
considered
this driver outdated back then, and later stopped maintaining drivers
altogether.
> > who are paid by somebody to maintain all drivers in the kernel. That's not the case in general.
> > You provided valuable input, and if you'd contribute to improving 8139too and submit patches for
> > fixing the issue you're facing, this would be much appreciated.
>
> Ok, it is a bit more clear now.
> I'll do more testing/searching/reading and probably come up with
> something then.
I thought about the issue a bit more. The idea of the level interrupt
handler is that it
gets called again as long as any of the bits in 'IntrStatus' are set,
so the handler
can just read the register, write ack or mask the bits it sees and then process
the events it got. If another tx-complete even comes in before the end
of the handler,
it gets entered again and everything works.
If the irqchip is set to edge mode, this breaks down, and the loop can
work around
it by making it much more likely that all bits are cleared or masked at the
end of the handler, but there is no guarantee for this: If any
interrupt comes in
between reading the IntrStatus register and finishing the handler, you never get
an interrupt again.
I think the easiest workaround to address this reliably would be to move all
the irq processing into the poll function. This way the interrupt is completely
masked in the device until the poll handler finishes, and unmasking it
while there
are pending events would reliably trigger a new irq regardless of level or edge
mode. Something like the untested change at https://pastebin.com/MhBJDt6Z .
I don't know of other drivers that do it like this though, so I'm not
sure if this
causes a different set of problems.
Arnd
next prev parent reply other threads:[~2021-06-02 9:14 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 [this message]
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
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=CAK8P3a0iwVpU_inEVH9mwkMkBxrxbGsXAfeR9_bOYBaNP4Wx5g@mail.gmail.com \
--to=arnd@kernel.org \
--cc=hkallweit1@gmail.com \
--cc=jgarzik@pobox.com \
--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.