Hello Artturi,
On 28/01/18(Sun) 09:08, Artturi Alm wrote:
> >Synopsis: stuck in netlock
> >Category: amd64
> >Environment:
> System : OpenBSD 6.2
> Details : OpenBSD 6.2-current (GENERIC.MP) #333: Sun Jan 7
> 09:13:00 MST 2018
>
> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> processes getting stuck w/STATE=netlock, kill has no effect.
> >How-To-Repeat:
> using the desktop normally, until trying to restart chrome ends
> up failing.
What do you mean with "using the desktop normally"? Which applications
are you using? Which browser plugins? Can you find out the minimum
setup to reproduce this deadlock?
> I've had this happen to me atleast twice in the last few of weeks.
Do you know how to reproduce it easily?
> At first time i noticed how trying to launch chrome did lock up
> all the other processes in netlock, and "pkill chrome" did allow
> the system to recover, i was unable to figure out what was wrong
> and rebooting did make everything work again, while ie.
> removing ~/.cache & ~/.config did not.
So the deadlock is related to your chrome usage?
> long before running the "ps cl" below, i had already killed all
> the xterm-windows those processes were in. cwm(1) was unable to
> kill some of those, but xkill did not.
Well killing process waiting for the 'netlock' won't help. What has to
be find is which process is holding it. For that we need the full ps
output, including kernel and userland threads.
>
> after exiting X w/ctrl+alt+backspace(iirc?) i didn't get back to
> $-prompt, and ^T did show xauth stuck in netlock..
> i guess it's obvious where it was heading; so i got pics of
> "# reboot -nq" failing because stuck in the fckng netlock -_-
>
> i do have ddb.{panic,console,log}=1, but
> "# sysctl ddb.trigger=1" ==
> "sysctl: ddb.trigger: Operation not supported by device"
Not having DDB access will limit the debugging experience. Are you sure
you tried to enter it on your console?
> ?? so i had no option but "virsh reset <domain>"...
Did you try top(1)? What were the kernel processes doing?
