Re: [gentoo-amd64] Re: xx used greatest stack depth: nnn bytes left

[David Shen]

Thanks you all. ;) Really helpful.


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



-- 
Best Regards,
David Shen

http://twitter.com/davidshen84