Re: port-i386/60848: Alix fails to boot sometimes after warmstart, very likely due to network initialization

["Andrius V via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-i386/60848; it has been noted by GNATS.

From: Andrius V <vezhlys%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: netbsd%lissners.de@localhost
Subject: Re: port-i386/60848: Alix fails to boot sometimes after warmstart,
 very likely due to network initialization
Date: Sat, 10 Oct 2026 20:44:33 +0300

 On Fri, Oct 9, 2026 at 9:00=E2=80=AFPM Ekkehard Lissner-Jung via gnats
 <gnats-admin%netbsd.org@localhost> wrote:
 >  Hi,
 
 Hi,
 
 Replying to gnats-bugs%netbsd.org@localhost should be fine, I think system add
 required emails by itself. You can add me (vezhlys@gmail or
 andvar%netbsd.org@localhost) to cc though.
 Sorry, I assumed you have built the kernel in the past, but thanks for
 testing the patch!
 
 >
 >  I built a kernel with the patch you sent me.
 >  The error happened again. Multiple times. Not more often than before, so=
 =3D
 >  =3D20
 >  situation is not gone worse. But it's also not better.
 >  Here is the log-sequence from the console when the boot hangs:
 >   >>>
 >  [   1.2422074] entropy: ready
 >  [   1.8900948] swwdog0: software watchdog initialized
 >  [   1.9067363] WARNING: 1 error while detecting hardware; check system l=
 og=3D
 >  .
 >  [   1.9267673] boot device: vr0
 >  [   1.9353257] root on vr0
 >  [   1.9426115] nfs_boot: trying DHCP/BOOTP
 >  [   2.9001106] uplcom0 at uhub0 port 2
 >  [   2.9102554] uplcom0: vendor 067b (0x067b) product 2303 (0x2303), rev=
 =3D20
 >  1.10/2.02, addr 2
 >  [   2.9401115] ucom0 at uplcom0
 >  [  19.9503720] nfs_boot: timeout...
 >  [  24.9504463] nfs_boot: timeout...
 >  [  29.9505245] nfs_boot: timeout...
 >  [  34.9506008] nfs_boot: trying RARP (and RPC/bootparam)
 >  [  34.9805993] vr0: using force reset command.
 >  [  34.9932305] vr0: force reset done (10 us)
 >  [  48.0007994] revarp failed, error=3D3D51
 >  [  48.0164371] Supported file systems: mfs lfs ffs ext2fs nfs umap=3D20
 >  procfs overlay null kernfs fdesc union tmpfs puffs ptyfs ntfs msdos efs=
 =3D20
 >  cd9660 coda
 >  [  48.0512703] no file system for vr0
 >  [  48.0655693] cannot mount root, error =3D3D 79
 >  [  48.0780441] root device (default vr0):
 >  [  49.0190151] dump device:
 >  [  49.8925993] file system (default generic):
 >  [  50.7438295] root on vr0
 >  [  50.7438295] nfs_boot: trying DHCP/BOOTP
 >  [  53.7613977] nfs_boot: DHCP next-server: 192.168.10.6
 >  [  53.7829694] nfs_boot: my_domain=3D3Dlissner.home
 >  [  53.7956889] nfs_boot: my_addr=3D3D192.168.10.8
 >  [  53.8079067] nfs_boot: my_mask=3D3D255.255.240.0
 >  [  53.8203868] nfs_boot: gateway=3D3D192.168.10.2
 >  [  59.8314912] root on papaya:/srv/diskless/netbsd0/root
 >  [  59.8515653] root file system type: nfs
 >  [  59.8627223] kern.module.path=3D3D/stand/i386/11.0/modules
 >  [  59.8780687] init path (default /sbin/init):
 >  [  60.6419621] init: trying /sbin/init
 >  Fri Oct  9 14:33:05 -00 2026
 >  Not checking /: fs_passno =3D3D 0 in /etc/fstab
 >  Setting sysctl variables:
 >  ddb.onpanic: 1 -> 0
 >  <<<
 
 Yeah, I was not expecting reset patch to help, was more for debugging purpo=
 ses.
 Since I have reproduced (even if rarely), I could debug locally too.
 It may be more correct way to reset vr interface, but it is not
 helping to solve the issue.
 
 >
 >  If I understand corretly, this means: Reset command finished successfull=
 =3D
 >  =3D20
 >  after 10 us.
 >
 
 Yes, it basically means, it succeeded on the first attempt, which is
 an important result to understand if reset was working as expected.
 
 >  What I don't understand: After doing the (forced) reset, there is no=3D2=
 0
 >  other "nfs_boot: tryping DHCP/BOOTP". For me this looks like "ok, we are=
 =3D
 >  =3D20
 >  trying to boot DHCP/BOOTP; hm, didn't work; 3 times; now let's try RARP;=
 =3D
 >  =3D20
 >  didn't work either; now reset and wait for user input".
 
 The process attempts to send DHCP requests a few times, but all three
 attempts fail and eventually time out.
 RARP is just a fallback mechanism that also fails, but for a different
 reason, thus it does not configure the interface either.
 However, it brings the vr interface up, triggering initialization and
 calling vr_reset(), which helps revive the interface.
 Thus prompt to find root device is given again.
 Clicking enter retries DHCP, and the request succeeds, since interface
 is working well now.
 
 >  My suggestion would have been: After the reset the sequence starts again=
 =3D
 >  =3D20
 >  with the "trying DHCP/BOOTP". At least one more time; now with the chip=
 =3D20
 >  initialized.
 >
 >  I will build another kernel with the "if (i =3D3D=3D3D VR_TIMEOUT)" remo=
 ved=3D20
 >  completely as suggested by you some days ago.
 
 You can discard my first patch completely now.
 The problem appears to be that the RX engine sometimes gets stuck (it
 seems to fail when the DHCP offer is not the first frame received).
 I have prepared a new patch that I have tested locally, and I believe
 it should work for you: https://netbsd.org/~andvar/if_vr.c.3.diff
 It does something similar to what you were expecting: it forces a
 reset of the vr interface during initialization when a DHCP request
 has been sent and a stuck RX engine is detected.
 I have tested it locally on my machine. You should see something like
 the following when a request that previously failed succeeds:
 root on vr0
 nfs_boot: trying DHCP/BOOTP
 vr0: restarting
 vr0: using force reset command.
 nfs_boot: DHCP next-server: 192.168.19.1
 nfs_boot: my_addr=3D192.168.19.8
 nfs_boot: my_mask=3D255.255.255.0
 nfs_boot: gateway=3D192.168.19.1
 root on 192.168.19.1:/srv/pxeroot
 
 If you have any problems applying the patch or building the kernel, I
 can provide a prebuilt kernel.
 If it works, I will apply this or a similar patch and request a
 pull-up to the NetBSD 11 branch.
 We have daily builds for supported branches (with some delay)
 available at https://nycdn.netbsd.org/, which you will be able to use
 directly once the patch is pulled up.
 Eventually, the fix will make its way into a new 11.x or 12.0 release.
 Of course, alternatives include using builds from the nycdn branches
 or building the kernel yourself.
 
 >
 >  Regards
 >  Ekkehard
 >
 
 Regards,
 Andrius V