이는 다음과 같은 맥락입니다.
[ 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: [email protected]
[ 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)
이는 커널 4.18.5(수동으로 컴파일됨)와 함께 Fedora 28을 실행하는 소위 AppVM이라고 불리는 Qubes OS 4.0의 VM(가상 머신) 내부에 있습니다.
메시지( Magic number: 1:252:3141
)가 사라졌습니다.만약에나병합모두이것들최고 옵션이것들기초적인.
왜 이것을 알아야 합니까? 커널을 .config
필요한 만큼만 줄 였으므로 dmesg
로그를 비교하여 누락된 내용과 여전히 필요할 수 있는 내용을 찾습니다.
lspci
참고: 이 가상 머신 내부에는 출력이 없습니다 lsusb
(이유는 모르겠습니다). 아마도 이것이 Xen에서 가상 머신이 작동하는 방식일까요? 그래서 저는 이 숫자들이 어떤 것과 연관되어 있는지 테스트할 수 없으며, 그 자체로는 다른 어떤 것도 의미하지 않습니다 dmesg
.
편집하다:방금 CONFIG_HID_MAGICMOUSE=y
(에서 변경 )을 사용하여 # CONFIG_HID_MAGICMOUSE is not set
커널을 다시 컴파일했는데 메시지가 나타나지 않았습니다! 그래서 내 결론 은 이건 선택사항이 아니야, 아니면 이전에 켜졌던 일부 디버깅 메시지도 꺼두었나요?
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]
답변1
메시지(
Magic number: 1:252:3141
)가 사라졌습니다.만약에나병합모두이것들최고 옵션이것들기초적인.
Magic number: 1:252:3141
.config
이 메시지는 커널 옵션이 다음과 같은 경우에만 나타 납니다 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]
문서에는 다음이 언급되어 있습니다 Magic number:
.https://www.kernel.org/doc/Documentation/power/s2ram.txt
문서에서 다음 내용을 인용합니다(드라이버/베이스/전력/trace.c) 메시지를 담당하는 코드는 다음과 같습니다 Magic number: 1:252:3141
.
/*
* 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
*/