Bug 29553

Summary:	Проблемный splash на свободных драйверах
Product:	Branch t6	Reporter:	Roman Savochenko <rom_as>
Component:	kernel-image-std-def	Assignee:	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!