Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
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. Karsten Merker (2014-10-27): > Package: installation-reports > > Boot method: hd-media (installer booted from USB stick) > Image version: > http://d-i.debian.org/daily-images/armhf/daily/hd-media/hd-media.tar.gz > (dated 27-Oct-2014 05:17) together with > > http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/debian-testing-armhf-CD-1.jigdo > (dated 2014-10-27 11:58) > Date: 2014-10-27 > U-Boot: 2014.10+dfsg1-1 > > Machine: LeMaker Banana Pi > Processor: Allwinner A20 (2x Cortex A7) > Memory: 1GB > Mass Storage: 16GB SD card > > Base System Installation Checklist: > [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it > > Initial boot: [O] > Detect network card:[E] (see comments below, getting this to work > requires manual loading of the proper > ethernet PHY driver module) > Configure network: [O] > Detect CD: [O] > Load installer modules: [O] > Detect hard drives: [O] > Partition hard drives: [O] > Install base system:[O] > Clock/timezone setup: [O] > User/password setup:[O] > Install tasks: [O] > Install boot loader:[O] > Overall install:[O] > > Comments/Problems: > The "detect network hardware" step fails with > "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." > > dmesg shows: > [ 73.100072] stmmaceth 1c5.ethernet: no reset control found > [ 73.100103] Ring mode enabled > [ 73.100112] No HW DMA feature register supported > [ 73.100120] Normal descriptors > [ 73.100127] TX Checksum insertion supported > [ 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. > Loading the realtek module after the stmmac driver has probed > for a PHY does not change anything; the stmmac driver does not > re-probe for a PHY upon later loading of the PHY driver. > Manually unloading the stmmac module, loading the PHY driver > and then loading the stmmac module again from a shell by > running > > ~ # rmmod stmmac > ~ # modprobe realtek > ~ # modprobe stmmac > > results in > > [ 499.364044] stmmaceth 1c5.ethernet: no reset control found > [ 499.364076] Ring mode enabled > [ 499.364084] No HW DMA feature register supported > [ 499.364090] Normal descriptors > [ 499.364097] TX Checksum insertion supported > [ 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. > > Regards, > Karsten Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
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 (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. 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. Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part
Re: 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 +, 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 (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_utf81170 2 nls_cp437 4767 1 loop 16202 2 isofs 31318 1 vfat9621 1 fat52693 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_common1159 1 crc_t10dif usb_storage41751 1 ahci_sunxi 2652 0 libahci_platform4679 1 ahci_sunxi libahci23069 1 libahci_platform libata161761 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 1c5.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 1c5.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_utf81170 2 nls_cp437 4767 1 loop 16202 2 isofs 31318 1 vfat9621 1 fat52693 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_common1159 1 crc_t10dif usb_storage41751 1 ahci_sunxi 2652 0 libahci_platform4679 1 ahci_sunxi libahci23069 1 libahci_platform libata161761 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 callin
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Tue, Oct 28, 2014 at 11:14:40PM +0100, Karsten Merker wrote: > On Mon, Oct 27, 2014 at 11:54:47PM +, Ben Hutchings wrote: > > I don't understand this. > > > > > Karsten Merker (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_utf81170 2 > nls_cp437 4767 1 > loop 16202 2 > isofs 31318 1 > vfat9621 1 > fat52693 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_common1159 1 crc_t10dif > usb_storage41751 1 > ahci_sunxi 2652 0 > libahci_platform4679 1 ahci_sunxi > libahci23069 1 libahci_platform > libata161761 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 1c5.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 1c5.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_utf81170 2 > nls_cp437 4767 1 > loop 16202 2 > isofs 31318 1 > vfat9621 1 > fat52693 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_common1159 1 crc_t10dif > usb_storage41751 1 > ahci_sunxi 2652 0 > libahci_platform4679 1 ahci_sunxi > libahci23069 1 libahci_platform > libata161761 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
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
Control: reassign -1 src:linux 3.16.5-1 Control: retitle -1 Linux 3.16 failing to run modprobe for libphy during installation Control: tag -1 d-i 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. I'm not sure how best to investigate further. You could add more logging to the kernel (in kernel/kmod.c) and then rebuild the installer. Possibly you could use systemtap for this, but it will be difficult to install the necessary packages within the installation environment. Ben. -- Ben Hutchings A free society is one where it is safe to be unpopular. - Adlai Stevenson signature.asc Description: This is a digitally signed message part
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Mon, 2014-11-03 at 00:26 +, Ben Hutchings wrote: [...] > I'm not sure how best to investigate further. You could add more > logging to the kernel (in kernel/kmod.c) and then rebuild the installer. > Possibly you could use systemtap for this, but it will be difficult to > install the necessary packages within the installation environment. Oh, also we don't build debug info for the armhf kernels (we should probably change that). Ben. -- Ben Hutchings Power corrupts. Absolute power is kind of neat. - John Lehman, Secretary of the US Navy 1981-1987 signature.asc Description: This is a digitally signed message part
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Mon, Nov 03, 2014 at 12:26:33AM +, 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 1c5.ethernet: no regulator found Jan 1 00:06:49 kernel: [ 79.057202] stmmaceth 1c5.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 1c5.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 1c5.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 1c5.ethernet: no regulator found on the Cubietruck that does not app
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Tue, 2014-11-04 at 22:37 +0100, Karsten Merker wrote: > I have run further installation tests with today's current d-i images > (still based on the same 3.16.5-1 kernel) OOI if you bodge your way through the install does the resulting system boot and discover the PHY reliably? IOW is it specific to d-i or not? > 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 = <5>; > > might play a role here. I think that's a decent theory. Decent enoguh that it is probably worth taking it up with the sunxi kernel folks. Might also be the power supply differs between the two boards? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415184312.11486.79.ca...@hellion.org.uk
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Wed, Nov 05, 2014 at 10:45:12AM +, Ian Campbell wrote: > On Tue, 2014-11-04 at 22:37 +0100, Karsten Merker wrote: > > > I have run further installation tests with today's current d-i images > > (still based on the same 3.16.5-1 kernel) > > OOI if you bodge your way through the install does the resulting system > boot and discover the PHY reliably? IOW is it specific to d-i or not? Ethernet works in the installed system (tested with several cold and warm boots): [2.448442] stmmaceth 1c5.ethernet: no reset control found [2.454322] Ring mode enabled [2.457396] No HW DMA feature register supported [2.461941] Normal descriptors [2.465279] TX Checksum insertion supported [2.495563] libphy: stmmac: probed [2.499078] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [2.505490] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) > > 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 = <5>; > > > > might play a role here. > > I think that's a decent theory. Decent enoguh that it is probably worth > taking it up with the sunxi kernel folks. > > Might also be the power supply differs between the two boards? Running the BananaPi with the Cubietruck's power supply does not change the behaviour. I have now run several tests with a modified BananaPi dtb in which I have added a "regulator-always-on" stanza to the reg_gmac_3v3 definition. With this change the PHY detection in d-i has worked every time, so this would support the theory that the regulator might not be powered up fast enough for the PHY detection to succeed, but I cannot see why this problem only occurs within the d-i environment. 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-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141105200107.ga4...@excalibur.cnev.de
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Wed, Nov 05, 2014 at 09:01:08PM +0100, Karsten Merker wrote: [Failing ethernet PHY detection in d-i on the BananaPi] > I have now run several tests with a modified BananaPi dtb in > which I have added a "regulator-always-on" stanza to the > reg_gmac_3v3 definition. With this change the PHY detection in > d-i has worked every time, so this would support the theory that > the regulator might not be powered up fast enough for the PHY > detection to succeed, but I cannot see why this problem only > occurs within the d-i environment. Further experiments show that increasing the "startup-delay-us" value in the regulator definition seems to solve the issue. I'll do some further experiments to determine a value that is long enough for a reliable detection without being unnecessary long and discuss the issue with the upstream author. 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-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141105205240.gb4...@excalibur.cnev.de
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
Control: tag -1 patch On Wed, Nov 05, 2014 at 09:52:40PM +0100, Karsten Merker wrote: > [Failing ethernet PHY detection in d-i on the BananaPi] > Further experiments show that increasing the "startup-delay-us" > value in the regulator definition seems to solve the issue. I'll > do some further experiments to determine a value that is long > enough for a reliable detection without being unnecessary long > and discuss the issue with the upstream author. A patch to solve the issue has been accepted upstream (see https://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/301727.html). Attached is a backport of this patch for inclusion into the upcoming linux 3.16.7-3 package. 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. Index: debian/patches/features/arm/dts-sunxi-Banana-Pi-increase-startup-delay-for-the-GMAC-PHY-regulator.patch === --- debian/patches/features/arm/dts-sunxi-Banana-Pi-increase-startup-delay-for-the-GMAC-PHY-regulator.patch (Revision 0) +++ debian/patches/features/arm/dts-sunxi-Banana-Pi-increase-startup-delay-for-the-GMAC-PHY-regulator.patch (Arbeitskopie) @@ -0,0 +1,35 @@ +From f82f99afaa65fd28d0f8409c50e8fcc65ee5e15b Mon Sep 17 00:00:00 2001 +From: Karsten Merker +Date: Wed, 12 Nov 2014 00:01:46 +0100 +Subject: ARM: dts: sunxi: Banana Pi: increase startup-delay for the GMAC PHY regulator +Origin: https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/commit/?h=sunxi/dt-for-3.19&id=f82f99afaa65fd28d0f8409c50e8fcc65ee5e15b + +On the LeMaker Banana Pi, probing the external ethernet PHY connected +to the SoC's internal GMAC module sometimes fails. The PHY power +supply is handled via a GPIO-controlled regulator, and the existing +regulator startup-delay of 5us is too short to make sure that the +PHY is always fully powered up when it is queried by phylib. Tests +have shown that to provide a reliable PHY detection, the startup-delay +has to be increased to at least 6us. To have a certain safety margin +and to cater for manufacturing variations between different boards, +the delay gets set to 10us as discussed on the linux-arm-kernel +mailinglist. + +Signed-off-by: Karsten Merker +Acked-by: Hans de Goede +Signed-off-by: Maxime Ripard + +diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts +index 3de847d..1cf1214 100644 +--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts +@@ -207,7 +207,7 @@ + regulator-name = "gmac-3v3"; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; +- startup-delay-us = <5>; ++ startup-delay-us = <10>; + enable-active-high; + gpio = <&pio 7 23 0>; + }; + Index: debian/patches/series === --- debian/patches/series (Revision 22061) +++ debian/patches/series (Arbeitskopie) @@ -113,6 +113,7 @@ features/arm/dts-sun7i-Add-spi0_pins_a-pinctrl-setting.patch features/arm/dts-sun7i-Add-uart3_pins_b-pinctrl-setting.patch features/arm/dts-sun7i-Add-Banana-Pi-board.patch +features/arm/dts-sunxi-Banana-Pi-increase-startup-delay-for-the-GMAC-PHY-regulator.patch features/arm/dts-sun7i-Add-support-for-Olimex-A20-OLinuXino-LIME.patch features/arm64/drivers-net-Add-APM-X-Gene-SoC-ethernet-driver-suppo.patch features/arm64/drivers-net-NET_XGENE-should-depend-on-HAS_DMA.patch
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Thu, 2014-11-13 at 07:56 +0100, Karsten Merker wrote: > Control: tag -1 patch > > On Wed, Nov 05, 2014 at 09:52:40PM +0100, Karsten Merker wrote: > > > [Failing ethernet PHY detection in d-i on the BananaPi] > > > Further experiments show that increasing the "startup-delay-us" > > value in the regulator definition seems to solve the issue. I'll > > do some further experiments to determine a value that is long > > enough for a reliable detection without being unnecessary long > > and discuss the issue with the upstream author. > > A patch to solve the issue has been accepted upstream (see > https://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/301727.html). > Attached is a backport of this patch for inclusion into the > upcoming linux 3.16.7-3 package. Thanks, I'll apply this shortly. Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415904878.31613.27.ca...@hellion.org.uk
Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
On Thu, 2014-11-13 at 18:54 +, Ian Campbell wrote: > > A patch to solve the issue has been accepted upstream (see > > https://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/301727.html). > > Attached is a backport of this patch for inclusion into the > > upcoming linux 3.16.7-3 package. > > Thanks, I'll apply this shortly. Done. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415915252.31613.30.ca...@hellion.org.uk
Processed: Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
Processing control commands: > reassign -1 src:linux 3.16.5-1 Bug #767042 [installation-reports] [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module Bug reassigned from package 'installation-reports' to 'src:linux'. Ignoring request to alter found versions of bug #767042 to the same values previously set Ignoring request to alter fixed versions of bug #767042 to the same values previously set Bug #767042 [src:linux] [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module Marked as found in versions linux/3.16.5-1. > retitle -1 Linux 3.16 failing to run modprobe for libphy during installation Bug #767042 [src:linux] [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module Changed Bug title to 'Linux 3.16 failing to run modprobe for libphy during installation' from '[jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module' > tag -1 d-i Bug #767042 [src:linux] Linux 3.16 failing to run modprobe for libphy during installation Added tag(s) d-i. -- 767042: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767042 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b767042.141497440923478.transcr...@bugs.debian.org
Processed: Re: Bug#767042: [jessie daily 2014-10-27] [armhf] Installation report: LeMaker Banana Pi - problems with autoloading the realtek ethernet PHY driver module
Processing control commands: > tag -1 patch Bug #767042 [src:linux] Linux 3.16 failing to run modprobe for libphy during installation Added tag(s) patch. -- 767042: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767042 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b767042.1415861800949.transcr...@bugs.debian.org
