哪个内核 .config 选项会导致 dmesg 上出现“幻数：1:252:3141”？

Question

消息( 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

引用文件中的以下内容（驱动程序/base/power/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
 */

Answer 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

引用文件中的以下内容（驱动程序/base/power/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
 */

哪个内核 .config 选项会导致 dmesg 上出现“幻数：1:252:3141”？

答案1

相关内容