On 2025/01/13 11:53, Stefan Sperling wrote:
> On Sun, Jan 12, 2025 at 09:35:03PM +0100, Radek wrote:
> > Hi,
> > I have two fresh installs of 7.6/amd64 as a router/gateway on APU2 and
> > APU4. There is site-to-site IPSec tunnel between them with ~30Mbps
> > permamenet traffic. The boxes usually drops into ddb (no kernel panic)
> > within a few hours of boot.
> >
> > I attached dmesgs and ddb console outputs of the boxes.
> >
> > ### APU2
> > ddb{0}> show panic
> > the kernel did not panic
> >
> > ddb{0}> trace
> > db_enter() at db_enter+0x14
> > comintr(ffff800000098000) at comintr+0x33e
^^
>
> This looks like sysctl ddb.console is set to 1, and then something
> causes a "break" to appear on the serial port which triggers ddb.
yes, that is a classic "break" trace.
> > rdx 0x3f8
+ there's your serial port :)
Things you can try:
- if you have a cable connected to the APU but unplugged at the other
end, either try disconnecting it, or plug it in to something
- check for a loose connection/intermittent short inside the cable
- if it's a long cable, try a shorter one
- lower the console port speed
To send 'break' you hold the line at 'space' or 'logic 0' condition
for longer than the time to transmit a valid character (including
stop/start/any parity bits) at the current bitrate.
This is detected by the UART on the receiving system, e.g. here is an
excerpt from TI's datasheet for 16550 uart
"Bit 4: This bit is the Break Interrupt (BI) indicator. Bit 4 is set
to a logic 1 whenever the received data input is held in the Spacing
(logic 0) state for longer than a full word transmission time (that
is, the total time of Start bit + data bits + Parity + Stop bits)."
With a standard 8n1 setting, at 115200 that's "longer than about 86
microseconds" and at 9600 it's "longer than about 1ms".
So at higher speeds then either quite a short glitch, or sending a single
char from a device connected to the port at a slower speed e.g. 9600,
can be enough to trigger it.
In particular I do not recommend 115200 for serial ports on devices
which do break detection and 57600 might be a bit high. On my own
systems I normally use 9600 for debug console ports as there's not
normally that much data sent over them and it's way more robust.
You just have to watch out for things that do a bunch of kernel
printfs - 'debug' on pppoe(4) for example is not very fun :)
On the OpenBSD side, update /etc/boot.conf and /etc/ttys to change
this, you'll also have the setting in the APU's bios.
