On Mon, Nov 03, 2014 at 12:26:33AM +0000, Ben Hutchings wrote: > On Sun, 2014-11-02 at 21:43 +0100, Karsten Merker wrote: > [...] > > Following is the log from a d-i run where /sbin/modprobe and > > /sbin/insmod have been replaced by a script that logs all > > invocations of these two binaries with a "modules-debug" prefix > > before executing the original binary: > [...] > > The entry at 00:03:37 does not show a modprobe invocation before > > the initialization of the stmmac module, so the module does not > > seem to be loaded by calling modprobe, which would explain why no > > autoloading of the PHY driver happens there. What I do not > > understand is that I also see no insmod invocation, and logging > > insmod invocations works when I run insmod from a shell. So the > > question remains: how is the stmmac module loaded at that point? > > I first thought that something might invoke kmod directly (i.e. > > not by calling the insmod/modprobe aliases), but logging direct > > kmod invocations also shows nothing, so I am probably overlooking > > something. > > > > Any ideas? > > So far as I can see, ethdetect runs hw-detect, which runs update-dev, > which runs 'udevadm trigger --action=add --subsystem-nomatch=sound' and > that should result in udev loading stmmac. (udev won't have done that > when it started because the stmmac module wasn't included in the > initramfs.) > > udev is now linked with libkmod, so it can load modules without running > modprobe, and most driver modules get loaded that way. But as I said > before, this isn't the case for the PHY driver modules. > > So, I think this shows the kernel is not running modprobe for some > reason.
Things are getting even stranger: I have run further installation tests with today's current d-i images (still based on the same 3.16.5-1 kernel) - http://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz dated 04-Nov-2014 05:16 and - http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/debian-testing-armhf-CD-1.jigdo dated 2014-11-03 12:14) on a Cubietruck and on the BananaPi. On the Cubietruck everything works while on the BananaPi the PHY is not found. Both are booted from the same USB stick, so there cannot be any differences in the installer image. The hardware on both is rather similar (Allwinner A20 SoC with integrated MAC, external Realtek PHY) and they show the same PHY ID once the probing was successful, so I assume that they use identical PHY chips: Cubietruck: ----------- Jan 1 00:06:47 main-menu[179]: INFO: Menu item 'ethdetect' selected Jan 1 00:06:48 kernel: [ 78.983839] cfg80211: Calling CRDA to update world regulatory domain Jan 1 00:06:49 kernel: [ 78.998759] brcmfmac_sdio mmc1:0001:1: firmware: failed to load brcm/brcmfmac43362-sdio.bin (-2) Jan 1 00:06:49 kernel: [ 79.057067] stmmaceth 1c50000.ethernet: no regulator found Jan 1 00:06:49 kernel: [ 79.057202] stmmaceth 1c50000.ethernet: no reset control found Jan 1 00:06:49 kernel: [ 79.057218] Ring mode enabled Jan 1 00:06:49 kernel: [ 79.057226] No HW DMA feature register supported Jan 1 00:06:49 kernel: [ 79.057233] Normal descriptors Jan 1 00:06:49 kernel: [ 79.057241] TX Checksum insertion supported Jan 1 00:06:49 kernel: [ 79.171058] libphy: stmmac: probed Jan 1 00:06:49 kernel: [ 79.171089] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active Jan 1 00:06:49 kernel: [ 79.171100] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) BananaPi: --------- No Ethernet card was detected. If you know the name of the driver needed by your Ethernet card, you can select it from the list. --> shell ~ # lsmod |grep realtek ~ # dmesg | tail -8 [ 32.138512] ISO 9660 Extensions: RRIP_1991A [ 77.235117] stmmaceth 1c50000.ethernet: no reset control found [ 77.235192] Ring mode enabled [ 77.235202] No HW DMA feature register supported [ 77.235211] Normal descriptors [ 77.235219] TX Checksum insertion supported [ 77.242678] libphy: stmmac: probed [ 77.242708] eth0: No PHY found ~ # rmmod stmmac ~ # modprobe stmmac ~ # lsmod |grep realtek realtek 1563 0 ~ # dmesg | tail -8 [ 148.823456] stmmaceth 1c50000.ethernet: no reset control found [ 148.823487] Ring mode enabled [ 148.823496] No HW DMA feature register supported [ 148.823502] Normal descriptors [ 148.823509] TX Checksum insertion supported [ 148.854654] libphy: stmmac: probed [ 148.854683] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ 148.854694] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) ~ # The main visible difference between the two systems is that the Cubietruck also has a Broadcom 43362 SDIO Wifi module and d-i asks for the non-free firmware for it before the stmmac gets initialized, but I do not see how that should make a difference regarding the realtek PHY driver. What makes me wonder is the line stmmaceth 1c50000.ethernet: no regulator found on the Cubietruck that does not appear on the BananaPi. Could there perhaps be some regulator/voltage supply issue with the PHY so that the PHY is not fully powered up upon the first probing but later on? The dts shows different setups for the PHY power supply between the two systems: BananaPi: --------- gmac: ethernet@01c50000 { pinctrl-names = "default"; pinctrl-0 = <&gmac_pins_rgmii_a>; phy = <&phy1>; phy-mode = "rgmii"; phy-supply = <®_gmac_3v3>; status = "okay"; phy1: ethernet-phy@1 { reg = <1>; }; } reg_gmac_3v3: gmac-3v3 { compatible = "regulator-fixed"; pinctrl-names = "default"; pinctrl-0 = <&gmac_power_pin_bananapi>; regulator-name = "gmac-3v3"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; startup-delay-us = <50000>; enable-active-high; gpio = <&pio 7 23 0>; }; Cubietruck: ----------- gmac: ethernet@01c50000 { pinctrl-names = "default"; pinctrl-0 = <&gmac_pins_rgmii_a>; phy = <&phy1>; phy-mode = "rgmii"; status = "okay"; phy1: ethernet-phy@1 { reg = <1>; }; }; i.e. the PHY appears to have a seperate regulator on the BananaPi but not on the Cubietruck and I wonder whether the startup-delay-us = <50000>; might play a role here. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
