On Fri, Apr 3, 2020 at 4:47 AM Geert Uytterhoeven <[email protected]> wrote: > On Thu, Apr 2, 2020 at 7:27 PM John Stultz <[email protected]> wrote: > > On Thu, Apr 2, 2020 at 3:17 AM Yoshihiro Shimoda > > <[email protected]> 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. 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 -john _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
