Messages in this thread | | | From | Marc Dionne <> | Date | Wed, 21 Nov 2018 19:13:31 -0400 | Subject | Re: Issue with RTL8111 NIC after upgrade to kernel 4.19 |
| |
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.
There's a side issue that network startup is taking a full minute longer than it should, but that's possibly unrelated.
Marc
| |