Bug 29553

Summary: Проблемный splash на свободных драйверах
Product: Branch t6 Reporter: Roman Savochenko <rom_as>
Component: kernel-image-std-defAssignee: Sergey Vlasov <vsu>
Status: NEW --- QA Contact: QA t6 <qa-t6>
Severity: normal    
Priority: P3    
Version: не указана   
Hardware: all   
OS: Linux   

Description Roman Savochenko 2013-11-04 22:31:26 MSK
Проблема актуальна и для un-def.
Проблема характерна для открытых драйверов "nouveau" и "radeon", т.е. для тех, модуля которых грузятся в initrd, согласно текущему порядку. В случае "fglrx" и "nvidia" такой проблемы нет.

Собственно проблема в том, что initrd, созданные "make-initrd" сначала пытается грузить splash, а затем только грузит "nouveau" и "radeon", если-же, как для закрытых драйверов поставить vga="0x314" то splash появляется, но в момент загрузки открытого драйвера имеем чёрных экран, до момента запуска XOrg.

Где-то указывали как добавить загрузку "radeon" и "nouveau" до запуска splash, но это как-то нетипично и у меня вызывало ещё более серьёзные проблемы сопровождающиеся ошибками в консоли загрузки.

На Сизифе конфигурация вроде та-же, но проблем с опцией vga="0x314" нет. Это свойство нового ядра и драйверов и для ядер в T6 не светит?
Comment 1 Roman Savochenko 2013-11-05 22:11:34 MSK
Оказывается в initrd нет ничего из radeon*, разве только библиотеки.

А эффект такой получается из-за ранней загрузки "radeon" уже когда
загрузка проваливается в основную корневую ФС.

Если его заbalcklistить то загрузка со сплешем идёт до конца, но если с
*DM переключиться в консоль то получаем чёрный экран без возможности
возврата, идентично обычному выходу, что похоже на зависание причём в ядре.

Короче radeon в ядре 3.4 и меньше смахивает на нерабочий в сочетании с
vesafb, а radeonfb, кстати заблеклистен, почему и не попадает в initrd
наверное.
Comment 2 Roman Savochenko 2013-11-05 22:12:02 MSK
На Сизифе radeonfb заменяет vesafb, а загрузка radeon не вызывает
чёрного экрана и зависаний, т.е. это таки проблема с radeon в ядре <= 3.4!