On 22.11.2018 20:29, Marc Dionne wrote: > On Thu, Nov 22, 2018 at 2:17 PM Heiner Kallweit <[email protected]> wrote: >> Thanks a lot for testing. Could you please test also the following >> as an alternative to the delay? >> >> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c >> index 55202a0ac..aeccb2323 100644 >> --- a/drivers/net/phy/phy_device.c >> +++ b/drivers/net/phy/phy_device.c >> @@ -2254,6 +2254,7 @@ int phy_driver_register(struct phy_driver *new_driver, >> struct module *owner) >> new_driver->mdiodrv.driver.probe = phy_probe; >> new_driver->mdiodrv.driver.remove = phy_remove; >> new_driver->mdiodrv.driver.owner = owner; >> + new_driver->mdiodrv.driver.probe_type = PROBE_FORCE_SYNCHRONOUS; >> >> retval = driver_register(&new_driver->mdiodrv.driver); >> if (retval) { > > That also gets me network reliably, switching between a kernel where > it fails (distro 4.19 kernel) and the custom kernel with the patch. > Thanks again for the very quick response. The result is good and bad news at once: good because it seems we have a fix, bad because we don't understand the root cause of the issue yet.
>>> There's a side issue that network startup is taking a full minute >>> longer than it should, but that's possibly unrelated. > > BTW that's an unrelated rng issue, for which I have a workaround. > Indeed totally unrelated, but sounds familiar. I had the same issue on a headless system which therefore generates very little entropy. I fixed it by setting CONFIG_RANDOM_TRUST_CPU=y >>> >> Thanks, Heiner > > Marc > Heiner
