Bug 27792

Summary: висит udevd в initrd
Product: Sisyphus Reporter: vx8400 <vx8400>
Component: kernel-image-std-defAssignee: Vitaly Chikunov <vt>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: critical    
Priority: P3 CC: aen, dans, dubrsl, george, kernelbot, led, placeholder, real.altlinux.org, serpiph, shaba, vt
Version: unstable   
Hardware: x86   
OS: Linux   
URL: http://lists.altlinux.org/pipermail/sisyphus/2012-October/358542.html
Bug Depends on:    
Bug Blocks: 27685    
Attachments:
Description Flags
обмен kernel<->udevd , жесткий диск есть
none
обмен kernel<->udevd , жесткий диск есть [2]
none
обмен kernel<->udevd , жесткого диска нет none

Description vx8400 2012-10-02 13:19:00 MSK 
> не запускается ни в одной из конфигураций.
> похоже висит udevd в initrd:
> запускается скрипт 000-propagator, последняя строка:
> systemd-udevd: starting version 191
> та же картина на сизифе для thinkpad x31 началась некоторое время назад.

> С 32-битным iso ловил это на qemu и virtualbox. .
> Иногда 000-propagator это место проскакивает.
> Закономерности не увидел.
Comment 1 Denis Pynkin 2012-10-02 16:12:19 MSK 
Проверил i586 на Dell Inspiron 1501 и Thinkpad X31.
Стабильно висят.

На dell поставил последний kdesktop, после чего накатил сизиф.
На ядре std-def виснет там же, на un-def работает.
Comment 2 Anton V. Boyarshinov 2012-10-03 12:22:57 MSK 
Проблема несомненно в ядре:
* un-def (по крайней мере 3.6) в этих же условиях работает
* SysRq комбинации при зависании ведут себя странно, а именно информационные sysrq выводят только заголовки, но не саму информацию.
Comment 3 Anton V. Boyarshinov 2012-10-03 12:25:24 MSK 
*** Bug 27791 has been marked as a duplicate of this bug. ***
Comment 4 Anton V. Boyarshinov 2012-10-03 12:47:33 MSK 
un-def 3.5.4 из архива в этих же условиях работает.

Есть мнение, что это может быть связано с новым udev, который,
предпололжительно, некорректно работает с непреемптивными ядрами.
См. https://lkml.org/lkml/2012/10/2/303
Comment 5 Anton V. Boyarshinov 2012-10-03 13:16:41 MSK 
> Есть мнение, что это может быть связано с новым udev, который,
> предпололжительно, некорректно работает с непреемптивными ядрами.
> См. https://lkml.org/lkml/2012/10/2/303
С другой стороны -- std-def 3.0.20 из p6 с этим udev работает нормально (по крайней мере на железе)..
Comment 6 Slava Dubrovskiy 2012-10-04 09:58:13 MSK 
на Acer 3570 тоже останавливается загрузка. un-def работает.
Comment 7 Anton V. Boyarshinov 2012-10-04 10:39:56 MSK 
(В ответ на комментарий №6)
> на Acer 3570 тоже останавливается загрузка. un-def работает.
Насколько я понимаю, она останавливается почти на любых системах, имеющих диски.
Comment 8 Anton V. Boyarshinov 2012-10-05 14:54:26 MSK 
Сборка из #81979 работает. Разница -- включение PREEMPTION. Видимо, придётся так и сделать..
Comment 9 Dmitry V. Levin 2012-10-05 14:55:59 MSK 
(In reply to comment #8)
> Сборка из #81979 работает. Разница -- включение PREEMPTION. Видимо, придётся
> так и сделать..

Видимо, придется, но надо понимать, что это объезд баги в udev.
Comment 10 vx8400 2012-10-05 18:54:22 MSK 
Created attachment 5584 [details]
обмен kernel<->udevd , жесткий диск есть
Comment 11 vx8400 2012-10-05 18:55:19 MSK 
Created attachment 5585 [details]
обмен kernel<->udevd , жесткий диск есть [2]
Comment 12 vx8400 2012-10-05 18:57:51 MSK 
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)
Comment 13 vx8400 2012-10-06 17:16:57 MSK 
(В ответ на комментарий №9)
> Есть мнение, что это может быть связано с новым udev, который,
> предпололжительно, некорректно работает с непреемптивными ядрами.
> См. https://lkml.org/lkml/2012/10/2/303

В udev-initramfs (150-alt9) разве новый udev? По ссылке, проблема появилась в районе v.172. В v.150 ее еще не должно быть.
Comment 14 vx8400 2012-10-06 23:35:10 MSK 
(В ответ на комментарий №13)
> В udev-initramfs (150-alt9) разве новый udev? 

upd: /sbin/udevd --version печатает действительно 150.
Comment 15 Anton V. Boyarshinov 2012-10-15 16:23:45 MSK 
(В ответ на комментарий №14)
> (В ответ на комментарий №13)
> > В udev-initramfs (150-alt9) разве новый udev? 
Вообще-то в initfs, собранных при помощи make-initrd-propagator не используется  udev-initramfs.
 
> upd: /sbin/udevd --version печатает действительно 150.
Где? Вот я взял свежий образ, задал неправильный параметр пропагатору, чтоб он остановился и стал вопросы задавать, переключился на вторю консоль и  /sbin/udevd --version сказал мне, как и ожидалось, 194
Comment 16 vx8400 2012-10-15 18:14:40 MSK 
(В ответ на комментарий №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 с ним воспроизводится.
Comment 17 led 2012-10-15 21:03:14 MSK 
Исправлено в 3.5.5.

commit d039ed8264695916335c639d8de77c3b1ff18e71 "Fix a dead loop in async_synchronize_full()".

Т.о. можно собирать с PREEMPT_NONE
Comment 18 serpiph 2012-10-16 15:02:11 MSK 
Тоже получил вис 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.
Comment 19 Anton V. Boyarshinov 2012-10-16 15:49:58 MSK 
(В ответ на комментарий №17)
> Исправлено в 3.5.5.
> 
> commit d039ed8264695916335c639d8de77c3b1ff18e71 "Fix a dead loop in
> async_synchronize_full()".
> 
> Т.о. можно собирать с PREEMPT_NONE

Спасибо!
Comment 20 AEN 2012-11-01 07:21:22 MSK 
(В ответ на комментарий №19)
> (В ответ на комментарий №17)
> > Исправлено в 3.5.5.
> > 
> > commit d039ed8264695916335c639d8de77c3b1ff18e71 "Fix a dead loop in
> > async_synchronize_full()".
> > 
> > Т.о. можно собирать с PREEMPT_NONE
> 
> Спасибо!

Исправлено или нет?
Comment 21 AEN 2012-11-08 22:51:57 MSK 
ping
Еще актуально?
Comment 22 Anton V. Boyarshinov 2012-11-09 13:24:12 MSK 
(В ответ на комментарий №21)
> ping
> Еще актуально?

Сложно сказать, std-def 3.6.6 собран без преемптивности, по идее работает и жалоб нет, но надо убедиться.
Comment 23 AEN 2012-11-18 07:17:18 MSK 
(В ответ на комментарий №22)
> (В ответ на комментарий №21)
> > ping
> > Еще актуально?
> 
> Сложно сказать, std-def 3.6.6 собран без преемптивности, по идее работает и
> жалоб нет, но надо убедиться.

Жалоб по-прежнему нет. Убедились?
Comment 24 vx8400 2012-11-19 16:45:12 MSK 
(В ответ на комментарий №16)
> 
> initfs для тестов делался mkinitfs из propagator-20101130-alt18, использующего
> udev-initramfs-150-alt9 с udev 150. Ошибка на un-def с ним воспроизводится.

На std-def 3.5.X это было на самом деле.

Пропало с новым std-def 3.6.6.
Comment 25 AEN 2012-11-19 17:04:44 MSK 
Закрываю.