Re: mutex vs turnstile

2018-02-14 Thread Mateusz Guzik
On Thu, Jan 18, 2018 at 10:38:02AM +, Nick Hudson wrote: > On 01/09/18 03:30, Mateusz Guzik wrote: > > Some time ago I wrote about performance problems when doing high -j > > build.sh and made few remarks about mutex implementation. > > > > TL;DR for that one was mostly that cas returns the

Re: Race condition between an LWP migration and curlwp_bind

2018-02-14 Thread Mateusz Guzik
On Tue, Feb 13, 2018 at 05:14:38PM +0900, Ryota Ozaki wrote: > panic: kernel diagnostic assertion "(psref->psref_cpu == curcpu())" > failed: file "/(hidden)/sys/kern/subr_psref.c", line 317 passive > reference transferred from CPU 0 to CPU 3 > > I first thought that something went wrong in an

Re: setting DDB_COMMANDONENTER="bt" by default

2018-02-14 Thread Sevan Janiyan
On 15/02/2018 02:35, Paul Goyette wrote: > Yeah, probably best to leave things as they currently are. Ok, no problem. :) Sevan

Re: setting DDB_COMMANDONENTER="bt" by default

2018-02-14 Thread Sevan Janiyan
On 02/15/18 01:23, Valery Ushakov wrote: > As someone has already mentioned upthread, because printing a > backtrace might cause another panic, so the default was selected to be > on the safe(r) side. At least that's what I recall. On 02/15/18 01:33, Paul Goyette wrote: > Yes, that matches my

Re: setting DDB_COMMANDONENTER="bt" by default

2018-02-14 Thread Paul Goyette
On Thu, 15 Feb 2018, Valery Ushakov wrote: On Thu, Feb 15, 2018 at 01:19:31 +, Sevan Janiyan wrote: I might/would suggest OPTIONS DDB_ONPANIC=2 clear, any reason not to have this as a default? (I'm going to sleep on it) As someone has already mentioned upthread, because printing a

Re: setting DDB_COMMANDONENTER="bt" by default

2018-02-14 Thread Valery Ushakov
On Thu, Feb 15, 2018 at 01:19:31 +, Sevan Janiyan wrote: > > I might/would suggest > > > >OPTIONS DDB_ONPANIC=2 > > clear, any reason not to have this as a default? (I'm going to sleep on it) As someone has already mentioned upthread, because printing a backtrace might cause another

Re: setting DDB_COMMANDONENTER="bt" by default

2018-02-14 Thread Sevan Janiyan
> On 15 Feb 2018, at 01:09, Paul Goyette wrote: > > Sounds like a good case for a custom kernel. Not sure that such a > specific situation would warrant turning this on for everyone... We do have this set by default on some config files albeit with differing commands to

Re: setting DDB_COMMANDONENTER="bt" by default

2018-02-14 Thread Paul Goyette
On Thu, 15 Feb 2018, Sevan Janiyan wrote: On 15 Feb 2018, at 00:37, Paul Goyette wrote: If you can boot _something_ then boot -d to get an initial breakpoint entry into ddb. Then just update the global variable db_onpanic to 1 Ah, no functioning keyboard when in ddb

Re: setting DDB_COMMANDONENTER="bt" by default

2018-02-14 Thread Sevan Janiyan
> On 15 Feb 2018, at 00:37, Paul Goyette wrote: > > If you can boot _something_ then boot -d to get an initial breakpoint entry > into ddb. Then just update the global variable db_onpanic to 1 Ah, no functioning keyboard when in ddb hence wanting to set a default command.

Re: setting DDB_COMMANDONENTER="bt" by default

2018-02-14 Thread Paul Goyette
On Thu, 15 Feb 2018, Sevan Janiyan wrote: On 13/02/2018 23:40, Paul Goyette wrote: Probably not needed. If you just set ddb.onpanic to 2 it should cause a stack trace to be printed before prompting for a command. See ddb(4) man page... On 14/02/2018 00:35, Christos Zoulas wrote: You can

Re: setting DDB_COMMANDONENTER="bt" by default

2018-02-14 Thread Sevan Janiyan
On 13/02/2018 23:40, Paul Goyette wrote: > Probably not needed. If you just set ddb.onpanic to 2 it should cause a > stack trace to be printed before prompting for a command. > > See ddb(4) man page... On 14/02/2018 00:35, Christos Zoulas wrote: > You can just do the same with sysctl

Re: Merging ugen into the usb stack

2018-02-14 Thread Martin Husemann
On Tue, Feb 13, 2018 at 03:07:11PM +0100, Martin Husemann wrote: > On Tue, Feb 13, 2018 at 03:02:56PM +0100, Wolfgang Solfrank wrote: > > What exactly do you mean with "can't use ttyU1"? > > The ttyU1 serial console is dead, no data in/no data out as far as I can > tell. I'll debug/investigate