Arch Linux и bumblebee: X unresponsive after 10 seconds

Надо ещё Xorg.8.log полностью.

Xorg.2.log (8 нет, запускаю на tty2)

Xorg.2.log (8 нет, запускаю на tty2)

В bumblebee.conf у Вас VirtualDisplay=:2? Лог больше похож на X-сы с Intel картой.

В Xorg.2.log нет ни строки про nVidia, надо убедиться, что в xorg.conf.nvidia задан Driver «nvidia-в_зависимости_от_дистрибутива/драйвера» и тот же драйвер указан в bumblebee.conf: Driver=то_же_самое.

Убедиться в правильности имени можно так

echo ON > /proc/acpi/bbswitch
modprobe nvidia-правильное_название_модуля

На всякий случай, мои конфиги.

Прошу прощения, я идиот. Указал VirtualDisplay - больше не висит.
Но всё-равно я что-то делаю очень неправильно. Теперь плюётся

X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  24 (X_GLXCreateNewContext)
  Value in failed request:  0x0
  Serial number of failed request:  19
  Current serial number in output stream:  20

[ERROR][XORG] (EE) Server is already active for display 2

Ну главное, чтобы оба X-сервера на разных «виртуальных дисплеях висели». По умолчанию вроде задаётся 8 для X-сов с nVidi-ей.

Теперь плюётся

Лучше полный лог X-сов, которые с nVidia целиком. Т.е. в /var/log должны быть 2 лога - один с Intel, 2-ой - с nVidia.

Xorg.2.log - в bumblebee.conf указан :2, значит X-ы на tty2 должны идти с nvidia? Однако в логе ни слова о nvidia. X-ы запускаются от юзера, не от root, если это важно (логи из ~/.local/share/xorg/), в /var/log лежат не те.
Стартую так: $ xinit /usr/bin/openbox-session -- :$XDG_VTNR vt$XDG_VTNR

Стартую так

Если Вы это делаете на 2-ом tty, то основные X-сы с Intel запускаются на 2-ом виртуальном дисплее (XDG_VTNR=2?). При этом в bumblebee.conf указан 2-ой виртуальный дисплей для запуска другого X-сервера с драйвером nVidia, кт. не может запуститься, т.к. 2-ой вирт. дисплей занят уже основными X-сами. Надо сменить VirtualDisplay в bumblebee.conf на 8 и смотреть /var/log/Xorg.8.log.

Можно вместо 8-ки выбрать любое число, не совпадающее с номером вирт. дисплея основного X-сервера с Intel, главное, чтобы в скриптах запуска primusrun/optirun было указано то же число.

Простите, я видимо запутал и вас, и себя.
Расклад такой: Есть SDDM. Он запускается на tty1. Из него запускается сессия KDE, KDE заменяет собой SDDM, и $DISPLAY у KDE-сессии :0. Я перехожу на tty2. Запускаю оттуда, из командной строки, openbox руками, вышеуказанной командой, от своего пользователя. Он стартует с дисплеем :2. В /etc/bumblebee/bumblebee.conf VirtualDisplay=:2. При вызове optirun возникает вышеназванная ошибка (X Error of failed request: BadValue)
Меняю VirtualDisplay в конфиге bumblebee на :8. Получаю ситуацию из ОП (X unresponsive after 10 seconds). Вот /var/log/Xorg.8.log при этом.

Меняю VirtualDisplay в конфиге bumblebee на :8.

Всё, так и надо оставить, осталось устранить

[  1907.464] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied
[  1907.937] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied

Кому-то помогает добавление в /etc/bumblebee/xorg.conf.nvidia строк

Section "Screen"
    Identifier "Default Screen"
    Device "DiscreteNvidia"
EndSection

Да, последние строчки dmesg не помешают, вдруг 635M не поддерживается 370.28...

С вероятностью 99% добавление этих 4-х строк в xorg.conf.nvidia должно решить проблему.

Не в тему, но тоже запускаю X-сы от юзера без DM-ов из терминала по алиасам x (Awesome), xt (Urxvt), в .zshrc/.bashrc так:

FGCONSOLE=`fgconsole 2>/dev/null`
alias nohup='nohup > /dev/null $1'
[ ! -z $FGCONSOLE ] && alias x="exec nohup xinit -- :$FGCONSOLE -nolisten tcp vt$FGCONSOLE &>/dev/null"
[ ! -z $FGCONSOLE ] && alias xt="exec nohup xinit urxvt -- :$FGCONSOLE -nolisten tcp vt$FGCONSOLE &>/dev/null"

Вы мой спаситель! Правда, пришлось выключить ещё iptables и ip6tables - с запущенными не работало. Выключил - шестерёнки закрутились.
Огромное спасибо за помощь!

пришлось выключить ещё iptables и ip6tables - с запущенными не работало.

Ого, надо же. По идее с и на 127.0.0.1 (localhost) пакеты не должны блокироваться...

Глянул свои ip6tables - у меня всё входящее наглухо резалось (lo вроде надо явно разрешать, как сделано с ipv4). Проблем это не создавало, казалось, посему как-то не подумал даже, давно уже так. Сейчас просто выключил ip6tables, оставив только для ipv4 - всё работает.