| 1 |
Volker Armin Hemmann <volkerarmin@××××××××××.com> posted |
| 2 |
200906301410.28158.volkerarmin@××××××××××.com, excerpted below, on Tue, |
| 3 |
30 Jun 2009 14:10:28 +0200: |
| 4 |
|
| 5 |
> On Dienstag 30 Juni 2009, David Shen wrote: |
| 6 |
>> Hi, |
| 7 |
>> |
| 8 |
>> I setup a gentoo 2008 amd 64 system, and then created my own initramfs |
| 9 |
>> file. But when the initramfs is processed during boot, I got the |
| 10 |
>> following message: |
| 11 |
>> |
| 12 |
>> exe used greatest stack depth: 6040bytes left mdev ...(similar as |
| 13 |
>> above) |
| 14 |
>> lvm ...(similar as above) |
| 15 |
>> |
| 16 |
>> The system could boot, but I am afraid I have made something wrong, and |
| 17 |
>> I have no idea how to troubleshoot this. |
| 18 |
> |
| 19 |
> |
| 20 |
> there is no 'trouble'. You activated a debug feature for devs and now |
| 21 |
> you get the output. Wit 8 or 16lk stack (I think its 16 for amd64, but |
| 22 |
> have to check that), 6k left is nothing to worry about. |
| 23 |
|
| 24 |
FWIW I think it's 8k stack, since the default is (or was at some point, |
| 25 |
I've never set it manually and I have this setting) "Warn for stack |
| 26 |
frames larger than... 2048, and he has 6k left. The setting is |
| 27 |
CONFIG_FRAME_WARN, and it's a number, not a toggle. However, it says set |
| 28 |
to 0 for nowarn. |
| 29 |
|
| 30 |
Duane's DEBUG_STACK_USAGE is apparently for older kernels (a quick git |
| 31 |
checkout and kernel config for older kernels says the CONFIG_FRAME_WARN |
| 32 |
option was added for 2.6.26), as a grep USAGE in the .config turns up no |
| 33 |
hits at all. (There are three for STACK, two indicating support for |
| 34 |
STACKTRACE and USER_STACKTRACE, the third for STACKPROTECTOR.) But it |
| 35 |
would seem the default is or was 2048, thus the warning. |
| 36 |
|
| 37 |
But it's interesting I don't seem to see such warnings here, running LVM |
| 38 |
and RAID-(0/1/6) both. However, I do NOT run an initrd/initramfs. I'm |
| 39 |
guessing that's what's triggering the stack warning (that's what mdev is, |
| 40 |
right?, the ramdisk memory device). |
| 41 |
|
| 42 |
> Go to the kernel hacking submenu in menuconfig and deactivate (almost) |
| 43 |
> everything but magic sysrq keys ... |
| 44 |
|
| 45 |
FWIW, in addition to Magic SysRq key (and 2048 for the stack frame, which |
| 46 |
I guess I could 0 out), I have three options near the bottom of the |
| 47 |
kernel hacking submenu enabled. |
| 48 |
|
| 49 |
Two of them aren't going to be of much interest to folks who like to hide |
| 50 |
their boot messages but they help debug kernels that crash before handing |
| 51 |
control to init, and are thus very useful for those like me that like to |
| 52 |
run kernel pre-releases, -rcs and even direct git kernels, who find that |
| 53 |
they don't boot sometimes, and who file bugs on kernel.org's bugzilla. |
| 54 |
These are the verbose boot messages and early printk options. |
| 55 |
|
| 56 |
The third one (well, actually first, since it's above the other two on |
| 57 |
the menu) is much more generally useful. Filter access to /dev/mem -- |
| 58 |
CONFIG_STRICT_DEVMEM. This is useful to have it enabled as there's not a |
| 59 |
lot that should access that, except debugging. xorg doesn't need it, |
| 60 |
neither does dosemu, or other "common users of /dev/mem". See the help |
| 61 |
for it. "If in doubt, say Y." |
| 62 |
|
| 63 |
Among other things, that can help prevent buggy drivers scribbling on the |
| 64 |
wrong memory, and it has some (limited) security value as well. As such, |
| 65 |
it has been enabled by many of the various security patches, for some |
| 66 |
time. Again, it should normally be enabled unless you do active kernel |
| 67 |
debugging that needs access to /dev/mem. |
| 68 |
|
| 69 |
-- |
| 70 |
Duncan - List replies preferred. No HTML msgs. |
| 71 |
"Every nonfree program has a lord, a master -- |
| 72 |
and if you use the program, he is your master." Richard Stallman |
Archives