Dissecting the acronym, I get that MCH stands for 'Memory Controller Hub' with is an older name for the northbridge. This chip is part of your I/O controller hub.
As for SSKPD, there is not much information I can find other than what is in various intel manuals. Here is a snippet from one of them:
SSKPD — Sticky Scratchpad Data Register
This register holds 64 writable bits with no functionality behind them. It is for the
convenience of BIOS and graphics drivers.
Unfortunately this doesn't give much information on what it is. According to Wikipedia, scratchpad is "special high-speed memory circuit used to hold small items of data for rapid retrieval."
Another piece of information is the log from the commit that added the warning:
drm/i915: detect wrong MCH watermark values
Some early bios versions seem to ship with the wrong tuning values for
the MCH, possible resulting in pipe underruns under load. Especially
on DP outputs this can lead to black screen, since DP really doesn't
like an occasional whack from an underrun.
Unfortunately the registers seem to be locked after boot, so the only
thing we can do is politely point out issues and suggest a BIOS
upgrade.
Arthur Runyan pointed us at this issue while discussion DP bugs - thus
far no confirmation from a bug report yet that it helps. But at least
some of my machines here have wrong values, so this might be useful in
understanding bug reports.
v2: After a bit more discussion with Art and Ben we've decided to only
the check the watermark values, since the OREF ones could be be a
notch more aggressive on certain machines.
So seemingly the value of the register has some meaning on some processors. There isn't anything I can find on the internet at this time which explains exactly what could go wrong by it having the wrong value, but I think this gives a good overall idea.
If you really want to dig further, you could email one of the guys who wrote or reviewed the commit.
To clear up a fundamental misconception, dmesg does not read from /var/log/dmesg. It reads directly from the kernel ring buffer and gives you the most recent N messages. Towards the end of the boot process, dmesg is invoked to write the boot messages to /var/log/dmesg (with older versions of that file being rotated in the usual manner).
Once you have a syslog running (syslogd, rsyslogd, syslog-ng, etc.) it reads from the kernel buffer and writes to a file such as /var/log/kern.log. (This is for Debian; other systems will vary). Assuming your system was able to write to disk and flush the disk buffers before it crashed, that is where you will find the dying screams of the kernel.
On my Debian system the /var/log/kern.log file contains human-readable timestamps.
Best Answer
That’s the timestamp of the event, i.e. the time at which it occurred, measured in seconds (with 0 being equal to the time at which the kernel booted).
You can print actual times using
-Tinstead, skip the timestamps with-t, or specify a format with--time-format. Seeman dmesgfor details.Note:
dmesg, as its manpage says, simply displays the contents of the “kernel ring buffer”, i.e. however many kernel messages fit in the buffer. That might extend all the way back to the kernel boot, but not necessarily. The end of dmesg is the last message printed by the kernel.