Hi,
On 2022/05/27 10:11, Emmanuel Dreyfus wrote:
On Thu, May 26, 2022 at 05:46:31PM +0900, Kengo NAKAHARA wrote:
Could you use head of netbsd-9 branch?
Tried that, workqueue now works fine, and this improves a lot
the behavior against heavy flows.
I am grad to hear that.
Is there a way t
On Thu, May 26, 2022 at 05:46:31PM +0900, Kengo NAKAHARA wrote:
> Could you use head of netbsd-9 branch?
Tried that, workqueue now works fine, and this improves a lot
the behavior against heavy flows.
Is there a way to tune the priority of the workqueue against
user processes?
The wm(4) man pag
hello. You're right, I missed that bit of data. I thought the
machines were hanging in
mid operation and "dying" in the night.
If shutting the process down hangs the system, that makes me think the program
is closing its
file descriptors, especially the network ones, in a way that's d
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
Hi,
Thank you for your information.
On 2022/05/26 15:50, Emmanuel Dreyfus wrote:
On Thu, May 26, 2022 at 11:40:15AM +0900, Kengo NAKAHARA wrote:
Hmm, could you send me the result of "dmesg | grep wm0" ?
This is NetBSD-9.2/amd64. It broke with two other acpi devices
starting to complain about
13 matches
Mail list logo
