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