NetBSD Problem Report #55317

From www@netbsd.org  Sat May 30 09:01:11 2020
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id DC0D71A921A
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 30 May 2020 09:01:10 +0000 (UTC)
Message-Id: <20200530090110.13B191A9227@mollari.NetBSD.org>
Date: Sat, 30 May 2020 09:01:10 +0000 (UTC)
From: cryintothebluesky@gmail.com
Reply-To: cryintothebluesky@gmail.com
To: gnats-bugs@NetBSD.org
Subject: RPi3 network interface fails to initialize correctly
X-Send-Pr-Version: www-1.0

>Number:         55317
>Category:       port-arm
>Synopsis:       RPi3 network interface fails to initialize correctly
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-arm-maintainer
>State:          feedback
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat May 30 09:05:00 +0000 2020
>Closed-Date:    
>Last-Modified:  Thu Dec 15 11:25:01 +0000 2022
>Originator:     Sad Clouds
>Release:        9.0
>Organization:
>Environment:
>Description:
This seems to be specific to RPi3 where network interface shares USB bus.

When booting from cold and I have no other USB devices plugged in, quite often network interface fails to initialize correctly. Seems like it is not ready when rc.d scripts are executed. See the following photo https://drive.google.com/open?id=18hsSFM9O8w5p-hKywD8TFAcfCm9pb9bv

However, if I plug in a USB keyboard, the problem seems to go away. On every boot the network interfaces initializes correctly and IP address is assigned.
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: skrll@NetBSD.org
State-Changed-When: Tue, 30 Aug 2022 11:49:58 +0000
State-Changed-Why:
Is this still a problem? Can you test against HEAD if it is?


From: Sad Clouds <cryintothebluesky@gmail.com>
To: gnats-bugs@netbsd.org
Cc: skrll@NetBSD.org, port-arm-maintainer@netbsd.org,
 netbsd-bugs@netbsd.org, gnats-admin@netbsd.org
Subject: Re: port-arm/55317 (RPi3 network interface fails to initialize
 correctly)
Date: Thu, 1 Sep 2022 11:44:17 +0100

 Unfortunately I'm not able to test it as I don't have spare RPi3
 any more. Have there been specific fixes for this issue, are you just
 hoping the race condition got resolved somehow?

From: Sad Clouds <cryintothebluesky@gmail.com>
To: gnats-bugs@netbsd.org
Cc: port-arm-maintainer@netbsd.org, gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org, skrll@NetBSD.org
Subject: Re: port-arm/55317
Date: Thu, 15 Dec 2022 08:22:56 +0000

 Got hold of RPi3 and updated to the latest 9.3_STABLE and the issue is
 still there. Workaround is to add sleep to /etc/rc.d/network script

 network_start()
 {
         sleep 3
 	...
 }

 Not tried recent -current yet, however this really needs fixing in the
 stable release. The question is - why /etc/rc.d/network runs before
 kernel manages to attach mue0 network interface? 

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-arm/55317
Date: Thu, 15 Dec 2022 09:32:42 -0000 (UTC)

 cryintothebluesky@gmail.com (Sad Clouds) writes:

 >Not tried recent -current yet, however this really needs fixing in the
 >stable release. The question is - why /etc/rc.d/network runs before
 >kernel manages to attach mue0 network interface? 

 USB is always "hot-plugging", the kernel doesn't know how long to wait
 for an USB device to attach.

 [     5.294732] uhub2: multiple transaction translators
 [     5.294732] uhub2: 3 ports with 2 removable, self powered
 [     5.634775] uhub0: autoconfiguration error: illegal enable change, port 1
 ...
 [     5.644779] boot device: ld0
 [     5.644779] root on ld0a dumps on ld0b
 [     5.664781] root file system type: ffs
 ...
 [     7.044973] mue0 at uhub2 port 1
 [     7.044973] mue0: SMSC (0x424) LAN7800 USB 3.1 gigabit ethernet device (0x7800), rev 2.10/3.00, addr 4
 [     7.335012] mue0: LAN7800 id 0x7800 rev 0x2

 two seconds later mue0 sees a carrier and
 nine seconds later dhcpcd gets an IP address.

 A static configuration might come too early. Best solution would be
 that the network script waits until the interfaces that it should
 configure have appeared. Basically s smarter version of the sleep
 that you added.

 We also need a configurable delay for the kernel itself to wait
 before trying to mount the root filesystem.


From: Sad Clouds <cryintothebluesky@gmail.com>
To: gnats-bugs@netbsd.org
Cc: mlelstv@serpens.de (Michael van Elst), port-arm-maintainer@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-arm/55317
Date: Thu, 15 Dec 2022 11:20:52 +0000

 On Thu, 15 Dec 2022 09:35:01 +0000 (UTC)
 mlelstv@serpens.de (Michael van Elst) wrote:

 >  USB is always "hot-plugging", the kernel doesn't know how long to wait
 >  for an USB device to attach.

 OK that answers the question and makes sense now. Could I suggest
 adding the following script fragment. This would avoid headaches for
 people who run Raspberry Pi 3 without other USB devices plugged in.

 /etc/rc.d/network:

 network_start()
 {
 	# Workaround for PR#55317
         local hw_model i
         hw_model=`sysctl -n hw.model | grep '^raspberrypi,3'`
         if [ -n "$hw_model" ]
         then
                 echo "Detected Raspberry Pi 3 hardware model"
                 echo "Waiting for USB ethernet device to attach..."

                 # Wait for up to 5 seconds before giving up
                 for i in 1 2 3 4 5
                 do
                         ifconfig mue0 >/dev/null 2>&1 && break
                         sleep 1
                 done
         fi

 ...
 }

>Unformatted:

Home	PR Database Search