>> Is it possible the machine is not, strictly, hung, just doing
>> something that renders it unresponsive for a human-perceptible time?
>> [...dumping core...]
> [...], no disk lighting, [...]
> I was communicating with him in the morning, hours after attempting
> to stop darkstat, so it had ple
Hi,
It also might be relevant to note which port you're running. It must
be capable of having re and wm interfaces, since you name them, but
that still includes a fair bit.
I still see no statement which port(s) you're running...
Here my brain equated port with ethernet, not with NetBSD port
On 27/05/22 06:00, John Klos wrote:
So here's an interesting problem:
On NetBSD 8, 9, current, with both ipfilter and with npf, with different
kinds of ethernet interfaces (re*, wm*), run pkgsrc/net/darkstat. Pass a
lot of traffic (like a week's worth of Internet traffic). Stop darkstat.
M
n it receives a signal
it can work
with.
-Brian
On May 26, 5:17pm, Mouse wrote:
} Subject: Re: Complete lock-up from using pkgsrc/net/darkstat
} > I'd be very surprised if the problem is running interfaces in
} Go back and read the original post - the hang is not during operation;
} then
hello. Mouse's thought is a good one as well. I'll note, for example,
it's pretty easy
to send a machine to hang heaven with vi(1). Edit a very large file, say one
of 3 gigs in
size. Then, pick a starting line a quarter of the way down the file and mark
it. Move down
the file and
> I'll note, for example, it's pretty easy to send a machine to hang
> heaven with vi(1). [...]
Does that cause it to hang so hard it doesn't even notice a keyboard
being plugged in?
I suspect one reason coredumping is particularly disabling is that it
is a long operation that stays in the kerne
Brian Buhrow's note sparked another thought.
> Stop darkstat. Machine locks.
Is it possible the machine is not, strictly, hung, just doing something
that renders it unresponsive for a human-perceptible time? You wrote
of having to get remote hands to poke an unresponsive machine; how long
did t
> I'd be very surprised if the problem is running interfaces in
> promiscuous mode.
So would I, but that is true of every possible explanation I've come up
with.
> I'm guessing it's a memory issue with darkstat -- specifically, it
> has a memory leak that runs the system it runs on out of RAM. I
hello. I'd be very surprised if the problem is running interfaces in
promiscuous mode.
Anyone using bridge(4), or vlans, for example, is runing their interfaces in
promiscuous mode,
as is anyone running a dhcp server, or any sort of arpwatch. I find it highly
unlikely that
the network
>>> [...] in case anyone can imagine how and why a complete system
>>> lockup could happen as the result of an interface being used in
>>> promiscuous mode for long periods of time (and not when used that
>>> way for short periods of time.
>> Don't forget, it may _not_ be "as the result of an inter
> On NetBSD 8, 9, current, [...] Stop darkstat. Machine locks.
> [...] in case anyone can imagine how and why a complete system lockup
> could happen as the result of an interface being used in promiscuous
> mode for long periods of time (and not when used that way for short
> periods of time.
> On NetBSD 8, 9, current, [...] Stop darkstat. Machine locks.
> [...] in case anyone can imagine how and why a complete system lockup
> could happen as the result of an interface being used in promiscuous
> mode for long periods of time (and not when used that way for short
> periods of time.
D
So here's an interesting problem:
On NetBSD 8, 9, current, with both ipfilter and with npf, with different
kinds of ethernet interfaces (re*, wm*), run pkgsrc/net/darkstat. Pass a
lot of traffic (like a week's worth of Internet traffic). Stop darkstat.
Machine locks.
I've only recently been
13 matches
Mail list logo
