= Сообщение: 8659 из 10753 ===================================== RU.UNIX.BSD = От : Sergey Anokhin 2:5034/10.999 13 Feb 19 23:28:42 Кому : All 13 Feb 19 23:28:42 Тема : Re: дебаг FGHI : area://RU.UNIX.BSD?msgid=2:5034/10.999+6240aa78 На : area://RU.UNIX.BSD?msgid=grosbein.net+15514ae5 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== > Это он дует на воду, обжегшись на молоке. > Во-первых, kern.maxssiz это не размер стека ядра, а размер стека > прикладных программ, которое им ядро назначает при создании > нового процесса. Размер стека ядерных тредов, о котором > тебе писали PR, измеряется в количестве страниц памяти и меняется > только через ребут и kern.kstack_pages в /boot/loader.conf > и, на самом деле, не имеет отношения к твоей проблеме. > До сравнительно недавнего времени на 32-битных системах > kern.kstack_pages был меньше, чем на amd64 и мог легко > привести к double fault из-за переполнения стека > при очень-очень длинных backtrace, но это не твой случай: > у тебя нет ни double fauilt, ни пары десятков фреймов > в backtrace. > Плюс эта проблема не касалась amd64, а нынче она не касается > и i386, где размер стека ядра подняли до величины на amd64 и > его стало хватать.
