С какими опциями я намудрил, что ядро стало медленно загружаться?

Попробуйте указать параметр loglevel=, значения от 0 до 7, что бы получить больше информации.

[    4.121796] alps.c: E6 report: 00 00 64
[    4.441812] alps.c: E7 report: 10 00 64
[    7.744655] IBM TrackPoint firmware: 0x0e, buttons: 3/3
[    7.980628] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/serio2/input/input8

От 4секундной задержки при активации трэкпоинта этого мне помогла активация CONFIG_DEVTMPFS.

diff config.old config.new

Там уже очень много изменений - пытался понять что не так.

Плюсую diff по конфигам, но прозреваю либо отключение CONFIG_SCSI_SCAN_ASYNC и в таком роде, либо вкомпиливание модуля видеокарты, или радости с udev-ом.

Вангую

PCI IOAPIC

Вангую
PCI IOAPIC

Не помогло.

CONFIG_SCSI_SCAN_ASYNC

Не помогло, но включить стоит. Спасибо.

CONFIG_DEVTMPFS

Не помогло.

Активировал вместе с CONFIG_DEVTMPFS_MOUNT?

Оно гентускриптами монтируется без этого.

Если я правильно понял суть этой опции, от devtmpfs будет смонтирована до того, как запустятся скрипты.

diff -u config.old config.new > config.diff

diff -u config.old config.new > config.diff

Я уже писал, что слишком много уже изменено - не могу в этом разобраться. Думал найти эксперта, который более-менее точно скажет куда рыть.

Активировал вместе с CONFIG_DEVTMPFS_MOUNT?

Да, никакого эффекта.

Выложи сюда оба конфига.

Должна уже впиливаться юзером по умолчанию, иначе новый udev не заработает.

Выложи сюда оба конфига.

См. пост. Там ссылки. http://pastebin.com/raw.php?i=jQsX47xc - старый, http://pastebin.com/raw.php?i=WbikvzEm - новый.

Выключил в bios TrackPoint - вторая задержка, естесственно, исчезла. Но что самое странное, но приятное - после включения задержка не появилась... =\ Чудеса случаются?!

Ещё симптоматика: После пересборки ядра (неважно какие опции меняем) задержка снова появляется. Для того, чтобы она исчезла надо опять отключить TrackPoint, загрузится и опять включить.

Более того. Задержку вернулась ещё так: включил в BIOS «Serial port», загружаясь получил SegFault. После перезагрузки появилась задержка...

Что за фигня?!

Что за фигня?!

Говно-acpi.

эм... не хочу ругать 3.3.8, но все прогрессивное человечество уже ждет 3.6-rc7 %)

проверьте, хотя бы, на 3.4.8...

эм... не хочу ругать 3.3.8, но все прогрессивное человечество уже ждет 3.6-rc7 %)
проверьте, хотя бы, на 3.4.8...

Я и на 3.5.0 проверял. Просто в портежах gentoo - 3.3.8 (если ~x86, то 3.5.0).

эм... не хочу ругать 3.3.8, но все прогрессивное человечество уже ждет 3.6-rc7 %)
проверьте, хотя бы, на 3.4.8...

PS: А tuxonice до сих пор 3.2 ;-) (это я о вашей аватарке)

вообщето это теперь нетру вэй, ЕМНИП

ты перезагрузку делаешь или полный павер оф павер он?

О_О слоупочно както у меня 3.5 с айсом, гиксурс он такой.

а попробуйте, ради теста, параметр ядру «acpi=off»

но это жуткий костыль будет, зато яснее будет в чем точнее проблемка

ты перезагрузку делаешь или полный павер оф павер он?

А есть разница?!

sudo reboot

а попробуйте, ради теста, параметр ядру «acpi=off»
но это жуткий костыль будет, зато яснее будет в чем точнее проблемка

первая задержка исчезла

dmesg

Значит смотреть опции, в которых есть ACPI или как?

для некоторых устройств есть. они состояния могут не сбрасывать при ребуте...после обновки ядра попробуй вместо отключения\включения трекпойнта сдалать павероф паверон. и глянь будет ли задержка, но о таком поведении стоит отписать дровомэйнтейнеру.

не-не-не... нет так сразу - отрубать acpi плохая идея. у меня все слетело, когда я его только что вырубал (а у меня тоже леновка) можно попробавать разные вариации

    acpi=       [HW,ACPI,X86]
            Advanced Configuration and Power Interface
            Format: { force | off | strict | noirq | rsdt }
            force -- enable ACPI if default was off
            off -- disable ACPI if default was on
            noirq -- do not use ACPI for IRQ routing
            strict -- Be less tolerant of platforms that are not
                strictly ACPI specification compliant.
            rsdt -- prefer RSDT over (default) XSDT 
            copy_dsdt -- copy DSDT to memory

еще знаю магический парамтр ядра - irqfixup - иногда помогал...

Прохладная история.

Влажные мечты.

Блин, если, если у тебя есть рабочий конфиг - это ж счастье!
Возможные причины две: 1) регресии в ядре и 2) ты что-то наконфигурил.
Различить две проблемы просто. Возьми, примени старый рабочий конфиг к новому ядру. Пробемы исчезли?

Блин, если, если у тебя есть рабочий конфиг - это ж счастье!
Возможные причины две: 1) регресии в ядре и 2) ты что-то наконфигурил.
Различить две проблемы просто. Возьми, примени старый рабочий конфиг к новому >ядру. Пробемы исчезли?

Рабочий конфиг - это не проблема. Во FreeBSD сложнее его получить (ИМХО - не холивара ради). Все верно, 2 -вариант на лицо. Но решить проблему сложно - вчера целый день перебирал опции по порядку - до сих пор не понял какая дала первую задержку. Вот, кстати, переборный diff - плюcиками помечены проверенные опции (их изменение не влияет на задержку №1).

Я до сих пор лелею надежду, что кто-то ткнёт меня в нужное место...

=) Вот ведь шило в $опе - времени на эту херню потратил на порядок больше, чем суммарное количество перезагрузок...

=) Вот ведь шило в $опе - времени на эту херню потратил на порядок больше, чем суммарное количество перезагрузок...

На самом деле, если найдешь, будет полезнейший опыт. Я уже не говорю о том, что багрепорт можно будет запостить.

времени на эту херню потратил на порядок больше

Вспоминаем теорию оптимизации. Не нужно перебирать опции по одной. Дели все изменения пополам: половину оставляй старой, половину применяй. Если бага ушла, то проблема в том наборе опций, которую ты установил на старую, если не ушла - то в какой-то из новых опций. Так ты на каждом шаге сможешь отсекать половину всех изменения. Количество шагов будет равняться log2(N), то есть, если ты сделал 100 изменения, то тебе нужно будет всего 7 шагов чтобы докопаться до заветного параметра.

Хуже, если за это отвечает связка из 2 опций. Но это маловероятно. Если до этого дойдет - расскажу алгоритм для двух опций.

Обязательно выложи результат!!!

Расскажи щас алгоритм, пожалуйста.

Расскажи щас алгоритм, пожалуйста.

Вступление
Две опции могут влиять двояко: каждая из опций дает баг, и они дают баг только когда включены вместе.
Еще нужно четко понимать: мы точно знаем что там именно 2 опции или там их может быть три и более.
Давай для простоты будем под словом «включаешь» понимать «применяешь новые опции».
Под Ok будем понимать ситуацию, когда при тестировании баг НЕ проявился, под notOk - проявление бага при тестировании.

Алгоритм.
Делишь пополам. Включаешь первую половину - тестируешь. Выключаешь первую, включаешь вторую половину - тестируешь. Есть 4 вероятных исхода (результаты первого и второго тестов):
1. notOk, Ok - опции, которые вносят баг, в первой половине.
2. Ok, notOk - опции, которые вносят баг, во второй половине.
3. Ok, Ok - и в первой и во второй половине есть опции, которые вносят баг только когда включены вместе.
4. notOk, notOk - и в первой и во второй половине есть опции, которые вносят баг поотдельности.
В случае 1 и 2 все просто: таким же алгоритмом идешь в ту часть, которая дала notOk.
В случаях 3 и 4 ты таким же способом ныряешь сначала в первую половину, потом во вторую. В случае 3 ты ныряешь в одну половину оставив включенной другую (чтобы иметь возможность проявлять баг), в случае 4 - наоборот, выключив другую, чтобы она не мешала проявлять баг.
Также, если ты четко уверен, что опции только две, то варианты 3 и 4 тебе скажут что в каждой половине есть искомая опция, а значит дальше ты можешь нырять по способу в предыдущем посте (делая только одну проверку на каждом шагу).

Получается, что при каждом делении ты делаешь два теста, а не один.

Надеюсь, я написал достаточно четко.

И самое важное. Когда найдешь опцию, ты должен убедиться, что включение только ее (а остальные оставляем старые) дает баг. Это - критерий успеха.

Вспоминаем теорию оптимизации.

Я примерно так и действую. Только блоками, на которые нативно разделен конфиг. Проблемка в том, что многие опции завязаны друг на друга. А некоторые даже не отображаются в menuconfig (напрямую не включаюстся - только по зависимостям от других). Короче, свои тонкости. А утром заметил, что я в скрипте пересборки/перезаписи забыл дефис в названии - в итоге не то ядро заменял... =) четверть работы коту под хвост.

будет полезнейший опыт

Это да. Я уже структуру конфига полностью представляю. Знаю что на что влияет. Короче, на то и Линуха, чтобы опыт получать.

Начиная с определённого момента мне стало проще апгрейдить старый конфиг до состояния нового (то чего я знаю), чем дайнгрейдить новый до состояния старого. Так что я закругляюсь с поиском проблемы.

Итоговые conf и dmesg кому интересно (загрузка ядра - 1.2 сек. - Lenovo ThinkPad T400). Вторая задержка - явно бага ибо проявляется спонтанно и не у одного меня.

Итоговые conf и dmesg кому интересно (загрузка ядра - 1.2 сек. - Lenovo ThinkPad T400).

Неплохо. В закладки...