Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no ethernet hotplug on Raspberry Pi 3B with current raspios #4393

Open
jrfromfl opened this issue Jun 14, 2021 · 10 comments
Open

no ethernet hotplug on Raspberry Pi 3B with current raspios #4393

jrfromfl opened this issue Jun 14, 2021 · 10 comments

Comments

@jrfromfl
Copy link

Describe the bug
after booting the newest version of raspios (May 7th,2021) with a Pi3B without ethernet connection I can't connect to a local network via ETH anymore. Plugging in the ethernet cable will leave the LEDs on the plug dark, /sys/class/net/$interface/carrier=0.
Booting the same sd-card with a Pi4B works fine.

To reproduce
copy iso to sd card and boot with a Pi3B without plugged ethernet cable, than connect cable (switch/dhcp srv)

Expected behaviour
LEDs on eth plug start blinking, ip addr show lists a ip addr on ethernet interface, link is UP

Actual behaviour
LEDs stay dark, ip link show lists ethernet interface as DOWN, no ip addr

System
System Information

Raspberry Pi 3 Model B Rev 1.2
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"

Raspberry Pi reference 2021-05-07
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, dcfd74d7d1fa293065ac6d565711e9ff891fe2b8, stage2

Linux raspberrypi 5.10.17-v7+ #1414 SMP Fri Apr 30 13:18:35 BST 2021 armv7l GNU/Linux
Revision : a02082
Serial : 000000008bd985a3
Model : Raspberry Pi 3 Model B Rev 1.2
Throttled flag : throttled=0x0
Camera : supported=0 detected=0

Videocore information

Apr 30 2021 13:47:07
Copyright (c) 2012 Broadcom
version d7f29d96450abfc77cd6cf011af1faf1e03e5e56 (clean) (release) (start)

alloc failures: 0
compactions: 0
legacy block fails: 0

Filesystem information

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 1507280 1289304 123360 92% /
devtmpfs 439916 0 439916 0% /dev
tmpfs 473196 0 473196 0% /dev/shm
tmpfs 473196 12324 460872 3% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 473196 0 473196 0% /sys/fs/cgroup
/dev/mmcblk0p1 258095 48781 209314 19% /boot
tmpfs 94636 0 94636 0% /run/user/1000

Filename Type Size Used Priority
/var/swap file 102396 0 -2

Package version information

raspberrypi-ui-mods:
Installed: (none)
raspberrypi-sys-mods:
Installed: 20210310
openbox:
Installed: (none)
lxpanel:
Installed: (none)
pcmanfm:
Installed: (none)
rpd-plym-splash:
Installed: (none)

Networking Information

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet x.x.x.x netmask x.x.x.x broadcast x.x.x.x
inet6 y::y.y.y.y prefixlen 64 scopeid 0x20
inet6 y.y.y.y.y.y.y.y prefixlen 64 scopeid 0x0
ether m.m.m.m txqueuelen 1000 (Ethernet)
RX packets 756 bytes 49641 (48.4 KiB)
RX errors 0 dropped 2 overruns 0 frame 0
TX packets 127 bytes 19241 (18.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet x.x.x.x netmask x.x.x.x
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

USB Information

/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
|__ Port 2: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 1: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 2: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 2: Dev 6, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M

config.txt

aphy_params_current=819
arm_freq=1200
arm_freq_min=600
audio_pwm_mode=514
config_hdmi_boost=5
core_freq=400
desired_osc_freq=0x387520
disable_commandline_tags=2
disable_l2cache=1
display_hdmi_rotate=-1
display_lcd_rotate=-1
dphy_params_current=547
dvfs=2
enable_tvout=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_ignore_alpha=1
framebuffer_swap=1
gpu_freq=300
init_uart_clock=0x2dc6c00
lcd_framerate=60
max_framebuffers=-1
over_voltage_avs=0x1cfde
pause_burst_frames=1
program_serial_random=1
sdram_freq=450
total_mem=1024
hdmi_force_cec_address:0=65535
hdmi_force_cec_address:1=65535
hdmi_pixel_freq_limit:0=0x9a7ec80
device_tree=-
overlay_prefix=overlays/
hdmi_cvt:0=
hdmi_cvt:1=
hdmi_edid_filename:0=
hdmi_edid_filename:1=
hdmi_timings:0=
hdmi_timings:1=

cmdline.txt

coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 root=PARTUUID=9730496b-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet net.ifnames=0

raspi-gpio settings

BANK0 (GPIO 0 to 27):
GPIO 0: level=1 fsel=0 func=INPUT
GPIO 1: level=1 fsel=0 func=INPUT
GPIO 2: level=1 fsel=0 func=INPUT
GPIO 3: level=1 fsel=0 func=INPUT
GPIO 4: level=1 fsel=0 func=INPUT
GPIO 5: level=1 fsel=0 func=INPUT
GPIO 6: level=1 fsel=0 func=INPUT
GPIO 7: level=1 fsel=0 func=INPUT
GPIO 8: level=1 fsel=0 func=INPUT
GPIO 9: level=0 fsel=0 func=INPUT
GPIO 10: level=0 fsel=0 func=INPUT
GPIO 11: level=0 fsel=0 func=INPUT
GPIO 12: level=0 fsel=0 func=INPUT
GPIO 13: level=0 fsel=0 func=INPUT
GPIO 14: level=0 fsel=0 func=INPUT
GPIO 15: level=1 fsel=0 func=INPUT
GPIO 16: level=0 fsel=0 func=INPUT
GPIO 17: level=0 fsel=0 func=INPUT
GPIO 18: level=0 fsel=0 func=INPUT
GPIO 19: level=0 fsel=0 func=INPUT
GPIO 20: level=0 fsel=0 func=INPUT
GPIO 21: level=0 fsel=0 func=INPUT
GPIO 22: level=0 fsel=0 func=INPUT
GPIO 23: level=0 fsel=0 func=INPUT
GPIO 24: level=0 fsel=0 func=INPUT
GPIO 25: level=0 fsel=0 func=INPUT
GPIO 26: level=0 fsel=0 func=INPUT
GPIO 27: level=0 fsel=0 func=INPUT
BANK1 (GPIO 28 to 45):
GPIO 28: level=0 fsel=0 func=INPUT
GPIO 29: level=1 fsel=0 func=INPUT
GPIO 30: level=0 fsel=0 func=INPUT
GPIO 31: level=0 fsel=0 func=INPUT
GPIO 32: level=1 fsel=7 alt=3 func=TXD0
GPIO 33: level=1 fsel=7 alt=3 func=RXD0
GPIO 34: level=0 fsel=7 alt=3 func=SD1_CLK
GPIO 35: level=1 fsel=7 alt=3 func=SD1_CMD
GPIO 36: level=1 fsel=7 alt=3 func=SD1_DAT0
GPIO 37: level=1 fsel=7 alt=3 func=SD1_DAT1
GPIO 38: level=1 fsel=7 alt=3 func=SD1_DAT2
GPIO 39: level=1 fsel=7 alt=3 func=SD1_DAT3
GPIO 40: level=0 fsel=4 alt=0 func=PWM0
GPIO 41: level=0 fsel=4 alt=0 func=PWM1
GPIO 42: level=1 fsel=4 alt=0 func=GPCLK1
GPIO 43: level=1 fsel=4 alt=0 func=GPCLK2
GPIO 44: level=1 fsel=0 func=INPUT
GPIO 45: level=1 fsel=0 func=INPUT
BANK2 (GPIO 46 to 53):
GPIO 46: level=1 fsel=0 func=INPUT
GPIO 47: level=1 fsel=1 func=OUTPUT
GPIO 48: level=0 fsel=4 alt=0 func=SD0_CLK
GPIO 49: level=1 fsel=4 alt=0 func=SD0_CMD
GPIO 50: level=1 fsel=4 alt=0 func=SD0_DAT0
GPIO 51: level=1 fsel=4 alt=0 func=SD0_DAT1
GPIO 52: level=1 fsel=4 alt=0 func=SD0_DAT2
GPIO 53: level=1 fsel=4 alt=0 func=SD0_DAT3

vcdbg log messages

001174.351: brfs: File read: /mfs/sd/config.txt
001175.373: brfs: File read: 1784 bytes
001258.852: brfs: File read: /mfs/sd/config.txt
001259.784: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
001279.602: brfs: File read: 1784 bytes
001464.422: gpioman: gpioman_get_pin_num: pin DISPLAY_DSI_PORT not defined
001465.749: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
001465.804: *** Restart logging
001498.752: HDMI0: hdmi_pixel_encoding: 162000000
001504.078: dtb_file 'bcm2710-rpi-3-b.dtb'
001510.285: brfs: File read: /mfs/sd/bcm2710-rpi-3-b.dtb
001510.307: Loading 'bcm2710-rpi-3-b.dtb' to 0x100 size 0x6ee8
001523.735: brfs: File read: 28392 bytes
001537.117: brfs: File read: /mfs/sd/overlays/overlay_map.dtb
001604.115: brfs: File read: 1523 bytes
001609.380: brfs: File read: /mfs/sd/config.txt
001609.985: dtparam: audio=on
001626.501: brfs: File read: 1784 bytes
001629.181: brfs: File read: /mfs/sd/cmdline.txt
001629.236: Read command line from file 'cmdline.txt':
001629.258: 'console=serial0,115200 console=tty1 root=PARTUUID=9730496b-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet net.ifnames=0'
003599.101: gpioman: gpioman_get_pin_num: pin EMMC_ENABLE not defined
003654.884: brfs: File read: 141 bytes
004095.213: brfs: File read: /mfs/sd/kernel7.img
004095.237: Loading 'kernel7.img' to 0x8000 size 0x6072f8
004095.268: Device tree loaded to 0x2eff8c00 (size 0x7344)
004097.805: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
007766.363: vchiq_core: vchiq_init_state: slot_zero = 0xf7580000, is_master = 1
007771.002: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
007776.876: TV service:host side not connected, dropping notification 0x00000002, 0x00000001, 0x00000010

dmesg log

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.10.17-v7+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1414 SMP Fri Apr 30 13:18:35 BST 2021
[ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model B Rev 1.2
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] Reserved memory: created CMA memory pool at 0x37400000, size 64 MiB
[ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000000000-0x000000003b3fffff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000003b3fffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000003b3fffff]
[ 0.000000] On node 0 totalpages: 242688
[ 0.000000] DMA zone: 2133 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 242688 pages, LIFO batch:63
[ 0.000000] percpu: Embedded 20 pages/cpu s50700 r8192 d23028 u81920
[ 0.000000] pcpu-alloc: s50700 r8192 d23028 u81920 alloc=20*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 240555
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 root=PARTUUID=9730496b-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet net.ifnames=0
[ 0.000000] Kernel parameter elevator= does not have any effect anymore.
Please use sysfs to set IO scheduler for individual devices.
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 879832K/970752K available (9216K kernel code, 1311K rwdata, 2940K rodata, 1024K init, 860K bss, 25384K reserved, 65536K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] ftrace: allocating 31910 entries in 63 pages
[ 0.000000] ftrace: allocated 63 pages with 6 groups
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] Rude variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] random: get_random_bytes called from start_kernel+0x3ac/0x580 with crng_init=0
[ 0.000000] arch_timer: cp15 timer(s) running at 19.20MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[ 0.000007] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[ 0.000021] Switching to timer-based delay loop, resolution 52ns
[ 0.000306] Console: colour dummy device 80x30
[ 0.000379] printk: console [tty1] enabled
[ 0.000430] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000)
[ 0.000460] pid_max: default: 32768 minimum: 301
[ 0.000675] LSM: Security Framework initializing
[ 0.000913] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.000937] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.002528] Disabling memory control group subsystem
[ 0.002646] CPU: Testing write buffer coherency: ok
[ 0.003145] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.004383] Setting up static identity map for 0x100000 - 0x10003c
[ 0.004568] rcu: Hierarchical SRCU implementation.
[ 0.005491] smp: Bringing up secondary CPUs ...
[ 0.006661] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.007964] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.009188] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.009346] smp: Brought up 1 node, 4 CPUs
[ 0.009369] SMP: Total of 4 processors activated (153.60 BogoMIPS).
[ 0.009381] CPU: All CPU(s) started in HYP mode.
[ 0.009392] CPU: Virtualization extensions available.
[ 0.010494] devtmpfs: initialized
[ 0.028028] VFP support v0.3: implementor 41 architecture 3 part 40 variant 3 rev 4
[ 0.028282] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.028312] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[ 0.031553] pinctrl core: initialized pinctrl subsystem
[ 0.032730] NET: Registered protocol family 16
[ 0.037117] DMA: preallocated 1024 KiB pool for atomic coherent allocations
[ 0.042858] audit: initializing netlink subsys (disabled)
[ 0.043179] audit: type=2000 audit(0.040:1): state=initialized audit_enabled=0 res=1
[ 0.043783] thermal_sys: Registered thermal governor 'step_wise'
[ 0.044884] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[ 0.044900] hw-breakpoint: maximum watchpoint size is 8 bytes.
[ 0.045186] Serial: AMBA PL011 UART driver
[ 0.063112] bcm2835-mbox 3f00b880.mailbox: mailbox enabled
[ 0.080122] raspberrypi-firmware soc:firmware: Attached to firmware from 2021-04-30T13:47:07, variant start
[ 0.090133] raspberrypi-firmware soc:firmware: Firmware hash is d7f29d96450abfc77cd6cf011af1faf1e03e5e56
[ 0.139236] bcm2835-dma 3f007000.dma: DMA legacy API manager, dmachans=0x1
[ 0.141747] SCSI subsystem initialized
[ 0.142010] usbcore: registered new interface driver usbfs
[ 0.142075] usbcore: registered new interface driver hub
[ 0.142145] usbcore: registered new device driver usb
[ 0.144226] clocksource: Switched to clocksource arch_sys_counter
[ 1.922180] VFS: Disk quotas dquot_6.6.0
[ 1.922301] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 1.922505] FS-Cache: Loaded
[ 1.922745] CacheFiles: Loaded
[ 1.932676] NET: Registered protocol family 2
[ 1.933691] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
[ 1.933751] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 1.933972] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 1.934165] TCP: Hash tables configured (established 8192 bind 8192)
[ 1.934406] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 1.934464] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 1.934928] NET: Registered protocol family 1
[ 1.935752] RPC: Registered named UNIX socket transport module.
[ 1.935765] RPC: Registered udp transport module.
[ 1.935777] RPC: Registered tcp transport module.
[ 1.935789] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 1.937562] hw perfevents: enabled with armv7_cortex_a7 PMU driver, 7 counters available
[ 1.941353] Initialise system trusted keyrings
[ 1.941635] workingset: timestamp_bits=14 max_order=18 bucket_order=4
[ 1.951268] zbud: loaded
[ 1.953359] FS-Cache: Netfs 'nfs' registered for caching
[ 1.954331] NFS: Registering the id_resolver key type
[ 1.954385] Key type id_resolver registered
[ 1.954398] Key type id_legacy registered
[ 1.954559] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 1.955718] Key type asymmetric registered
[ 1.955733] Asymmetric key parser 'x509' registered
[ 1.955793] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[ 1.955807] io scheduler mq-deadline registered
[ 1.955820] io scheduler kyber registered
[ 1.960673] bcm2708_fb soc:fb: FB found 1 display(s)
[ 1.995574] Console: switching to colour frame buffer device 228x61
[ 2.025900] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 1824x984
[ 2.031532] bcm2835-rng 3f104000.rng: hwrng registered
[ 2.031983] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
[ 2.032804] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[ 2.045325] brd: module loaded
[ 2.057721] loop: module loaded
[ 2.059323] Loading iSCSI transport class v2.0-870.
[ 2.061093] libphy: Fixed MDIO Bus: probed
[ 2.061398] usbcore: registered new interface driver lan78xx
[ 2.061477] usbcore: registered new interface driver smsc95xx
[ 2.061504] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[ 2.789809] Core Release: 2.80a
[ 2.789825] Setting default values for core params
[ 2.789862] Finished setting default values for core params
[ 2.990268] Using Buffer DMA mode
[ 2.990282] Periodic Transfer Interrupt Enhancement - disabled
[ 2.990294] Multiprocessor Interrupt Enhancement - disabled
[ 2.990308] OTG VER PARAM: 0, OTG VER FLAG: 0
[ 2.990336] Dedicated Tx FIFOs mode

[ 2.990943] WARN::dwc_otg_hcd_init:1074: FIQ DMA bounce buffers: virt = b7504000 dma = 0xf7504000 len=9024
[ 2.990979] FIQ FSM acceleration enabled for :
Non-periodic Split Transactions
Periodic Split Transactions
High-Speed Isochronous Endpoints
Interrupt/Control Split Transaction hack enabled
[ 2.990993] dwc_otg: Microframe scheduler enabled

[ 2.991073] WARN::hcd_init_fiq:457: FIQ on core 1

[ 2.991090] WARN::hcd_init_fiq:458: FIQ ASM at 807be568 length 36

[ 2.991108] WARN::hcd_init_fiq:497: MPHI regs_base at bb810000
[ 2.991134] dwc_otg 3f980000.usb: DWC OTG Controller
[ 2.991177] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[ 2.991228] dwc_otg 3f980000.usb: irq 89, io mem 0x00000000
[ 2.991284] Init: Port Power? op_state=1
[ 2.991297] Init: Power Port (0)
[ 2.991681] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.10
[ 2.991700] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 2.991716] usb usb1: Product: DWC OTG Controller
[ 2.991731] usb usb1: Manufacturer: Linux 5.10.17-v7+ dwc_otg_hcd
[ 2.991746] usb usb1: SerialNumber: 3f980000.usb
[ 2.992562] hub 1-0:1.0: USB hub found
[ 2.992642] hub 1-0:1.0: 1 port detected
[ 2.993742] dwc_otg: FIQ enabled
[ 2.993756] dwc_otg: NAK holdoff enabled
[ 2.993768] dwc_otg: FIQ split-transaction FSM enabled
[ 2.993788] Module dwc_common_port init
[ 2.994133] usbcore: registered new interface driver usb-storage
[ 2.994414] mousedev: PS/2 mouse device common for all mice
[ 2.995656] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[ 2.998442] sdhci: Secure Digital Host Controller Interface driver
[ 2.998455] sdhci: Copyright(c) Pierre Ossman
[ 2.999083] mmc-bcm2835 3f300000.mmcnr: could not get clk, deferring probe
[ 2.999785] sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
[ 3.000015] sdhci-pltfm: SDHCI platform and OF driver helper
[ 3.001882] ledtrig-cpu: registered to indicate activity on CPUs
[ 3.002325] hid: raw HID events driver (C) Jiri Kosina
[ 3.002490] usbcore: registered new interface driver usbhid
[ 3.002502] usbhid: USB HID core driver
[ 3.007799] Initializing XFRM netlink socket
[ 3.007850] NET: Registered protocol family 17
[ 3.008025] Key type dns_resolver registered
[ 3.008778] Registering SWP/SWPB emulation handler
[ 3.008942] registered taskstats version 1
[ 3.008976] Loading compiled-in X.509 certificates
[ 3.009933] Key type ._fscrypt registered
[ 3.009947] Key type .fscrypt registered
[ 3.009961] Key type fscrypt-provisioning registered
[ 3.021543] uart-pl011 3f201000.serial: cts_event_workaround enabled
[ 3.021657] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 114, base_baud = 0) is a PL011 rev2
[ 3.024100] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[ 3.025915] mmc-bcm2835 3f300000.mmcnr: mmc_debug:0 mmc_debug2:0
[ 3.025932] mmc-bcm2835 3f300000.mmcnr: DMA channel allocated
[ 3.053068] sdhost: log_buf @ (ptrval) (f7507000)
[ 3.089904] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 3.091569] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 3.093231] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 3.096412] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 3.102391] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
[ 3.105494] of_cfs_init
[ 3.105690] of_cfs_init: OK
[ 3.107054] Waiting for root device PARTUUID=9730496b-02...
[ 3.162650] random: fast init done
[ 3.190432] mmc0: host does not support reading read-only switch, assuming write-enable
[ 3.194771] mmc0: new high speed SDHC card at address aaaa
[ 3.195984] mmcblk0: mmc0:aaaa SC32G 29.7 GiB
[ 3.199852] mmcblk0: p1 p2
[ 3.204464] Indeed it is in host mode hprt0 = 00021501
[ 3.237548] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 3.237632] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 3.245524] devtmpfs: mounted
[ 3.266431] Freeing unused kernel memory: 1024K
[ 3.278292] mmc1: new high speed SDIO card at address 0001
[ 3.304722] Run /sbin/init as init process
[ 3.304733] with arguments:
[ 3.304745] /sbin/init
[ 3.304756] with environment:
[ 3.304767] HOME=/
[ 3.304778] TERM=linux
[ 3.414304] usb 1-1: new high-speed USB device number 2 using dwc_otg
[ 3.414498] Indeed it is in host mode hprt0 = 00001101
[ 3.654631] usb 1-1: New USB device found, idVendor=0424, idProduct=9514, bcdDevice= 2.00
[ 3.654657] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 3.655566] hub 1-1:1.0: USB hub found
[ 3.655690] hub 1-1:1.0: 5 ports detected
[ 3.879824] systemd[1]: System time before build time, advancing clock.
[ 3.974297] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[ 4.029894] NET: Registered protocol family 10
[ 4.031489] Segment Routing with IPv6
[ 4.104667] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00, bcdDevice= 2.00
[ 4.104691] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 4.107556] smsc95xx v2.0.0
[ 4.119555] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[ 4.120747] systemd[1]: Detected architecture arm.
[ 4.194519] libphy: smsc95xx-mdiobus: probed
[ 4.195848] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, m.m.m.m
[ 4.197748] systemd[1]: Set hostname to .
[ 4.294400] usb 1-1.2: new high-speed USB device number 4 using dwc_otg
[ 4.425954] usb 1-1.2: New USB device found, idVendor=05e3, idProduct=0608, bcdDevice=77.63
[ 4.425981] usb 1-1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 4.425998] usb 1-1.2: Product: USB2.0 Hub
[ 4.427026] hub 1-1.2:1.0: USB hub found
[ 4.427360] hub 1-1.2:1.0: 4 ports detected
[ 4.774340] usb 1-1.2.1: new low-speed USB device number 5 using dwc_otg
[ 4.936876] usb 1-1.2.1: New USB device found, idVendor=046d, idProduct=c518, bcdDevice=42.04
[ 4.936899] usb 1-1.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 4.936916] usb 1-1.2.1: Product: USB Receiver
[ 4.936931] usb 1-1.2.1: Manufacturer: Logitech
[ 4.964675] input: Logitech USB Receiver as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1:1.0/0003:046D:C518.0001/input/input0
[ 4.965306] hid-generic 0003:046D:C518.0001: input,hidraw0: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-3f980000.usb-1.2.1/input0
[ 4.977780] input: Logitech USB Receiver Consumer Control as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1:1.1/0003:046D:C518.0002/input/input1
[ 5.045047] hid-generic 0003:046D:C518.0002: input,hiddev96,hidraw1: USB HID v1.11 Device [Logitech USB Receiver] on usb-3f980000.usb-1.2.1/input1
[ 5.062169] random: systemd: uninitialized urandom read (16 bytes read)
[ 5.077522] random: systemd: uninitialized urandom read (16 bytes read)
[ 5.080113] systemd[1]: Created slice User and Session Slice.
[ 5.080428] random: systemd: uninitialized urandom read (16 bytes read)
[ 5.080510] systemd[1]: Reached target Slices.
[ 5.081723] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[ 5.082591] systemd[1]: Listening on Syslog Socket.
[ 5.083774] systemd[1]: Listening on Journal Audit Socket.
[ 5.086677] systemd[1]: Created slice system-getty.slice.
[ 5.086830] systemd[1]: Reached target Swap.
[ 5.144376] usb 1-1.2.2: new low-speed USB device number 6 using dwc_otg
[ 5.288323] usb 1-1.2.2: New USB device found, idVendor=046d, idProduct=c312, bcdDevice= 1.00
[ 5.288350] usb 1-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 5.288367] usb 1-1.2.2: Product: USB Multimedia Keyboard
[ 5.288382] usb 1-1.2.2: Manufacturer: BTC
[ 5.316828] input: BTC USB Multimedia Keyboard as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/0003:046D:C312.0003/input/input4
[ 5.386289] hid-generic 0003:046D:C312.0003: input,hidraw2: USB HID v1.10 Keyboard [BTC USB Multimedia Keyboard] on usb-3f980000.usb-1.2.2/input0
[ 5.397285] input: BTC USB Multimedia Keyboard System Control as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.1/0003:046D:C312.0004/input/input5
[ 5.465050] input: BTC USB Multimedia Keyboard Consumer Control as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.1/0003:046D:C312.0004/input/input6
[ 5.465821] hid-generic 0003:046D:C312.0004: input,hiddev97,hidraw3: USB HID v1.10 Device [BTC USB Multimedia Keyboard] on usb-3f980000.usb-1.2.2/input1
[ 5.792280] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[ 5.913463] systemd-journald[109]: Received request to flush runtime journal from PID 1
[ 7.039805] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.043113] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
[ 7.043150] [vc_sm_connected_init]: start
[ 7.049258] mc: Linux media interface: v0.10
[ 7.054830] [vc_sm_connected_init]: installed successfully
[ 7.112451] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.144999] bcm2835_audio bcm2835_audio: card created with 4 channels
[ 7.151383] bcm2835_audio bcm2835_audio: card created with 4 channels
[ 7.169755] videodev: Linux video capture interface: v2.00
[ 7.237005] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.237498] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.240008] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.255760] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.262311] bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.276659] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.286151] bcm2835-codec bcm2835-codec: Device registered as /dev/video10
[ 7.286216] bcm2835-codec bcm2835-codec: Loaded V4L2 decode
[ 7.296880] bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video13
[ 7.297497] bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video14
[ 7.297884] bcm2835-codec bcm2835-codec: Device registered as /dev/video11
[ 7.298101] bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video15
[ 7.298209] bcm2835-codec bcm2835-codec: Loaded V4L2 encode
[ 7.299062] bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video16
[ 7.299166] bcm2835-isp bcm2835-isp: Register output node 0 with media controller
[ 7.299192] bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
[ 7.299215] bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
[ 7.299236] bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
[ 7.299492] bcm2835-isp bcm2835-isp: Loaded V4L2 bcm2835-isp
[ 7.302857] bcm2835-codec bcm2835-codec: Device registered as /dev/video12
[ 7.302975] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
[ 7.464767] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 7.617832] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 7.708898] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[ 7.718613] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 7.719042] usbcore: registered new interface driver brcmfmac
[ 7.748681] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt failed with error -2
[ 7.960210] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[ 7.960372] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 7.961258] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Oct 22 2019 01:59:28 version 7.45.98.94 (r723000 CY) FWID 01-3b33decd
[ 10.094164] random: crng init done
[ 10.094200] random: 7 urandom warning(s) missed due to ratelimiting
[ 10.147064] 8021q: 802.1Q VLAN Support v1.8
[ 10.157142] uart-pl011 3f201000.serial: no DMA platform data
[ 10.384426] Adding 102396k swap on /var/swap. Priority:-2 extents:1 across:102396k SSFS
[ 11.206842] SMSC LAN8700 usb-001:003:01: attached PHY driver [SMSC LAN8700] (mii_bus:phy_addr=usb-001:003:01, irq=POLL)
[ 11.207364] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[ 11.215721] smsc95xx 1-1.1:1.0 eth0: Link is Down
[ 13.275498] smsc95xx 1-1.1:1.0 eth0: Link is Up - 100Mbps/Full - flow control off
[ 13.275556] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 14.478007] ICMPv6: process `dhcpcd' is using deprecated sysctl (syscall) net.ipv6.neigh.eth0.retrans_time - use net.ipv6.neigh.eth0.retrans_time_ms instead
[ 14.596727] Bluetooth: Core ver 2.22
[ 14.596843] NET: Registered protocol family 31
[ 14.596855] Bluetooth: HCI device and connection manager initialized
[ 14.596884] Bluetooth: HCI socket layer initialized
[ 14.596899] Bluetooth: L2CAP socket layer initialized
[ 14.596928] Bluetooth: SCO socket layer initialized
[ 14.609626] Bluetooth: HCI UART driver ver 2.3
[ 14.609645] Bluetooth: HCI UART protocol H4 registered
[ 14.609745] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 14.609954] Bluetooth: HCI UART protocol Broadcom registered
[ 14.880139] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 14.880160] Bluetooth: BNEP filters: protocol multicast
[ 14.880188] Bluetooth: BNEP socket layer initialized
root@raspberrypi:/home/pi#

Logs
If applicable, add the relevant output from dmesg or similar.

Additional context
I made the same test with the raspios version of Dec 10,2020 and it worked just fine.

@shawaj
Copy link

shawaj commented Aug 25, 2021

Possibly related to #4341

@morrisrob
Copy link

I am experiencing the same issue on our custom 3b boards after updating to the 5.10 kernel and have been looking for a solution. A couple of observations that I've made while troubleshooting this:

  • I only experience the issue when plugged into some network switches. When connected to one my switches, it consistently works fine but when connected to a couple other switches, I experience this issue. With the switches where I am experiencing the issue, if I downgrade back to our previous 4.19 kernel that we were using, everything works fine, so this rules out an issue with the switches / cabling (I have tried multiple other ethernet cables). I have replicated this same test a number of times.

  • When it is in this state, if I run 'ifconfig eth0 down', and then 'ifconfig eth0 up', I get back to a working state.

@jrfromfl
Copy link
Author

jrfromfl commented Sep 14, 2021

I can confirm, that it works with some switches and with others it does not.
I did tests with a Netgear switch and a FritzBox router and plugging in the ethernet cable after boot didn't work.
I also tested with a D-Link switch and it worked fine.

I can also confirm, that 'ip link set eth0 down' followed by 'ip link set eth0 up' reactivates the network connection to the Netgear switch and also to the FritzBox router.

For us this is a critical issue, because headless systems, that are remotely controlled via network may not be connected to the network after a powerfail, when the switch or router needs more time to activate the network ports than the rpi needs to boot.

@pelwell
Copy link
Contributor

pelwell commented Sep 22, 2021

I think I've got at least a workaround for this. It seems that link detection can take more than the allowed 640ms, but if the PHY driver is allowed to wait 1500ms then the link comes back up.

Can anyone here test this patch? I've had success on a 3B and a 2B with it (and not without it):

diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index caf7291ffaf8..9983eeded624 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -195,12 +195,12 @@ static int lan87xx_read_status(struct phy_device *phydev)
                if (rc < 0)
                        return rc;
 
-               /* Wait max 640 ms to detect energy and the timeout is not
+               /* Wait max 1500 ms to detect energy and the timeout is not
                 * an actual error.
                 */
                read_poll_timeout(phy_read, rc,
                                  rc & MII_LAN83C185_ENERGYON || rc < 0,
-                                 10000, 640000, true, phydev,
+                                 10000, 1500000, true, phydev,
                                  MII_LAN83C185_CTRL_STATUS);
                if (rc < 0)
                        return rc;

pelwell added a commit to pelwell/linux that referenced this issue Sep 22, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: raspberrypi#4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
@pelwell
Copy link
Contributor

pelwell commented Sep 22, 2021

See #4598.

@morrisrob
Copy link

Can anyone here test this patch? I've had success on a 3B and a 2B with it (and not without it):

@pelwell Yes, this does look to resolve the issue on the custom 3b that I'm using. I have not been able to reproduce the issue after applying this patch. Thank you for your help with this.

pelwell added a commit that referenced this issue Sep 23, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
@pelwell
Copy link
Contributor

pelwell commented Sep 23, 2021

Thanks for the feedback. The patch will be in future releases.

pelwell added a commit that referenced this issue Sep 23, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
pelwell added a commit that referenced this issue Sep 23, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Sep 23, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
@pelwell
Copy link
Contributor

pelwell commented Sep 24, 2021

Yesterday's firmware release (available via rpi-update) includes this fix.

popcornmix pushed a commit that referenced this issue Sep 30, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Sep 30, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Oct 5, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
limeng-linux pushed a commit to limeng-linux/linux-yocto-5.10 that referenced this issue Oct 9, 2021
commit  094e36e10c122edc089f1629a3d906c21afa2319 from
https://github.com/raspberrypi/linux.git rpi-5.10.y

With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: raspberrypi/linux#4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Signed-off-by: Meng Li <Meng.Li@windriver.com>
popcornmix pushed a commit that referenced this issue Oct 12, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Oct 13, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Oct 19, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Oct 19, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Oct 22, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Oct 27, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
limeng-linux pushed a commit to limeng-linux/linux-yocto-develop that referenced this issue Oct 29, 2021
commit  59bd0184158581304069fe4e7347dbdf31d73f47 from
https://github.com/raspberrypi/linux.git rpi-5.15.y

With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: raspberrypi/linux#4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Signed-off-by: Meng Li <Meng.Li@windriver.com>
popcornmix pushed a commit that referenced this issue Nov 1, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Nov 8, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Nov 8, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Nov 15, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Nov 15, 2021
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
herrnst pushed a commit to herrnst/linux-raspberrypi that referenced this issue May 16, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: raspberrypi#4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue May 16, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue May 16, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue May 16, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Noltari pushed a commit to Noltari/rpi-linux that referenced this issue May 17, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: raspberrypi#4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
herrnst pushed a commit to herrnst/linux-raspberrypi that referenced this issue May 21, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: raspberrypi#4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue May 23, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue May 23, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
asheplyakov pushed a commit to asheplyakov/linux that referenced this issue May 24, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: raspberrypi/linux#4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
herrnst pushed a commit to herrnst/linux-raspberrypi that referenced this issue May 25, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: raspberrypi#4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
herrnst pushed a commit to herrnst/linux-raspberrypi that referenced this issue May 25, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: raspberrypi#4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue May 26, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Jun 1, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Jun 1, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Jun 6, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Jun 6, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Jun 6, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Jun 14, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Jun 14, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Jun 20, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
herrnst pushed a commit to herrnst/linux-raspberrypi that referenced this issue Jun 21, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: raspberrypi#4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Jun 23, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Jul 4, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
herrnst pushed a commit to herrnst/linux-raspberrypi that referenced this issue Jul 10, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: raspberrypi#4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Jul 11, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Jul 18, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Aug 1, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Aug 15, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
popcornmix pushed a commit that referenced this issue Aug 23, 2022
With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: #4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
papamoose pushed a commit to papamoose/ubuntu-kernel-raspi-jammy that referenced this issue Sep 3, 2022
BugLink: https://bugs.launchpad.net/bugs/1958146

With EDPWRDOWN set in idle, it must be cleared before checking for
ENERGYON going high, indicating that a link is being established.
The existing code allows 640ms for ENERGYON to go high, but on
Raspberry Pis that appears not to be enough, causing link detection
to fail.

Increase the polling timeout to 1500ms - with a polling interval of
10ms it shouldn't cause unnecessary delays.

See: raspberrypi/linux#4393

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

(cherry picked from commit a907a7f485cb6837797fb603fd4c2ab08d5b29f0 rpi-5.15.y)
Signed-off-by: Juerg Haefliger <juergh@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants