Michael van Elst wrote:
> k...@munnari.oz.au (Robert Elz) writes:
>
> >Do we do crash dumps onto raidsets?
>
> We can dump on raidsets, the code selects a working component or a spare
> disk to dump on. Doesn't mean that it works, the more complicated the
> device access gets, the less likely it
k...@munnari.oz.au (Robert Elz) writes:
>Do we do crash dumps onto raidsets?
We can dump on raidsets, the code selects a working component or a spare
disk to dump on. Doesn't mean that it works, the more complicated the
device access gets, the less likely it will succeed.
PR 57171
BERTRAND Joël a écrit :
> Taylor R Campbell a écrit :
>>> Date: Fri, 6 Jan 2023 15:55:37 +0100
>>> From: BERTRAND Joël
>>>
>>> /etc/rc.d/altqd onestop doesn't stop altqd. top shows that altqd
>>> remains on CPU (and takes 100% of a CPU).
>>>
>>> gdb -p 1342 (altq) returns that altqd stalls in
Taylor R Campbell a écrit :
>> Date: Fri, 6 Jan 2023 15:55:37 +0100
>> From: BERTRAND Joël
>>
>> /etc/rc.d/altqd onestop doesn't stop altqd. top shows that altqd
>> remains on CPU (and takes 100% of a CPU).
>>
>> gdb -p 1342 (altq) returns that altqd stalls in qop_clear() function (I
>>
Brian Buhrow a écrit :
> Hello Joel. I'm not sure this is a new problem. I've seen similar
> behavior on NetBSD-5.2. It seems to happen on systems where there is a
> good deal of traffic traversing the network at the time the stop is
> requested.
Yes, I have seen this issue for a
> Date: Fri, 6 Jan 2023 15:55:37 +0100
> From: BERTRAND Joël
>
> /etc/rc.d/altqd onestop doesn't stop altqd. top shows that altqd
> remains on CPU (and takes 100% of a CPU).
>
> gdb -p 1342 (altq) returns that altqd stalls in qop_clear() function (I
> don't have altdq sources on this
Hello Joel. I'm not sure this is a new problem. I've seen similar
behavior on NetBSD-5.2. It seems to happen on systems where there is a
good deal of traffic traversing the network at the time the stop is
requested.
-thanks
-Brian
>> PS: /etc/rc.d/altqd stop doesn't run as expected. altqd only takes 100%
>> of a CPU and is not stopped after this command.
>
> 5. Can you use crash(8) to find the kernel stack trace of the process
>that's eating CPU?
Hello,
I a -10.0_BETA VM, I have rebuilt a kernel with
