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" vt220    on 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 -0000      1.105
+++ ddb.4       30 May 2023 06:34:19 -0000
@@ -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 -0000      1.31
+++ securelevel.7       30 May 2023 06:36:30 -0000
@@ -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 -0000, Stuart Henderson wrote:
| On 2023-05-29, Sebastien Marie <sema...@online.fr> 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 <we...@weirdnet.nl> 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/                 

Reply via email to