On Mon, Oct 27, 2014 at 11:54:47PM +0000, Ben Hutchings wrote: > On Tue, 2014-10-28 at 00:18 +0100, Cyril Brulebois wrote: > > Cc+=debian-kernel@ for input since I seem to recall having seen PHY > > drivers (including in a realtek context) being mentioned lately, at > > least on IRC, maybe on list as well. > > I don't understand this. > > > Karsten Merker <mer...@debian.org> (2014-10-27): > [...] > > > [ 73.104782] libphy: stmmac: probed > > > [ 73.104812] eth0: No PHY found > > > > > > i.e. the correct ethernet MAC driver (stmmac) gets loaded > > > automatically, but the necessary PHY driver (realtek) does not. > [...] > > > [ 499.392561] libphy: stmmac: probed > > > [ 499.392592] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active > > > [ 499.392604] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) > > > > > > and the ethernet interface works. The kernel version used in this > > > installer build is 3.16.5-1. > > $ modinfo -F alias realtek > mdio:???????????111001100100100010101 > mdio:???????????111001100100100010010 > > In hex those are 1cc915 and 1cc912. (The 11 most significant bits are > unspecified.) So modprobe certainly should find this module when > requested by phylib.
I have retried the installation today and tried something I had not done yesterday: just rmmod and directly afterwards modprobe the stmmac module. This results in the realtek PHY module getting auto-loaded, so the modprobe mechanism seems to work correctly there, but the question remains why this does not happen upon the first loading of the stmmac module. A protocol from d-i: "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." --> start shell ~ # lsmod Module Size Used by stmmac 73442 0 nls_utf8 1170 2 nls_cp437 4767 1 loop 16202 2 isofs 31318 1 vfat 9621 1 fat 52693 1 vfat ext4 485433 0 crc16 1146 1 ext4 mbcache 8210 1 ext4 jbd2 88199 1 ext4 sg 20824 0 sd_mod 38535 2 crc_t10dif 1041 1 sd_mod crct10dif_common 1159 1 crc_t10dif usb_storage 41751 1 ahci_sunxi 2652 0 libahci_platform 4679 1 ahci_sunxi libahci 23069 1 libahci_platform libata 161761 3 libahci,libahci_platform,ahci_sunxi ohci_platform 4062 0 ohci_hcd 37591 1 ohci_platform scsi_mod 175644 4 sg,usb_storage,libata,sd_mod ehci_platform 4526 0 phy_sun4i_usb 4216 4 ehci_hcd 64373 1 ehci_platform sunxi_mmc 10557 0 ~ # dmesg | tail -8 [ 31.558145] ISO 9660 Extensions: RRIP_1991A [ 77.839161] stmmaceth 1c50000.ethernet: no reset control found [ 77.839194] Ring mode enabled [ 77.839202] No HW DMA feature register supported [ 77.839210] Normal descriptors [ 77.839217] TX Checksum insertion supported [ 77.844560] libphy: stmmac: probed [ 77.844589] eth0: No PHY found ~ # rmmod stmmac ~ # modprobe stmmac ~ # dmesg | tail -8 [ 330.112850] stmmaceth 1c50000.ethernet: no reset control found [ 330.112883] Ring mode enabled [ 330.112891] No HW DMA feature register supported [ 330.112898] Normal descriptors [ 330.112905] TX Checksum insertion supported [ 330.140101] libphy: stmmac: probed [ 330.140139] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ 330.140150] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) ~ # lsmod Module Size Used by realtek 1563 0 stmmac 73442 0 nls_utf8 1170 2 nls_cp437 4767 1 loop 16202 2 isofs 31318 1 vfat 9621 1 fat 52693 1 vfat ext4 485433 0 crc16 1146 1 ext4 mbcache 8210 1 ext4 jbd2 88199 1 ext4 sg 20824 0 sd_mod 38535 2 crc_t10dif 1041 1 sd_mod crct10dif_common 1159 1 crc_t10dif usb_storage 41751 1 ahci_sunxi 2652 0 libahci_platform 4679 1 ahci_sunxi libahci 23069 1 libahci_platform libata 161761 3 libahci,libahci_platform,ahci_sunxi ohci_platform 4062 0 ohci_hcd 37591 1 ohci_platform scsi_mod 175644 4 sg,usb_storage,libata,sd_mod ehci_platform 4526 0 phy_sun4i_usb 4216 4 ehci_hcd 64373 1 ehci_platform sunxi_mmc 10557 0 > As udev is *not* involved in loading MDIO PHY drivers (NIC drivers > expect them to be bound synchronously) it isn't easy to monitor what's > going on. You could replace modprobe with a script that logs its > arguments to a file before calling the real modprobe. That should tell > us whether the bug is in the kernel or userland. I am currently short on time, but I will try that during the next days. 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
