Summary: | race conditions during media detection | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Sisyphus | Reporter: | Michael Shigorin <mike> | ||||||||||||||
Component: | propagator | Assignee: | Michael Shigorin <mike> | ||||||||||||||
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||||||||||||
Severity: | normal | ||||||||||||||||
Priority: | P3 | CC: | dangolan, dubrsl, gremlin, klark.devel, ldv, mike, rider, ruslandh, sem, zerg | ||||||||||||||
Version: | unstable | Keywords: | usability | ||||||||||||||
Hardware: | all | ||||||||||||||||
OS: | Linux | ||||||||||||||||
Bug Depends on: | |||||||||||||||||
Bug Blocks: | 27685 | ||||||||||||||||
Attachments: |
|
Created attachment 6143 [details]
фрагмент dmesg в "плохом" случае
Вот исправление (спасибо ldv@): http://git.altlinux.org/people/mike/packages/?p=propagator.git;a=commitdiff;h=542567af7b09e4e5d78f85cfb7d48c7ab489b6a8 Желающие приглашаются к тестированию, результат надо будет положить и в бранчи. Это блокер bug #27685, надо протестировать и поместить в p7 до 7.0.5. propagator-20141217-alt1 -> sisyphus: * Wed Dec 17 2014 Michael Shigorin <mike@altlinux> 20141217-alt1 - ldv@'s workaround for media detection race condition (closes: #30315) *** Bug 29140 has been marked as a duplicate of this bug. *** На самом деле проблема не исправлена полностью даже с propagator-20150306-alt1, т.к. причина её явно в параллельно-расистом характере udev; ещё один пинок в виде udevadm trigger (возможно, будет -c add) добавлен в make-initrd-propagator -- но похоже на то, что придётся в цикл "waiting for /dev/disk" добавить пинок в trigger каждые 5--10 секунд (по крайней мере при столкновении с такой ситуацией это на tty2 помогает). Вот с этим патчем пока не получается поймать тот race condition: http://git.altlinux.org/gears/p/propagator.git?p=propagator.git;a=commitdiff;h=ce7dbcef2b00e29fbe7c1318561d93ec07b4fe20 Туда же: https://vk.com/wall-667081_9954 (7.0.5, там ещё не было исправлено) https://vk.com/topic-16711511_33346654 (регулярка, неясно) Опять напоролся. Посмотрел внимательней на disk.c, вкостылил в 20161024-alt2 двухсекундную паузу и повтор попытки найти ФС в /dev/disk/by-label/ по результатам наблюдений за флэшками при загрузке (на синей альтовой довольно устойчиво наблюдается эффект "ro, rw, ro => проиграли гонку"). С этим костылём мне пока не удалось воспроизвести проблему на четырёх сильно разных по скорости флэшках (быстрая/медленная * USB2/USB3). PS: вообще надо бы выкинуть из gfxboot тот хак с перекостыливанием метода -- он сейчас больше мешает, а cdrom.c давно обучен всему нужному для флэшек. Миша, я тебе предлагаю подумать над реализацией поиска флешек в отдельном потоке на основании данных от udev. В этом случае можно было бы реализовать схему, когда пропагатор идёт дальше после появления загрузочного устройства. Ещё. вместо параллельного потока можно вывести сообщение <Waiting for boot device> с кнопкой Cancel, и крутить в цикле поиск нужного устройства. (В ответ на комментарий №10) > Ещё. вместо параллельного потока можно вывести сообщение <Waiting for boot > device> с кнопкой Cancel, и крутить в цикле поиск нужного устройства. Bootsplash желательно без действительной необходимости не трогать, иначе он у нас никогда не будет без разрывов. (В ответ на комментарий №10) > Миша, я тебе предлагаю подумать над реализацией [...] legion@ давно предлагал заменить propagator на небольшой шелл-скрипт. :) Как только что обсудили с boyarsh@ -- вместо sleep(2) и двух попыток вокруг лучше хотя бы сделать десятикратный цикл с минимум одной попыткой запуска try_with_uuidlabel(). А чем тебе не нравится идея с вечным циклом, прерываемым пользователем ? Что касается шелл скрипта, то функциональность пропагатора только кажется маленькой. Скрипт будет большой. Образ: alt-kworkstation-8.1-install-x86_64.iso Образ: alt-kworkstation-8.1-install-i586.iso USB-Flash: Transcend 4Gb Программа записи: imagewriter-1.10-alt4 Системная плата: ASUS H81M-K HDD: TOSHIBA DT01ACA1 931Gb В BIOS выставлена загрузка с устройств Legacy. При загрузке с флэшки после выбора в меню Grub опции "LiveCD" или "Установка" выводится псевдографическое окно "Please choose..." с предложением выбора носителя из подключенных носителей: см. 1.Choose the boot disk drive.jpg Выбираю sdb (Transcend 4Gb) Затем выводится псевдографическое окно "Please choose..." с предложением выбора раздела из имеющихся на выбранном носителе: см. 2. Choose the partition.jpg Выбираю sdb1 (size 3585 Mbytes) Потом выводится псевдографическое окно "Please fill entries..." с вводом пути к образу: см. 3. Enter the directory.jpg Выбираю "Ок" без ввода данных Далее загрузка с флэшки проходит до рабочего стола без ошибок. Данная ситуация аналогично воспроизводится на нетбуке ASUS X101CH. Created attachment 6963 [details]
Окно выбора носителя
Created attachment 6964 [details]
Окно выбора раздела
Created attachment 6965 [details]
Окно ввода пути к образу
Прошу переоткрыть баг по причине стабильного его воспроизведения. Также о данной проблеме сообщают пользователи на форуме: https://forum.altlinux.org/index.php?topic=37785.0 https://forum.altlinux.org/index.php?topic=38274.msg305759#msg305759 Собственно переоткрываю. Угу, пишут, что актуально для крабочей станции 8.2: http://www.opennet.ru/openforum/vsluhforumID3/112310.html#108 Метод лечения: CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_PCI=y CONFIG_USB_OHCI_HCD_PCI=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_UHCI_HCD=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PCI=y CONFIG_USB_STORAGE=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="panic=30 rootdelay=10" Я таких секретных аппаратнозависимых настроек много знаю... обращайтесь, если что. Если LiveCD-образ скопирован на MMC, видим те же страшные сообщения. Исправляется включением поддержки MMC в propagator. Проверил патч на P8 -- работает. Какой патч проверил на P8 ? Created attachment 7240 [details]
Два исправления, включая поддержку MMC
(В ответ на комментарий №24) > Какой патч проверил на P8 ? Вы так быстро отреагировали, я ещё даже патчик приатачить не успел> :) См. выше... Да, отлично. Но эта ошибка немного не о том. Надо перерабатывать архитектуру propagator к следующей версии. (В ответ на комментарий №27) > эта ошибка немного не о том. Да, но проявления похожие, хотя причины другие. Чтобы наработка не потерялась, Михаил Шигорин предложил выложить сюда. Согласен, что остальные проблемы, вызванные udevsettle, этот патч не закроет. > Надо перерабатывать архитектуру propagator к следующей версии. Вообще-то да. Собственно он и не особо нужен. Патч выглядит нормальным, можно в сизиф отправить. Что касается "не особо нужен" - тут вопрос спорный, всё равно нужен кто-то, умеющий то, что делает propagator. А умеет он слишком много. (В ответ на комментарий №29) > нужен кто-то, умеющий то, что делает propagator. Не хватающий функционал пропагатора имеет смысл перетащить в make-initrd, IMHO. Я ещё не приложил скриншоты багов пропагатора -- это явно следствие не очень аккуратного кодирования на си. В столь ответственном месте, которое под задачи часто приходится дотачивать, скрипт и надёжнее, и полезнее, благо в initrd большая часть того же функционала уже имеется. (В ответ на комментарий №23) > Если LiveCD-образ скопирован на MMC, видим те же страшные сообщения. Это другое (#32171, #30239); просьба НЕ устраивать здесь мультибаг, а повесить новый с обсуждением того, что от propagator требуется и кто как собирается его переписывать (возможно, CC: legion@). (В ответ на комментарий №31) >> Если LiveCD-образ скопирован на MMC, видим те же страшные сообщения. > Это другое (#32171, #30239) К #30315 больше подходит по выводимым сообщениям, конечно причина другая. К двум перечисленным не подходит однозначно, потому что в моём случае, как и здесь, MMC выступает в качестве source, а там в качестве target, к тому же тут речь о пропагаторе, а там о evms и инсталляторе. Обсуждение же хотелок и судьбы пропагатора - да, наверное лучше вообще вынести в devel@. propagator-20171208-alt1 -> sisyphus: Fri Dec 08 2017 Mikhail Efremov <sem@altlinux> 20171208-alt1 - probing.c: added support for MMC devices when boot in LiveCD-mode (by Leonid Krivoshein). - cdrom.c: fixed implicit declaration of function opendir warning (by Leonid Krivoshein). - disk.c: Workaround race conditions during disks detection (closes: #30315). - cdrom.c, network.c, tools.c: Fix memory leaks. - tools.c: Don't do useless comparisons during cmdline processing. - Use ramdisk_size from kernel cmdline. - Check that RAM size is enough for ramdisk. |
Created attachment 6142 [details] снимок экрана в "хорошем" случае Как известно, в нашем propagator живут гонки; одна из них проявляется как порой воспроизводящийся "waiting for /dev/disk", уходящий до лимита в 59 секунд; вторая -- как вываливание в диалог выбора носителя при загрузке с флэшки. Экспериментально выяснено, что стартеркиты 20140312 и 20140912 ведут себя в плане второй гонки одинаково, при этом вероятность её поймать в моём тесте на трёх флэшках (USB3, ~70Mb/s; USB2, ~16MB/s; USB2, ~8 MB/s) выглядит примерно как 3/3; 2/3; 1/3 (при этом и на быстрой флэшке раз из нескольких всё-таки удаётся загрузиться "на автомате"). Различие в логе на tty3 при случаях "грузимся" и "не грузимся" наблюдается в том, сколько записей о носителях _перед_ попытками их монтирования выдано: SCSI/1: sda is что_там_за_HDD => не успели SCSI/1: sda is <hdd> SCSI/1: sdb is <флэшка> => успели вариант для CD-ROM: SCSI/1: sda is <hdd> SCSI/0: sr0 is <cdrom> Судя по dmesg в "плохом" случае, разница между sda (hdd) и sdb (flash) может быть в пару секунд. Возможно, в cdrom.c::cdrom_prepare() есть смысл попытаться взять паузу и сходить на второй/третий круг до того, как вываливаться из автоматического режима.