Messages in this thread Patch in this message | | | Subject | Re: Issue with RTL8111 NIC after upgrade to kernel 4.19 | From | Heiner Kallweit <> | Date | Thu, 22 Nov 2018 19:17:19 +0100 |
| |
On 22.11.2018 00:13, Marc Dionne wrote: > On Wed, Nov 21, 2018 at 6:28 PM Heiner Kallweit <hkallweit1@gmail.com> wrote: >> >> On 21.11.2018 22:53, Marc Dionne wrote: >>> On Wed, Nov 21, 2018 at 4:52 PM Heiner Kallweit <hkallweit1@gmail.com> wrote: >>>> >>>> On 21.11.2018 21:49, Heiner Kallweit wrote: >>>>> On 21.11.2018 21:32, Heiner Kallweit wrote: >>>>>> On 21.11.2018 21:20, Andrew Lunn wrote: >>>>>>>> request_module() is supposed to be synchronous, however after some >>>>>>>> reading this may not be 100% guaranteed. Maybe the module init >>>>>>>> function on some systems isn't finished yet when request_module() >>>>>>>> returns. As a result the genphy driver may be used instead of >>>>>>>> the PHY version-specific driver. >>>>>>> >>>>>>> Hi Heiner >>>>>>> >>>>>>> That would be true for all PHYs i think. We would of noticed this >>>>>>> problem with other systems using other PHY drivers. >>>>>>> >>>>>>> Andrew >>>>>>> >>>>>> It could be a timing issue affecting certain systems only. At least >>>>>> for now I don't have a good explanation why loading the module via >>>>>> request_module() and loading it upfront manually makes a difference. >>>>>> >>>>>> One affected user just reported the PHY to be a RTL8211B. This is >>>>>> what I expected, because this PHY crashes when writing to the MMD >>>>>> registers (the MMD registers are used otherwise by this PHY). >>>>>> See also commit 0231b1a074c6 ("net: phy: realtek: Use the dummy >>>>>> stubs for MMD register access for rtl8211b"). >>>>>> >>>>>> Let's see whether the other affected systems use the same PHY >>>>>> version. >>>>>> >>>>> Next report is also about a RTL8211B and as I assumed: >>>>> - W/o manually loading the realtek module the genphy driver is used >>>>> and network fails. >>>>> - W/ manually loading the realtek module the proper RTL8211B PHY >>>>> driver is used and network works. >>>>> >>>>> So it seems that even after request_module() the PHY driver isn't >>>>> yet available when device and driver are matched. >>>>> >>>>> If further reports support this (pre-)analysis, then indeed it >>>>> seems to be a timing issue and a proper fix most likely is >>>>> difficult. As a workaround I could imagine to add a delay loop >>>>> after request_module() checking for a Realtek PHY driver via >>>>> driver_find(). When adding one small delay after this we should >>>>> be sufficiently sure that all Realtek PHY drivers are registered. >>>>> >>>> Uups, no. We talk about phylib here, not about the r8169 driver. >>>> So we need a different solution. >>>> >>>>>> Heiner >>> >>> Thanks for the explanation, better than my crude attempt at >>> understanding what was going on. >>> >>> If you have any proposed fixes or diagnostic patches based on current >>> mainline I can quickly compile and test them here on an affected >>> system. It doesn't fail consistently for me (as others have >>> reported), but that could be because it depends on the timing. >>> >> >> Thanks for the offer. Can you try the following diagnostic patch >> and check whether it helps? >> >> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c >> index 55202a0ac..84f417f8b 100644 >> --- a/drivers/net/phy/phy_device.c >> +++ b/drivers/net/phy/phy_device.c >> @@ -607,6 +607,8 @@ struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int phy_id, >> */ >> request_module(MDIO_MODULE_PREFIX MDIO_ID_FMT, MDIO_ID_ARGS(phy_id)); >> >> + msleep(1000); >> + >> device_initialize(&mdiodev->dev); >> >> return dev; > > I was not able to get it to fail with that extra delay; hard to be > 100% sure but the network starts even when switching over from the > distro kernel after a boot where network failed to start. > 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) { > There's a side issue that network startup is taking a full minute > longer than it should, but that's possibly unrelated. > > Marc > Thanks, Heiner
| |