Hello all!
I noticed that on a pine64-pro board running aarch64 Fedora 32, ethernet is broken with the latest set of patches installed through dfn update. To reproduce:
1. Download the latest Fedora-Minimal-32-1.6.aarch64.raw.xz image from the Fedora alternate architectures page 2. Flash the image to an SD card using 'arm-image-installer --image=Fedora-Minimal-32-1.6.aarch64.raw.xz --media=[sd card here] --target=pine64_plus' 3. Boot the pine64-pro board from the SD card like usual, set up new account, etc. 4. At this point, ethernet should work. Run 'dnf update', install latest patches, reboot 5. Upon reboot, ethernet no longer works
Has anyone else run into this or have some possible hints?
Thanks!
-Karl
Is there anything odd looking in dmesg / maybe something missing ?. You might join the pine64 IRC channel also the pinebook pro channel is super active.
HTH
On Sat, Oct 24, 2020 at 4:38 PM Karl Li karl@omjii.com wrote:
Hello all!
I noticed that on a pine64-pro board running aarch64 Fedora 32, ethernet is broken with the latest set of patches installed through dfn update. To reproduce:
- Download the latest Fedora-Minimal-32-1.6.aarch64.raw.xz image from the Fedora alternate architectures page
- Flash the image to an SD card using 'arm-image-installer --image=Fedora-Minimal-32-1.6.aarch64.raw.xz --media=[sd card here] --target=pine64_plus'
- Boot the pine64-pro board from the SD card like usual, set up new account, etc.
- At this point, ethernet should work. Run 'dnf update', install latest patches, reboot
- Upon reboot, ethernet no longer works
Has anyone else run into this or have some possible hints?
Thanks!
-Karl _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Here is the output of 'dmesg | grep ethernet'. I'm not sure what any of this means:
dwmac-sun8i lc300000.ethernet: IRQ eth_wake_irq not found dwmac-sun8i lc300000.ethernet: IRQ eth_lpi not found dwmac-sun8i lc300000.ethernet: PTP uses main clock dwmac-sun8i lc300000.ethernet: Current syscon value is not the default 6 (expect 0) dwmac-sun8i lc300000.ethernet: No HW DMA feature register supported dwmac-sun8i lc300000.ethernet: RX Checksum Offload engine supported dwmac-sun8i lc300000.ethernet: COE Type 2 dwmac-sun8i lc300000.ethernet: TX Checksum insertion supported dwmac-sun8i lc300000.ethernet: Normal descriptors dwmac-sun8i lc300000.ethernet: Chain mode enabled dwmac-sun8i lc300000.ethernet etho0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL) dwmac-sun8i lc300000.ethernet etho0: No Safety Features support found dwmac-sun8i lc300000.ethernet etho0: No MAC Management Counters available dwmac-sun8i lc300000.ethernet etho0: PTP not suppoted by HW dwmac-sun8i lc300000.ethernet etho0: configuring for phy/rgmii link mode dwmac-sun8i lc300000.ethernet etho0: Link is Up - 1Gbps/Full - flow control rx/tx
I did a bit more experimenting and found that the ethernet problem only happens with kernel version 5.8.16-200.fc32.aarach64. On 5.8.16-200, if I run nmcli device, for eth0 I get something like "Getting IP Configuration", and it just gets stuck there until it eventually fails after some time. If I revert to kernel version 5.6.6-300.fc32.aarch64, everything works fine. The dmesg output is the same between the two kernel versions.
On Sun, Oct 25, 2020 at 09:46:43PM -0000, Karl Li wrote:
Here is the output of 'dmesg | grep ethernet'. I'm not sure what any of this means:
dwmac-sun8i lc300000.ethernet: IRQ eth_wake_irq not found dwmac-sun8i lc300000.ethernet: IRQ eth_lpi not found dwmac-sun8i lc300000.ethernet: PTP uses main clock dwmac-sun8i lc300000.ethernet: Current syscon value is not the default 6 (expect 0) dwmac-sun8i lc300000.ethernet: No HW DMA feature register supported dwmac-sun8i lc300000.ethernet: RX Checksum Offload engine supported dwmac-sun8i lc300000.ethernet: COE Type 2 dwmac-sun8i lc300000.ethernet: TX Checksum insertion supported dwmac-sun8i lc300000.ethernet: Normal descriptors dwmac-sun8i lc300000.ethernet: Chain mode enabled dwmac-sun8i lc300000.ethernet etho0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL) dwmac-sun8i lc300000.ethernet etho0: No Safety Features support found dwmac-sun8i lc300000.ethernet etho0: No MAC Management Counters available dwmac-sun8i lc300000.ethernet etho0: PTP not suppoted by HW dwmac-sun8i lc300000.ethernet etho0: configuring for phy/rgmii link mode dwmac-sun8i lc300000.ethernet etho0: Link is Up - 1Gbps/Full - flow control rx/tx
I did a bit more experimenting and found that the ethernet problem only happens with kernel version 5.8.16-200.fc32.aarach64. On 5.8.16-200, if I run nmcli device, for eth0 I get something like "Getting IP Configuration", and it just gets stuck there until it eventually fails after some time. If I revert to kernel version 5.6.6-300.fc32.aarch64, everything works fine. The dmesg output is the same between the two kernel versions.
Could this be similar / the same as
https://bugzilla.redhat.com/show_bug.cgi?id=1889090
?
On Sat, Oct 24, 2020 at 9:38 PM Karl Li karl@omjii.com wrote:
Hello all!
I noticed that on a pine64-pro board running aarch64 Fedora 32, ethernet is broken with the latest set of patches installed through dfn update. To reproduce:
- Download the latest Fedora-Minimal-32-1.6.aarch64.raw.xz image from the Fedora alternate architectures page
- Flash the image to an SD card using 'arm-image-installer --image=Fedora-Minimal-32-1.6.aarch64.raw.xz --media=[sd card here] --target=pine64_plus'
- Boot the pine64-pro board from the SD card like usual, set up new account, etc.
Do you mean Pine64+ board? There's no pine64 pro that I'm aware of. It's the board based on the Allwinner a64 SoC?
- At this point, ethernet should work. Run 'dnf update', install latest patches, reboot
- Upon reboot, ethernet no longer works
Has anyone else run into this or have some possible hints?
If it's the Pine64+ I think it's due to the following upstream fix for the realtek phy, which in turn looks like it's uncovered a bunch of issues that were obstructed by the first bug.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
Sorry, yes, it is in fact the Pine64+ board; don't know why I brainfarted and called it Pine64 Pro (multiple times!)
Good to know that this is a known issue; I'll sit tight and stay on 5.6.6-300 until things clear up in a later kernel. :)
On Mon, Oct 26, 2020 at 7:47 PM Karl Li karl@omjii.com wrote:
Sorry, yes, it is in fact the Pine64+ board; don't know why I brainfarted and called it Pine64 Pro (multiple times!)
Good to know that this is a known issue; I'll sit tight and stay on 5.6.6-300 until things clear up in a later kernel. :)
Why not the 5.8.14 that's reported to work?
-
Jan Pazdziora -
Karl Li -
Nigel Sollars -
Peter Robinson