Bug 27792 - висит udevd в initrd
: висит udevd в initrd
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/kernel-image-std-def)
: unstable
: x86 Linux
: P3 critical
Assigned To:
:
: http://lists.altlinux.org/pipermail/s...
:
:
: 27685
  Show dependency tree
 
Reported: 2012-10-02 13:19 by
Modified: 2012-11-19 17:04 (History)


Attachments
обмен kernel<->udevd , жесткий диск есть (33.70 KB, text/plain)
2012-10-05 18:54, vx8400
no flags Details
обмен kernel<->udevd , жесткий диск есть [2] (47.26 KB, application/octet-stream)
2012-10-05 18:55, vx8400
no flags Details
обмен kernel<->udevd , жесткого диска нет (81.12 KB, text/x-log)
2012-10-05 18:57, vx8400
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


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

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

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

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

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

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

upd: /sbin/udevd --version печатает действительно 150.
------- Comment #15 From 2012-10-15 16:23:45 -------
(В ответ на комментарий №14)
> (В ответ на комментарий №13)
> > В udev-initramfs (150-alt9) разве новый udev? 
Вообще-то в initfs, собранных при помощи make-initrd-propagator не используется
 udev-initramfs.

> upd: /sbin/udevd --version печатает действительно 150.
Где? Вот я взял свежий образ, задал неправильный параметр пропагатору, чтоб он
остановился и стал вопросы задавать, переключился на вторю консоль и 
/sbin/udevd --version сказал мне, как и ожидалось, 194
------- Comment #16 From 2012-10-15 18:14:40 -------
(В ответ на комментарий №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 From 2012-10-15 21:03:14 -------
Исправлено в 3.5.5.

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

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

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

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

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

Жалоб по-прежнему нет. Убедились?
------- Comment #24 From 2012-11-19 16:45:12 -------
(В ответ на комментарий №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 From 2012-11-19 17:04:44 -------
Закрываю.