hello. In looking at my vmstat-m output, I see:
mclpl 211228146028146 14109 1407435 187 0 524288 35
I see no failures and the number of nmbclusters is: 524288
yet, this machine has displayed this message about 6 times since it was
rebooted about 5 hours
hello. One strange thing I notice on this particular system that seems
to be different
from the other systems I'm running is that the request count on the mclpl line
is incrementing
at a pretty fast rate, where as on other systems, the request rate is, more or
less, constant
over time,
hello. In looking at the if_xennet_xenbus.c file, I see where the
if_xennetrxbuf_cache is
initialized, but I don't see where data is put into it before it's requested.
Is the idea that
the items in the cache are supposed to be provided by the backend, i.e. the
dom0? Is it
possible
On Thu, Jun 23, 2022 at 01:48:55PM -0700, Brian Buhrow wrote:
> hello. In looking at the if_xennet_xenbus.c file, I see where the
> if_xennetrxbuf_cache is
> initialized, but I don't see where data is put into it before it's requested.
> Is the idea that
> the items in the cache are
On Thu, Jun 23, 2022 at 12:54:59PM -0700, Brian Buhrow wrote:
> hello. In looking at my vmstat-m output, I see:
>
> mclpl 211228146028146 14109 1407435 187 0 524288
> 35
>
> I see no failures and the number of nmbclusters is: 524288
>
> yet, this machine has
On Thu, Jun 23, 2022 at 12:29:11PM -0700, Brian Buhrow wrote:
> Hello. I'm running a number of NetBSD-9 and -current as of 99.77
> amd/64 domu machines on
> a couple of different servers with FreeBSD as dom0. I'm getting the
> following messages from
> the kernel:
> xennet0: rx no
Hello. I'm running a number of NetBSD-9 and -current as of 99.77
amd/64 domu machines on
a couple of different servers with FreeBSD as dom0. I'm getting the following
messages from
the kernel:
xennet0: rx no cluster
Much of the time, these messages seem harmless, but occasionally, the
I saw almost the same situation. To recover from the error, I had to
power-down the machine, unplug the battery, keep a few minutes, plug the
battery and power-up again.
I committed the change yesterday. I guess that it fixes kern/55192 and
kern/56669.
My machine is only 2500 km away, but
> I committed the change yesterday.
I don't get what the #if defined(__LP64__) && 0 is for.
