LINUX.ORG.RU

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

 


1

5

Работаю на gentoo, использую собственноручно собранное ядро. На ядре 3.0.6 все было более-менее в порядке (config и dmesg). Как только перешел на 3.3.8 появились 2 задержки при загрузке ядра каждая по 5 секунд (config и dmesg):

было

[    0.172049] SCSI subsystem initialized
[    0.172080] libata version 3.00 loaded.
[    0.172080] usbcore: registered new interface driver usbfs
[    0.172089] usbcore: registered new interface driver hub
[    0.172089] usbcore: registered new device driver usb
[    0.173004] Advanced Linux Sound Architecture Driver Version 1.0.24.
[    0.173082] PCI: Using ACPI for IRQ routing
[    0.175430] PCI: pci_cache_line_size set to 64 bytes

стaло

[    0.106031] SCSI subsystem initialized
[    0.106084] libata version 3.00 loaded.
[    5.105246] PCI: Using ACPI for IRQ routing
[    5.107607] PCI: pci_cache_line_size set to 64 bytes</code>
и ещё тут:

было

[    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</code>

стало

[    6.238782] psmouse serio1: synaptics: Touchpad model: 1, fw: 7.0, id: 0x1c0b1, caps: 0xd04791/0xb00000/0x20000
[    6.238895] psmouse serio1: synaptics: serio: Synaptics pass-through port at isa0060/serio1/input0
[    6.284251] input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input1
[    6.288293] registered taskstats version 1
[   11.967080] IBM TrackPoint firmware: 0x0e, buttons: 3/3
[   12.204385] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/serio2/input/input2

Перековырял весь конфиг - не могу понять с чем это связано. Может кто поможет? Любые замечания по конфигу тоже воспринимаются очень положительно.

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

kostik87 ★★★★★ ()
[    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.

Array ()
Ответ на: комментарий от fads

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

hoxnox ()

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

anonymous ()
Ответ на: комментарий от anonymous

CONFIG_SCSI_SCAN_ASYNC

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

hoxnox ()
Ответ на: комментарий от anonymous

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

Array ()
Ответ на: комментарий от anonymous

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

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

hoxnox ()
Ответ на: комментарий от Array

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

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

hoxnox ()
Ответ на: комментарий от Array

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

LongLiveUbuntu ★★★★★ ()

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

hoxnox ()

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

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

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

hoxnox ()
Ответ на: комментарий от metawishmaster

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

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

hoxnox ()
Ответ на: комментарий от metawishmaster

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

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

hoxnox ()
Ответ на: комментарий от hoxnox

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

Thero ★★★★★ ()
Ответ на: комментарий от metawishmaster

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

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

dmesg

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

hoxnox ()
Ответ на: комментарий от hoxnox

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

Thero ★★★★★ ()
Ответ на: комментарий от hoxnox

не-не-не... нет так сразу - отрубать 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
без acpi могли уйти в небытие всякие разные вкусные штуки...

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

metawishmaster ★★★★ ()

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

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

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

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

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

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

hoxnox ()
Ответ на: комментарий от hoxnox

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

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

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

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

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

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

Kroz ★★★★★ ()
Ответ на: комментарий от cdshines

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

Вступление
Две опции могут влиять двояко: каждая из опций дает баг, и они дают баг только когда включены вместе.
Еще нужно четко понимать: мы точно знаем что там именно 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 тебе скажут что в каждой половине есть искомая опция, а значит дальше ты можешь нырять по способу в предыдущем посте (делая только одну проверку на каждом шагу).

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

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

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

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

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

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

hoxnox ()
Ответ на: комментарий от Kroz

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

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

hoxnox ()

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

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

hoxnox ()
Ответ на: комментарий от hoxnox

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

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

Kroz ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.