On 17/02/2018 10:52, Martin Husemann wrote:
> I wonder if we should create a ddb_set_console_lines() function
> which is an empty dummy if no ddb is compiled in. Then have the
> wscons driver call it when attaching the console with the actual
> number of lines. The function would subtrace a few lin
On Sat, Feb 17, 2018 at 02:35:01AM +, Sevan Janiyan wrote:
> Will look at getting a panic message to print after trace next.
> Martin, what's a "reasonable default" for ddb.panicstackframes?
I wonder if we should create a ddb_set_console_lines() function
which is an empty dummy if no ddb is co
On 02/17/18 01:23, Sevan Janiyan wrote:
> Cool, thanks for the heads up.
> That's in and ddb(4) has been updated also.
>
> Now to clean up those kernel configs which set DDB_COMMANDONENTER="bt" :)
updated options(4) too, thanks to pgoyette.
Will look at getting a panic message to print after tr
On 02/16/18 22:38, matthew green wrote:
> rest LGTM.
Cool, thanks for the heads up.
That's in and ddb(4) has been updated also.
Now to clean up those kernel configs which set DDB_COMMANDONENTER="bt" :)
Sevan
On Feb 17, 9:13am, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: setting DDB_COMMANDONENTER="bt" by default
| > also the backtrace is not that useful on the default glass console tty
| > unless you also limit the number of backtrace level with the new sysctl
| >
> >> eg, make it look like, with new "dumpstack" sysctl, defaults
> >> to value of 1:
> >>
> >> if (dumpstack > 0)
> >> do current dumpstack method
> >> if (onpanic > 0)
> >> enter ddb
> >> reboot
> >>
> >> (this idea came from jmcneill@.)
> >
> > I'll take a look.
thanks for taki
On Sat, Feb 17, 2018 at 08:35:32 +1100, matthew green wrote:
> Valery Ushakov writes:
> > 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 goi
> also the backtrace is not that useful on the default glass console tty
> unless you also limit the number of backtrace level with the new sysctl
> variable I recently added.
if by "default" you mean the KMS one, then there are usually
*heaps* of lines available, and video cameras help :-)
Valery Ushakov writes:
> 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 pri
On Thu, Feb 15, 2018 at 06:27:25PM +, David Brownlee wrote:
> Is there some useful variant where the panic message is shown again at the
> end of the stack trace, or the stack trace defaults to a very small number
> of entries by default?
I figure it is not a simple matter to program, but you
On 02/15/18 09:27, Valery Ushakov wrote:
> Well, "testing" here would be to throw random garbage in the stack for
> "bt" to choke on (and that garbage might also need to point to just
> the right other data). You might be able to script this with
> something like vbox snapshots I guess, by snaps
On 02/15/18 17:51, Manuel Bouyer wrote:
> the Xen kernels are a special case, becasue the console output
> happens in an environnement where it's easy to scroll back.
Ah, I see. There are configs in other ports which set it also though.
Sevan
On 02/15/18 21:06, Martin Husemann wrote:
> We can make a reasonable default for ddb.panicstackframes, and
> also printing panicstr again after the stacktrace if ddb.onpanic = 2
> should be simple.
Will take a look tomorrow.
Sevan
On 02/15/18 12:00, Sevan Janiyan wrote:
>
>
>> On 14 Feb 2018, at 20:35, matthew green wrote:
>>
>> i think we should actually make ddb default to this with a
>> new sysctl, and remove interpretting onpanic = 2 differently.
>> eg, make it look like, with new "dumpstack" sysctl, defaults
>> to
On Thu, 15 Feb 2018, Christos Zoulas wrote:
also the backtrace is not that useful on the default glass console tty
unless you also limit the number of backtrace level with the new sysctl
variable I recently added.
Which new sysctl variable is this?
+--+---
On Thu, Feb 15, 2018 at 08:28:36PM +0100, Manuel Bouyer wrote:
> > Is there some useful variant where the panic message is shown again at the
> > end of the stack trace, or the stack trace defaults to a very small number
> > of entries by default?
>
> AFAIK no
We can make a reasonable default for
On Thu, Feb 15, 2018 at 06:27:25PM +, David Brownlee wrote:
> On 15 February 2018 at 17:51, Manuel Bouyer wrote:
>
> > On Thu, Feb 15, 2018 at 01:19:31AM +, Sevan Janiyan wrote:
> > >
> > >
> > > > On 15 Feb 2018, at 01:09, Paul Goyette wrote:
> > > >
> > > > Sounds like a good case for
On 15 February 2018 at 17:51, Manuel Bouyer wrote:
> On Thu, Feb 15, 2018 at 01:19:31AM +, Sevan Janiyan wrote:
> >
> >
> > > 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 tu
On Thu, Feb 15, 2018 at 01:19:31AM +, Sevan Janiyan wrote:
>
>
> > 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 defaul
In article ,
Sevan Janiyan wrote:
>
>
>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,
> On 14 Feb 2018, at 20:35, matthew green wrote:
>
> i think we should actually make ddb default to this with a
> new sysctl, and remove interpretting onpanic = 2 differently.
> eg, make it look like, with new "dumpstack" sysctl, defaults
> to value of 1:
>
> if (dumpstack > 0)
> do cur
Christos Zoulas writes:
> In article ,
> Sevan Janiyan wrote:
> >Hello,
> >Is there any reason good reason why we should not opt for
> >DDB_COMMANDONENTER="bt" by default across the board??
> >We have it set or a variation of, on some ports (amd64, some evbarm and
> >evbmips configs, i386, macppc
On Thu, Feb 15, 2018 at 02:11:07 +, Sevan Janiyan wrote:
> 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 reca
On 15/02/2018 02:35, Paul Goyette wrote:
> Yeah, probably best to leave things as they currently are.
Ok, no problem. :)
Sevan
On Thu, 15 Feb 2018, Sevan Janiyan wrote:
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, Pau
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 r
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 pan
> 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 run e.g xen kernels.
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 hence wanting to set
> 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.
e.g in this scenar
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 j
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 ddb.onpanic
In article ,
Sevan Janiyan wrote:
>Hello,
>Is there any reason good reason why we should not opt for
>DDB_COMMANDONENTER="bt" by default across the board??
>We have it set or a variation of, on some ports (amd64, some evbarm and
>evbmips configs, i386, macppc). Would be useful to have it there by
On Tue, 13 Feb 2018, Sevan Janiyan wrote:
Hello,
Is there any reason good reason why we should not opt for
DDB_COMMANDONENTER="bt" by default across the board??
We have it set or a variation of, on some ports (amd64, some evbarm and
evbmips configs, i386, macppc). Would be useful to have it ther
35 matches
Mail list logo
