Bug 42057

Summary: Не работает framebuffer в virtualbox в EFI с vmsvga
Product: Sisyphus Reporter: Антон Мидюков <antohami>
Component: kernel-image-un-defAssignee: Vitaly Chikunov <vt>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: normal    
Priority: P5 CC: asheplyakov, kernelbot, nickel, placeholder, vt
Version: unstable   
Hardware: x86_64   
OS: Linux   
See Also: https://bugzilla.altlinux.org/show_bug.cgi?id=40232
https://bugzilla.altlinux.org/show_bug.cgi?id=41305
Bug Depends on:    
Bug Blocks: 33000    

Description Антон Мидюков 2022-03-02 15:42:49 MSK
В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено, что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если использовать simpledrm вместо simplefb. Т.е.:
CONFIG_FB_SIMPLE=n
CONFIG_DRM=y
CONFIG_DRM_SIMPLEDRM=y

И видимо ещё
CONFIG_DRM_KMS_HELPER=y

Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами, но только для x86_64.
Comment 1 Sergey V Turchin 2022-03-02 16:54:03 MSK
> неработающий framebuffer чинится  для virtualbox в EFI с vmsvga
А для EFI с vboxsvga не сломается при этом? Неплохо бы проверить при починке.
Comment 2 Anton Farygin 2022-03-02 17:50:08 MSK
@ldv кто будет делать ?
Comment 3 Dmitry V. Levin 2022-03-03 04:22:22 MSK
(In reply to Anton Farygin from comment #2)
> @ldv кто будет делать ?

Меня интересует для начала, кто будет думать, как всем угодить и ничего не сломать.

Мне вот DRM=y не нужно вообще нигде, ни на серверах, ни на ноутах.
Comment 4 Anton Farygin 2022-03-03 08:43:10 MSK
Разные ядра для разных целей - единственный нормальный путь.
Но важно что бы количество таких ядер не захлестнуло.
Comment 5 Alexey Sheplyakov 2022-03-03 14:30:57 MSK
(In reply to Антон Мидюков from comment #0)
> В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено,
> что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если
> использовать simpledrm вместо simplefb. Т.е.:
> CONFIG_FB_SIMPLE=n
> CONFIG_DRM=y
> CONFIG_DRM_SIMPLEDRM=y
> 
> И видимо ещё
> CONFIG_DRM_KMS_HELPER=y
> 
> Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами,
> но только для x86_64.

А почему только для x86_64? Можно и для aarch64.
Comment 6 Антон Мидюков 2022-03-03 14:47:26 MSK
(Ответ для Alexey Sheplyakov на комментарий #5)
> (In reply to Антон Мидюков from comment #0)
> > В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено,
> > что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если
> > использовать simpledrm вместо simplefb. Т.е.:
> > CONFIG_FB_SIMPLE=n
> > CONFIG_DRM=y
> > CONFIG_DRM_SIMPLEDRM=y
> > 
> > И видимо ещё
> > CONFIG_DRM_KMS_HELPER=y
> > 
> > Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами,
> > но только для x86_64.
> 
> А почему только для x86_64? Можно и для aarch64.

Я проверял для aarch64.
1. Ядро становится несколько больше и u-boot на Raspberry Pi его загрузить не может. Впрочем, эта проблема обязательно вылезет вновь в одном из следующих релизов ядра и так.
2. simpledrm работает только с EFI. При загрузке с u-boot через extlinux.conf framebuffer'а нет. На Allwinner H5 (Orange Pi Prime) так.

А каковы резоны для включения на aarch64?
Comment 7 Alexey Sheplyakov 2022-03-03 14:53:31 MSK
(In reply to Dmitry V. Levin from comment #3)
> (In reply to Anton Farygin from comment #2)
> > @ldv кто будет делать ?
> 
> Меня интересует для начала, кто будет думать, как всем угодить

Всем угодить невозможно...

> Мне вот DRM=y не нужно вообще нигде, ни на серверах, ни на ноутах.

... особенно если вместо технических критериев пользоваться субъективными предпочтениями.

> и ничего не сломать.

Тут волшебных рецептов нет, только тестировать.

P.S.

Если у Вас графическая подсистема Linux вызывает такое отторжение, то самое время придумать другую, более правильную. Затем адаптировать Mesa, Xorg (а также Qt, gtk, и далее со всеми остановками). Точнее говоря, делать это надо было лет 8 назад (а то и раньше), когда окончательно стало ясно, что fbdev мёртв, а Xorg вскоре за ним последует.
Comment 8 Dmitry V. Levin 2022-03-03 15:19:07 MSK
(In reply to Alexey Sheplyakov from comment #7)
> Если у Вас графическая подсистема Linux вызывает такое отторжение,

Вопрос не в отношении, графическая система нужна не для всех классов систем.
Например, на серверах нужна не графическая система, а serial console.
Comment 9 Anton Farygin 2022-03-03 15:26:15 MSK
Дима, всё верно, но ядро un-def обычно никто на серверах не использует.
Comment 10 Sergey V Turchin 2022-03-03 15:40:59 MSK
> Например, на серверах нужна не графическая система, а serial console.
Вообще, да. При разделении хотя бы на сервер и десктоп будет проще не мешать всё в кучу.

P.S.
Правда, судя по тому, что в BIOS уже настоящий графический интерфейс с мышью пихают, спрос есть.
Comment 11 Sergey V Turchin 2022-03-03 15:47:19 MSK
(In reply to Anton Farygin from comment #9)
> Дима, всё верно, но ядро un-def обычно никто на серверах не использует.
Не-не. Это "предварительное" ядро. Лучше пусть таким и останется.
Сейчас получается удобно, что можно p10-un-def == sisyphus-std-def.

По мне бы лучше std-srv, std-wks, un-srv и un-wks.
Comment 12 Alexey Sheplyakov 2022-03-03 18:59:01 MSK
(In reply to Антон Мидюков from comment #6)
> (Ответ для Alexey Sheplyakov на комментарий #5)
> > (In reply to Антон Мидюков from comment #0)
> > > В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено,
> > > что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если
> > > использовать simpledrm вместо simplefb. Т.е.:
> > > CONFIG_FB_SIMPLE=n
> > > CONFIG_DRM=y
> > > CONFIG_DRM_SIMPLEDRM=y
> > > 
> > > И видимо ещё
> > > CONFIG_DRM_KMS_HELPER=y
> > > 
> > > Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами,
> > > но только для x86_64.
> > 
> > А почему только для x86_64? Можно и для aarch64.
> 
> Я проверял для aarch64.
> 1. Ядро становится несколько больше и u-boot на Raspberry Pi его загрузить
> не может.


1. Зачем нужен u-boot на rasberry pi? Встроенный загрузчик прекрасно умеет запускать ядра Linux в разных видах (EFI stub, zImage, и т.п.). Есть UEFI (https://github.com/pftf/RPi4) - это если кому-то хочется стандартизации (я в их числе, если что).

2. Насколько я знаю, и u-boot, и встроенный загрузчик, и UEFI (EDK2) умеют загружать не только EFI stub, но и Image.gz

 Впрочем, эта проблема обязательно вылезет вновь в одном из
> следующих релизов ядра и так.

> 2. simpledrm работает только с EFI.

rock pi 4c (arm-tf + u-boot) - UEFI нет, а framebuffer есть. И неудивительно.
simpedrmfb (как и fb_simple) работает с тем, что настроил и *о чём рассказал* загрузчик/прошивка (рассказал через uefi таблицы, или в device tree). И не важно, какой именно загрузчик - u-boot, UEFI, arm-tf.


> При загрузке с u-boot через extlinux.conf framebuffer'а нет.

Возможно Вы не умеете его готовить (я тоже не умею, я пользуюсь тем, что добрые люди из armbian готовят)


> А каковы резоны для включения на aarch64?

1. Не хочется на создавать дополнительную разницу между разными архитектурами.
2. fbdev по сути давно заброшен, его уже неоднократно собирались выпилить, и лучше заранее к этому подготовиться.
Comment 13 Alexey Sheplyakov 2022-03-03 18:59:52 MSK
(In reply to Sergey V Turchin from comment #11)
> (In reply to Anton Farygin from comment #9)
> > Дима, всё верно, но ядро un-def обычно никто на серверах не использует.
> Не-не. Это "предварительное" ядро. Лучше пусть таким и останется.
> Сейчас получается удобно, что можно p10-un-def == sisyphus-std-def.
> 
> По мне бы лучше std-srv, std-wks, un-srv и un-wks.

А кто тестировать-то всё это будет?
Comment 14 Антон Мидюков 2022-03-03 19:36:53 MSK
(Ответ для Alexey Sheplyakov на комментарий #12)
> (In reply to Антон Мидюков from comment #6)
> > (Ответ для Alexey Sheplyakov на комментарий #5)
> > > (In reply to Антон Мидюков from comment #0)
> > > > В https://bugzilla.altlinux.org/show_bug.cgi?id=41305#c5 было установлено,
> > > > что неработающий framebuffer чинится для virtualbox в EFI с vmsvga, если
> > > > использовать simpledrm вместо simplefb. Т.е.:
> > > > CONFIG_FB_SIMPLE=n
> > > > CONFIG_DRM=y
> > > > CONFIG_DRM_SIMPLEDRM=y
> > > > 
> > > > И видимо ещё
> > > > CONFIG_DRM_KMS_HELPER=y
> > > > 
> > > > Для решения проблемы предлагаю попробовать собрать ядро с этими конфигами,
> > > > но только для x86_64.
> > > 
> > > А почему только для x86_64? Можно и для aarch64.
> > 
> > Я проверял для aarch64.
> > 1. Ядро становится несколько больше и u-boot на Raspberry Pi его загрузить
> > не может.
> 
> 
> 1. Зачем нужен u-boot на rasberry pi?

Для унификации. Грузить ядро с FAT раздела то ещё счастье. Вот не грузится с новым ядром и что делать? С предыдущим то не загрузишься.

> Встроенный загрузчик прекрасно умеет
> запускать ядра Linux в разных видах (EFI stub, zImage, и т.п.). Есть UEFI
> (https://github.com/pftf/RPi4) - это если кому-то хочется стандартизации (я
> в их числе, если что).

Я знаю об этом проекте. Даже собирал edk2-rpi в Сизиф и p9 одно время.
Я думаю, что в перспективе можно перейти на него попробовать.

> 
> 2. Насколько я знаю, и u-boot, и встроенный загрузчик, и UEFI (EDK2) умеют
> загружать не только EFI stub, но и Image.gz
> 

Да, u-boot умеет грузиться в режиме EFI. Но и в режиме EFI получившееся ядро не смогло загрузиться. Начало грузиться и не смогло.

>  Впрочем, эта проблема обязательно вылезет вновь в одном из
> > следующих релизов ядра и так.
> 
> > 2. simpledrm работает только с EFI.
> 
> rock pi 4c (arm-tf + u-boot) - UEFI нет, а framebuffer есть. И неудивительно.

Там работает не simpedrmfb, а свой framebuffer. Я пробовал на Nano PC T4 (rk3399). В начале загрузки ядра монитор тухнет, и, пока свой framebuffer не загрузится, изображения нет. Идея вкомпиливания состоит ещё и в том, чтобы framebuffer был доступен с первых секунд загрузки ядра, чтобы на нём можно было видеть сообщения ядра. На Rockchip одинаково бесполезны simpedrmfb и fb_simple.

> simpedrmfb (как и fb_simple) работает с тем, что настроил и *о чём
> рассказал* загрузчик/прошивка (рассказал через uefi таблицы, или в device
> tree). И не важно, какой именно загрузчик - u-boot, UEFI, arm-tf.
> 

Верно. На Orange Pi Prime сообщения нормально выводятся на экран с fb_simple, как при загрузке через extlinux.conf, так и режим EFI. А с simpedrmfb только в режиме EFI.

> 
> > При загрузке с u-boot через extlinux.conf framebuffer'а нет.
> 
> Возможно Вы не умеете его готовить (я тоже не умею, я пользуюсь тем, что
> добрые люди из armbian готовят)
> 
> 
> > А каковы резоны для включения на aarch64?
> 
> 1. Не хочется на создавать дополнительную разницу между разными
> архитектурами.
> 2. fbdev по сути давно заброшен, его уже неоднократно собирались выпилить, и
> лучше заранее к этому подготовиться.

Польза от fb_simple только в том, чтобы выводить сообщения на экран, пока не загрузится нормальный drm-модуль.
Польза от вкомпиливания simpedrmfb видится ещё и в том, что plymouth будет запускаться сразу, а в initrd не будет необходимости класть другие drm-модули. Но это гипотеза, которую нужно будет проверить.
На aarch64 plymouth мы не используем (plymouth не работает при включении вывода на serial console), поэтому и резона не вижу.
Comment 15 Sergey V Turchin 2022-03-04 10:54:35 MSK
> > По мне бы лучше std-srv, std-wks, un-srv и un-wks.
> А кто тестировать-то всё это будет?
Да все те же, кто раньше. Некоторые сразу оба вида будут использовать, только на разных системах.
Comment 16 Anton Farygin 2022-03-04 10:56:48 MSK
С тестированием, как раз, будет проще.
Comment 17 Alexey Sheplyakov 2022-03-04 15:07:04 MSK
(In reply to Dmitry V. Levin from comment #8)
> (In reply to Alexey Sheplyakov from comment #7)
> > Если у Вас графическая подсистема Linux вызывает такое отторжение,
> 
> Вопрос не в отношении, графическая система нужна не для всех классов систем.
> Например, на серверах нужна не графическая система, а serial console.

1. Графическая система всё равно есть (CONFIG_FB_SIMPLE=Y), только ущербная, никем не поддерживаемая.

2. uart/rs232 консоль далеко не у всякого сервера есть.

3. И самое главное: "на серверах не нужна графическая подсистема" - это Ваши личные предпочтения, ничем технически не обоснованные. А принятые на основе этого предпочтения решения (сборка drm модулем + упаковка в отдельный пакет drm драйверов) создают объективные проблемы. Например, обсуждаемый баг. А ещё невозможность автоматической установки обновлений ядра.
Comment 18 Alexey Sheplyakov 2022-03-04 15:14:47 MSK
(In reply to Антон Мидюков from comment #14)

> На aarch64 plymouth мы не используем

А зря. Очень хотелось бы, чтобы и на aarch64 при загрузке отображалось что-то более человеческое, чем чёрный экран.

> (plymouth не работает при включении вывода на serial console), поэтому и резона не вижу.

Я рассматриваю aarch64 как "обычный компьютер для обычного пользователя", а не как хакерскую игрушку. А соответственно serial console а) нужна < 1% пользователей, б) не всегда (легко) доступна
Comment 19 Антон Мидюков 2022-03-04 16:11:07 MSK
(Ответ для Alexey Sheplyakov на комментарий #18)
> (In reply to Антон Мидюков from comment #14)
> 
> > На aarch64 plymouth мы не используем
> 
> А зря. Очень хотелось бы, чтобы и на aarch64 при загрузке отображалось
> что-то более человеческое, чем чёрный экран.

И мне хочется, чтобы plymouth выводился исключительно на экран, не мешая serial console:
https://bugzilla.altlinux.org/39326

> 
> > (plymouth не работает при включении вывода на serial console), поэтому и резона не вижу.
> 
> Я рассматриваю aarch64 как "обычный компьютер для обычного пользователя", а
> не как хакерскую игрушку. А соответственно serial console а) нужна < 1%
> пользователей, б) не всегда (легко) доступна

И тем не менее, на одноплатниках обычно врубается она, если не указать console=tty1.
Comment 20 Антон Мидюков 2022-05-05 03:40:22 MSK
Проблемы больше нет, как в новых, так и в старых образах. Видимо, помогло последнее обновление virtualbox до 6.1.34