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:
> >
> > 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
