Bug 36938

Какой дистрибутив?

1. А нет ли у вас случайно /etc/X11/xorg.conf? Или может что лишнее в /etc/X11/xorg.conf.d/* затесалось? Переместите это всё в /root на время.

2. Чтобы помог iommu=soft, нужно сначала отключить IOMMU в BIOS'е. Но похоже, именно у вас дело в xorg.conf.

3. Вышлите мне на почту SOS report, а лучше выложить в облако и кинуть сюда ссылку.

(В ответ на комментарий №1)
> Какой дистрибутив?
Ставил с образа alt-p8-server-20190312-
x86_64

(В ответ на комментарий №2)
> 1. А нет ли у вас случайно /etc/X11/xorg.conf? Или может что лишнее в
> /etc/X11/xorg.conf.d/* затесалось? Переместите это всё в /root на время.

Система чистая, /etc/X11/xorg.conf отсутствует.
 
> 2. Чтобы помог iommu=soft, нужно сначала отключить IOMMU в BIOS'е. Но похоже,
> именно у вас дело в xorg.conf.

В BIOS по умолчанию выставлено.
Intel(R) VT for Directed I/O: DISABLED

> 
> 3. Вышлите мне на почту SOS report, а лучше выложить в облако и кинуть сюда
> ссылку.

https://yadi.sk/d/44WJhe0_i45Pmg

Стало немного понятнее, но лучше бы сравнить с "ситуацией в норме" -- rescue, так rescue.

Используется серверный стартеркит с 5 ядром и sysvinit. Мешанина контроллеров и модулей USB, причём медленные HID 1.1 мышь/клава подключены к USB 3.0. Если возможность есть, так лучше не делать. Немного смущает отсутствие xhci_pci, в норме он вроде должен быть, но есть тому и логическое объяснение:

dmesg | grep quirk_usb
pci 0000:00:1a.0: quirk_usb_early_handoff+0x0/0x683 took 21517 usecs
pci 0000:00:1d.0: quirk_usb_early_handoff+0x0/0x683 took 21734 usecs

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/usb/host/pci-quirks.c?h=v5.0.21#n1235
[2] https://patchwork.kernel.org/patch/10135925/
[3] http://helpadmins.ru/xhci-hand-off-chto-yeto/

Другими словами факап происходит при передаче управления шиной USB от BIOS к ОС и это зависит от ядра или набора модулей в initramfs. Стоит поиграться с EHCI/XHCI HandOf в BIOS'е, использовать параметр загрузки initcall_debug для выяснения деталей, а в первую очередь хотелось бы сравнить с выводом lsmod и dmesg, где всё в норме.

VTx/VTd -- смотрите сами, для вашего USB-контроллера iommu=soft не решит проблемы. Я бы включил в BIOS'е IOMMU/AGP для ускорения, уж больно много там всего на DMA повисло...

Добавлю: по lsmod всё ОК -- xhci_pci грузится.

И ещё: у модуля xhci-hcd есть всего два параметра -- link_quirk и quirks.

> Используется серверный стартеркит с 5 ядром и sysvinit. Мешанина контроллеров и
> модулей USB, причём медленные HID 1.1 мышь/клава подключены к USB 3.0. Если
> возможность есть, так лучше не делать.

Все USB порты 3.0

> Немного смущает отсутствие xhci_pci, в
> норме он вроде должен быть, но есть тому и логическое объяснение:
> 
> dmesg | grep quirk_usb
> pci 0000:00:1a.0: quirk_usb_early_handoff+0x0/0x683 took 21517 usecs
> pci 0000:00:1d.0: quirk_usb_early_handoff+0x0/0x683 took 21734 usecs
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/usb/host/pci-quirks.c?h=v5.0.21#n1235
> [2] https://patchwork.kernel.org/patch/10135925/
> [3] http://helpadmins.ru/xhci-hand-off-chto-yeto/
> 
> Другими словами факап происходит при передаче управления шиной USB от BIOS к ОС
> и это зависит от ядра или набора модулей в initramfs. Стоит поиграться с
> EHCI/XHCI HandOf в BIOS'е, использовать параметр загрузки initcall_debug для
> выяснения деталей, а в первую очередь хотелось бы сравнить с выводом lsmod и
> dmesg, где всё в норме.

Вывод lsmod и dmesg c rescue livecd + initcall_debug

положил туда же https://yadi.sk/d/44WJhe0_i45Pmg

Разница в модулях небольшая, очевидное отфильтровал:

--- lsmod.good
+++ lsmod.bad

; Пробуем выгрузить
-drm
-drm_kms_helper
-edac_core
-fjes
-gf128mul
-i2c_algo_bit
-i2c_smbus
-mgag200
-ttm
-uas
-usb_storage

; Пробуем загрузить
+ecdh_generic
+ipmi_devintf
+ipmi_msghandler
+ipmi_si
+mdio
+msr
+xfrm_algo

Начал бы вообще с uas и i2c*. Очень может быть, что регрессия в ядре или каком-то из модулей, очевидно разные ядра 4.x и 5.x, собранные соответственно gcc5 и gcc8 (тоже могло повлиять). Вообще удивлён был увидеть 5.x-un-def в серверном страртерките, надо будет спросить antohami@, почему так. Понизить на сервере ядро до std-def тоже хорошая идея.

Да, и что характерно -- вот этого:

dmesg | grep quirk_usb
pci 0000:00:1a.0: quirk_usb_early_handoff+0x0/0x683 took 21517 usecs
pci 0000:00:1d.0: quirk_usb_early_handoff+0x0/0x683 took 21734 usecs

в нормальной системе нет, поэтому в BIOS'е я бы всё-таки посмотрел на предмет EHCI/XHCI HandOf.

(В ответ на комментарий №8)
> Разница в модулях небольшая, очевидное отфильтровал:
> 
> --- lsmod.good
> +++ lsmod.bad
> 
> ; Пробуем выгрузить
> -drm
> -drm_kms_helper
> -edac_core
> -fjes
> -gf128mul
> -i2c_algo_bit
> -i2c_smbus
> -mgag200
> -ttm
> -uas
> -usb_storage
> 
> ; Пробуем загрузить
> +ecdh_generic
> +ipmi_devintf
> +ipmi_msghandler
> +ipmi_si
> +mdio
> +msr
> +xfrm_algo
> 
> Начал бы вообще с uas и i2c*. Очень может быть, что регрессия в ядре или
> каком-то из модулей, очевидно разные ядра 4.x и 5.x, собранные соответственно
> gcc5 и gcc8 (тоже могло повлиять). Вообще удивлён был увидеть 5.x-un-def в
> серверном страртерките, надо будет спросить antohami@, почему так. Понизить на
> сервере ядро до std-def тоже хорошая идея.

Дико извиняюсь !
Забыл сказать что после танцев с бубном, решил накатить сизиф на P8 в надежде что может быть проблема с клавиатурой решиться.
И сейчас там подключены репозитории сизифа.
И соответственно там сейчас Sisyphus.
Ещё раз прошу меня извинить.

(В ответ на комментарий №9)
> Да, и что характерно -- вот этого:
> 
> dmesg | grep quirk_usb
> pci 0000:00:1a.0: quirk_usb_early_handoff+0x0/0x683 took 21517 usecs
> pci 0000:00:1d.0: quirk_usb_early_handoff+0x0/0x683 took 21734 usecs
> 
> в нормальной системе нет, поэтому в BIOS'е я бы всё-таки посмотрел на предмет
> EHCI/XHCI HandOf.

Добавил сюда https://disk.yandex.ru/client/disk/P8 скрин с настройками в BIOS USB (S2600WTTR_USB_BIOS.jpg)

Перепробовал все возможные в данном случае варианты. Не помогло.

(В ответ на комментарий №8)
> Разница в модулях небольшая, очевидное отфильтровал:
> 
> --- lsmod.good
> +++ lsmod.bad
> 
> ; Пробуем выгрузить
> -drm
> -drm_kms_helper
> -edac_core
> -fjes
> -gf128mul
> -i2c_algo_bit
> -i2c_smbus
> -mgag200
> -ttm
> -uas
> -usb_storage

rmmod: ERROR: Module drm is not currently loaded
rmmod: ERROR: Module drm_kms_helper is not currently loaded
rmmod: ERROR: Module edac_core is builtin.
rmmod: ERROR: Module fjes is not currently loaded
rmmod: ERROR: Module gf128mul is builtin.
rmmod: ERROR: Module i2c_algo_bit is not currently loaded
rmmod: ERROR: Module i2c_smbus is not currently loaded
rmmod: ERROR: Module mgag200 is not currently loaded
rmmod: ERROR: Module ttm is not currently loaded
rmmod: ERROR: Module uas is not currently loaded
rmmod: ERROR: Module usb_storage is not currently loaded

> 
> ; Пробуем загрузить
> +ecdh_generic
> +ipmi_devintf
> +ipmi_msghandler
> +ipmi_si
> +mdio
> +msr
> +xfrm_algo

Не помогло.

(In reply to comment #12)
> (В ответ на комментарий №8)
> > ; Пробуем выгрузить
> > -uas
> rmmod: ERROR: Module uas is not currently loaded
> > 
> > ; Пробуем загрузить
> Не помогло.

Извиняюсь, перепутал заголовки. Должно быть конечно наоборот. uas и другие есть только где всё ОК, а где не работает, их надо загрузить. А понизить ядро до std-def пробовали?

(В ответ на комментарий №13)
> (In reply to comment #12)
> > (В ответ на комментарий №8)
> > > ; Пробуем выгрузить
> > > -uas
> > rmmod: ERROR: Module uas is not currently loaded
> > > 
> > > ; Пробуем загрузить
> > Не помогло.
> 
> Извиняюсь, перепутал заголовки. Должно быть конечно наоборот. uas и другие есть
> только где всё ОК, а где не работает, их надо загрузить. А понизить ядро до
> std-def пробовали?

Понизил ядро до 4.19.56-std-def-alt1
Всё что надо было выгрузить, загрузил.
Всё что надо было загрузить, выгрузил.
Ниже на что ругнулось в процессе.

modprobe: ERROR: could not insert 'fjes': No such device
modprobe: FATAL: Module mgag200 not found in directory /lib/modules/4.19.56-std-def-alt1

mdio выгрузить не могу, зависимость на ixgbe
rmmod: ERROR: Module mdio is in use by: ixgbe

К слову, на CentOS 7 данные сервера работают отлично.

Заметил, что после загрузки системы и появления приглашения login:
Клавиатура работает примерно 2 секунды.
То есть можно успеть набрать root )))

(In reply to comment #14)
> Понизил ядро до 4.19.56-std-def-alt1
> Всё что надо было выгрузить, загрузил.
> Всё что надо было загрузить, выгрузил.

То есть, это и не ядро, и не какой-то конкретный модуль.

(In reply to comment #15)
> Заметил, что после загрузки системы и появления приглашения login:
> Клавиатура работает примерно 2 секунды.
> То есть можно успеть набрать root )))

Отлично! Хорошо бы залогиниться с простым паролем или хотя бы начать это делать, а потом по сети дать journalctl -r и смотреть dmesg -- тогда станет понятней, что происходило с момента логина в последние пару секунд.

(В ответ на комментарий №16)
> (In reply to comment #14)
> > Понизил ядро до 4.19.56-std-def-alt1
> > Всё что надо было выгрузить, загрузил.
> > Всё что надо было загрузить, выгрузил.
> 
> То есть, это и не ядро, и не какой-то конкретный модуль.
> 
> (In reply to comment #15)
> > Заметил, что после загрузки системы и появления приглашения login:
> > Клавиатура работает примерно 2 секунды.
> > То есть можно успеть набрать root )))
> 
> Отлично! Хорошо бы залогиниться с простым паролем или хотя бы начать это
> делать, а потом по сети дать journalctl -r и смотреть dmesg -- тогда станет
> понятней, что происходило с момента логина в последние пару секунд.

Так, попробовал очень быстро залогиниться.
С 2 секундами я погорячился )
По моим подсчётам есть примерно 1.2 - 1.5 секунды что-бы залогинится.
И вот что заметил (на скриншоте, что положил в облако по ссылке выше), после того как успел набрать логин и нажать Enter, консоль зависла.
Не появилась приглашение ввести пароль.
Наводит на мысль, что USB тут может и не причём.
Косвенно это может подтвердиться тем, что при попытках в консоли неоднократно набрать логин с последующим нажатием Enter визуально не приводило к никаким изменений, в то время как в логе есть записи такого рода.

Jun 28 10:21:14 work login[3085]: login_authenticate_user: Login failed - too many bad attempts
Jun 28 10:21:23 work login[3104]: login_authenticate_user: Login failed - too many bad attempts

Что-бы не искать по треду.

https://yadi.sk/d/44WJhe0_i45Pmg

> > Отлично! Хорошо бы залогиниться с простым паролем или хотя бы начать это
> > делать, а потом по сети дать journalctl -r и смотреть dmesg -- тогда станет
> > понятней, что происходило с момента логина в последние пару секунд.
> 
> Так, попробовал очень быстро залогиниться.
> С 2 секундами я погорячился )
> По моим подсчётам есть примерно 1.2 - 1.5 секунды что-бы залогинится.
> И вот что заметил (на скриншоте, что положил в облако по ссылке выше), после
> того как успел набрать логин и нажать Enter, консоль зависла.
> Не появилась приглашение ввести пароль.
> Наводит на мысль, что USB тут может и не причём.
> Косвенно это может подтвердиться тем, что при попытках в консоли неоднократно
> набрать логин с последующим нажатием Enter визуально не приводило к никаким
> изменений, в то время как в логе есть записи такого рода.
> 
> Jun 28 10:21:14 work login[3085]: login_authenticate_user: Login failed - too
> many bad attempts
> Jun 28 10:21:23 work login[3104]: login_authenticate_user: Login failed - too
> many bad attempts

Немного поразмыслив, решил установить ядрёный модуль kernel-modules-drm-ancient-un-def
для поддержки

lspci | grep -i vga
08:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05)

И консоль стала нормально отзываться на нажатие клавиш.

(In reply to comment #19)
> Немного поразмыслив, решил установить ядрёный модуль
> kernel-modules-drm-ancient-un-def
> И консоль стала нормально отзываться на нажатие клавиш.

Надо же! То есть, решилась проблема? А ведь когда фильтровал разницу, на drm ставку не делал, но не стал их исключать:

-drm
-drm_kms_helper
-mgag200

Надо будет сказать boyarsh@, он словил похожее на одном сервере.

(In reply to comment #19)
> Немного поразмыслив, решил установить ядрёный модуль
> kernel-modules-drm-ancient-un-def

Ох, а ведь выше было:

(In reply to comment #14)
> modprobe: FATAL: Module mgag200 not found in directory

Это я пропустил и поторопился с выводами. Значит, всё-таки дело в модуле.

(В ответ на комментарий №21)
> (In reply to comment #19)
> > Немного поразмыслив, решил установить ядрёный модуль
> > kernel-modules-drm-ancient-un-def
> 
> Ох, а ведь выше было:
> 
> (In reply to comment #14)
> > modprobe: FATAL: Module mgag200 not found in directory
> 
> Это я пропустил и поторопился с выводами. Значит, всё-таки дело в модуле.

(В ответ на комментарий №20)
> (In reply to comment #19)
> > Немного поразмыслив, решил установить ядрёный модуль
> > kernel-modules-drm-ancient-un-def
> > И консоль стала нормально отзываться на нажатие клавиш.
> 
> Надо же! То есть, решилась проблема? А ведь когда фильтровал разницу, на drm
> ставку не делал, но не стал их исключать:

Да, проблема с установкой модуля mgag200 решилась.

> 
> -drm
> -drm_kms_helper
> -mgag200
> 
> Надо будет сказать boyarsh@, он словил похожее на одном сервере.

(В ответ на комментарий №21)
> (In reply to comment #19)
> > Немного поразмыслив, решил установить ядрёный модуль
> > kernel-modules-drm-ancient-un-def
> 
> Ох, а ведь выше было:
> 
> (In reply to comment #14)
> > modprobe: FATAL: Module mgag200 not found in directory
> 
> Это я пропустил и поторопился с выводами. Значит, всё-таки дело в модуле.

Хорошо бы сделать, если присутствует
VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e
автоматом подгружался соответствующий модуль при установке системы.