From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiner Kallweit Subject: Re: Issue with RTL8111 NIC after upgrade to kernel 4.19 Date: Wed, 21 Nov 2018 23:28:21 +0100 Message-ID: References: <38dad61b-bc7f-7038-6d1b-f5c4afe3841c@gmail.com> <20181121202034.GA10697@lunn.ch> <6aeba3d6-2292-1221-9be7-1c0bb7cbc203@gmail.com> <7d6362e1-e197-d338-d6b0-9036c3802e2c@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: andrew@lunn.ch, norbert.jurkeit@web.de, nic_swsd@realtek.com, Florian Fainelli , David Miller , netdev , Linux Kernel Mailing List , michael.wiktowy@gmail.com, jcline@redhat.com To: Marc Dionne Return-path: Received: from mail-wm1-f66.google.com ([209.85.128.66]:53227 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731518AbeKVJEs (ORCPT ); Thu, 22 Nov 2018 04:04:48 -0500 In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 21.11.2018 22:53, Marc Dionne wrote: > On Wed, Nov 21, 2018 at 4:52 PM Heiner Kallweit 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; > Marc >