> не запускается ни в одной из конфигураций. > похоже висит udevd в initrd: > запускается скрипт 000-propagator, последняя строка: > systemd-udevd: starting version 191 > та же картина на сизифе для thinkpad x31 началась некоторое время назад. > С 32-битным iso ловил это на qemu и virtualbox. . > Иногда 000-propagator это место проскакивает. > Закономерности не увидел.
Проверил i586 на Dell Inspiron 1501 и Thinkpad X31. Стабильно висят. На dell поставил последний kdesktop, после чего накатил сизиф. На ядре std-def виснет там же, на un-def работает.
Проблема несомненно в ядре: * un-def (по крайней мере 3.6) в этих же условиях работает * SysRq комбинации при зависании ведут себя странно, а именно информационные sysrq выводят только заголовки, но не саму информацию.
*** Bug 27791 has been marked as a duplicate of this bug. ***
un-def 3.5.4 из архива в этих же условиях работает. Есть мнение, что это может быть связано с новым udev, который, предпололжительно, некорректно работает с непреемптивными ядрами. См. https://lkml.org/lkml/2012/10/2/303
> Есть мнение, что это может быть связано с новым udev, который, > предпололжительно, некорректно работает с непреемптивными ядрами. > См. https://lkml.org/lkml/2012/10/2/303 С другой стороны -- std-def 3.0.20 из p6 с этим udev работает нормально (по крайней мере на железе)..
на Acer 3570 тоже останавливается загрузка. un-def работает.
(В ответ на комментарий №6) > на Acer 3570 тоже останавливается загрузка. un-def работает. Насколько я понимаю, она останавливается почти на любых системах, имеющих диски.
Сборка из #81979 работает. Разница -- включение PREEMPTION. Видимо, придётся так и сделать..
(In reply to comment #8) > Сборка из #81979 работает. Разница -- включение PREEMPTION. Видимо, придётся > так и сделать.. Видимо, придется, но надо понимать, что это объезд баги в udev.
Created attachment 5584 [details] обмен kernel<->udevd , жесткий диск есть
Created attachment 5585 [details] обмен kernel<->udevd , жесткий диск есть [2]
Created attachment 5586 [details] обмен kernel<->udevd , жесткого диска нет (В ответ на комментарий №7) > Насколько я понимаю, она останавливается почти на любых системах, имеющих > диски. Вывод udev monitor c диском (with.hda.log.{1,2}) и без (wo.hda.log) может быть полезен? C жестким диском чехарда начинается после того, как udev видит сообщение от ядра "add /module/libata", независимо от того, подгружены уже libata,ata_generic,ata_piix или нет. В with.hda.log.* выше модули предварительно не загружались. (qemu, std-def 3.5.4, sisyphus)
(В ответ на комментарий №9) > Есть мнение, что это может быть связано с новым udev, который, > предпололжительно, некорректно работает с непреемптивными ядрами. > См. https://lkml.org/lkml/2012/10/2/303 В udev-initramfs (150-alt9) разве новый udev? По ссылке, проблема появилась в районе v.172. В v.150 ее еще не должно быть.
(В ответ на комментарий №13) > В udev-initramfs (150-alt9) разве новый udev? upd: /sbin/udevd --version печатает действительно 150.
(В ответ на комментарий №14) > (В ответ на комментарий №13) > > В udev-initramfs (150-alt9) разве новый udev? Вообще-то в initfs, собранных при помощи make-initrd-propagator не используется udev-initramfs. > upd: /sbin/udevd --version печатает действительно 150. Где? Вот я взял свежий образ, задал неправильный параметр пропагатору, чтоб он остановился и стал вопросы задавать, переключился на вторю консоль и /sbin/udevd --version сказал мне, как и ожидалось, 194
(В ответ на комментарий №15) > > > В udev-initramfs (150-alt9) разве новый udev? > Вообще-то в initfs, собранных при помощи make-initrd-propagator не используется > udev-initramfs. > > > upd: /sbin/udevd --version печатает действительно 150. > Где? initfs для тестов делался mkinitfs из propagator-20101130-alt18, использующего udev-initramfs-150-alt9 с udev 150. Ошибка на un-def с ним воспроизводится.
Исправлено в 3.5.5. commit d039ed8264695916335c639d8de77c3b1ff18e71 "Fix a dead loop in async_synchronize_full()". Т.о. можно собирать с PREEMPT_NONE
Тоже получил вис udevd в initrd на ядрах 3.5 и выше в std-def и un-def на одной машине. На экране после фразы "Starting udevd..." в течение 15 минут ничего не происходит. Проблема оказалась в попадании модулей ядра ide_core, ide_pci_generic, piix и scsi_mod в initrd. Без них система нормально поднимается и работает. Какой из них гадит точно сказать не могу. Но они подхватываются через AUTODETECT = root. Пришлось autodetect убирать и оставлять только загрузку модулей crc-t10dif, sd_mod, libata, ata_piix, pata_acpi, ata_generic, xfs. Система - Сизиф от 11.10.2012.
(В ответ на комментарий №17) > Исправлено в 3.5.5. > > commit d039ed8264695916335c639d8de77c3b1ff18e71 "Fix a dead loop in > async_synchronize_full()". > > Т.о. можно собирать с PREEMPT_NONE Спасибо!
(В ответ на комментарий №19) > (В ответ на комментарий №17) > > Исправлено в 3.5.5. > > > > commit d039ed8264695916335c639d8de77c3b1ff18e71 "Fix a dead loop in > > async_synchronize_full()". > > > > Т.о. можно собирать с PREEMPT_NONE > > Спасибо! Исправлено или нет?
ping Еще актуально?
(В ответ на комментарий №21) > ping > Еще актуально? Сложно сказать, std-def 3.6.6 собран без преемптивности, по идее работает и жалоб нет, но надо убедиться.
(В ответ на комментарий №22) > (В ответ на комментарий №21) > > ping > > Еще актуально? > > Сложно сказать, std-def 3.6.6 собран без преемптивности, по идее работает и > жалоб нет, но надо убедиться. Жалоб по-прежнему нет. Убедились?
(В ответ на комментарий №16) > > initfs для тестов делался mkinitfs из propagator-20101130-alt18, использующего > udev-initramfs-150-alt9 с udev 150. Ошибка на un-def с ним воспроизводится. На std-def 3.5.X это было на самом деле. Пропало с новым std-def 3.6.6.
Закрываю.
