Проверил 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.

Закрываю.