mjhjmtu

Here it is in context:

[ 0.507474] i8042: PNP: No PS/2 controller found.
[ 0.507568] mousedev: PS/2 mouse device common for all mice
[ 0.507683] device-mapper: uevent: version 1.0.3
[ 0.507809] device-mapper: ioctl: 4.39.0-ioctl (2018-04-03) initialised: dm-devel@redhat.com
[ 0.508081] hidraw: raw HID events driver (C) Jiri Kosina
[ 0.508169] usbcore: registered new interface driver usbhid
[ 0.508186] usbhid: USB HID core driver
[ 0.508401] drop_monitor: Initializing network drop monitor service
[ 0.510160] Initializing XFRM netlink socket
[ 0.510252] NET: Registered protocol family 10
[ 0.513721] Segment Routing with IPv6
[ 0.513769] mip6: Mobile IPv6
[ 0.513822] NET: Registered protocol family 17
[ 0.516773] RAS: Correctable Errors collector initialized.
[ 0.516822] AVX2 version of gcm_enc/dec engaged.
[ 0.516832] AES CTR mode by8 optimization enabled
[ 0.535396] sched_clock: Marking stable (535392296, 0)->(356708768710, -356173376414)
[ 0.541048] registered taskstats version 1
[ 0.541070] Loading compiled-in X.509 certificates
[ 0.549865] Key type big_key registered
[ 0.553967] Key type encrypted registered
[ 0.553984] ima: No TPM chip found, activating TPM-bypass! (rc=-19)
[ 0.553999] ima: Allocated hash algorithm: sha1
[ 0.554183] xenbus_probe_frontend: Device with no driver: device/vbd/51712
[ 0.554195] xenbus_probe_frontend: Device with no driver: device/vbd/51728
[ 0.554205] xenbus_probe_frontend: Device with no driver: device/vbd/51744
[ 0.554216] xenbus_probe_frontend: Device with no driver: device/vbd/51760
[ 0.554227] xenbus_probe_frontend: Device with no driver: device/vif/0
[ 0.554241] Magic number: 1:252:3141
[ 0.554301] hctosys: unable to open rtc device (rtc0)
[ 0.556156] Freeing unused kernel image memory: 2172K
[ 0.841038] Write protecting the kernel read-only data: 20480k
[ 0.843299] Freeing unused kernel image memory: 2024K
[ 0.843560] Freeing unused kernel image memory: 152K
[ 0.843700] rodata_test: all tests were successful
[ 0.985918] blkfront: xvda: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;
[ 0.993816] xvda: xvda1 xvda2 xvda3
[ 1.001625] blkfront: xvdb: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;
[ 1.019880] blkfront: xvdc: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;
[ 1.031687] blkfront: xvdd: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled;
[ 1.105659] xvdc: xvdc1
[ 1.152834] EXT4-fs (xvda3): mounted filesystem with ordered data mode. Opts: (null)
[ 1.161403] EXT4-fs (xvdd): mounting ext3 file system using the ext4 subsystem
[ 1.164350] EXT4-fs (xvdd): mounted filesystem with ordered data mode. Opts: (null)
[ 1.173317] EXT4-fs (xvda3): re-mounted. Opts: (null)
[ 1.184075] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x6a8f3c48a1e, max_idle_ns: 881591127766 ns
[ 1.207129] EXT4-fs (xvda3): re-mounted. Opts: (null)

This is inside a VM (virtual machine) under Qubes OS 4.0, a so called AppVM running Fedora 28 with kernel 4.18.5 (manually compiled).

The message(Magic number: 1:252:3141) is gone if I merge all these options on top of these base ones.

Why do I need to know this? I am reducing my kernel .config to only what's needed, so I'm comparing dmesg logs for anything that is missing and I might still need.

Note: there is no output for lspci or lsusb inside this VM (I don't know why), maybe this is how it works for VMs under xen? So I couldn't test to see if those numbers grep to anything - and it's nothing else in the dmesg itself.

EDIT: I recompiled kernel with only CONFIG_HID_MAGICMOUSE=y (changed from # CONFIG_HID_MAGICMOUSE is not set) and the message did not appear! So I conclude that either this is not the option, OR I also turned off some debug messages that were previously on?

CONFIG_HID_MAGICMOUSE: 

Support for the Apple Magic Mouse/Trackpad multi-touch. 

Say Y here if you want support for the multi-touch features of the 
Apple Wireless "Magic" Mouse and the Apple Wireless "Magic" Trackpad.

Symbol: HID_MAGICMOUSE [=n] 
Type : tristate 
Prompt: Apple Magic Mouse/Trackpad multi-touch support
 Location: 
 -> Device Drivers 
 -> HID support 
 -> HID bus support (HID [=y]) 
 -> Special HID drivers 
 Defined at drivers/hid/Kconfig:561 
 Depends on: INPUT [=y] && HID [=y] 

The message(Magic number: 1:252:3141) is gone if I merge all these options on top of these base ones.

The message Magic number: 1:252:3141 appears only when kernel .config option CONFIG_PM_TRACE_RTC=y:

CONFIG_PM_TRACE_RTC: 

This enables some cheesy code to save the last PM event point in the
RTC across reboots, so that you can debug a machine that just hangs 
during suspend (or more commonly, during resume). 

To use this debugging feature you should attempt to suspend the 
machine, reboot it and then run 

 dmesg -s 1000000 | grep 'hash matches' 

CAUTION: this option will cause your machine's real-time clock to be
set to an invalid time after a resume. 

Symbol: PM_TRACE_RTC [=y] 
Type : bool 
Prompt: Suspend/resume event tracing 
 Location: 
 -> Power management and ACPI options 
 Defined at kernel/power/Kconfig:218 
 Depends on: PM_SLEEP_DEBUG [=y] && X86 [=y] 
 Selects: PM_TRACE [=y] 

Documentation mentioning Magic number:: https://www.kernel.org/doc/Documentation/power/s2ram.txt

Quoting the following from the file(drivers/base/power/trace.c) whose code is responsible for the Magic number: 1:252:3141 message:

/*
 * drivers/base/power/trace.c
 *
 * Copyright (C) 2006 Linus Torvalds
 *
 * Trace facility for suspend/resume problems, when none of the
 * devices may be working.
 */
...
/*
 * Horrid, horrid, horrid.
 *
 * It turns out that the _only_ piece of hardware that actually
 * keeps its value across a hard boot (and, more importantly, the
 * POST init sequence) is literally the realtime clock.
 *
 * Never mind that an RTC chip has 114 bytes (and often a whole
 * other bank of an additional 128 bytes) of nice SRAM that is
 * _designed_ to keep data - the POST will clear it. So we literally
 * can just use the few bytes of actual time data, which means that
 * we're really limited.
 *
 * It means, for example, that we can't use the seconds at all
 * (since the time between the hang and the boot might be more
 * than a minute), and we'd better not depend on the low bits of
 * the minutes either.
 *
 * There are the wday fields etc, but I wouldn't guarantee those
 * are dependable either. And if the date isn't valid, either the
 * hw or POST will do strange things.
 *
 * So we're left with:
 * - year: 0-99
 * - month: 0-11
 * - day-of-month: 1-28
 * - hour: 0-23
 * - min: (0-30)*2
 *
 * Giving us a total range of 0-16128000 (0xf61800), ie less
 * than 24 bits of actual data we can save across reboots.
 *
 * And if your box can't boot in less than three minutes,
 * you're screwed.
 *
 * Now, almost 24 bits of data is pitifully small, so we need
 * to be pretty dense if we want to use it for anything nice.
 * What we do is that instead of saving off nice readable info,
 * we save off _hashes_ of information that we can hopefully
 * regenerate after the reboot.
 *
 * In particular, this means that we might be unlucky, and hit
 * a case where we have a hash collision, and we end up not
 * being able to tell for certain exactly which case happened.
 * But that's hopefully unlikely.
 *
 * What we do is to take the bits we can fit, and split them
 * into three parts (16*997*1009 = 16095568), and use the values
 * for:
 * - 0-15: user-settable
 * - 0-996: file + line number
 * - 0-1008: device
 */