Date: Mon, 16 Feb 2026 12:08:53 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net>, freebsd-arm@freebsd.org Subject: Re: -current network buffer exhaustion on RPi2 armv7 Message-ID: <bed432c0-0e88-4654-b109-c21b02462e33@yahoo.com> In-Reply-To: <aZNQKmWzZTBBkobG@www.zefox.net>
index | next in thread | previous in thread | raw e-mail
On 2/16/26 09:13, bob prohaska wrote:
> From time to time a Raspberry Pi 2 v1.1 (armv7) running -current reports
>
> Feb 16 08:23:34 generic syslogd: last message repeated 1 times, op=20, val=0, arg_len=7]: Can't assign requested address send_packet: No buffer space available
It looks like the text after "times," may have missing text before the
"op=20,".
contrib/wpa/src/drivers/driver_bsd.c has (up to line wrapping):
static int
bsd_set80211(void *priv, int op, int val, const void *arg, int arg_len)
. . .
if (ioctl(drv->global->sock, SIOCS80211, &ireq) < 0) {
wpa_printf(MSG_ERROR, "ioctl[SIOCS80211, op=%u, val=%u, "
"arg_len=%u]: %s", op, val, arg_len,
strerror(errno));
return -1;
}
. . .
I've not found anything else that looks to be a match.
So, apparently, 802.11 WiFi as the communication channel "media".
My guess for op:
sys/net80211/ieee80211_ioctl.h:
#define IEEE80211_IOC_DELKEY 20
"Can't assign requested address" Looks to be from EADDRNOTAVAIL in:
sys/net80211/ieee80211_ioctl.c :
. . .
static int
ieee80211_ioctl_delkey(struct ieee80211vap *vap, struct ieee80211req *ireq)
. . .
if (dk.idk_keyix == (uint8_t) IEEE80211_KEYIX_NONE) {
struct ieee80211_node *ni;
if (vap->iv_opmode == IEEE80211_M_STA) {
ni = ieee80211_ref_node(vap->iv_bss);
if (!IEEE80211_ADDR_EQ(dk.idk_macaddr,
ni->ni_bssid)) {
ieee80211_free_node(ni);
return EADDRNOTAVAIL;
}
} else {
. . .
> (I think the numerical values repeat, but I'm not certain of it)
> n
> In this case, the ethernet network (via a usb-wifi adapter) remained up:
Yep: Looks to be that WiFi usage that is involved.
>
> root@generic:/usr/src # ping 192.168.1.254
> PING 192.168.1.254 (192.168.1.254): 56 data bytes
> 64 bytes from 192.168.1.254: icmp_seq=0 ttl=64 time=4.406 ms
> 64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=4.101 ms
> 64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=3.989 ms
> 64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=4.186 ms
> 64 bytes from 192.168.1.254: icmp_seq=4 ttl=64 time=4.119 ms
> 64 bytes from 192.168.1.254: icmp_seq=5 ttl=64 time=3.948 ms
> 64 bytes from 192.168.1.254: icmp_seq=6 ttl=64 time=4.478 ms
> 64 bytes from 192.168.1.254: icmp_seq=7 ttl=64 time=5.119 ms
> 64 bytes from 192.168.1.254: icmp_seq=8 ttl=64 time=4.417 ms
> ^C
> --- 192.168.1.254 ping statistics ---
> 9 packets transmitted, 9 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 3.948/4.307/5.119/0.339 ms
>
> Anybody have an idea what the machine is complaining about?
I've not managed to get the point of referencing any specifics for the
"No buffer space available", so: not me.
> At the time of these observations the machine was running a
> -j4 buildworld with about 500M of swap in use. Within a few
> minutes swap use declined to ~70M and no further complaints
> were reported.
>
> The ethernet adapter is a
> ugen0.5: <RT5370 Wireless Adapter Ralink Technology, Corp.> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (450mA)
> running on a powered hub, together with the root device, a usb-sata
> mechanical hard disk drive.
>
> Could this be indicative of a conflict or traffic jam between the
> root device and the network by way of USB?
The USB being a single shared channel across the RPi2 v1.1 USB2 ports,
any saturation of the channel could lead to either waiting and/or
buffering/queuing for later (if possible at the time).
But I've no clue what type of buffer had no space available.
I'm not likely to get beyond what I have above. May be someone with
background knowledge of the areas can indicate more.
--
===
Mark Millard
marklmi at yahoo.com
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bed432c0-0e88-4654-b109-c21b02462e33>