Re: setting DDB_COMMANDONENTER="bt" by default
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 lines (10?) > and use that as default for the sysctl. > > If no wscons console attaches, let's assume serial console and the > whole problem is nonexistent (i.e. leave ddb.panicstackframes set > to max). Ok, I'll take a look. Sevan
Re: setting DDB_COMMANDONENTER="bt" by default
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 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 lines (10?) and use that as default for the sysctl. If no wscons console attaches, let's assume serial console and the whole problem is nonexistent (i.e. leave ddb.panicstackframes set to max). Martin
Re: setting DDB_COMMANDONENTER="bt" by default
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 trace next. Martin, what's a "reasonable default" for ddb.panicstackframes? Sevan
Re: setting DDB_COMMANDONENTER="bt" by default
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
re: setting DDB_COMMANDONENTER="bt" by default
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 | > variable I recently added. | | if by "default" you mean the KMS one, then there are usually | *heaps* of lines available, and video cameras help :-) Yes, or I can learn not to blink :-) christos
re: setting DDB_COMMANDONENTER="bt" by default
> >> 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 taking a look :) > Like so? (haven't dealt with documentation yet) > https://www.netbsd.org/~sevan/patch-netbsd-ddb-dumpstack.txt i think you need to move the } above the return before the if (db_onpanic > 0) block. right now, db_dumpstack is not set, Debugger() will never be called. rest LGTM. .mrg.
Re: setting DDB_COMMANDONENTER="bt" by default
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 going to sleep on > > > it) > > > > 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. > > i don't think this is the case. > > the builtin stack trace code is fault-tolerant. if it > faults, it will not re-try and you'll get a db> prompt. My memory is hazy. I do have (for more than a decade it seems) a local change in db_trap() that adds db_recover around db_print_loc_and_inst() call, but I think that was to protect from fat fingers in ddb (hpcsh keyboard is tiny :). -uwe
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 > variable I recently added. if by "default" you mean the KMS one, then there are usually *heaps* of lines available, and video cameras help :-)
re: setting DDB_COMMANDONENTER="bt" by default
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 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. i don't think this is the case. the builtin stack trace code is fault-tolerant. if it faults, it will not re-try and you'll get a db> prompt. AFAIR, this support was added and the default left alone, not beacuse the old/current default is right, but that there was pushback from people who wanted the old style. .mrg
Re: setting DDB_COMMANDONENTER="bt" by default
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 could probably print the stack trace "upside down" followed by the panic message? Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
Re: setting DDB_COMMANDONENTER="bt" by default
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 snapshotting a VM when it's > in ddb and then fuzzing the kernel stack before resuming it (I don't > remember if vbox vm debugger is scriptable, you might also need to > hack it a bit to be). Sound like a cool experiment :) Sevan
Re: setting DDB_COMMANDONENTER="bt" by default
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
Re: setting DDB_COMMANDONENTER="bt" by default
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
Re: setting DDB_COMMANDONENTER="bt" by default
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 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. Like so? (haven't dealt with documentation yet) https://www.netbsd.org/~sevan/patch-netbsd-ddb-dumpstack.txt Haven't dealt with documentation yet nor other suggestions which have come up later in the thread, yet. Sevan
Re: setting DDB_COMMANDONENTER="bt" by default
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? +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: setting DDB_COMMANDONENTER="bt" by default
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 ddb.panicstackframes, and also printing panicstr again after the stacktrace if ddb.onpanic = 2 should be simple. Martin
Re: setting DDB_COMMANDONENTER="bt" by default
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 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. > > > > The problem with setting it by default is that the important information > > (the panic message, or the function where the fault happended) may > > be scrolled out of the screen by the stack trace. So I wouldn't > > recommenend activating it by default. > > the Xen kernels are a special case, becasue the console output > > happens in an environnement where it's easy to scroll back. > > > > 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 -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: setting DDB_COMMANDONENTER="bt" by default
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 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. > > The problem with setting it by default is that the important information > (the panic message, or the function where the fault happended) may > be scrolled out of the screen by the stack trace. So I wouldn't > recommenend activating it by default. > the Xen kernels are a special case, becasue the console output > happens in an environnement where it's easy to scroll back. > 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? David
Re: setting DDB_COMMANDONENTER="bt" by default
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 default on some config files albeit with differing > commands to run e.g xen kernels. The problem with setting it by default is that the important information (the panic message, or the function where the fault happended) may be scrolled out of the screen by the stack trace. So I wouldn't recommenend activating it by default. the Xen kernels are a special case, becasue the console output happens in an environnement where it's easy to scroll back. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: setting DDB_COMMANDONENTER="bt" by default
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, Paul Goyette wrote: >> Yes, that matches my recall as well. > >Ah, ok, so leave this to rest? (is it worth testing in -current to see >how things go?) 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. christos
Re: setting DDB_COMMANDONENTER="bt" by default
> 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 current dumpstack method > if (onpanic > 0) > enter ddb > reboot > > (this idea came from jmcneill@.) I'll take a look. Sevan
re: setting DDB_COMMANDONENTER="bt" by default
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). Would be useful to have it there by > >default, especially on the slower ports which require a little more time > >to get going. Cuts out one it > >Happy to make the change to the configs. > > You can just do the same with sysctl ddb.onpanic=2... more importantly, this method also has checks to make sure it doesn't recurse if the backtrace happens to fault. the enter command method doesn't.. we used to do this: - if entering ddb, just enter it (onpanic = 1) - otherwise, dump a trace and reboot (onpanic = 0) the later, we added support for doing both via onpanic = 2, but left the default as-is. 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 current dumpstack method if (onpanic > 0) enter ddb reboot (this idea came from jmcneill@.) .mrg.
Re: setting DDB_COMMANDONENTER="bt" by default
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 recall. > > On 02/15/18 01:33, Paul Goyette wrote: > > Yes, that matches my recall as well. > > Ah, ok, so leave this to rest? (is it worth testing in -current to see > how things go?) 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 snapshotting a VM when it's in ddb and then fuzzing the kernel stack before resuming it (I don't remember if vbox vm debugger is scriptable, you might also need to hack it a bit to be). -uwe
Re: setting DDB_COMMANDONENTER="bt" by default
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
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, Paul Goyette wrote: Yes, that matches my recall as well. Ah, ok, so leave this to rest? (is it worth testing in -current to see how things go?) Yeah, probably best to leave things as they currently are. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: setting DDB_COMMANDONENTER="bt" by default
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 recall as well. Ah, ok, so leave this to rest? (is it worth testing in -current to see how things go?) Sevan
Re: setting DDB_COMMANDONENTER="bt" by default
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 backtrace might cause another panic, so the default was selected to be on the safe(r) side. At least that's what I recall. Yes, that matches my recall as well. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: setting DDB_COMMANDONENTER="bt" by default
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 panic, so the default was selected to be on the safe(r) side. At least that's what I recall. -uwe
Re: setting DDB_COMMANDONENTER="bt" by default
> 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. One of the perks of running the macppc port, fyi if anyone is interested ;) > In any case, rather than setting the command-on-enter string via > >OPTIONS DDB_COMMAND_ON_ENTER="bt" > > 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) Sevan
Re: setting DDB_COMMANDONENTER="bt" by default
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 a default command. e.g in this scenario I have 2 amd64 apple laptops which can't boot normally & panic. As I have a functioning keyboard at the boot loader I can disable smp and boot one of the systems, otherwise I'm completely stuck. I can imagine crashing and not being able to request a backtrace is a common occurrence, and setting this will improve the bug reports we receive, as the user will have more information at hand by default. In return there's one less thing to try on their part to extract more information if required. Sounds like a good case for a custom kernel. Not sure that such a specific situation would warrant turning this on for everyone... In any case, rather than setting the command-on-enter string via OPTIONS DDB_COMMAND_ON_ENTER="bt" I might/would suggest OPTIONS DDB_ONPANIC=2 +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: setting DDB_COMMANDONENTER="bt" by default
> 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 scenario I have 2 amd64 apple laptops which can't boot normally & panic. As I have a functioning keyboard at the boot loader I can disable smp and boot one of the systems, otherwise I'm completely stuck. I can imagine crashing and not being able to request a backtrace is a common occurrence, and setting this will improve the bug reports we receive, as the user will have more information at hand by default. In return there's one less thing to try on their part to extract more information if required. Sevan
Re: setting DDB_COMMANDONENTER="bt" by default
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 just do the same with sysctl ddb.onpanic=2... Thanks for the pointer, so on a fresh system which doesn't have NetBSD installed yet & I have issues booting the stock kernel on install media, how would I set that? 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 +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: setting DDB_COMMANDONENTER="bt" by default
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=2... Thanks for the pointer, so on a fresh system which doesn't have NetBSD installed yet & I have issues booting the stock kernel on install media, how would I set that? Sevan
Re: setting DDB_COMMANDONENTER="bt" by default
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 >default, especially on the slower ports which require a little more time >to get going. Cuts out one it >Happy to make the change to the configs. You can just do the same with sysctl ddb.onpanic=2... christos
Re: setting DDB_COMMANDONENTER="bt" by default
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 there by default, especially on the slower ports which require a little more time to get going. Cuts out one it Happy to make the change to the configs. 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... +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
setting DDB_COMMANDONENTER="bt" by default
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 default, especially on the slower ports which require a little more time to get going. Cuts out one it Happy to make the change to the configs. Sevan
