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
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
On 15/02/2018 02:35, Paul Goyette wrote:
> Yeah, probably best to leave things as they currently are.
Ok, no problem. :)
Sevan
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
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
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
> 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
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
> 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.
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
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
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
12 matches
Mail list logo