Re: Shark hangs hard

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Fri, Mar 10, 2017 at 5:01 PM, Martin Husemann <martin%duskware.de@localhost> wrote:
> On Thu, Mar 09, 2017 at 11:27:23AM +0100, Martin Husemann wrote:
>> Just a heads up (while still investigating): this week I have been unable
>> to run the weekly atf tests on shark.
>>
>> The machine hangs hard, randomly, and never survived a full test run.
>> We have seen hangs before (on sharks with less memory, even during
>> the nightly runs), but never on this 96 MB one.
>>
>> My other shark (with 64MB) is happy and never crashed since Nick's recent
>> pmap changes. I haven't stressed it a lot nor run atf tests on it though.
>
> It survived a full atf run now, after reverting a local config change:
>
> in testing for kern/52023 I had moved the machine from its ancient, hard
> wired network configuration:
>
> ifconfig_cs0="inet 192.168.150.102 netmask 255.255.254.0"
> defaultroute=192.168.151.1
> rtsol=YES
>
> to:
>
> dhcpcd=YES
>
> and reverting that avoided the problem. I guess having a bpf listener open
> causes a race somewhere - this is a tiny machine, and atf loads it
> heavily. A full run takes about 12 hours. Full dmesg below.

Hmm, strange. If packets aren't matched on the filter, bpf MP-ification
doesn't add visible overhead (it added only splsoftserial for pserialize).
If a decent amount of packets are matched on the filter resulting in
slowing ATF tests, the filter is something wrong.

Can you show me outputs of netstat -B and netstat -B -s?
(If there are outputs of both before and after a full run of ATF tests,
that's better of course...)

Thanks,
  ozaki-r