At version 4.3 dmesg -a was added, so you can see console output remotely. If you have lots of output going to /dev/console (happened at 32k of data here) dmesg output will not be readable eventually. The LINT file says MSGBUF_SIZE=40960, but "dmesg -a >file;du file" reports 32(k) when it is broken. It should push out old lines and append new ones when it is full.
Reboot to get a sane dmesg output back.
How-To-Repeat: Set up syslog to log to /dev/console, and send more than ~32k (or whatever your MSGBUF_SIZE is) of data to that facility. Then run dmesg. If it is corrupt, run dmesg -a, redirect to a file, and see how large the file is. It should be about the same as MSGBUF_SIZE.
This occurs because we use a single combined buffer for both kernel
messages (normally captured in the kernel's msgbuf) and logged
console output (/dev/console). This results in a variety of problems,
and would probably be best corrected by breaking out msgbuf into two
separate buffers since their contents have different properties.
An important security issue relating to this bug/feature can be found
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017
- Set Status to "Open"