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. Fix: 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.
State Changed From-To: open->analyzed 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 in bin/25337.
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open"