Hi John, Geert, > From: John Stultz, Sent: Saturday, April 4, 2020 1:19 PM > > On Fri, Apr 3, 2020 at 4:47 AM Geert Uytterhoeven <ge...@linux-m68k.org> > wrote: > > On Thu, Apr 2, 2020 at 7:27 PM John Stultz <john.stu...@linaro.org> wrote: > > > On Thu, Apr 2, 2020 at 3:17 AM Yoshihiro Shimoda > > > <yoshihiro.shimoda...@renesas.com> wrote: > > > > > > > > I found an issue after applied the following patches: > > > > --- > > > > 64c775f driver core: Rename deferred_probe_timeout and make it global > > > > 0e9f8d0 driver core: Remove driver_deferred_probe_check_state_continue() > > > > bec6c0e pinctrl: Remove use of > > > > driver_deferred_probe_check_state_continue() > > > > e2cec7d driver core: Set deferred_probe_timeout to a longer default if > > > > CONFIG_MODULES is set > > > > Note that just setting deferred_probe_timeout = -1 like for the > > CONFIG_MODULES=n case doesn't help. > > Yea. I can see why in that case, as we're checking > !IS_ENABLED(CONFIG_MODULES) directly in > driver_deferred_probe_check_state. > > I guess we could switch that to checking > (driver_deferred_probe_timeout == -1) which would have the same logic > and at least make it consistent if someone specifies -1 on the command > line (since now it will effectively have it EPROBE_DEFER forever in > that case). But also having a timeout=infinity could be useful if > folks don't want the deferring to time out. Maybe in the !modules > case setting it to =0 would be the most clear. > > But that's sort of a further cleanup. I'm still more worried about the > NFS failure below. > > > > > Hey, > > > Terribly sorry for the trouble. So as Robin mentioned I have a patch > > > to remove the WARN messages, but I'm a bit more concerned about why > > > after the 30 second delay, the ethernet driver loads: > > > [ 36.218666] ravb e6800000.ethernet eth0: Base address at > > > 0xe6800000, 2e:09:0a:02:eb:2d, IRQ 117. > > > but NFS fails. > > > > > > Is it just that the 30 second delay is too long and NFS gives up? > > > > I added some debug code to mount_nfs_root(), which shows that the first > > 3 tries happen before ravb is instantiated, and the last 3 tries happen > > after. So NFS root should work, if the network works. > > > > However, it seems the Ethernet PHY is never initialized, hence the link > > never becomes ready. Dmesg before/after: > > > > ravb e6800000.ethernet eth0: Base address at 0xe6800000, > > 2e:09:0a:02:ea:ff, IRQ 108. > > > > Good. > > > > ... > > -gpio_rcar e6052000.gpio: sense irq = 11, type = 8 > > > > This is the GPIO the PHY IRQ is connected to. > > Note that that GPIO controller has been instantiated before. > > > > ... > > -Micrel KSZ9031 Gigabit PHY e6800000.ethernet-ffffffff:00: > > attached PHY driver [Micrel KSZ9031 Gigabit PHY] > > (mii_bus:phy_addr=e6800000.ethernet-ffffffff:00, irq=197) > > ... > > -ravb e6800000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off > > > > Oops. > > > > -Sending DHCP requests .., OK > > -IP-Config: Got DHCP answer from ... > > ... > > +VFS: Unable to mount root fs via NFS, trying floppy. > > +VFS: Cannot open root device "nfs" or unknown-block(2,0): error -6 > > > > > Does booting with deferred_probe_timeout=0 work? > > > > It does, as now everything using optional links (DMA and IOMMU) is now > > instantiated on first try. > > Thanks so much for helping clarify this! > > So it's at least good to hear that booting with > deferred_probe_timeout=0 is working! But I'm bummed the NFS (or as > you pointed out in your later mail, ip_auto_config) falls over > because the network isn't immediately there. > > Looking a little closer at the ip_auto_config() code, I think the > issue may be that wait_for_device_probe() is effectively returning too > early, since the probe_defer_timeout is still active? I need to dig a > bit more on that code, on Monday, as I don't fully understand it yet.
I think so. I also investigated this issue more and then the following patch seems to be related because return value is changed a bit. c8c43ce driver core: Fix driver_deferred_probe_check_state() logic # By the way, this is other topic though, IIUC we should revise # the deferred_probe_timeout= in Documentation/admin-guide/kernel-parameters.txt # for the commit c8c43ce. Especially " A timeout of 0 will timeout at the end of initcalls." # doesn't match after we applied the commit. I'm guessing we should add the following flush_work for deferred_probe_timeout_work(). # Sorry, I didn't test this for some reasons yet though... + /* wait for the deferred probe timeout workqueue to finish */ + if (driver_deferred_probe_timeout > 0) + flush_work(&deferred_probe_timeout_work); > If I can't find a way to address that, I think the best course will be > to set the driver_deferred_probe_timeout value to default to 0 > regardless of the value of CONFIG_MODULES, so we don't cause any > apparent regression from previous behavior. That will also sort out > the less intuitive = -1 initialization in the non-modules case. > > In any case, I'll try to have a patch to send out on Monday. Thanks! Best regards, Yoshihiro Shimoda > thanks > -john _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu