NetBSD Problem Report #60848
From www@netbsd.org Sun Oct 4 16:58:40 2026
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits)
client-signature RSA-PSS (2048 bits))
(Client CN "mail.netbsd.org", Issuer "YR1" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id F1AA41A923B
for <gnats-bugs@gnats.NetBSD.org>; Sun, 4 Oct 2026 16:58:39 +0000 (UTC)
Message-Id: <20261004165838.358E21A923C@mollari.NetBSD.org>
Date: Sun, 4 Oct 2026 16:58:38 +0000 (UTC)
From: netbsd@lissners.de
Reply-To: netbsd@lissners.de
To: gnats-bugs@NetBSD.org
Subject: Alix fails to boot sometimes after warmstart, very likely due to network initialization
X-Send-Pr-Version: www-1.0
X-From4GNATS: "netbsd@lissners.de via gnats" <gnats-admin@NetBSD.org>
>Number: 60848
>Category: port-i386
>Synopsis: Alix fails to boot sometimes after warmstart, very likely due to network initialization
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: andvar
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Oct 04 17:00:00 +0000 2026
>Closed-Date: Wed Oct 14 18:51:42 +0000 2026
>Last-Modified: Wed Oct 14 18:51:42 +0000 2026
>Originator: Ekkehard
>Release: Netbsd11
>Organization:
>Environment:
NetBSD melone2 11.0 NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 UTC 2026 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC i386
>Description:
I configured a PC-Engines Alix with 3 ethernet-ports to boot via pxe/dhcp as headless nfs-root machine. I created a new pxeboot_ia32_com0 to work with com0 at 38400.
In most cases, booting this setup works.
But sometimes when doing a warmstart ("reboot" from the running system), booting hangs when trying to mount the root-filesystem as nfs.
Here is the log from the serial console:
---
PC Engines ALIX.2 v0.99
640 KB Base Memory
261120 KB Extended Memory
Waiting for HDD .....................
01F0 - no drive found !
Intel UNDI, PXE-2.0 (build 082)
Copyright (C) 1997,1998,1999 Intel Corporation
VIA Rhine III Management Adapter v2.43 (2005/12/15)
CLIENT MAC ADDR: 00 0D B9 15 22 14
CLIENT IP: 192.168.10.8 MASK: 255.255.240.0 DHCP IP: 192.168.10.6
GATEWAY IP: 192.168.10.2
\\-__,------,___.
\\ __,---` NetBSD/x86 PXE Boot
\\ `---,_. Revision 5.2 (Sun Oct 4 14:23:18 UTC 2026)
\\-,_____,.---`
\\
\\
\\
Press return to boot now, any other key for boot menu
booting netbsd - starting in 0 seconds.
PXE BIOS Version 2.1
Using PCI device at bus 0 device 9 function 0
Ethernet address 00:0d:b9:15:22:14
20607664+593992+745400 [990792+947152+1036453]=0x17c5a7c
[ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
[ 1.0000000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013,
[ 1.0000000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023,
[ 1.0000000] 2024, 2025, 2026
[ 1.0000000] The NetBSD Foundation, Inc. All rights reserved.
[ 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[ 1.0000000] The Regents of the University of California. All rights reserved.
[ 1.0000000] NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 UTC 2026
[ 1.0000000] mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC
[ 1.0000000] total memory = 255 MB
[ 1.0000000] avail memory = 227 MB
[ 1.0000040] mainbus0 (root)
[ 1.0000040] Firmware Error (ACPI): A valid RSDP was not found (20241212/tbxfroot-383)
acpi_probe: failed to initialize tables
[ 1.0000040] ACPI Error: Could not remove SCI handler (20241212/evmisc-424)
[ 1.0000040] cpu0 at mainbus0
[ 1.0000040] ACPI Error: AE_BAD_PARAMETER, Thread 3243335680 could not acquire Mutex [ACPI_MTX_Tables] (0x2) (20241212/utmutex-434)
[ 1.0000040] ACPI Error: Mutex [ACPI_MTX_Tables] (0x2) is not acquired, cannot release (20241212/utmutex-475)
[ 1.0000040] cpu0: Geode(TM) Integrated Processor by AMD PCS, id 0x5a2
[ 1.0000040] cpu0: node 0, package 0, core 0, smt 0
[ 1.0000040] pci0 at mainbus0 bus 0: configuration mode 1
[ 1.0000040] pchb0 at pci0 dev 1 function 0: AMD Geode LX Host-PCI Bridge (rev. 0x33)
[ 1.0000040] glxsb0 at pci0 dev 1 function 2: RNG AES
[ 1.0000040] vr0 at pci0 dev 9 function 0: VIA Technologies VT6105M (Rhine III) 10/100 Ethernet (rev. 0x96)
[ 1.0000040] vr0: interrupting at irq 10
[ 1.0000040] vr0: Ethernet address 00:0d:b9:15:22:14
[ 1.0000040] ukphy0 at vr0 phy 1: OUI 0x0002c6, model 0x0034, rev. 3
[ 1.0000040] ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
[ 1.0000040] vr1 at pci0 dev 10 function 0: VIA Technologies VT6105M (Rhine III) 10/100 Ethernet (rev. 0x96)
[ 1.0000040] vr1: interrupting at irq 11
[ 1.0000040] vr1: Ethernet address 00:0d:b9:15:22:15
[ 1.0000040] ukphy1 at vr1 phy 1: OUI 0x0002c6, model 0x0034, rev. 3
[ 1.0000040] ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
[ 1.0000040] vr2 at pci0 dev 11 function 0: VIA Technologies VT6105M (Rhine III) 10/100 Ethernet (rev. 0x96)
[ 1.0000040] vr2: interrupting at irq 12
[ 1.0000040] vr2: Ethernet address 00:0d:b9:15:22:16
[ 1.0000040] ukphy2 at vr2 phy 1: OUI 0x0002c6, model 0x0034, rev. 3
[ 1.0000040] ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
[ 1.0000040] gcscpcib0 at pci0 dev 15 function 0: AMD CS5536 PCI-ISA Bridge (rev. 0x03)
[ 1.0057994] gcscpcib0: Watchdog Timer via MFGPT0, GPIO
[ 1.0057994] gpio0 at gcscpcib0: 32 pins
[ 1.0057994] viaide0 at pci0 dev 15 function 2: AMD CS5536 IDE Controller (rev. 0x01)
[ 1.0057994] viaide0: primary channel interrupting at irq 14
[ 1.0057994] atabus0 at viaide0 channel 0
[ 1.0057994] viaide0: secondary channel ignored (disabled)
[ 1.0057994] ohci0 at pci0 dev 15 function 4: AMD CS5536 OHCI USB Controller (rev. 0x02)
[ 1.0057994] ohci0: interrupting at irq 15
[ 1.0057994] ohci0: OHCI version 1.0, legacy support
[ 1.0057994] usb0 at ohci0: USB revision 1.0
[ 1.0057994] gcscehci0 at pci0 dev 15 function 5: AMD CS5536 EHCI USB Controller (rev. 0x02)
[ 1.0057994] gcscehci0: interrupting at irq 15
[ 1.0057994] gcscehci0: 1 companion controller, 4 ports: ohci0
[ 1.0057994] gcscehci0: Using DMA subregion for control data structures
[ 1.0057994] usb1 at gcscehci0: USB revision 2.0
[ 1.0057994] isa0 at gcscpcib0
[ 1.0057994] com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, 16-byte FIFO
[ 1.0057994] com0: console
[ 1.0057994] attimer0 at isa0 port 0x40-0x43
[ 1.0057994] pcppi0 at isa0 port 0x61
[ 1.0057994] midi0 at pcppi0: PC speaker
[ 1.0057994] sysbeep0 at pcppi0
[ 1.0057994] isapnp0 at isa0 port 0x279
[ 1.0057994] attimer0: attached to pcppi0
[ 1.0057994] WARNING: system needs entropy for security; see entropy(7)
[ 1.1900868] uhub0 at usb0: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev 1.00/1.00, addr 1
[ 1.2180982] uhub1 at usb1: NetBSD (0x0000) EHCI root hub (0x0000), class 9/0, rev 2.00/1.00, addr 1
[ 1.2500849] entropy: ready
[ 1.7500904] swwdog0: software watchdog initialized
[ 1.7667646] WARNING: 1 error while detecting hardware; check system log.
[ 1.7867928] boot device: vr0
[ 1.7953523] root on vr0
[ 1.8026381] nfs_boot: trying DHCP/BOOTP
[ 19.8203658] nfs_boot: timeout...
[ 24.8204446] nfs_boot: timeout...
[ 29.8205195] nfs_boot: timeout...
[ 34.8205982] nfs_boot: trying RARP (and RPC/bootparam)
[ 34.8505981] vr0: using force reset command.
[ 47.8607989] revarp failed, error=51
[ 47.8764193] Supported file systems: mfs lfs ffs ext2fs nfs umap procfs overlay null kernfs fdesc union tmpfs puffs ptyfs ntfs msdos efs cd9660 coda
[ 47.9112556] no file system for vr0
[ 47.9255498] cannot mount root, error = 79
[ 47.9380282] root device (default vr0):
---
After that it's waiting at the console for inputs.
Just pressing enter several times (root device, dump device, file-system, init) booting continues:
---
[ 47.9380282] root device (default vr0):
[ 48.0934634] dump device:
[ 49.0017294] file system (default generic):
[ 49.7203006] root on vr0
[ 49.7271053] nfs_boot: trying DHCP/BOOTP
[ 52.7417650] nfs_boot: DHCP next-server: 192.168.10.6
[ 52.7643841] nfs_boot: my_domain=lissner.home
[ 52.7771070] nfs_boot: my_addr=192.168.10.8
[ 52.7893228] nfs_boot: my_mask=255.255.240.0
[ 52.8018160] nfs_boot: gateway=192.168.10.2
[ 58.8118575] root on papaya:/srv/diskless/netbsd0/root
[ 58.8310180] root file system type: nfs
[ 58.8422158] kern.module.path=/stand/i386/11.0/modules
[ 58.8575345] init path (default /sbin/init):
[ 59.8588760] init: trying /sbin/init
Sun Oct 4 16:26:39 -00 2026
Not checking /: fs_passno = 0 in /etc/fstab
Setting sysctl variables:
ddb.onpanic: 1 -> 0
Starting file system checks:
[ 61.2919464] papaya:/srv/diskless/netbsd0/root: inaccurate wcc data (ctime) detected, disabling wcc (ctime 1791131203.186064145 1791131203.186064145, mtime 1791131203.186064145 1791131203.186064145)
Loaded entropy from /var/db/entropy-file.
Waiting for entropy...done
Setting tty flags.
Starting network.
Hostname: melone2
IPv6 mode: host
Configuring network interfaces:.
Adding interface aliases:.
add net default: gateway 192.168.10.2
Waiting for duplicate address detection to finish...
Building databases: dev, utmp, utmpx.
Starting syslogd.
Mounting all file systems...
Clearing temporary files.
Creating a.out runtime link editor directory cache.
Checking quotas: done.
/etc/rc: WARNING: No swap space configured!
/etc/rc.d/swap2 exited with code 1
Starting virecover.
Checking for core dump...
savecore: no core dump (no dumpdev)
Creating /var/run/munin...
Starting local daemons:.
Updating motd.
Starting ntpd.
Starting powerd.
Starting sshd.
Starting postfix.
postfix/postlog: starting the Postfix mail system
Starting munin_node.
Starting inetd.
Starting cron.
The following components reported failures:
/etc/rc.d/swap2
See /var/run/rc.log for more information.
Sun Oct 4 18:27:07 CEST 2026
NetBSD/i386 (melone2) (constty)
login:
---
The log of the tftp/dhcp-server (a linux machine) shows several DHCPDISCOVER and DHCPOFFER lines after the kernel has been requested several times:
---
2026-10-04T18:23:03.082995+02:00 papaya in.tftpd[21402]: RRQ from 192.168.10.8 filename netbsd0/root/netbsd
2026-10-04T18:23:03.087076+02:00 papaya in.tftpd[21403]: RRQ from 192.168.10.8 filename netbsd0/root/netbsd
2026-10-04T18:23:24.748493+02:00 papaya in.tftpd[21404]: RRQ from 192.168.10.8 filename netbsd0/root/netbsd
2026-10-04T18:23:48.175746+02:00 papaya in.tftpd[21405]: RRQ from 192.168.10.8 filename netbsd0/root/netbsd
2026-10-04T18:24:09.792481+02:00 papaya in.tftpd[21406]: RRQ from 192.168.10.8 filename netbsd0/root/netbsd
2026-10-04T18:24:45.696587+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 00:0d:b9:15:22:14 via eth0
2026-10-04T18:24:45.696601+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.168.10.8 to 00:0d:b9:15:22:14 via eth0
2026-10-04T18:24:46.696637+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 00:0d:b9:15:22:14 via eth0
2026-10-04T18:24:46.696672+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.168.10.8 to 00:0d:b9:15:22:14 via eth0
2026-10-04T18:24:48.696964+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 00:0d:b9:15:22:14 via eth0
2026-10-04T18:24:48.696993+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.168.10.8 to 00:0d:b9:15:22:14 via eth0
2026-10-04T18:24:51.697545+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 00:0d:b9:15:22:14 via eth0
2026-10-04T18:24:51.697559+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.168.10.8 to 00:0d:b9:15:22:14 via eth0
2026-10-04T18:24:55.698425+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 00:0d:b9:15:22:14 via eth0
2026-10-04T18:24:55.698499+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.168.10.8 to 00:0d:b9:15:22:14 via eth0
2026-10-04T18:25:00.708539+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 00:0d:b9:15:22:14 via eth0
2026-10-04T18:25:00.709251+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.168.10.8 to 00:0d:b9:15:22:14 via eth0
2026-10-04T18:25:05.709148+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 00:0d:b9:15:22:14 via eth0
2026-10-04T18:25:05.709162+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.168.10.8 to 00:0d:b9:15:22:14 via eth0
2026-10-04T18:25:10.710081+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 00:0d:b9:15:22:14 via eth0
2026-10-04T18:25:10.710096+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.168.10.8 to 00:0d:b9:15:22:14 via eth0
---
The same machine does not show this behaviour when using Linux (but linux does not support the Alix any longer, so I need a replacement ...)
>How-To-Repeat:
Just reboot several times.
Sometimes it happens at the 3rd attemt, sometimes it takes some more.
>Fix:
continuing on the serial console works. but this is not satisfying; console is not always connected.
Doing cold-start (happened often enough before pxe-booting worked) did not show this behaviour.
>Release-Note:
>Audit-Trail:
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: netbsd@lissners.de
Subject: Re: port-i386/60848: Alix fails to boot sometimes after warmstart,
very likely due to network initialization
Date: Tue, 6 Oct 2026 13:01:25 +0300
--0000000000008f137a065d2915e1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sun, Oct 4, 2026 at 8:00=E2=80=AFPM netbsd@lissners.de via gnats
<gnats-admin@netbsd.org> wrote:
>
> >Number: 60848
> >Category: port-i386
> >Synopsis: Alix fails to boot sometimes after warmstart, very likel=
y due to network initialization
> >Confidential: no
> >Severity: serious
> >Priority: medium
> >Responsible: port-i386-maintainer
> >State: open
> >Class: sw-bug
> >Submitter-Id: net
> >Arrival-Date: Sun Oct 04 17:00:00 +0000 2026
> >Originator: Ekkehard
> >Release: Netbsd11
> >Organization:
> >Environment:
> NetBSD melone2 11.0 NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 UTC 202=
6 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC i386
> >Description:
> I configured a PC-Engines Alix with 3 ethernet-ports to boot via pxe/dhcp=
as headless nfs-root machine. I created a new pxeboot_ia32_com0 to work wi=
th com0 at 38400.
> In most cases, booting this setup works.
> But sometimes when doing a warmstart ("reboot" from the running system), =
booting hangs when trying to mount the root-filesystem as nfs.
>
> Here is the log from the serial console:
> ---
> PC Engines ALIX.2 v0.99
> 640 KB Base Memory
> 261120 KB Extended Memory
> Waiting for HDD .....................
>
> 01F0 - no drive found !
>
> Intel UNDI, PXE-2.0 (build 082)
> Copyright (C) 1997,1998,1999 Intel Corporation
> VIA Rhine III Management Adapter v2.43 (2005/12/15)
>
> CLIENT MAC ADDR: 00 0D B9 15 22 14
> CLIENT IP: 192.168.10.8 MASK: 255.255.240.0 DHCP IP: 192.168.10.6
> GATEWAY IP: 192.168.10.2
>
>
> \\-__,------,___.
> \\ __,---` NetBSD/x86 PXE Boot
> \\ `---,_. Revision 5.2 (Sun Oct 4 14:23:18 UTC 2026)
> \\-,_____,.---`
> \\
> \\
> \\
>
> Press return to boot now, any other key for boot menu
> booting netbsd - starting in 0 seconds.
> PXE BIOS Version 2.1
> Using PCI device at bus 0 device 9 function 0
> Ethernet address 00:0d:b9:15:22:14
> 20607664+593992+745400 [990792+947152+1036453]=3D0x17c5a7c
> [ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 20=
03,
> [ 1.0000000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, =
2013,
> [ 1.0000000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, =
2023,
> [ 1.0000000] 2024, 2025, 2026
> [ 1.0000000] The NetBSD Foundation, Inc. All rights reserved.
> [ 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
> [ 1.0000000] The Regents of the University of California. All righ=
ts reserved.
>
> [ 1.0000000] NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 UTC 2026
> [ 1.0000000] mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile=
/GENERIC
> [ 1.0000000] total memory =3D 255 MB
> [ 1.0000000] avail memory =3D 227 MB
> [ 1.0000040] mainbus0 (root)
> [ 1.0000040] Firmware Error (ACPI): A valid RSDP was not found (2024121=
2/tbxfroot-383)
> acpi_probe: failed to initialize tables
> [ 1.0000040] ACPI Error: Could not remove SCI handler (20241212/evmisc-=
424)
> [ 1.0000040] cpu0 at mainbus0
> [ 1.0000040] ACPI Error: AE_BAD_PARAMETER, Thread 3243335680 could not =
acquire Mutex [ACPI_MTX_Tables] (0x2) (20241212/utmutex-434)
> [ 1.0000040] ACPI Error: Mutex [ACPI_MTX_Tables] (0x2) is not acquired,=
cannot release (20241212/utmutex-475)
> [ 1.0000040] cpu0: Geode(TM) Integrated Processor by AMD PCS, id 0x5a2
> [ 1.0000040] cpu0: node 0, package 0, core 0, smt 0
> [ 1.0000040] pci0 at mainbus0 bus 0: configuration mode 1
> [ 1.0000040] pchb0 at pci0 dev 1 function 0: AMD Geode LX Host-PCI Brid=
ge (rev. 0x33)
> [ 1.0000040] glxsb0 at pci0 dev 1 function 2: RNG AES
> [ 1.0000040] vr0 at pci0 dev 9 function 0: VIA Technologies VT6105M (Rh=
ine III) 10/100 Ethernet (rev. 0x96)
> [ 1.0000040] vr0: interrupting at irq 10
> [ 1.0000040] vr0: Ethernet address 00:0d:b9:15:22:14
> [ 1.0000040] ukphy0 at vr0 phy 1: OUI 0x0002c6, model 0x0034, rev. 3
> [ 1.0000040] ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, au=
to
> [ 1.0000040] vr1 at pci0 dev 10 function 0: VIA Technologies VT6105M (R=
hine III) 10/100 Ethernet (rev. 0x96)
> [ 1.0000040] vr1: interrupting at irq 11
> [ 1.0000040] vr1: Ethernet address 00:0d:b9:15:22:15
> [ 1.0000040] ukphy1 at vr1 phy 1: OUI 0x0002c6, model 0x0034, rev. 3
> [ 1.0000040] ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, au=
to
> [ 1.0000040] vr2 at pci0 dev 11 function 0: VIA Technologies VT6105M (R=
hine III) 10/100 Ethernet (rev. 0x96)
> [ 1.0000040] vr2: interrupting at irq 12
> [ 1.0000040] vr2: Ethernet address 00:0d:b9:15:22:16
> [ 1.0000040] ukphy2 at vr2 phy 1: OUI 0x0002c6, model 0x0034, rev. 3
> [ 1.0000040] ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, au=
to
> [ 1.0000040] gcscpcib0 at pci0 dev 15 function 0: AMD CS5536 PCI-ISA Br=
idge (rev. 0x03)
> [ 1.0057994] gcscpcib0: Watchdog Timer via MFGPT0, GPIO
> [ 1.0057994] gpio0 at gcscpcib0: 32 pins
> [ 1.0057994] viaide0 at pci0 dev 15 function 2: AMD CS5536 IDE Controll=
er (rev. 0x01)
> [ 1.0057994] viaide0: primary channel interrupting at irq 14
> [ 1.0057994] atabus0 at viaide0 channel 0
> [ 1.0057994] viaide0: secondary channel ignored (disabled)
> [ 1.0057994] ohci0 at pci0 dev 15 function 4: AMD CS5536 OHCI USB Contr=
oller (rev. 0x02)
> [ 1.0057994] ohci0: interrupting at irq 15
> [ 1.0057994] ohci0: OHCI version 1.0, legacy support
> [ 1.0057994] usb0 at ohci0: USB revision 1.0
> [ 1.0057994] gcscehci0 at pci0 dev 15 function 5: AMD CS5536 EHCI USB C=
ontroller (rev. 0x02)
> [ 1.0057994] gcscehci0: interrupting at irq 15
> [ 1.0057994] gcscehci0: 1 companion controller, 4 ports: ohci0
> [ 1.0057994] gcscehci0: Using DMA subregion for control data structures
> [ 1.0057994] usb1 at gcscehci0: USB revision 2.0
> [ 1.0057994] isa0 at gcscpcib0
> [ 1.0057994] com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, 16-byte FIF=
O
> [ 1.0057994] com0: console
> [ 1.0057994] attimer0 at isa0 port 0x40-0x43
> [ 1.0057994] pcppi0 at isa0 port 0x61
> [ 1.0057994] midi0 at pcppi0: PC speaker
> [ 1.0057994] sysbeep0 at pcppi0
> [ 1.0057994] isapnp0 at isa0 port 0x279
> [ 1.0057994] attimer0: attached to pcppi0
> [ 1.0057994] WARNING: system needs entropy for security; see entropy(7)
> [ 1.1900868] uhub0 at usb0: NetBSD (0x0000) OHCI root hub (0x0000), cla=
ss 9/0, rev 1.00/1.00, addr 1
> [ 1.2180982] uhub1 at usb1: NetBSD (0x0000) EHCI root hub (0x0000), cla=
ss 9/0, rev 2.00/1.00, addr 1
> [ 1.2500849] entropy: ready
> [ 1.7500904] swwdog0: software watchdog initialized
> [ 1.7667646] WARNING: 1 error while detecting hardware; check system lo=
g.
> [ 1.7867928] boot device: vr0
> [ 1.7953523] root on vr0
> [ 1.8026381] nfs_boot: trying DHCP/BOOTP
> [ 19.8203658] nfs_boot: timeout...
> [ 24.8204446] nfs_boot: timeout...
> [ 29.8205195] nfs_boot: timeout...
> [ 34.8205982] nfs_boot: trying RARP (and RPC/bootparam)
> [ 34.8505981] vr0: using force reset command.
> [ 47.8607989] revarp failed, error=3D51
> [ 47.8764193] Supported file systems: mfs lfs ffs ext2fs nfs umap procfs=
overlay null kernfs fdesc union tmpfs puffs ptyfs ntfs msdos efs cd9660 co=
da
> [ 47.9112556] no file system for vr0
> [ 47.9255498] cannot mount root, error =3D 79
> [ 47.9380282] root device (default vr0):
> ---
>
> After that it's waiting at the console for inputs.
> Just pressing enter several times (root device, dump device, file-system,=
init) booting continues:
> ---
> [ 47.9380282] root device (default vr0):
> [ 48.0934634] dump device:
> [ 49.0017294] file system (default generic):
> [ 49.7203006] root on vr0
> [ 49.7271053] nfs_boot: trying DHCP/BOOTP
> [ 52.7417650] nfs_boot: DHCP next-server: 192.168.10.6
> [ 52.7643841] nfs_boot: my_domain=3Dlissner.home
> [ 52.7771070] nfs_boot: my_addr=3D192.168.10.8
> [ 52.7893228] nfs_boot: my_mask=3D255.255.240.0
> [ 52.8018160] nfs_boot: gateway=3D192.168.10.2
> [ 58.8118575] root on papaya:/srv/diskless/netbsd0/root
> [ 58.8310180] root file system type: nfs
> [ 58.8422158] kern.module.path=3D/stand/i386/11.0/modules
> [ 58.8575345] init path (default /sbin/init):
> [ 59.8588760] init: trying /sbin/init
> Sun Oct 4 16:26:39 -00 2026
> Not checking /: fs_passno =3D 0 in /etc/fstab
> Setting sysctl variables:
> ddb.onpanic: 1 -> 0
> Starting file system checks:
> [ 61.2919464] papaya:/srv/diskless/netbsd0/root: inaccurate wcc data (ct=
ime) detected, disabling wcc (ctime 1791131203.186064145 1791131203.1860641=
45, mtime 1791131203.186064145 1791131203.186064145)
> Loaded entropy from /var/db/entropy-file.
> Waiting for entropy...done
> Setting tty flags.
> Starting network.
> Hostname: melone2
> IPv6 mode: host
> Configuring network interfaces:.
> Adding interface aliases:.
> add net default: gateway 192.168.10.2
> Waiting for duplicate address detection to finish...
> Building databases: dev, utmp, utmpx.
> Starting syslogd.
> Mounting all file systems...
> Clearing temporary files.
> Creating a.out runtime link editor directory cache.
> Checking quotas: done.
> /etc/rc: WARNING: No swap space configured!
> /etc/rc.d/swap2 exited with code 1
> Starting virecover.
> Checking for core dump...
> savecore: no core dump (no dumpdev)
> Creating /var/run/munin...
> Starting local daemons:.
> Updating motd.
> Starting ntpd.
> Starting powerd.
> Starting sshd.
> Starting postfix.
> postfix/postlog: starting the Postfix mail system
> Starting munin_node.
> Starting inetd.
> Starting cron.
> The following components reported failures:
> /etc/rc.d/swap2
> See /var/run/rc.log for more information.
> Sun Oct 4 18:27:07 CEST 2026
>
> NetBSD/i386 (melone2) (constty)
>
> login:
>
> ---
>
> The log of the tftp/dhcp-server (a linux machine) shows several DHCPDISCO=
VER and DHCPOFFER lines after the kernel has been requested several times:
> ---
> 2026-10-04T18:23:03.082995+02:00 papaya in.tftpd[21402]: RRQ from 192.168=
.10.8 filename netbsd0/root/netbsd
> 2026-10-04T18:23:03.087076+02:00 papaya in.tftpd[21403]: RRQ from 192.168=
.10.8 filename netbsd0/root/netbsd
> 2026-10-04T18:23:24.748493+02:00 papaya in.tftpd[21404]: RRQ from 192.168=
.10.8 filename netbsd0/root/netbsd
> 2026-10-04T18:23:48.175746+02:00 papaya in.tftpd[21405]: RRQ from 192.168=
.10.8 filename netbsd0/root/netbsd
> 2026-10-04T18:24:09.792481+02:00 papaya in.tftpd[21406]: RRQ from 192.168=
.10.8 filename netbsd0/root/netbsd
> 2026-10-04T18:24:45.696587+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 0=
0:0d:b9:15:22:14 via eth0
> 2026-10-04T18:24:45.696601+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.16=
8.10.8 to 00:0d:b9:15:22:14 via eth0
> 2026-10-04T18:24:46.696637+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 0=
0:0d:b9:15:22:14 via eth0
> 2026-10-04T18:24:46.696672+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.16=
8.10.8 to 00:0d:b9:15:22:14 via eth0
> 2026-10-04T18:24:48.696964+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 0=
0:0d:b9:15:22:14 via eth0
> 2026-10-04T18:24:48.696993+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.16=
8.10.8 to 00:0d:b9:15:22:14 via eth0
> 2026-10-04T18:24:51.697545+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 0=
0:0d:b9:15:22:14 via eth0
> 2026-10-04T18:24:51.697559+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.16=
8.10.8 to 00:0d:b9:15:22:14 via eth0
> 2026-10-04T18:24:55.698425+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 0=
0:0d:b9:15:22:14 via eth0
> 2026-10-04T18:24:55.698499+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.16=
8.10.8 to 00:0d:b9:15:22:14 via eth0
> 2026-10-04T18:25:00.708539+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 0=
0:0d:b9:15:22:14 via eth0
> 2026-10-04T18:25:00.709251+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.16=
8.10.8 to 00:0d:b9:15:22:14 via eth0
> 2026-10-04T18:25:05.709148+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 0=
0:0d:b9:15:22:14 via eth0
> 2026-10-04T18:25:05.709162+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.16=
8.10.8 to 00:0d:b9:15:22:14 via eth0
> 2026-10-04T18:25:10.710081+02:00 papaya dhcpd[18181]: DHCPDISCOVER from 0=
0:0d:b9:15:22:14 via eth0
> 2026-10-04T18:25:10.710096+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.16=
8.10.8 to 00:0d:b9:15:22:14 via eth0
> ---
>
> The same machine does not show this behaviour when using Linux (but linux=
does not support the Alix any longer, so I need a replacement ...)
> >How-To-Repeat:
> Just reboot several times.
> Sometimes it happens at the 3rd attemt, sometimes it takes some more.
>
> >Fix:
> continuing on the serial console works. but this is not satisfying; conso=
le is not always connected.
>
> Doing cold-start (happened often enough before pxe-booting worked) did no=
t show this behaviour.
>
Hi,
I will try to reproduce in a coming days with the hardware I have
(using if_vr interface).
Since, I've seen forced reset, I modified a code a bit in that place
to print if reset failed and make it slightly more optimized.
I don't think so it will help to resolve the issue but at least it can
confirm that forced reset succeeds. Do you see this message on every
failure?
Another test which you can do is to comment out `if (i =3D=3D VR_TIMEOUT)
{` condition and always use force reset to see if it helps.
If it does, my biggest suspicion is that detachment/stopping code
leaves invalid or stale state which hinders initialization after a
warm reboot.
I would likely need to compare it with the Linux code.
Regards,
Andrius V
--0000000000008f137a065d2915e1
Content-Type: application/x-patch; name="if_vr.c.diff"
Content-Disposition: attachment; filename="if_vr.c.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_muwgvkql0>
X-Attachment-Id: f_muwgvkql0
ZGlmZiAtLWdpdCBhL3N5cy9kZXYvcGNpL2lmX3ZyLmMgYi9zeXMvZGV2L3BjaS9pZl92ci5jCmlu
ZGV4IGFmYzYxMGYwZTZjLi44ZGEwNTU4NDI2NiAxMDA2NDQKLS0tIGEvc3lzL2Rldi9wY2kvaWZf
dnIuYworKysgYi9zeXMvZGV2L3BjaS9pZl92ci5jCkBAIC01MjEsNiArNTIxLDcgQEAgc3RhdGlj
IHZvaWQKIHZyX3Jlc2V0KHN0cnVjdCB2cl9zb2Z0YyAqc2MpCiB7CiAJaW50IGk7CisJdWludDE2
X3QgcnN0OwogCiAJVlJfU0VUQklUMTYoc2MsIFZSX0NPTU1BTkQsIFZSX0NNRF9SRVNFVCk7CiAK
QEAgLTUyOSwyMCArNTMwLDI5IEBAIHZyX3Jlc2V0KHN0cnVjdCB2cl9zb2Z0YyAqc2MpCiAJCWlm
ICghKENTUl9SRUFEXzIoc2MsIFZSX0NPTU1BTkQpICYgVlJfQ01EX1JFU0VUKSkKIAkJCWJyZWFr
OwogCX0KKwkvKiBXYWl0IGEgbGl0dGxlIHdoaWxlIGZvciB0aGUgY2hpcCB0byBnZXQgaXRzIGJy
YWlucyBpbiBvcmRlci4gKi8KKwlpZiAoc2MtPnZyX3JldmlkIDwgUkVWX0lEX1ZUMzA2NV9BKQor
CQkJREVMQVkoMTAwMCk7CiAJaWYgKGkgPT0gVlJfVElNRU9VVCkgewotCQlpZiAoc2MtPnZyX3Jl
dmlkIDwgUkVWX0lEX1ZUMzA2NV9BKSB7Ci0JCQlhcHJpbnRfZXJyb3JfZGV2KHNjLT52cl9kZXYs
Ci0JCQkgICAgInJlc2V0IG5ldmVyIGNvbXBsZXRlZCFcbiIpOwotCQl9IGVsc2UgeworCQlpZiAo
c2MtPnZyX3JldmlkIDwgUkVWX0lEX1ZUMzA2NV9BICYmIAorCQkgICAgKENTUl9SRUFEXzIoc2Ms
IFZSX0NPTU1BTkQpICYgVlJfQ01EX1JFU0VUKSkKKwkJCQlhcHJpbnRfZXJyb3JfZGV2KHNjLT52
cl9kZXYsICJyZXNldCBuZXZlciBjb21wbGV0ZWQhXG4iKTsKKwkJZWxzZSB7CiAJCQkvKiBVc2Ug
bmV3ZXIgZm9yY2UgcmVzZXQgY29tbWFuZCAqLwogCQkJYXByaW50X25vcm1hbF9kZXYoc2MtPnZy
X2RldiwKIAkJCSAgICAidXNpbmcgZm9yY2UgcmVzZXQgY29tbWFuZC5cbiIpOwogCQkJVlJfU0VU
QklUKHNjLCBWUl9NSVNDX0NSMSwgVlJfTUlTQ0NSMV9GT1JTUlNUKTsKKworCQkJZm9yIChpID0g
MDsgaSA8IFZSX1RJTUVPVVQ7IGkrKykgeworCQkJCURFTEFZKDEwKTsKKwkJCQlyc3QgPSBDU1Jf
UkVBRF8yKHNjLCBWUl9DT01NQU5EKSAmIFZSX0NNRF9SRVNFVDsKKwkJCQlpZiAocnN0ID09IDAp
CisJCQkJCWJyZWFrOworCQkJfQorCQkJYXByaW50X25vcm1hbF9kZXYoc2MtPnZyX2RldiwgImZv
cmNlIHJlc2V0ICVzICglZCB1cylcbiIsCisJCQkJcnN0ID8gImRpZCBub3QgY29tcGxldGUiIDog
ImRvbmUiLCAoaSArIDEpICogMTApOwogCQl9CiAJfQotCi0JLyogV2FpdCBhIGxpdHRsZSB3aGls
ZSBmb3IgdGhlIGNoaXAgdG8gZ2V0IGl0cyBicmFpbnMgaW4gb3JkZXIuICovCi0JREVMQVkoMTAw
MCk7CiB9CiAKIC8qCg==
--0000000000008f137a065d2915e1--
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/60848: Alix fails to boot sometimes after warmstart,
very likely due to network initialization
Date: Fri, 9 Oct 2026 09:15:55 +0300
On Tue, Oct 6, 2026 at 1:01=E2=80=AFPM Andrius V <vezhlys@gmail.com> wrote:
>
> On Sun, Oct 4, 2026 at 8:00=E2=80=AFPM netbsd@lissners.de via gnats
> <gnats-admin@netbsd.org> wrote:
> >
> > >Number: 60848
> > >Category: port-i386
> > >Synopsis: Alix fails to boot sometimes after warmstart, very lik=
ely due to network initialization
> > >Confidential: no
> > >Severity: serious
> > >Priority: medium
> > >Responsible: port-i386-maintainer
> > >State: open
> > >Class: sw-bug
> > >Submitter-Id: net
> > >Arrival-Date: Sun Oct 04 17:00:00 +0000 2026
> > >Originator: Ekkehard
> > >Release: Netbsd11
> > >Organization:
> > >Environment:
> > NetBSD melone2 11.0 NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 UTC 2=
026 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC i386
> > >Description:
> > I configured a PC-Engines Alix with 3 ethernet-ports to boot via pxe/dh=
cp as headless nfs-root machine. I created a new pxeboot_ia32_com0 to work =
with com0 at 38400.
> > In most cases, booting this setup works.
> > But sometimes when doing a warmstart ("reboot" from the running system)=
, booting hangs when trying to mount the root-filesystem as nfs.
> >
> > Here is the log from the serial console:
> > ---
> > PC Engines ALIX.2 v0.99
> > 640 KB Base Memory
> > 261120 KB Extended Memory
> > Waiting for HDD .....................
> >
> > 01F0 - no drive found !
> >
> > Intel UNDI, PXE-2.0 (build 082)
> > Copyright (C) 1997,1998,1999 Intel Corporation
> > VIA Rhine III Management Adapter v2.43 (2005/12/15)
> >
> > CLIENT MAC ADDR: 00 0D B9 15 22 14
> > CLIENT IP: 192.168.10.8 MASK: 255.255.240.0 DHCP IP: 192.168.10.6
> > GATEWAY IP: 192.168.10.2
> >
> >
> > \\-__,------,___.
> > \\ __,---` NetBSD/x86 PXE Boot
> > \\ `---,_. Revision 5.2 (Sun Oct 4 14:23:18 UTC 2026)
> > \\-,_____,.---`
> > \\
> > \\
> > \\
> >
> > Press return to boot now, any other key for boot menu
> > booting netbsd - starting in 0 seconds.
> > PXE BIOS Version 2.1
> > Using PCI device at bus 0 device 9 function 0
> > Ethernet address 00:0d:b9:15:22:14
> > 20607664+593992+745400 [990792+947152+1036453]=3D0x17c5a7c
> > [ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, =
2003,
> > [ 1.0000000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012=
, 2013,
> > [ 1.0000000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022=
, 2023,
> > [ 1.0000000] 2024, 2025, 2026
> > [ 1.0000000] The NetBSD Foundation, Inc. All rights reserved.
> > [ 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
> > [ 1.0000000] The Regents of the University of California. All ri=
ghts reserved.
> >
> > [ 1.0000000] NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 UTC 2026
> > [ 1.0000000] mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compi=
le/GENERIC
> > [ 1.0000000] total memory =3D 255 MB
> > [ 1.0000000] avail memory =3D 227 MB
> > [ 1.0000040] mainbus0 (root)
> > [ 1.0000040] Firmware Error (ACPI): A valid RSDP was not found (20241=
212/tbxfroot-383)
> > acpi_probe: failed to initialize tables
> > [ 1.0000040] ACPI Error: Could not remove SCI handler (20241212/evmis=
c-424)
> > [ 1.0000040] cpu0 at mainbus0
> > [ 1.0000040] ACPI Error: AE_BAD_PARAMETER, Thread 3243335680 could no=
t acquire Mutex [ACPI_MTX_Tables] (0x2) (20241212/utmutex-434)
> > [ 1.0000040] ACPI Error: Mutex [ACPI_MTX_Tables] (0x2) is not acquire=
d, cannot release (20241212/utmutex-475)
> > [ 1.0000040] cpu0: Geode(TM) Integrated Processor by AMD PCS, id 0x5a=
2
> > [ 1.0000040] cpu0: node 0, package 0, core 0, smt 0
> > [ 1.0000040] pci0 at mainbus0 bus 0: configuration mode 1
> > [ 1.0000040] pchb0 at pci0 dev 1 function 0: AMD Geode LX Host-PCI Br=
idge (rev. 0x33)
> > [ 1.0000040] glxsb0 at pci0 dev 1 function 2: RNG AES
> > [ 1.0000040] vr0 at pci0 dev 9 function 0: VIA Technologies VT6105M (=
Rhine III) 10/100 Ethernet (rev. 0x96)
> > [ 1.0000040] vr0: interrupting at irq 10
> > [ 1.0000040] vr0: Ethernet address 00:0d:b9:15:22:14
> > [ 1.0000040] ukphy0 at vr0 phy 1: OUI 0x0002c6, model 0x0034, rev. 3
> > [ 1.0000040] ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, =
auto
> > [ 1.0000040] vr1 at pci0 dev 10 function 0: VIA Technologies VT6105M =
(Rhine III) 10/100 Ethernet (rev. 0x96)
> > [ 1.0000040] vr1: interrupting at irq 11
> > [ 1.0000040] vr1: Ethernet address 00:0d:b9:15:22:15
> > [ 1.0000040] ukphy1 at vr1 phy 1: OUI 0x0002c6, model 0x0034, rev. 3
> > [ 1.0000040] ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, =
auto
> > [ 1.0000040] vr2 at pci0 dev 11 function 0: VIA Technologies VT6105M =
(Rhine III) 10/100 Ethernet (rev. 0x96)
> > [ 1.0000040] vr2: interrupting at irq 12
> > [ 1.0000040] vr2: Ethernet address 00:0d:b9:15:22:16
> > [ 1.0000040] ukphy2 at vr2 phy 1: OUI 0x0002c6, model 0x0034, rev. 3
> > [ 1.0000040] ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, =
auto
> > [ 1.0000040] gcscpcib0 at pci0 dev 15 function 0: AMD CS5536 PCI-ISA =
Bridge (rev. 0x03)
> > [ 1.0057994] gcscpcib0: Watchdog Timer via MFGPT0, GPIO
> > [ 1.0057994] gpio0 at gcscpcib0: 32 pins
> > [ 1.0057994] viaide0 at pci0 dev 15 function 2: AMD CS5536 IDE Contro=
ller (rev. 0x01)
> > [ 1.0057994] viaide0: primary channel interrupting at irq 14
> > [ 1.0057994] atabus0 at viaide0 channel 0
> > [ 1.0057994] viaide0: secondary channel ignored (disabled)
> > [ 1.0057994] ohci0 at pci0 dev 15 function 4: AMD CS5536 OHCI USB Con=
troller (rev. 0x02)
> > [ 1.0057994] ohci0: interrupting at irq 15
> > [ 1.0057994] ohci0: OHCI version 1.0, legacy support
> > [ 1.0057994] usb0 at ohci0: USB revision 1.0
> > [ 1.0057994] gcscehci0 at pci0 dev 15 function 5: AMD CS5536 EHCI USB=
Controller (rev. 0x02)
> > [ 1.0057994] gcscehci0: interrupting at irq 15
> > [ 1.0057994] gcscehci0: 1 companion controller, 4 ports: ohci0
> > [ 1.0057994] gcscehci0: Using DMA subregion for control data structur=
es
> > [ 1.0057994] usb1 at gcscehci0: USB revision 2.0
> > [ 1.0057994] isa0 at gcscpcib0
> > [ 1.0057994] com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, 16-byte F=
IFO
> > [ 1.0057994] com0: console
> > [ 1.0057994] attimer0 at isa0 port 0x40-0x43
> > [ 1.0057994] pcppi0 at isa0 port 0x61
> > [ 1.0057994] midi0 at pcppi0: PC speaker
> > [ 1.0057994] sysbeep0 at pcppi0
> > [ 1.0057994] isapnp0 at isa0 port 0x279
> > [ 1.0057994] attimer0: attached to pcppi0
> > [ 1.0057994] WARNING: system needs entropy for security; see entropy(=
7)
> > [ 1.1900868] uhub0 at usb0: NetBSD (0x0000) OHCI root hub (0x0000), c=
lass 9/0, rev 1.00/1.00, addr 1
> > [ 1.2180982] uhub1 at usb1: NetBSD (0x0000) EHCI root hub (0x0000), c=
lass 9/0, rev 2.00/1.00, addr 1
> > [ 1.2500849] entropy: ready
> > [ 1.7500904] swwdog0: software watchdog initialized
> > [ 1.7667646] WARNING: 1 error while detecting hardware; check system =
log.
> > [ 1.7867928] boot device: vr0
> > [ 1.7953523] root on vr0
> > [ 1.8026381] nfs_boot: trying DHCP/BOOTP
> > [ 19.8203658] nfs_boot: timeout...
> > [ 24.8204446] nfs_boot: timeout...
> > [ 29.8205195] nfs_boot: timeout...
> > [ 34.8205982] nfs_boot: trying RARP (and RPC/bootparam)
> > [ 34.8505981] vr0: using force reset command.
> > [ 47.8607989] revarp failed, error=3D51
> > [ 47.8764193] Supported file systems: mfs lfs ffs ext2fs nfs umap proc=
fs overlay null kernfs fdesc union tmpfs puffs ptyfs ntfs msdos efs cd9660 =
coda
> > [ 47.9112556] no file system for vr0
> > [ 47.9255498] cannot mount root, error =3D 79
> > [ 47.9380282] root device (default vr0):
> > ---
> >
> > After that it's waiting at the console for inputs.
> > Just pressing enter several times (root device, dump device, file-syste=
m, init) booting continues:
> > ---
> > [ 47.9380282] root device (default vr0):
> > [ 48.0934634] dump device:
> > [ 49.0017294] file system (default generic):
> > [ 49.7203006] root on vr0
> > [ 49.7271053] nfs_boot: trying DHCP/BOOTP
> > [ 52.7417650] nfs_boot: DHCP next-server: 192.168.10.6
> > [ 52.7643841] nfs_boot: my_domain=3Dlissner.home
> > [ 52.7771070] nfs_boot: my_addr=3D192.168.10.8
> > [ 52.7893228] nfs_boot: my_mask=3D255.255.240.0
> > [ 52.8018160] nfs_boot: gateway=3D192.168.10.2
> > [ 58.8118575] root on papaya:/srv/diskless/netbsd0/root
> > [ 58.8310180] root file system type: nfs
> > [ 58.8422158] kern.module.path=3D/stand/i386/11.0/modules
> > [ 58.8575345] init path (default /sbin/init):
> > [ 59.8588760] init: trying /sbin/init
> > Sun Oct 4 16:26:39 -00 2026
> > Not checking /: fs_passno =3D 0 in /etc/fstab
> > Setting sysctl variables:
> > ddb.onpanic: 1 -> 0
> > Starting file system checks:
> > [ 61.2919464] papaya:/srv/diskless/netbsd0/root: inaccurate wcc data (=
ctime) detected, disabling wcc (ctime 1791131203.186064145 1791131203.18606=
4145, mtime 1791131203.186064145 1791131203.186064145)
> > Loaded entropy from /var/db/entropy-file.
> > Waiting for entropy...done
> > Setting tty flags.
> > Starting network.
> > Hostname: melone2
> > IPv6 mode: host
> > Configuring network interfaces:.
> > Adding interface aliases:.
> > add net default: gateway 192.168.10.2
> > Waiting for duplicate address detection to finish...
> > Building databases: dev, utmp, utmpx.
> > Starting syslogd.
> > Mounting all file systems...
> > Clearing temporary files.
> > Creating a.out runtime link editor directory cache.
> > Checking quotas: done.
> > /etc/rc: WARNING: No swap space configured!
> > /etc/rc.d/swap2 exited with code 1
> > Starting virecover.
> > Checking for core dump...
> > savecore: no core dump (no dumpdev)
> > Creating /var/run/munin...
> > Starting local daemons:.
> > Updating motd.
> > Starting ntpd.
> > Starting powerd.
> > Starting sshd.
> > Starting postfix.
> > postfix/postlog: starting the Postfix mail system
> > Starting munin_node.
> > Starting inetd.
> > Starting cron.
> > The following components reported failures:
> > /etc/rc.d/swap2
> > See /var/run/rc.log for more information.
> > Sun Oct 4 18:27:07 CEST 2026
> >
> > NetBSD/i386 (melone2) (constty)
> >
> > login:
> >
> > ---
> >
> > The log of the tftp/dhcp-server (a linux machine) shows several DHCPDIS=
COVER and DHCPOFFER lines after the kernel has been requested several times=
:
> > ---
> > 2026-10-04T18:23:03.082995+02:00 papaya in.tftpd[21402]: RRQ from 192.1=
68.10.8 filename netbsd0/root/netbsd
> > 2026-10-04T18:23:03.087076+02:00 papaya in.tftpd[21403]: RRQ from 192.1=
68.10.8 filename netbsd0/root/netbsd
> > 2026-10-04T18:23:24.748493+02:00 papaya in.tftpd[21404]: RRQ from 192.1=
68.10.8 filename netbsd0/root/netbsd
> > 2026-10-04T18:23:48.175746+02:00 papaya in.tftpd[21405]: RRQ from 192.1=
68.10.8 filename netbsd0/root/netbsd
> > 2026-10-04T18:24:09.792481+02:00 papaya in.tftpd[21406]: RRQ from 192.1=
68.10.8 filename netbsd0/root/netbsd
> > 2026-10-04T18:24:45.696587+02:00 papaya dhcpd[18181]: DHCPDISCOVER from=
00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:24:45.696601+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.=
168.10.8 to 00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:24:46.696637+02:00 papaya dhcpd[18181]: DHCPDISCOVER from=
00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:24:46.696672+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.=
168.10.8 to 00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:24:48.696964+02:00 papaya dhcpd[18181]: DHCPDISCOVER from=
00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:24:48.696993+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.=
168.10.8 to 00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:24:51.697545+02:00 papaya dhcpd[18181]: DHCPDISCOVER from=
00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:24:51.697559+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.=
168.10.8 to 00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:24:55.698425+02:00 papaya dhcpd[18181]: DHCPDISCOVER from=
00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:24:55.698499+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.=
168.10.8 to 00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:25:00.708539+02:00 papaya dhcpd[18181]: DHCPDISCOVER from=
00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:25:00.709251+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.=
168.10.8 to 00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:25:05.709148+02:00 papaya dhcpd[18181]: DHCPDISCOVER from=
00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:25:05.709162+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.=
168.10.8 to 00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:25:10.710081+02:00 papaya dhcpd[18181]: DHCPDISCOVER from=
00:0d:b9:15:22:14 via eth0
> > 2026-10-04T18:25:10.710096+02:00 papaya dhcpd[18181]: DHCPOFFER on 192.=
168.10.8 to 00:0d:b9:15:22:14 via eth0
> > ---
> >
> > The same machine does not show this behaviour when using Linux (but lin=
ux does not support the Alix any longer, so I need a replacement ...)
> > >How-To-Repeat:
> > Just reboot several times.
> > Sometimes it happens at the 3rd attemt, sometimes it takes some more.
> >
> > >Fix:
> > continuing on the serial console works. but this is not satisfying; con=
sole is not always connected.
> >
> > Doing cold-start (happened often enough before pxe-booting worked) did =
not show this behaviour.
> >
>
> Hi,
>
> I will try to reproduce in a coming days with the hardware I have
> (using if_vr interface).
>
> Since, I've seen forced reset, I modified a code a bit in that place
> to print if reset failed and make it slightly more optimized.
>
> I don't think so it will help to resolve the issue but at least it can
> confirm that forced reset succeeds. Do you see this message on every
> failure?
>
> Another test which you can do is to comment out `if (i =3D=3D VR_TIMEOUT)
> {` condition and always use force reset to see if it helps.
>
> If it does, my biggest suspicion is that detachment/stopping code
> leaves invalid or stale state which hinders initialization after a
> warm reboot.
> I would likely need to compare it with the Linux code.
>
> Regards,
> Andrius V
Hi,
Just wanted to update that I managed to reproduce the issue, however
it happens too rarely for me to properly debug.
So, I can't promise I will find a fast solution, but I will be
investigating for a while.
How often does it actually happen to you? For me I can barely hit this
issue in multiple reboots.
If I do it may repeat once or twice, but once it's gone, it is close
to impossible to reproduce again.
From: netbsd@lissners.de
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/60848: Alix fails to boot sometimes after warmstart,
very likely due to network initialization
Date: Fri, 9 Oct 2026 12:51:08 +0200
Am 09.10.26 um 8:20 AM schrieb Andrius V via gnats:
> The following reply was made to PR port-i386/60848; it has been noted by=
GNATS.
>=20
> From: Andrius V <vezhlys@gmail.com>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: port-i386/60848: Alix fails to boot sometimes after warmsta=
rt,
> very likely due to network initialization
> Date: Fri, 9 Oct 2026 09:15:55 +0300
>=20
> On Tue, Oct 6, 2026 at 1:01=3DE2=3D80=3DAFPM Andrius V <vezhlys@gmail.=
com> wrote:
> >
> > On Sun, Oct 4, 2026 at 8:00=3DE2=3D80=3DAFPM netbsd@lissners.de via =
gnats
> > <gnats-admin@netbsd.org> wrote:
> > >
> > > >Number: 60848
> > > >Category: port-i386
> > > >Synopsis: Alix fails to boot sometimes after warmstart, ver=
y lik=3D
> ely due to network initialization
> > > >Confidential: no
> > > >Severity: serious
> > > >Priority: medium
> > > >Responsible: port-i386-maintainer
> > > >State: open
> > > >Class: sw-bug
> > > >Submitter-Id: net
> > > >Arrival-Date: Sun Oct 04 17:00:00 +0000 2026
> > > >Originator: Ekkehard
> > > >Release: Netbsd11
> > > >Organization:
> > > >Environment:
> > > NetBSD melone2 11.0 NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 =
UTC 2=3D
> 026 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC=
i386
> > > >Description:
> > > I configured a PC-Engines Alix with 3 ethernet-ports to boot via p=
xe/dh=3D
> cp as headless nfs-root machine. I created a new pxeboot_ia32_com0 to =
work =3D
> with com0 at 38400.
> > > In most cases, booting this setup works.
> > > But sometimes when doing a warmstart ("reboot" from the running sy=
stem)=3D
> , booting hangs when trying to mount the root-filesystem as nfs.
> > >
> > > Here is the log from the serial console:
> > > ---
> > > PC Engines ALIX.2 v0.99
> > > 640 KB Base Memory
> > > 261120 KB Extended Memory
> > > Waiting for HDD .....................
> > >
> > > 01F0 - no drive found !
> > >
> > > Intel UNDI, PXE-2.0 (build 082)
> > > Copyright (C) 1997,1998,1999 Intel Corporation
> > > VIA Rhine III Management Adapter v2.43 (2005/12/15)
> > >
> > > CLIENT MAC ADDR: 00 0D B9 15 22 14
> > > CLIENT IP: 192.168.10.8 MASK: 255.255.240.0 DHCP IP: 192.168.10.=
6
> > > GATEWAY IP: 192.168.10.2
> > >
> > >
> > > \\-__,------,___.
> > > \\ __,---` NetBSD/x86 PXE Boot
> > > \\ `---,_. Revision 5.2 (Sun Oct 4 14:23:18 UTC 2026)
> > > \\-,_____,.---`
> > > \\
> > > \\
> > > \\
> > >
> > > Press return to boot now, any other key for boot menu
> > > booting netbsd - starting in 0 seconds.
> > > PXE BIOS Version 2.1
> > > Using PCI device at bus 0 device 9 function 0
> > > Ethernet address 00:0d:b9:15:22:14
> > > 20607664+593992+745400 [990792+947152+1036453]=3D3D0x17c5a7c
> > > [ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2=
002, =3D
> 2003,
> > > [ 1.0000000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011,=
2012=3D
> , 2013,
> > > [ 1.0000000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021,=
2022=3D
> , 2023,
> > > [ 1.0000000] 2024, 2025, 2026
> > > [ 1.0000000] The NetBSD Foundation, Inc. All rights reserve=
d.
> > > [ 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
> > > [ 1.0000000] The Regents of the University of California. A=
ll ri=3D
> ghts reserved.
> > >
> > > [ 1.0000000] NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 UTC 2=
026
> > > [ 1.0000000] mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/=
compi=3D
> le/GENERIC
> > > [ 1.0000000] total memory =3D3D 255 MB
> > > [ 1.0000000] avail memory =3D3D 227 MB
> > > [ 1.0000040] mainbus0 (root)
> > > [ 1.0000040] Firmware Error (ACPI): A valid RSDP was not found (=
20241=3D
> 212/tbxfroot-383)
> > > acpi_probe: failed to initialize tables
> > > [ 1.0000040] ACPI Error: Could not remove SCI handler (20241212/=
evmis=3D
> c-424)
> > > [ 1.0000040] cpu0 at mainbus0
> > > [ 1.0000040] ACPI Error: AE_BAD_PARAMETER, Thread 3243335680 cou=
ld no=3D
> t acquire Mutex [ACPI_MTX_Tables] (0x2) (20241212/utmutex-434)
> > > [ 1.0000040] ACPI Error: Mutex [ACPI_MTX_Tables] (0x2) is not ac=
quire=3D
> d, cannot release (20241212/utmutex-475)
> > > [ 1.0000040] cpu0: Geode(TM) Integrated Processor by AMD PCS, id=
0x5a=3D
> 2
> > > [ 1.0000040] cpu0: node 0, package 0, core 0, smt 0
> > > [ 1.0000040] pci0 at mainbus0 bus 0: configuration mode 1
> > > [ 1.0000040] pchb0 at pci0 dev 1 function 0: AMD Geode LX Host-P=
CI Br=3D
> idge (rev. 0x33)
> > > [ 1.0000040] glxsb0 at pci0 dev 1 function 2: RNG AES
> > > [ 1.0000040] vr0 at pci0 dev 9 function 0: VIA Technologies VT61=
05M (=3D
> Rhine III) 10/100 Ethernet (rev. 0x96)
> > > [ 1.0000040] vr0: interrupting at irq 10
> > > [ 1.0000040] vr0: Ethernet address 00:0d:b9:15:22:14
> > > [ 1.0000040] ukphy0 at vr0 phy 1: OUI 0x0002c6, model 0x0034, re=
v. 3
> > > [ 1.0000040] ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-=
FDX, =3D
> auto
> > > [ 1.0000040] vr1 at pci0 dev 10 function 0: VIA Technologies VT6=
105M =3D
> (Rhine III) 10/100 Ethernet (rev. 0x96)
> > > [ 1.0000040] vr1: interrupting at irq 11
> > > [ 1.0000040] vr1: Ethernet address 00:0d:b9:15:22:15
> > > [ 1.0000040] ukphy1 at vr1 phy 1: OUI 0x0002c6, model 0x0034, re=
v. 3
> > > [ 1.0000040] ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-=
FDX, =3D
> auto
> > > [ 1.0000040] vr2 at pci0 dev 11 function 0: VIA Technologies VT6=
105M =3D
> (Rhine III) 10/100 Ethernet (rev. 0x96)
> > > [ 1.0000040] vr2: interrupting at irq 12
> > > [ 1.0000040] vr2: Ethernet address 00:0d:b9:15:22:16
> > > [ 1.0000040] ukphy2 at vr2 phy 1: OUI 0x0002c6, model 0x0034, re=
v. 3
> > > [ 1.0000040] ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-=
FDX, =3D
> auto
> > > [ 1.0000040] gcscpcib0 at pci0 dev 15 function 0: AMD CS5536 PCI=
-ISA =3D
> Bridge (rev. 0x03)
> > > [ 1.0057994] gcscpcib0: Watchdog Timer via MFGPT0, GPIO
> > > [ 1.0057994] gpio0 at gcscpcib0: 32 pins
> > > [ 1.0057994] viaide0 at pci0 dev 15 function 2: AMD CS5536 IDE C=
ontro=3D
> ller (rev. 0x01)
> > > [ 1.0057994] viaide0: primary channel interrupting at irq 14
> > > [ 1.0057994] atabus0 at viaide0 channel 0
> > > [ 1.0057994] viaide0: secondary channel ignored (disabled)
> > > [ 1.0057994] ohci0 at pci0 dev 15 function 4: AMD CS5536 OHCI US=
B Con=3D
> troller (rev. 0x02)
> > > [ 1.0057994] ohci0: interrupting at irq 15
> > > [ 1.0057994] ohci0: OHCI version 1.0, legacy support
> > > [ 1.0057994] usb0 at ohci0: USB revision 1.0
> > > [ 1.0057994] gcscehci0 at pci0 dev 15 function 5: AMD CS5536 EHC=
I USB=3D
> Controller (rev. 0x02)
> > > [ 1.0057994] gcscehci0: interrupting at irq 15
> > > [ 1.0057994] gcscehci0: 1 companion controller, 4 ports: ohci0
> > > [ 1.0057994] gcscehci0: Using DMA subregion for control data str=
uctur=3D
> es
> > > [ 1.0057994] usb1 at gcscehci0: USB revision 2.0
> > > [ 1.0057994] isa0 at gcscpcib0
> > > [ 1.0057994] com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, 16-b=
yte F=3D
> IFO
> > > [ 1.0057994] com0: console
> > > [ 1.0057994] attimer0 at isa0 port 0x40-0x43
> > > [ 1.0057994] pcppi0 at isa0 port 0x61
> > > [ 1.0057994] midi0 at pcppi0: PC speaker
> > > [ 1.0057994] sysbeep0 at pcppi0
> > > [ 1.0057994] isapnp0 at isa0 port 0x279
> > > [ 1.0057994] attimer0: attached to pcppi0
> > > [ 1.0057994] WARNING: system needs entropy for security; see ent=
ropy(=3D
> 7)
> > > [ 1.1900868] uhub0 at usb0: NetBSD (0x0000) OHCI root hub (0x000=
0), c=3D
> lass 9/0, rev 1.00/1.00, addr 1
> > > [ 1.2180982] uhub1 at usb1: NetBSD (0x0000) EHCI root hub (0x000=
0), c=3D
> lass 9/0, rev 2.00/1.00, addr 1
> > > [ 1.2500849] entropy: ready
> > > [ 1.7500904] swwdog0: software watchdog initialized
> > > [ 1.7667646] WARNING: 1 error while detecting hardware; check sy=
stem =3D
> log.
> > > [ 1.7867928] boot device: vr0
> > > [ 1.7953523] root on vr0
> > > [ 1.8026381] nfs_boot: trying DHCP/BOOTP
> > > [ 19.8203658] nfs_boot: timeout...
> > > [ 24.8204446] nfs_boot: timeout...
> > > [ 29.8205195] nfs_boot: timeout...
> > > [ 34.8205982] nfs_boot: trying RARP (and RPC/bootparam)
> > > [ 34.8505981] vr0: using force reset command.
> > > [ 47.8607989] revarp failed, error=3D3D51
> > > [ 47.8764193] Supported file systems: mfs lfs ffs ext2fs nfs umap=
proc=3D
> fs overlay null kernfs fdesc union tmpfs puffs ptyfs ntfs msdos efs cd=
9660 =3D
> coda
> > > [ 47.9112556] no file system for vr0
> > > [ 47.9255498] cannot mount root, error =3D3D 79
> > > [ 47.9380282] root device (default vr0):
> > > ---
> > >
> > > After that it's waiting at the console for inputs.
> > > Just pressing enter several times (root device, dump device, file-=
syste=3D
> m, init) booting continues:
> > > ---
> > > [ 47.9380282] root device (default vr0):
> > > [ 48.0934634] dump device:
> > > [ 49.0017294] file system (default generic):
> > > [ 49.7203006] root on vr0
> > > [ 49.7271053] nfs_boot: trying DHCP/BOOTP
> > > [ 52.7417650] nfs_boot: DHCP next-server: 192.168.10.6
> > > [ 52.7643841] nfs_boot: my_domain=3D3Dlissner.home
> > > [ 52.7771070] nfs_boot: my_addr=3D3D192.168.10.8
> > > [ 52.7893228] nfs_boot: my_mask=3D3D255.255.240.0
> > > [ 52.8018160] nfs_boot: gateway=3D3D192.168.10.2
> > > [ 58.8118575] root on papaya:/srv/diskless/netbsd0/root
> > > [ 58.8310180] root file system type: nfs
> > > [ 58.8422158] kern.module.path=3D3D/stand/i386/11.0/modules
> > > [ 58.8575345] init path (default /sbin/init):
> > > [ 59.8588760] init: trying /sbin/init
> > > Sun Oct 4 16:26:39 -00 2026
> > > Not checking /: fs_passno =3D3D 0 in /etc/fstab
> > > Setting sysctl variables:
> > > ddb.onpanic: 1 -> 0
> > > Starting file system checks:
> > > [ 61.2919464] papaya:/srv/diskless/netbsd0/root: inaccurate wcc d=
ata (=3D
> ctime) detected, disabling wcc (ctime 1791131203.186064145 1791131203.=
18606=3D
> 4145, mtime 1791131203.186064145 1791131203.186064145)
> > > Loaded entropy from /var/db/entropy-file.
> > > Waiting for entropy...done
> > > Setting tty flags.
> > > Starting network.
> > > Hostname: melone2
> > > IPv6 mode: host
> > > Configuring network interfaces:.
> > > Adding interface aliases:.
> > > add net default: gateway 192.168.10.2
> > > Waiting for duplicate address detection to finish...
> > > Building databases: dev, utmp, utmpx.
> > > Starting syslogd.
> > > Mounting all file systems...
> > > Clearing temporary files.
> > > Creating a.out runtime link editor directory cache.
> > > Checking quotas: done.
> > > /etc/rc: WARNING: No swap space configured!
> > > /etc/rc.d/swap2 exited with code 1
> > > Starting virecover.
> > > Checking for core dump...
> > > savecore: no core dump (no dumpdev)
> > > Creating /var/run/munin...
> > > Starting local daemons:.
> > > Updating motd.
> > > Starting ntpd.
> > > Starting powerd.
> > > Starting sshd.
> > > Starting postfix.
> > > postfix/postlog: starting the Postfix mail system
> > > Starting munin_node.
> > > Starting inetd.
> > > Starting cron.
> > > The following components reported failures:
> > > /etc/rc.d/swap2
> > > See /var/run/rc.log for more information.
> > > Sun Oct 4 18:27:07 CEST 2026
> > >
> > > NetBSD/i386 (melone2) (constty)
> > >
> > > login:
> > >
> > > ---
> > >
> > > The log of the tftp/dhcp-server (a linux machine) shows several DH=
CPDIS=3D
> COVER and DHCPOFFER lines after the kernel has been requested several =
times=3D
> :
> > > ---
> > > 2026-10-04T18:23:03.082995+02:00 papaya in.tftpd[21402]: RRQ from =
192.1=3D
> 68.10.8 filename netbsd0/root/netbsd
> > > 2026-10-04T18:23:03.087076+02:00 papaya in.tftpd[21403]: RRQ from =
192.1=3D
> 68.10.8 filename netbsd0/root/netbsd
> > > 2026-10-04T18:23:24.748493+02:00 papaya in.tftpd[21404]: RRQ from =
192.1=3D
> 68.10.8 filename netbsd0/root/netbsd
> > > 2026-10-04T18:23:48.175746+02:00 papaya in.tftpd[21405]: RRQ from =
192.1=3D
> 68.10.8 filename netbsd0/root/netbsd
> > > 2026-10-04T18:24:09.792481+02:00 papaya in.tftpd[21406]: RRQ from =
192.1=3D
> 68.10.8 filename netbsd0/root/netbsd
> > > 2026-10-04T18:24:45.696587+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:45.696601+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:46.696637+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:46.696672+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:48.696964+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:48.696993+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:51.697545+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:51.697559+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:55.698425+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:55.698499+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:25:00.708539+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:25:00.709251+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:25:05.709148+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:25:05.709162+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:25:10.710081+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:25:10.710096+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > ---
> > >
> > > The same machine does not show this behaviour when using Linux (bu=
t lin=3D
> ux does not support the Alix any longer, so I need a replacement ...)
> > > >How-To-Repeat:
> > > Just reboot several times.
> > > Sometimes it happens at the 3rd attemt, sometimes it takes some mo=
re.
> > >
> > > >Fix:
> > > continuing on the serial console works. but this is not satisfying=
; con=3D
> sole is not always connected.
> > >
> > > Doing cold-start (happened often enough before pxe-booting worked)=
did =3D
> not show this behaviour.
> > >
> >
> > Hi,
> >
> > I will try to reproduce in a coming days with the hardware I have
> > (using if_vr interface).
> >
> > Since, I've seen forced reset, I modified a code a bit in that place
> > to print if reset failed and make it slightly more optimized.
> >
> > I don't think so it will help to resolve the issue but at least it c=
an
> > confirm that forced reset succeeds. Do you see this message on every
> > failure?
> >
> > Another test which you can do is to comment out `if (i =3D3D=3D3D VR=
_TIMEOUT)
> > {` condition and always use force reset to see if it helps.
> >
> > If it does, my biggest suspicion is that detachment/stopping code
> > leaves invalid or stale state which hinders initialization after a
> > warm reboot.
> > I would likely need to compare it with the Linux code.
> >
> > Regards,
> > Andrius V
> =20
> Hi,
> =20
> Just wanted to update that I managed to reproduce the issue, however
> it happens too rarely for me to properly debug.
> So, I can't promise I will find a fast solution, but I will be
> investigating for a while.
> How often does it actually happen to you? For me I can barely hit this
> issue in multiple reboots.
> If I do it may repeat once or twice, but once it's gone, it is close
> to impossible to reproduce again.
> =20
Hi Andrius,
please exuse if I don't follow the rules. I'm new to netbsd and also=20
newer to bug-tracker handling. Therefore I'm just answering to=20
"gnats-bugs@netbsd.org" (as this was the "reply-to" in your last=20
message). Is that ok?
Regarding your last question how often this happens:
At least 1 in 10 reboots.
To be sure that was a issue and not single incident I did reboot-loops.=20
And there I hit this.
I didn't had the time to try your supposed changes yet. I'll try to do=20
today. But (as said above) I'm new to netbsd and even newer to compiling=
=20
a kernel, so it may take somehow longer :-)
Regards
Ekkehard
From: Ekkehard Lissner-Jung <ekkehard@lissners.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/60848: Alix fails to boot sometimes after warmstart,
very likely due to network initialization
Date: Fri, 9 Oct 2026 19:50:36 +0200
Am 09.10.26 um 8:20 AM schrieb Andrius V via gnats:
> The following reply was made to PR port-i386/60848; it has been noted by=
GNATS.
>=20
> From: Andrius V <vezhlys@gmail.com>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: port-i386/60848: Alix fails to boot sometimes after warmsta=
rt,
> very likely due to network initialization
> Date: Fri, 9 Oct 2026 09:15:55 +0300
>=20
> On Tue, Oct 6, 2026 at 1:01=3DE2=3D80=3DAFPM Andrius V <vezhlys@gmail.=
com> wrote:
> >
> > On Sun, Oct 4, 2026 at 8:00=3DE2=3D80=3DAFPM netbsd@lissners.de via =
gnats
> > <gnats-admin@netbsd.org> wrote:
> > >
> > > >Number: 60848
> > > >Category: port-i386
> > > >Synopsis: Alix fails to boot sometimes after warmstart, ver=
y lik=3D
> ely due to network initialization
> > > >Confidential: no
> > > >Severity: serious
> > > >Priority: medium
> > > >Responsible: port-i386-maintainer
> > > >State: open
> > > >Class: sw-bug
> > > >Submitter-Id: net
> > > >Arrival-Date: Sun Oct 04 17:00:00 +0000 2026
> > > >Originator: Ekkehard
> > > >Release: Netbsd11
> > > >Organization:
> > > >Environment:
> > > NetBSD melone2 11.0 NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 =
UTC 2=3D
> 026 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/compile/GENERIC=
i386
> > > >Description:
> > > I configured a PC-Engines Alix with 3 ethernet-ports to boot via p=
xe/dh=3D
> cp as headless nfs-root machine. I created a new pxeboot_ia32_com0 to =
work =3D
> with com0 at 38400.
> > > In most cases, booting this setup works.
> > > But sometimes when doing a warmstart ("reboot" from the running sy=
stem)=3D
> , booting hangs when trying to mount the root-filesystem as nfs.
> > >
> > > Here is the log from the serial console:
> > > ---
> > > PC Engines ALIX.2 v0.99
> > > 640 KB Base Memory
> > > 261120 KB Extended Memory
> > > Waiting for HDD .....................
> > >
> > > 01F0 - no drive found !
> > >
> > > Intel UNDI, PXE-2.0 (build 082)
> > > Copyright (C) 1997,1998,1999 Intel Corporation
> > > VIA Rhine III Management Adapter v2.43 (2005/12/15)
> > >
> > > CLIENT MAC ADDR: 00 0D B9 15 22 14
> > > CLIENT IP: 192.168.10.8 MASK: 255.255.240.0 DHCP IP: 192.168.10.=
6
> > > GATEWAY IP: 192.168.10.2
> > >
> > >
> > > \\-__,------,___.
> > > \\ __,---` NetBSD/x86 PXE Boot
> > > \\ `---,_. Revision 5.2 (Sun Oct 4 14:23:18 UTC 2026)
> > > \\-,_____,.---`
> > > \\
> > > \\
> > > \\
> > >
> > > Press return to boot now, any other key for boot menu
> > > booting netbsd - starting in 0 seconds.
> > > PXE BIOS Version 2.1
> > > Using PCI device at bus 0 device 9 function 0
> > > Ethernet address 00:0d:b9:15:22:14
> > > 20607664+593992+745400 [990792+947152+1036453]=3D3D0x17c5a7c
> > > [ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2=
002, =3D
> 2003,
> > > [ 1.0000000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011,=
2012=3D
> , 2013,
> > > [ 1.0000000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021,=
2022=3D
> , 2023,
> > > [ 1.0000000] 2024, 2025, 2026
> > > [ 1.0000000] The NetBSD Foundation, Inc. All rights reserve=
d.
> > > [ 1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993
> > > [ 1.0000000] The Regents of the University of California. A=
ll ri=3D
> ghts reserved.
> > >
> > > [ 1.0000000] NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 UTC 2=
026
> > > [ 1.0000000] mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/i386/=
compi=3D
> le/GENERIC
> > > [ 1.0000000] total memory =3D3D 255 MB
> > > [ 1.0000000] avail memory =3D3D 227 MB
> > > [ 1.0000040] mainbus0 (root)
> > > [ 1.0000040] Firmware Error (ACPI): A valid RSDP was not found (=
20241=3D
> 212/tbxfroot-383)
> > > acpi_probe: failed to initialize tables
> > > [ 1.0000040] ACPI Error: Could not remove SCI handler (20241212/=
evmis=3D
> c-424)
> > > [ 1.0000040] cpu0 at mainbus0
> > > [ 1.0000040] ACPI Error: AE_BAD_PARAMETER, Thread 3243335680 cou=
ld no=3D
> t acquire Mutex [ACPI_MTX_Tables] (0x2) (20241212/utmutex-434)
> > > [ 1.0000040] ACPI Error: Mutex [ACPI_MTX_Tables] (0x2) is not ac=
quire=3D
> d, cannot release (20241212/utmutex-475)
> > > [ 1.0000040] cpu0: Geode(TM) Integrated Processor by AMD PCS, id=
0x5a=3D
> 2
> > > [ 1.0000040] cpu0: node 0, package 0, core 0, smt 0
> > > [ 1.0000040] pci0 at mainbus0 bus 0: configuration mode 1
> > > [ 1.0000040] pchb0 at pci0 dev 1 function 0: AMD Geode LX Host-P=
CI Br=3D
> idge (rev. 0x33)
> > > [ 1.0000040] glxsb0 at pci0 dev 1 function 2: RNG AES
> > > [ 1.0000040] vr0 at pci0 dev 9 function 0: VIA Technologies VT61=
05M (=3D
> Rhine III) 10/100 Ethernet (rev. 0x96)
> > > [ 1.0000040] vr0: interrupting at irq 10
> > > [ 1.0000040] vr0: Ethernet address 00:0d:b9:15:22:14
> > > [ 1.0000040] ukphy0 at vr0 phy 1: OUI 0x0002c6, model 0x0034, re=
v. 3
> > > [ 1.0000040] ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-=
FDX, =3D
> auto
> > > [ 1.0000040] vr1 at pci0 dev 10 function 0: VIA Technologies VT6=
105M =3D
> (Rhine III) 10/100 Ethernet (rev. 0x96)
> > > [ 1.0000040] vr1: interrupting at irq 11
> > > [ 1.0000040] vr1: Ethernet address 00:0d:b9:15:22:15
> > > [ 1.0000040] ukphy1 at vr1 phy 1: OUI 0x0002c6, model 0x0034, re=
v. 3
> > > [ 1.0000040] ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-=
FDX, =3D
> auto
> > > [ 1.0000040] vr2 at pci0 dev 11 function 0: VIA Technologies VT6=
105M =3D
> (Rhine III) 10/100 Ethernet (rev. 0x96)
> > > [ 1.0000040] vr2: interrupting at irq 12
> > > [ 1.0000040] vr2: Ethernet address 00:0d:b9:15:22:16
> > > [ 1.0000040] ukphy2 at vr2 phy 1: OUI 0x0002c6, model 0x0034, re=
v. 3
> > > [ 1.0000040] ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-=
FDX, =3D
> auto
> > > [ 1.0000040] gcscpcib0 at pci0 dev 15 function 0: AMD CS5536 PCI=
-ISA =3D
> Bridge (rev. 0x03)
> > > [ 1.0057994] gcscpcib0: Watchdog Timer via MFGPT0, GPIO
> > > [ 1.0057994] gpio0 at gcscpcib0: 32 pins
> > > [ 1.0057994] viaide0 at pci0 dev 15 function 2: AMD CS5536 IDE C=
ontro=3D
> ller (rev. 0x01)
> > > [ 1.0057994] viaide0: primary channel interrupting at irq 14
> > > [ 1.0057994] atabus0 at viaide0 channel 0
> > > [ 1.0057994] viaide0: secondary channel ignored (disabled)
> > > [ 1.0057994] ohci0 at pci0 dev 15 function 4: AMD CS5536 OHCI US=
B Con=3D
> troller (rev. 0x02)
> > > [ 1.0057994] ohci0: interrupting at irq 15
> > > [ 1.0057994] ohci0: OHCI version 1.0, legacy support
> > > [ 1.0057994] usb0 at ohci0: USB revision 1.0
> > > [ 1.0057994] gcscehci0 at pci0 dev 15 function 5: AMD CS5536 EHC=
I USB=3D
> Controller (rev. 0x02)
> > > [ 1.0057994] gcscehci0: interrupting at irq 15
> > > [ 1.0057994] gcscehci0: 1 companion controller, 4 ports: ohci0
> > > [ 1.0057994] gcscehci0: Using DMA subregion for control data str=
uctur=3D
> es
> > > [ 1.0057994] usb1 at gcscehci0: USB revision 2.0
> > > [ 1.0057994] isa0 at gcscpcib0
> > > [ 1.0057994] com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, 16-b=
yte F=3D
> IFO
> > > [ 1.0057994] com0: console
> > > [ 1.0057994] attimer0 at isa0 port 0x40-0x43
> > > [ 1.0057994] pcppi0 at isa0 port 0x61
> > > [ 1.0057994] midi0 at pcppi0: PC speaker
> > > [ 1.0057994] sysbeep0 at pcppi0
> > > [ 1.0057994] isapnp0 at isa0 port 0x279
> > > [ 1.0057994] attimer0: attached to pcppi0
> > > [ 1.0057994] WARNING: system needs entropy for security; see ent=
ropy(=3D
> 7)
> > > [ 1.1900868] uhub0 at usb0: NetBSD (0x0000) OHCI root hub (0x000=
0), c=3D
> lass 9/0, rev 1.00/1.00, addr 1
> > > [ 1.2180982] uhub1 at usb1: NetBSD (0x0000) EHCI root hub (0x000=
0), c=3D
> lass 9/0, rev 2.00/1.00, addr 1
> > > [ 1.2500849] entropy: ready
> > > [ 1.7500904] swwdog0: software watchdog initialized
> > > [ 1.7667646] WARNING: 1 error while detecting hardware; check sy=
stem =3D
> log.
> > > [ 1.7867928] boot device: vr0
> > > [ 1.7953523] root on vr0
> > > [ 1.8026381] nfs_boot: trying DHCP/BOOTP
> > > [ 19.8203658] nfs_boot: timeout...
> > > [ 24.8204446] nfs_boot: timeout...
> > > [ 29.8205195] nfs_boot: timeout...
> > > [ 34.8205982] nfs_boot: trying RARP (and RPC/bootparam)
> > > [ 34.8505981] vr0: using force reset command.
> > > [ 47.8607989] revarp failed, error=3D3D51
> > > [ 47.8764193] Supported file systems: mfs lfs ffs ext2fs nfs umap=
proc=3D
> fs overlay null kernfs fdesc union tmpfs puffs ptyfs ntfs msdos efs cd=
9660 =3D
> coda
> > > [ 47.9112556] no file system for vr0
> > > [ 47.9255498] cannot mount root, error =3D3D 79
> > > [ 47.9380282] root device (default vr0):
> > > ---
> > >
> > > After that it's waiting at the console for inputs.
> > > Just pressing enter several times (root device, dump device, file-=
syste=3D
> m, init) booting continues:
> > > ---
> > > [ 47.9380282] root device (default vr0):
> > > [ 48.0934634] dump device:
> > > [ 49.0017294] file system (default generic):
> > > [ 49.7203006] root on vr0
> > > [ 49.7271053] nfs_boot: trying DHCP/BOOTP
> > > [ 52.7417650] nfs_boot: DHCP next-server: 192.168.10.6
> > > [ 52.7643841] nfs_boot: my_domain=3D3Dlissner.home
> > > [ 52.7771070] nfs_boot: my_addr=3D3D192.168.10.8
> > > [ 52.7893228] nfs_boot: my_mask=3D3D255.255.240.0
> > > [ 52.8018160] nfs_boot: gateway=3D3D192.168.10.2
> > > [ 58.8118575] root on papaya:/srv/diskless/netbsd0/root
> > > [ 58.8310180] root file system type: nfs
> > > [ 58.8422158] kern.module.path=3D3D/stand/i386/11.0/modules
> > > [ 58.8575345] init path (default /sbin/init):
> > > [ 59.8588760] init: trying /sbin/init
> > > Sun Oct 4 16:26:39 -00 2026
> > > Not checking /: fs_passno =3D3D 0 in /etc/fstab
> > > Setting sysctl variables:
> > > ddb.onpanic: 1 -> 0
> > > Starting file system checks:
> > > [ 61.2919464] papaya:/srv/diskless/netbsd0/root: inaccurate wcc d=
ata (=3D
> ctime) detected, disabling wcc (ctime 1791131203.186064145 1791131203.=
18606=3D
> 4145, mtime 1791131203.186064145 1791131203.186064145)
> > > Loaded entropy from /var/db/entropy-file.
> > > Waiting for entropy...done
> > > Setting tty flags.
> > > Starting network.
> > > Hostname: melone2
> > > IPv6 mode: host
> > > Configuring network interfaces:.
> > > Adding interface aliases:.
> > > add net default: gateway 192.168.10.2
> > > Waiting for duplicate address detection to finish...
> > > Building databases: dev, utmp, utmpx.
> > > Starting syslogd.
> > > Mounting all file systems...
> > > Clearing temporary files.
> > > Creating a.out runtime link editor directory cache.
> > > Checking quotas: done.
> > > /etc/rc: WARNING: No swap space configured!
> > > /etc/rc.d/swap2 exited with code 1
> > > Starting virecover.
> > > Checking for core dump...
> > > savecore: no core dump (no dumpdev)
> > > Creating /var/run/munin...
> > > Starting local daemons:.
> > > Updating motd.
> > > Starting ntpd.
> > > Starting powerd.
> > > Starting sshd.
> > > Starting postfix.
> > > postfix/postlog: starting the Postfix mail system
> > > Starting munin_node.
> > > Starting inetd.
> > > Starting cron.
> > > The following components reported failures:
> > > /etc/rc.d/swap2
> > > See /var/run/rc.log for more information.
> > > Sun Oct 4 18:27:07 CEST 2026
> > >
> > > NetBSD/i386 (melone2) (constty)
> > >
> > > login:
> > >
> > > ---
> > >
> > > The log of the tftp/dhcp-server (a linux machine) shows several DH=
CPDIS=3D
> COVER and DHCPOFFER lines after the kernel has been requested several =
times=3D
> :
> > > ---
> > > 2026-10-04T18:23:03.082995+02:00 papaya in.tftpd[21402]: RRQ from =
192.1=3D
> 68.10.8 filename netbsd0/root/netbsd
> > > 2026-10-04T18:23:03.087076+02:00 papaya in.tftpd[21403]: RRQ from =
192.1=3D
> 68.10.8 filename netbsd0/root/netbsd
> > > 2026-10-04T18:23:24.748493+02:00 papaya in.tftpd[21404]: RRQ from =
192.1=3D
> 68.10.8 filename netbsd0/root/netbsd
> > > 2026-10-04T18:23:48.175746+02:00 papaya in.tftpd[21405]: RRQ from =
192.1=3D
> 68.10.8 filename netbsd0/root/netbsd
> > > 2026-10-04T18:24:09.792481+02:00 papaya in.tftpd[21406]: RRQ from =
192.1=3D
> 68.10.8 filename netbsd0/root/netbsd
> > > 2026-10-04T18:24:45.696587+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:45.696601+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:46.696637+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:46.696672+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:48.696964+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:48.696993+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:51.697545+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:51.697559+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:55.698425+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:24:55.698499+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:25:00.708539+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:25:00.709251+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:25:05.709148+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:25:05.709162+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:25:10.710081+02:00 papaya dhcpd[18181]: DHCPDISCOVER=
from=3D
> 00:0d:b9:15:22:14 via eth0
> > > 2026-10-04T18:25:10.710096+02:00 papaya dhcpd[18181]: DHCPOFFER on=
192.=3D
> 168.10.8 to 00:0d:b9:15:22:14 via eth0
> > > ---
> > >
> > > The same machine does not show this behaviour when using Linux (bu=
t lin=3D
> ux does not support the Alix any longer, so I need a replacement ...)
> > > >How-To-Repeat:
> > > Just reboot several times.
> > > Sometimes it happens at the 3rd attemt, sometimes it takes some mo=
re.
> > >
> > > >Fix:
> > > continuing on the serial console works. but this is not satisfying=
; con=3D
> sole is not always connected.
> > >
> > > Doing cold-start (happened often enough before pxe-booting worked)=
did =3D
> not show this behaviour.
> > >
> >
> > Hi,
> >
> > I will try to reproduce in a coming days with the hardware I have
> > (using if_vr interface).
> >
> > Since, I've seen forced reset, I modified a code a bit in that place
> > to print if reset failed and make it slightly more optimized.
> >
> > I don't think so it will help to resolve the issue but at least it c=
an
> > confirm that forced reset succeeds. Do you see this message on every
> > failure?
> >
> > Another test which you can do is to comment out `if (i =3D3D=3D3D VR=
_TIMEOUT)
> > {` condition and always use force reset to see if it helps.
> >
> > If it does, my biggest suspicion is that detachment/stopping code
> > leaves invalid or stale state which hinders initialization after a> =
> warm reboot.
> > I would likely need to compare it with the Linux code.
> >
> > Regards,
> > Andrius V
> =20
> Hi,
> =20
> Just wanted to update that I managed to reproduce the issue, however
> it happens too rarely for me to properly debug.
> So, I can't promise I will find a fast solution, but I will be
> investigating for a while.
> How often does it actually happen to you? For me I can barely hit this
> issue in multiple reboots.
> If I do it may repeat once or twice, but once it's gone, it is close
> to impossible to reproduce again.
> =20
Hi,
I built a kernel with the patch you sent me.
The error happened again. Multiple times. Not more often than before, so=
=20
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 log=
.
[ 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=20
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=3D51
[ 48.0164371] Supported file systems: mfs lfs ffs ext2fs nfs umap=20
procfs overlay null kernfs fdesc union tmpfs puffs ptyfs ntfs msdos efs=20
cd9660 coda
[ 48.0512703] no file system for vr0
[ 48.0655693] cannot mount root, error =3D 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=3Dlissner.home
[ 53.7956889] nfs_boot: my_addr=3D192.168.10.8
[ 53.8079067] nfs_boot: my_mask=3D255.255.240.0
[ 53.8203868] nfs_boot: gateway=3D192.168.10.2
[ 59.8314912] root on papaya:/srv/diskless/netbsd0/root
[ 59.8515653] root file system type: nfs
[ 59.8627223] kern.module.path=3D/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 =3D 0 in /etc/fstab
Setting sysctl variables:
ddb.onpanic: 1 -> 0
<<<
If I understand corretly, this means: Reset command finished successfull=
=20
after 10 us.
What I don't understand: After doing the (forced) reset, there is no=20
other "nfs_boot: tryping DHCP/BOOTP". For me this looks like "ok, we are=
=20
trying to boot DHCP/BOOTP; hm, didn't work; 3 times; now let's try RARP;=
=20
didn't work either; now reset and wait for user input".
My suggestion would have been: After the reset the sequence starts again=
=20
with the "trying DHCP/BOOTP". At least one more time; now with the chip=20
initialized.
I will build another kernel with the "if (i =3D=3D VR_TIMEOUT)" removed=20
completely as suggested by you some days ago.
Regards
Ekkehard
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: netbsd@lissners.de
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> wrote:
> Hi,
Hi,
Replying to gnats-bugs@netbsd.org should be fine, I think system add
required emails by itself. You can add me (vezhlys@gmail or
andvar@netbsd.org) 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
Responsible-Changed-From-To: port-i386-maintainer->andvar
Responsible-Changed-By: andvar@NetBSD.org
Responsible-Changed-When: Sat, 10 Oct 2026 17:45:30 +0000
Responsible-Changed-Why:
take
From: netbsd@lissners.de
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/60848: Alix fails to boot sometimes after warmstart,
very likely due to network initialization
Date: Mon, 12 Oct 2026 11:55:00 +0200
Am 10.10.26 um 7:45 PM schrieb Andrius V via gnats:
> =20
> 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=3D3D192.168.19.8
> nfs_boot: my_mask=3D3D255.255.255.0
> nfs_boot: gateway=3D3D192.168.19.1
> root on 192.168.19.1:/srv/pxeroot
> =20
> 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.
> =20
> >
> > Regards
> > Ekkehard
> >
> =20
> Regards,
> Andrius V
Hi Andrius,
I tested your latest patch and this seems to fix the problem. I had ~20=20
bootups and found the "vr0: restarting", "vr0: using force reset=20
command" in the console log. Booting continued.
I think, that proves your patch is working.
Thanks a lot!
Regards
Ekkehard
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: andvar@netbsd.org, netbsd@lissners.de
Subject: Re: port-i386/60848: Alix fails to boot sometimes after warmstart,
very likely due to network initialization
Date: Mon, 12 Oct 2026 17:28:01 +0300
On Mon, Oct 12, 2026 at 1:00=E2=80=AFPM netbsd@lissners.de via gnats
<gnats-admin@netbsd.org> wrote:
>
> The following reply was made to PR port-i386/60848; it has been noted by =
GNATS.
>
> From: netbsd@lissners.de
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: port-i386/60848: Alix fails to boot sometimes after warmstar=
t,
> very likely due to network initialization
> Date: Mon, 12 Oct 2026 11:55:00 +0200
>
> Am 10.10.26 um 7:45 PM schrieb Andrius V via gnats:
> > =3D20
> > You can discard my first patch completely now.
> > The problem appears to be that the RX engine sometimes gets stuck (i=
t
> > 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 believ=
e
> > 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 lik=
e
> > 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=3D3D3D192.168.19.8
> > nfs_boot: my_mask=3D3D3D255.255.255.0
> > nfs_boot: gateway=3D3D3D192.168.19.1
> > root on 192.168.19.1:/srv/pxeroot
> > =3D20
> > 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 us=
e
> > directly once the patch is pulled up.
> > Eventually, the fix will make its way into a new 11.x or 12.0 releas=
e.
> > Of course, alternatives include using builds from the nycdn branches
> > or building the kernel yourself.
> > =3D20
> > >
> > > Regards
> > > Ekkehard
> > >
> > =3D20
> > Regards,
> > Andrius V
>
> Hi Andrius,
>
> I tested your latest patch and this seems to fix the problem. I had ~20=
=3D20
> bootups and found the "vr0: restarting", "vr0: using force reset=3D20
> command" in the console log. Booting continued.
> I think, that proves your patch is working.
>
> Thanks a lot!
>
> Regards
> Ekkehard
>
Hi,
Thank you for confirmation, I will commit later today.
Regards,
Andrius V
From: "Andrius Varanavicius" <andvar@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60848 CVS commit: src/sys/dev/pci
Date: Mon, 12 Oct 2026 19:35:49 +0000
Module Name: src
Committed By: andvar
Date: Mon Oct 12 19:35:49 UTC 2026
Modified Files:
src/sys/dev/pci: if_vr.c
Log Message:
vr(4): reinitialize device when rx engine fails to go to the idle state.
When detecting root via NFS, DHCP timed out on some boots.
Investigation showed that in certain cases RX engine was getting stuck,
likely triggered by an ARP frame arriving before driver handled a link up
state.
NFS boot's RARP fallback was calling media up command, triggering
reinitialization and forced reset, restoring the device state.
Since fallback doesn't set the IP address, NFS boot failed,
requesting to prompt root device again.
Subsequent attempt succeeded since device was reinitialized
by the RARP fallback, but manual input was required.
The fix always verifies successful rx/tx engine shutdown in vr_mii_statchg(),
even when state is active and media link is up.
In case it fails, device reinitialization is initiated, allowing DHCP process
to succeed.
Verified fixed by the bug report owner Ekkehard.
Tested on my own hardware as well.
PR port-i386/60848
To generate a diff of this commit:
cvs rdiff -u -r1.138 -r1.139 src/sys/dev/pci/if_vr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->pending-pullups
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Mon, 12 Oct 2026 21:19:40 +0000
State-Changed-Why:
[pullup-10 #1361] and [pullup-11 #520]. fixed in current.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60848 CVS commit: [netbsd-11] src/sys/dev/pci
Date: Wed, 14 Oct 2026 17:39:46 +0000
Module Name: src
Committed By: martin
Date: Wed Oct 14 17:39:46 UTC 2026
Modified Files:
src/sys/dev/pci [netbsd-11]: if_vr.c
Log Message:
Pull up following revision(s) (requested by andvar in ticket #520):
sys/dev/pci/if_vr.c: revision 1.139
vr(4): reinitialize device when rx engine fails to go to the idle state.
When detecting root via NFS, DHCP timed out on some boots.
Investigation showed that in certain cases RX engine was getting stuck,
likely triggered by an ARP frame arriving before driver handled a link up
state.
NFS boot's RARP fallback was calling media up command, triggering
reinitialization and forced reset, restoring the device state.
Since fallback doesn't set the IP address, NFS boot failed,
requesting to prompt root device again.
Subsequent attempt succeeded since device was reinitialized
by the RARP fallback, but manual input was required.
The fix always verifies successful rx/tx engine shutdown in vr_mii_statchg(),
even when state is active and media link is up.
In case it fails, device reinitialization is initiated, allowing DHCP process
to succeed.
Verified fixed by the bug report owner Ekkehard.
Tested on my own hardware as well.
PR port-i386/60848
To generate a diff of this commit:
cvs rdiff -u -r1.138 -r1.138.4.1 src/sys/dev/pci/if_vr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60848 CVS commit: [netbsd-10] src/sys/dev/pci
Date: Wed, 14 Oct 2026 17:40:56 +0000
Module Name: src
Committed By: martin
Date: Wed Oct 14 17:40:56 UTC 2026
Modified Files:
src/sys/dev/pci [netbsd-10]: if_vr.c
Log Message:
Pull up following revision(s) (requested by andvar in ticket #1361):
sys/dev/pci/if_vr.c: revision 1.139
vr(4): reinitialize device when rx engine fails to go to the idle state.
When detecting root via NFS, DHCP timed out on some boots.
Investigation showed that in certain cases RX engine was getting stuck,
likely triggered by an ARP frame arriving before driver handled a link up
state.
NFS boot's RARP fallback was calling media up command, triggering
reinitialization and forced reset, restoring the device state.
Since fallback doesn't set the IP address, NFS boot failed,
requesting to prompt root device again.
Subsequent attempt succeeded since device was reinitialized
by the RARP fallback, but manual input was required.
The fix always verifies successful rx/tx engine shutdown in vr_mii_statchg(),
even when state is active and media link is up.
In case it fails, device reinitialization is initiated, allowing DHCP process
to succeed.
Verified fixed by the bug report owner Ekkehard.
Tested on my own hardware as well.
PR port-i386/60848
To generate a diff of this commit:
cvs rdiff -u -r1.137 -r1.137.4.1 src/sys/dev/pci/if_vr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->closed
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Wed, 14 Oct 2026 18:51:42 +0000
State-Changed-Why:
pullups applied
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home