Discussion:
current issues on Octeon (ER-4)
(too old to reply)
David H. Gutteridge
2023-06-09 21:49:01 UTC
Permalink
* When booting octeon.img.gz, DHCP client works.
* When booting netbsd-OCTEON after the manual installation, DHCP client
works.
* When booting netbsd-INSTALL_OCTEON, DHCP client does not work because
the kernel does not seem to have BPF (this has been this way at least
since 2021), also there is an assertion at the end. Using static
IPv4 configuration in the installer works around the problem.
Status: Command failed
Command: /sbin/dhcpcd -d -n cnmac1
Hit enter to continue
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
Berkley Packet Filter not found
cnmac1: sending DISCOVER (xid 0xeb30a157), next in 8.4 seconds
cnmac1: sending DISCOVER (xid 0xeb30a157), next in 8.4 seconds
Berkley Packet Filter not found
Berkley Packet Filter not found
cnmac1: sending DISCOVER (xid 0xeb30a157), next in 15.6 seconds
cnmac1: sending DISCOVER (xid 0xeb30a157), next in 15.6 seconds
Berkley Packet Filter not found
Berkley Packet Filter not found
timed out
timed out
cnmac1: executing: /libexec/dhcpcd-run-hooks STOPPED
cnmac1: executing: /libexec/dhcpcd-run-hooks STOPPED
dhcpcd_fork_cb: truncated read 0 (expected 4)
dhcpcd_fork_cb: truncated read 0 (expected 4)
assertion "ifp != NULL" failed: file
"/usr/src/lib/libc/net/getifaddrs.c", line
303, function "_freeifaddrs"
Examining the ramdisk build recipe, I saw that bpf wasn't on the list
of device nodes to be created (though dhcpcd is included, and bpf is
enabled in the kernel configuration), so I've now added it.

I'm not able to test this directly, but verified by mounting the ramdisk
images generated before and after this change. Testing would be
appreciated.

Regards,

Dave

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Denis Ovsienko
2023-06-12 21:17:26 UTC
Permalink
On Fri, 09 Jun 2023 17:49:01 -0400
Post by David H. Gutteridge
Examining the ramdisk build recipe, I saw that bpf wasn't on the list
of device nodes to be created (though dhcpcd is included, and bpf is
enabled in the kernel configuration), so I've now added it.
I'm not able to test this directly, but verified by mounting the
ramdisk images generated before and after this change. Testing would
be appreciated.
Thank you for looking into this Dave.

Unfortunately, I timed out waiting for any requests to test and moved
the hardware from the lab to its production location, so unless somebody
else gets to test the fix first, it could be a few months before I see
this ER-4 again. If you would like to have the ERLite-3 for tests, let
me know.
--
Denis Ovsienko

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David H. Gutteridge
2023-07-26 22:30:19 UTC
Permalink
Post by David H. Gutteridge
* When booting octeon.img.gz, DHCP client works.
* When booting netbsd-OCTEON after the manual installation, DHCP client
works.
* When booting netbsd-INSTALL_OCTEON, DHCP client does not work because
the kernel does not seem to have BPF (this has been this way at least
since 2021), also there is an assertion at the end. Using static
IPv4 configuration in the installer works around the problem.
Status: Command failed
Command: /sbin/dhcpcd -d -n cnmac1
Hit enter to continue
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
Berkley Packet Filter not found
cnmac1: sending DISCOVER (xid 0xeb30a157), next in 8.4 seconds
cnmac1: sending DISCOVER (xid 0xeb30a157), next in 8.4 seconds
Berkley Packet Filter not found
Berkley Packet Filter not found
cnmac1: sending DISCOVER (xid 0xeb30a157), next in 15.6 seconds
cnmac1: sending DISCOVER (xid 0xeb30a157), next in 15.6 seconds
Berkley Packet Filter not found
Berkley Packet Filter not found
timed out
timed out
cnmac1: executing: /libexec/dhcpcd-run-hooks STOPPED
cnmac1: executing: /libexec/dhcpcd-run-hooks STOPPED
dhcpcd_fork_cb: truncated read 0 (expected 4)
dhcpcd_fork_cb: truncated read 0 (expected 4)
assertion "ifp != NULL" failed: file
"/usr/src/lib/libc/net/getifaddrs.c", line
303, function "_freeifaddrs"
Examining the ramdisk build recipe, I saw that bpf wasn't on the list
of device nodes to be created (though dhcpcd is included, and bpf is
enabled in the kernel configuration), so I've now added it.
I'm not able to test this directly, but verified by mounting the ramdisk
images generated before and after this change. Testing would be
appreciated.
I've been able to test the netbsd-INSTALL_OCTEON installer now, with my
addition of the bpf device to the image. With evbmips-mips64eb dhcpcd
now works, though with evbmips-mipsn64eb we run into a different
problem, which I'm still looking at. I've requested a pullup of this
to the netbsd-10 branch, along with some other additions to allow that
ramdisk to work with GPT wedges, should someone use the octeon.img
image, then find the need to recover the resulting installation. (Which
has already happened to me twice -- that is, I place a copy of
netbsd-INSTALL_OCTEON on the boot wedge, so I can boot into that and
recover rather than going through the trouble of removing the USB stick
from the machine; I'd done that in my initial setup, then discovered I
couldn't inspect or mount dk1 the first time I tried to recover!)

Dave

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David H. Gutteridge
2023-09-27 00:22:57 UTC
Permalink
Post by David H. Gutteridge
Post by David H. Gutteridge
Before I forget, there is one other rough edge with evbmips-
* When booting octeon.img.gz, DHCP client works.
* When booting netbsd-OCTEON after the manual installation, DHCP client
works.
* When booting netbsd-INSTALL_OCTEON, DHCP client does not work because
the kernel does not seem to have BPF (this has been this way at least
since 2021), also there is an assertion at the end.  Using static
IPv4 configuration in the installer works around the problem.
Status: Command failed
Command: /sbin/dhcpcd -d -n cnmac1
Hit enter to continue
qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq
qqqqqqqqqqqqqq
Berkley Packet Filter not found
cnmac1: sending DISCOVER (xid 0xeb30a157), next in 8.4 seconds
cnmac1: sending DISCOVER (xid 0xeb30a157), next in 8.4 seconds
Berkley Packet Filter not found
Berkley Packet Filter not found
cnmac1: sending DISCOVER (xid 0xeb30a157), next in 15.6 seconds
cnmac1: sending DISCOVER (xid 0xeb30a157), next in 15.6 seconds
Berkley Packet Filter not found
Berkley Packet Filter not found
timed out
timed out
cnmac1: executing: /libexec/dhcpcd-run-hooks STOPPED
cnmac1: executing: /libexec/dhcpcd-run-hooks STOPPED
dhcpcd_fork_cb: truncated read 0 (expected 4)
dhcpcd_fork_cb: truncated read 0 (expected 4)
assertion "ifp != NULL" failed: file
"/usr/src/lib/libc/net/getifaddrs.c", line
303, function "_freeifaddrs"
Examining the ramdisk build recipe, I saw that bpf wasn't on the list
of device nodes to be created (though dhcpcd is included, and bpf is
enabled in the kernel configuration), so I've now added it.
I'm not able to test this directly, but verified by mounting the ramdisk
images generated before and after this change. Testing would be
appreciated.
I've been able to test the netbsd-INSTALL_OCTEON installer now, with my
addition of the bpf device to the image. With evbmips-mips64eb dhcpcd
now works, though with evbmips-mipsn64eb we run into a different
problem, which I'm still looking at. I've requested a pullup of this
to the netbsd-10 branch, along with some other additions to allow that
ramdisk to work with GPT wedges, should someone use the octeon.img
image, then find the need to recover the resulting installation. (Which
has already happened to me twice -- that is, I place a copy of
netbsd-INSTALL_OCTEON on the boot wedge, so I can boot into that and
recover rather than going through the trouble of removing the USB stick
from the machine; I'd done that in my initial setup, then discovered I
couldn't inspect or mount dk1 the first time I tried to recover!)
evbmips-mipsn64eb has had an issue with bpf(4) fixed by rin@, and pulled
up to netbsd-10, so you should find dhcpcd(8) and tcpdump(8) now work on
it. (It was pulled up to netbsd-10 on September 13th.)

Regards,

Dave


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...