NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/51531 (Recent networking regression affecting installs)
The following reply was made to PR kern/51531; it has been noted by GNATS.
From: Jason Thorpe <thorpej%me.com@localhost>
To: Andreas Gustafsson <gson%gson.org@localhost>
Cc: kern-bug-people%netbsd.org@localhost,
gnats-admin%netbsd.org@localhost,
netbsd-bugs%netbsd.org@localhost,
gnats-bugs%netbsd.org@localhost
Subject: Re: kern/51531 (Recent networking regression affecting installs)
Date: Wed, 29 Sep 2021 14:33:41 -0700
> On Sep 28, 2021, at 10:55 AM, Andreas Gustafsson <gson%gson.org@localhost> =
wrote:
>=20
> To me this looks like sk(4) is failing to update the link state when
> it actually changes, and instead updating it much later at the point
> when "ifconfig -a" is run.
Ok, so I took a quick look and this looks like this is a logic bug in =
sk_tick().
Background: The MII layer uses mii_tick() to perform periodic link =
checks and send link status changes up the network stack. These are =
generally assumed to happen once per second (for example, the MII =
auto-negotiation logic counts "ticks", where a tick is assumed to be 1 =
second, to determine how often to re-initiate auto-negotiation if the =
link is down).
The "sk" driver is doing something different, and possibly being a =
little too clever (and certainly not working the way the MII layer =
assumes drivers work). It appears to be using an interrupt on one of =
the MAC's GPIO pins to determine if link status has changed, and then =
conditionally disables the 1-second periodic timer if it detects link. =
It also has some code that reads a GPIO pin and skips work if that pin =
reads back asserted.
It does something entirely different if the device has a Broadcom PHY =
(which your interface doesn't have; you have a Marvell "Alaska" PHY).
Anyway, I think it would probably work a lot better if it wasn't trying =
to be quite so clever around link change interrupts and the GPIO link =
status input. If it just called mii_tick() once per second like other =
drivers do, it would probably work just fine. But I don't have any =
manuals for these parts, nor generally much familiarity with them, so =
I'll let someone else who's done some actual work on the "sk" driver to =
chime in and take a deeper look.
-- thorpej
Home |
Main Index |
Thread Index |
Old Index