Та же проблема, что и #40868. А именно, при попытке запуска Xorg на device tree системе с дискретной PCIe видеокартой происходит segfault. Backtrace аналогичен #40868
Приглашаю всех желающих потестировать: #284898 TESTED #2 [test-only] sisyphus xorg-server.git=1.20.13-alt2
(In reply to Alexey Sheplyakov from comment #1) > Приглашаю всех желающих потестировать: > > #284898 TESTED #2 [test-only] sisyphus xorg-server.git=1.20.13-alt2 на x86_64 системах. В теории ничего не должно поменяться.
(In reply to Alexey Sheplyakov from comment #2) > (In reply to Alexey Sheplyakov from comment #1) > > Приглашаю всех желающих потестировать: > > > > #284898 TESTED #2 [test-only] sisyphus xorg-server.git=1.20.13-alt2 > > на x86_64 системах. В теории ничего не должно поменяться. Uptime 20 минут, полёт нормальный. Ноутбук Dell Inspiron 7577 # lspci | grep -e VGA -e 3D 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630 (rev 04) 01:00.0 3D controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Ti Mobile] (rev a1)
Было бы отлично этот revert провести через апстрим xorg, заодно узнаем что при этом ломается (кто возражает).
Пару раз словил, и больше не воспроизводится => normal
(In reply to Anton Farygin from comment #4) > Было бы отлично этот revert провести через апстрим xorg, заодно узнаем что > при этом ломается (кто возражает). Нечего проводить: "revert 249a12c5, 74b7427c, 5c96eb5f" - это наше творчество. https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/config/udev.c#L546-L555 Другими словами, в upstream код совпадает config/udev.c совпадает с task #284898, за исключением "config: fixed probe for platform devices" (это я у кого-то стянул)
Виноват, segfault нету, это у меня старые логи остались. Однако проблема всё равно есть (хоть и менее серьёзная): 1. При старте иногда чёрный экран без какой-либо диагностики (процесс Xorg продолжает выполняться, ничего подозрительного в Xorg.log или dmesg) 2. При попытке разблокировать экран (light-locker) вместо интерфейса greeter -- чёрный экран Такое поведение может возникать из-за использования drmSetInterfaceVersion когда Xorg ещё/уже не владеет виртуальным терминалом, т.е. при запуске и переключении между виртуальными терминалами (*включая* неявные переключения при использовании light-locker) At the point where xf86BusProbe runs we haven't yet taken our own VT, which means we can't perform drm "master" operations on the device. This is tragic, because we need master to fish the bus id string out of the kernel, which we can only do after drmSetInterfaceVersion, which for some reason stores that string on the device not the file handle and thus needs master access. Fortunately we know the format of the busid string, and it happens to almost be the same as the ID_PATH variable from udev. Use that instead and stop calling drmSetInterfaceVersion. Такую проблему я чинил в p9. Поэтому предлагаю вернуть коммиты 249a12c5, 74b7427c, 5c96eb5f, и добавить исправление для probe platform device (коммит a26aebdc94b7 из задания #284898). Аналогичный код у нас давно есть в p9 [1], и он работает и на x86, и на rpi, и на байкалах. [1] http://git.altlinux.org/gears/x/xorg-server.git?p=xorg-server.git;a=blob;f=config/udev.c;h=af32a5bcb37a9c84244c021b86ddf09b5f05d8de;hb=29049a8ea695c2e6e909ea569b6caa6ddbf7f9bd#l484 Возражения? Предложения? Замечания?
(Ответ для Alexey Sheplyakov на комментарий #6) > Нечего проводить: "revert 249a12c5, 74b7427c, 5c96eb5f" - это наше > творчество. https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.20-branch&id=4b6fce5975c2f931a0478cf4deeec97529b05eb6 https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.20-branch&id=39cb95e959fab97a7e255dda1a1599b096fb0f7e https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.20-branch&id=af4c84ce8855e84c0ad89b929bc972e884f0b8e3 без комментариев > https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/config/udev.c#L546- > L555 > > Другими словами, в upstream код совпадает config/udev.c совпадает с task > #284898, за исключением "config: fixed probe for platform devices" (это я у > кого-то стянул) я все таки надеюсь что это утверждение ошибка, а не намеренное враньё
*** Bug 40872 has been marked as a duplicate of this bug. ***
(In reply to Valery Inozemtsev from comment #8) > (Ответ для Alexey Sheplyakov на комментарий #6) > > Нечего проводить: "revert 249a12c5, 74b7427c, 5c96eb5f" - это наше > > творчество. > > https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.20- > branch&id=4b6fce5975c2f931a0478cf4deeec97529b05eb6 > https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.20- > branch&id=39cb95e959fab97a7e255dda1a1599b096fb0f7e > https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.20- > branch&id=af4c84ce8855e84c0ad89b929bc972e884f0b8e3 > > без комментариев Я плохо искал, надо было не только в master. > > https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/config/udev.c#L546- > > L555 > > > > Другими словами, в upstream код совпадает config/udev.c совпадает с task > > #284898, за исключением "config: fixed probe for platform devices" (это я у > > кого-то стянул) > я все таки надеюсь что это утверждение ошибка, а не намеренное враньё Утверждений два. 1. "revert ... - это наше творчество" - да, ошибка. 2. "в upstream код config/udev.c совпадает c task #284898, ..." - верно.
> > https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/config/udev.c#L546- > > L555 > > > > Другими словами, в upstream код совпадает config/udev.c совпадает с task > > #284898, за исключением "config: fixed probe for platform devices" (это я у > > кого-то стянул) > > я все таки надеюсь что это утверждение ошибка, а не намеренное враньё Проблема всё равно существует, и устраняется патчами, предложенными в #284898
(In reply to Alexey Sheplyakov from comment #10) > (In reply to Valery Inozemtsev from comment #8) > > (Ответ для Alexey Sheplyakov на комментарий #6) > > > Нечего проводить: "revert 249a12c5, 74b7427c, 5c96eb5f" - это наше > > > творчество. > > > > https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.20- > > branch&id=4b6fce5975c2f931a0478cf4deeec97529b05eb6 > > https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.20- > > branch&id=39cb95e959fab97a7e255dda1a1599b096fb0f7e > > https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.20- > > branch&id=af4c84ce8855e84c0ad89b929bc972e884f0b8e3 > > > > без комментариев С комментарием: эти коммиты возвращают гонку между vt switch и drmSetInterfaceVersion, последствия которой (ошибки при старте и зависания при разблокировании экрана) трудно диагностировать. > Я плохо искал, надо было не только в master. И слишком быстро сделал выводы ("наше творчество"), прошу прощения.
гонку наблюдали. лучше патчи не откатывать, а поправить.
(In reply to Anton Farygin from comment #13) > гонку наблюдали. лучше патчи не откатывать, а поправить. "Оба хуже": https://gitlab.freedesktop.org/xorg/xserver/-/issues/993 https://gitlab.freedesktop.org/xorg/xserver/-/issues/1044
(Ответ для Anton Farygin на комментарий #13) > гонку наблюдали. лучше патчи не откатывать, а поправить. пока эти патчи не будут полностью работоспособны я откатываю все до состояния апстрима
Протестировал xorg-server-1.20.13-alt2.aarch64 из задачи 284900 для p10 на TF307, RPi4, RPi400, в том числе по 10 раз блокировал экран. Проблему: > Однако проблема всё равно есть (хоть и менее серьёзная): > > 1. При старте иногда чёрный экран без какой-либо диагностики (процесс Xorg > продолжает выполняться, ничего подозрительного в Xorg.log или dmesg) > 2. При попытке разблокировать экран (light-locker) вместо интерфейса greeter > -- чёрный экран не наблюдал.
(In reply to Valery Inozemtsev from comment #15) > (Ответ для Anton Farygin на комментарий #13) > > гонку наблюдали. лучше патчи не откатывать, а поправить. > > пока эти патчи не будут полностью работоспособны я откатываю все до > состояния апстрима Уточните пожалуйста, что Вы собираетесь сделать. 1. Не принимать изменения из задачи #284898 => OK 2. git reset --hard origin/server-1.20-branch (или эквивалентное) => НЕТ, тогда Xorg перестанет работать на Байкалах (-М)
(Ответ для Alexey Sheplyakov на комментарий #17) > 2. git reset --hard origin/server-1.20-branch (или эквивалентное) => НЕТ, из config/udev.c hw/xfree86/os-support/linux/lnx_platform.c hw/xfree86/common/xf86platformBus.c исключено все чего нет в upstream/debuan/fedora
(In reply to Valery Inozemtsev from comment #18) > (Ответ для Alexey Sheplyakov на комментарий #17) > > 2. git reset --hard origin/server-1.20-branch (или эквивалентное) => НЕТ, > > из config/udev.c hw/xfree86/os-support/linux/lnx_platform.c > hw/xfree86/common/xf86platformBus.c исключено все чего нет в > upstream/debuan/fedora Для работы Xorg на байкалах необходим вот этот коммит: commit 9f0aa9e0caee3634b08510dad1ead7670b063833 Author: Jian-Hong Pan <jian-hong@endlessm.com> Date: Tue Jul 28 17:37:18 2020 +0800 xfree86: Detect the primary device by checking outputs Before this patch, X server detects/sets the primary device by: 1. The "PrimaryGPU" option in extra X configuration 2. pci_device_is_boot_vga() for PCI devices 3. Set the first (0 index) device as the primary device, if it is not found yet. However, the other display controllers like Amlogic's meson cannot be detected as the primary device by pci_device_is_boot_vga(). Thus, it has to set the extra X configuration for the "PrimaryGPU" option. Otherwise, X server will set the first (0 index) device as the primary device. But it may not be the correct one, because it has no output. For example, Amlogic puts the GPU and display controller as different devices: (II) xfree86: Adding drm device (/dev/dri/card0) (II) Platform probe for /sys/devices/platform/soc/d0000000.apb/d00c0000.gpu/drm/card0 (II) xfree86: Adding drm device (/dev/dri/card1) (II) Platform probe for /sys/devices/platform/soc/d0100000.vpu/drm/card1 This patch introduces a new member num_connectors into OdevAttributes to hold the number of display connectors for each DRM device. It gets the number of the device's connectors by detecting the output connecters of devices in platform dev driver, that refers to the check_outputs() function in modesetting driver. Then, adds a new way to set the primary device by checking the number of display connectors for drm devices, before use the first platform device as a fallback. Buglink: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1023 Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
(In reply to Alexey Sheplyakov from comment #19) > (In reply to Valery Inozemtsev from comment #18) > > (Ответ для Alexey Sheplyakov на комментарий #17) > > > 2. git reset --hard origin/server-1.20-branch (или эквивалентное) => НЕТ, > > > > из config/udev.c hw/xfree86/os-support/linux/lnx_platform.c > > hw/xfree86/common/xf86platformBus.c исключено все чего нет в > > upstream/debuan/fedora > > Для работы Xorg на байкалах необходим вот этот коммит: > > > commit 9f0aa9e0caee3634b08510dad1ead7670b063833 > Author: Jian-Hong Pan <jian-hong@endlessm.com> > Date: Tue Jul 28 17:37:18 2020 +0800 > Прошу вернуть, и впредь так не делать.
(Ответ для Alexey Sheplyakov на комментарий #20) > Прошу вернуть для начала определитесь что конкретно нужно для работы на байкалах и при этом что бы оно не ломало все остальные device tree (и не только) системы, тогда можно будет говорить о "вернуть" пысы: в p10 9f0aa9e0caee3634b08510dad1ead7670b063833 остался
Вариант "не смотреть на TF" нельзя допускать. Предлагаю Алексею попробоват собрать xorg-server и проверить его по крайней мере на Байкал-М и rpi3,4.
xorg-server-2:1.20.13-alt4 -> sisyphus: Thu Sep 16 2021 Alexey Sheplyakov <asheplyakov@altlinux> 2:1.20.13-alt4 - Fixed detection of primary device on ARM systems with Mali Midgard and other headless GPUs (closes: #40946) - Avoid race between vt switching and drmSetInterfaceVersion (closes: #40888)
