Re: sysctl ddb.trigger
Paul de Weerd: > Indeed, `sysctl kern.securelevel=-1` allows entering DDB with `sysctl > ddb.trigger=1`. (Yes, I am logged in over serial, and that works > well). That was not clear from the ddb manpage, nor from the > securelevel manpage It's in sysctl(2): DBCTL_TRIGGER (ddb.trigger) When DBCTL_CONSOLE is set, writing to DBCTL_TRIGGER causes the system to enter ddb(4). When running with a securelevel(7) greater than 0, the process writing to this variable must be running on the console in order to enter ddb(4). > --- ddb.4 22 Dec 2022 19:53:22 - 1.105 > +++ ddb.4 30 May 2023 06:34:19 - > @@ -46,7 +46,9 @@ is invoked upon a kernel panic when the > is set to 1. > It may be invoked from the console when the sysctl > .Va ddb.console > -is set to 1, using any of the following methods: > +is set to 1 and > +.Va kern.securelevel > +is set to 0 or -1, using any of the following methods: But your problem appears to be that you are invoking it not from the console. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: sysctl ddb.trigger
Thank you, Stuart, Sebastien and Aaron (and others, off-list).
Indeed, `sysctl kern.securelevel=-1` allows entering DDB with `sysctl
ddb.trigger=1`. (Yes, I am logged in over serial, and that works
well). That was not clear from the ddb manpage, nor from the
securelevel manpage (admittedly, I didn't read that until after the
replies to my mail, since I didn't think securelevel played into
this).
I suggest the below diffs to document this requirement.
Paul
PS: sending BREAK over uplcom still doesn't work, but if I'm reading
Stuart correctly, I think this is because my serial getty runs on
tty00, not on console:
[weerd@pom] $ grep -e console -e tty00 /etc/ttys
console "/usr/libexec/getty std.9600" vt220 off secure
tty00 "/usr/libexec/getty std.115200" vt220on secure
On this machine, I often switch between `set tty pc0` and `set tty
com0` for debugging purposes, but I always want a getty running on the
serial port.
Index: ddb.4
===
RCS file: /cvs/src/share/man/man4/ddb.4,v
retrieving revision 1.105
diff -u -p -r1.105 ddb.4
--- ddb.4 22 Dec 2022 19:53:22 - 1.105
+++ ddb.4 30 May 2023 06:34:19 -
@@ -46,7 +46,9 @@ is invoked upon a kernel panic when the
is set to 1.
It may be invoked from the console when the sysctl
.Va ddb.console
-is set to 1, using any of the following methods:
+is set to 1 and
+.Va kern.securelevel
+is set to 0 or -1, using any of the following methods:
.Bl -dash -offset 3n
.It
Using the key sequence
Index: securelevel.7
===
RCS file: /cvs/src/share/man/man7/securelevel.7,v
retrieving revision 1.31
diff -u -p -r1.31 securelevel.7
--- securelevel.7 21 Aug 2019 20:44:09 - 1.31
+++ securelevel.7 30 May 2023 06:36:30 -
@@ -73,6 +73,7 @@ raw disk devices of mounted file systems
system immutable and append-only file flags may not be removed
.It
the
+.Va ddb.trigger ,
.Va fs.posix.setuid ,
.Va hw.allowpowerdown ,
.Va kern.allowkmem ,
On Mon, May 29, 2023 at 07:56:51AM -, Stuart Henderson wrote:
| On 2023-05-29, Sebastien Marie wrote:
| > On Mon, May 29, 2023 at 02:41:00PM +1000, Aaron Mason wrote:
| >> On Mon, May 29, 2023 at 4:08 AM Paul de Weerd wrote:
| >> >
| >> > (for the record, BREAK doesn't work either to enter ddb, I
| >> > guessed it was due to the USB-to-serial dongle I'm using (uplcom(4)
| >> > lacking support for sending a proper BREAK .. but this may be the same
| >> > issue?)
|
| fwiw BREAK does usually work in uplcom. It's uark that is known not to work.
| (but since a BREAK is just holding the line at 0 for longer than a normal
| character transmission time, if the console port speed is fairly high,
| it's easy to send something that will be interpreted as break by setting
| a low speed on the transmitting port and sending a char with enough 0 bits
| in it).
|
| > From the code, to use ddb.trigger (aka DBCTL_TRIGGER), you need:
| >
| > - kern.securelevel < 1 (on a running system, kern.securelevel = -1)
| > OR
| > - something related to the console (I suppose "having the tty of the
current
| > process being the same than the console")
| >
| > If you are connected to serial, but your console is on VGA, it might be
related.
|
| If that's the case, 1) it would also prevent BREAK on the serial port
| from working, and 2) it probably wouldn't help to be able to trigger
| ddb anyway, because ddb output will go to the system console, not the
| console where ddb.trigger=1 was used.
|
| > So you might need to set kern.securelevel to lower value ("sysctl
kern.securelevel=-1"
| > in /etc/rc.securelevel), or make your console on serial (with "set tty
com0" on
| > bootloader).
|
| If 'set tty comX' isn't already used, the answer is almost certainly to
| set that.
|
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: sysctl ddb.trigger
On 2023-05-29, Sebastien Marie wrote:
> On Mon, May 29, 2023 at 02:41:00PM +1000, Aaron Mason wrote:
>> On Mon, May 29, 2023 at 4:08 AM Paul de Weerd wrote:
>> >
>> > (for the record, BREAK doesn't work either to enter ddb, I
>> > guessed it was due to the USB-to-serial dongle I'm using (uplcom(4)
>> > lacking support for sending a proper BREAK .. but this may be the same
>> > issue?)
fwiw BREAK does usually work in uplcom. It's uark that is known not to work.
(but since a BREAK is just holding the line at 0 for longer than a normal
character transmission time, if the console port speed is fairly high,
it's easy to send something that will be interpreted as break by setting
a low speed on the transmitting port and sending a char with enough 0 bits
in it).
> From the code, to use ddb.trigger (aka DBCTL_TRIGGER), you need:
>
> - kern.securelevel < 1 (on a running system, kern.securelevel = -1)
> OR
> - something related to the console (I suppose "having the tty of the current
> process being the same than the console")
>
> If you are connected to serial, but your console is on VGA, it might be
> related.
If that's the case, 1) it would also prevent BREAK on the serial port
from working, and 2) it probably wouldn't help to be able to trigger
ddb anyway, because ddb output will go to the system console, not the
console where ddb.trigger=1 was used.
> So you might need to set kern.securelevel to lower value ("sysctl
> kern.securelevel=-1"
> in /etc/rc.securelevel), or make your console on serial (with "set tty com0"
> on
> bootloader).
If 'set tty comX' isn't already used, the answer is almost certainly to
set that.
Re: sysctl ddb.trigger
On Mon, May 29, 2023 at 02:41:00PM +1000, Aaron Mason wrote:
> On Mon, May 29, 2023 at 4:08 AM Paul de Weerd wrote:
> >
> > Hi folks,
> >
> > I'm trying to debug an issue where my machine partially locks up after
> > some hours (somewhere between 12 and 48, is my current window). The
> > extent of the locking is still unclear, that's part of what I'm trying
> > to figure out.
> >
> > While debugging, I thought I'd try to enter ddb, so I set ddb.console
> > to 1 in /etc/sysctl.conf and tried to write to ddb.trigger:
> >
> > pom# sysctl ddb.{console,panic}
> > ddb.console=1
> > ddb.panic=1
> > pom# sysctl ddb.trigger=1
> > sysctl: ddb.trigger: Operation not supported by device
> >
> > Am I holding this thing wrong? According to ddb(4), the above should
> > be sufficient, no?
> >
> > One thing to note is that I'm running this from a chroot into a mfs
> > system (as part of the debugging of the locking up), could that affect
> > things? Even if it's from a chroot, I can still change sysctl MIBs -
> > is ddb.trigger special?
> >
> > I'm doing all this through the serial console (glass console and
> > network both are unresponsive in the locked up state), could that be
> > related? (for the record, BREAK doesn't work either to enter ddb, I
> > guessed it was due to the USB-to-serial dongle I'm using (uplcom(4)
> > lacking support for sending a proper BREAK .. but this may be the same
> > issue?)
> >
> > Paul
> >
>
> Just spitballing... could it be something blocked by kern.securelevel?
>
It might helps.
The "Operation not supported by device" is ENODEV, and seems to be the one here:
sys/ddb/db_usrreq.c
74 case DBCTL_TRIGGER:
75 if (newp && db_console) {
76 struct process *pr = curproc->p_p;
77
78 if (securelevel < 1 ||
79 (pr->ps_flags & PS_CONTROLT && cn_tab &&
80 cn_tab->cn_dev ==
pr->ps_session->s_ttyp->t_dev)) {
81 db_enter();
82 newp = NULL;
83 } else
84 return (ENODEV);
85 }
86 return (sysctl_rdint(oldp, oldlenp, newp, 0));
>From the code, to use ddb.trigger (aka DBCTL_TRIGGER), you need:
- kern.securelevel < 1 (on a running system, kern.securelevel = -1)
OR
- something related to the console (I suppose "having the tty of the current
process being the same than the console")
If you are connected to serial, but your console is on VGA, it might be related.
So you might need to set kern.securelevel to lower value ("sysctl
kern.securelevel=-1"
in /etc/rc.securelevel), or make your console on serial (with "set tty com0" on
bootloader).
Thanks.
--
Sebastien Marie
Re: sysctl ddb.trigger
On Mon, May 29, 2023 at 4:08 AM Paul de Weerd wrote:
>
> Hi folks,
>
> I'm trying to debug an issue where my machine partially locks up after
> some hours (somewhere between 12 and 48, is my current window). The
> extent of the locking is still unclear, that's part of what I'm trying
> to figure out.
>
> While debugging, I thought I'd try to enter ddb, so I set ddb.console
> to 1 in /etc/sysctl.conf and tried to write to ddb.trigger:
>
> pom# sysctl ddb.{console,panic}
> ddb.console=1
> ddb.panic=1
> pom# sysctl ddb.trigger=1
> sysctl: ddb.trigger: Operation not supported by device
>
> Am I holding this thing wrong? According to ddb(4), the above should
> be sufficient, no?
>
> One thing to note is that I'm running this from a chroot into a mfs
> system (as part of the debugging of the locking up), could that affect
> things? Even if it's from a chroot, I can still change sysctl MIBs -
> is ddb.trigger special?
>
> I'm doing all this through the serial console (glass console and
> network both are unresponsive in the locked up state), could that be
> related? (for the record, BREAK doesn't work either to enter ddb, I
> guessed it was due to the USB-to-serial dongle I'm using (uplcom(4)
> lacking support for sending a proper BREAK .. but this may be the same
> issue?)
>
> Paul
>
> --
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
> http://www.weirdnet.nl/
>
Just spitballing... could it be something blocked by kern.securelevel?
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
sysctl ddb.trigger
Hi folks,
I'm trying to debug an issue where my machine partially locks up after
some hours (somewhere between 12 and 48, is my current window). The
extent of the locking is still unclear, that's part of what I'm trying
to figure out.
While debugging, I thought I'd try to enter ddb, so I set ddb.console
to 1 in /etc/sysctl.conf and tried to write to ddb.trigger:
pom# sysctl ddb.{console,panic}
ddb.console=1
ddb.panic=1
pom# sysctl ddb.trigger=1
sysctl: ddb.trigger: Operation not supported by device
Am I holding this thing wrong? According to ddb(4), the above should
be sufficient, no?
One thing to note is that I'm running this from a chroot into a mfs
system (as part of the debugging of the locking up), could that affect
things? Even if it's from a chroot, I can still change sysctl MIBs -
is ddb.trigger special?
I'm doing all this through the serial console (glass console and
network both are unresponsive in the locked up state), could that be
related? (for the record, BREAK doesn't work either to enter ddb, I
guessed it was due to the USB-to-serial dongle I'm using (uplcom(4)
lacking support for sending a proper BREAK .. but this may be the same
issue?)
Paul
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
