Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
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 <merker@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.
Reply to: