Summary: | висит udevd в initrd | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Sisyphus | Reporter: | vx8400 <vx8400> | ||||||||
Component: | kernel-image-std-def | Assignee: | 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
vx8400
2012-10-02 13:19:00 MSK
Проверил 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. Закрываю. |