Re: kern/51531 (Recent networking regression affecting installs)

[Jason Thorpe <thorpej%me.com@localhost>]

> On Sep 28, 2021, at 10:55 AM, Andreas Gustafsson <gson%gson.org@localhost> wrote:
> 
> 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