xealits's questions

É um controle 8BitDo SN30 pro+. Ele é conectado por meio de um dongle USB Bluetooth. Ele costumava funcionar perfeitamente bem. Mas em algum momento após uma atualização recente, todo o comportamento simplesmente degradou. Ele costumava vibrar na conexão - agora nunca mais. Ele pode se desconectar aleatoriamente logo após ser conectado. De alguma forma, reiniciando as coisas e reemparelhando, consegui fazê-lo funcionar em um jogo do Steam algumas vezes recentemente. Mas fica muito doloroso.

Vejo que ele está pareado, confiável e conectado em blueman-applet, e em bluetoothctl info. Mas o Steam não o detecta: Steam > Configurações > Controles diz "Nenhum controle detectado".

E não vejo nada relacionado a um controle em /dev. Ou seja, de acordo com o Arch Gamepad wiki, ele deveria aparecer como /dev/input/jsXe como algo em /dev/input/by-id/. No meu caso, não há jsXdispositivos, /dev/input/contém apenas eventXdispositivos e micee mouse0. Tudo o que vejo em /dev/input/by-id/são meu teclado e mouse. E há um pouco mais em /dev/input/by-path/:

$ ls /dev/input/by-path/ -l
total 0
lrwxrwxrwx 1 root root 9 Feb  8 03:31 pci-0000:09:00.4-usb-0:2:1.1-event-mouse -> ../event3
lrwxrwxrwx 1 root root 9 Feb  8 03:31 pci-0000:09:00.4-usb-0:2:1.1-mouse -> ../mouse0
lrwxrwxrwx 1 root root 9 Feb  8 03:31 pci-0000:09:00.4-usbv2-0:2:1.1-event-mouse -> ../event3
lrwxrwxrwx 1 root root 9 Feb  8 03:31 pci-0000:09:00.4-usbv2-0:2:1.1-mouse -> ../mouse0
lrwxrwxrwx 1 root root 9 Feb  8 03:31 platform-eeepc-wmi-event -> ../event4
lrwxrwxrwx 1 root root 9 Feb  8 03:31 platform-i8042-serio-0-event-kbd -> ../event2

Acho que i8042é o driver do teclado. Não tenho certeza do que é platform-eeepc-wmi-event.

Então, acho que o bluetooth conecta o dispositivo, mas o controle não é reconhecido.

Quando olho journalctl -fenquanto conecto no bluetooth, recebo isto:

dunst[10327]: CRITICAL: Source ID 73 was not found when attempting to remove it
kernel: nintendo 0005:057E:2009.0008: unknown main item tag 0x0
kernel: nintendo 0005:057E:2009.0008: hidraw3: BLUETOOTH HID v80.01 Gamepad [Pro Controller] on 44:01:bb:ad:a0:55
kernel: nintendo 0005:057E:2009.0008: Failed to get joycon info; ret=-110
kernel: nintendo 0005:057E:2009.0008: Failed to retrieve controller info; ret=-110
kernel: nintendo 0005:057E:2009.0008: Failed to initialize controller; ret=-110
kernel: nintendo 0005:057E:2009.0008: probe - fail = -110
kernel: nintendo: probe of 0005:057E:2009.0008 failed with error -110

Então, ele é reconhecido como um controle nintendo, mas falha ao ser inicializado? Como posso consertar isso? Devo instalar algum driver para o controle?

Atualização: Também atualizei o FW no controlador para a última versão suportada v6.01. Ainda assim, os mesmos erros nintendo ... failed to initialize the controllerem journalctl -f.

Acabei de instalar o Ubuntu 24.04 em uma unidade Intel Optane p4801x. Estou tentando ver o quão rápido ele inicializa a partir deste disco. De fato, ele inicializa muito rápido. Mas a NetworkManagerunidade geralmente não inicia. Ela está habilitada, mas morta, e não há nada no journalctl -b 0 -u NetworkManager.service. Ou seja, a unidade nunca foi executada durante a inicialização. Quando eu mesmo a inicio após a inicialização, ela inicializa bem:

systemctl start NetworkManager

Os logs mostram que networkd-dispatcherfoi desabilitado para quebrar o ciclo de ordenação:

$ journalctl -b 0 | grep network
Oct 20 14:21:15 evergreens kernel: drop_monitor: Initializing network drop monitor service
Oct 20 14:21:15 evergreens systemd[1]: multi-user.target: Found ordering cycle on networkd-dispatcher.service/start
Oct 20 14:21:15 evergreens systemd[1]: multi-user.target: Job networkd-dispatcher.service/start deleted to break ordering cycle starting with multi-user.target/start
Oct 20 14:21:15 evergreens systemd[1]: Reached target network.target - Network.
Oct 20 14:21:15 evergreens systemd[1]: Reached target network-online.target - Network is Online.
...

Suspeito que isso fez com NetworkManagerque nunca fosse executado também.

O Systemd não mostra nenhum problema em nenhum dos dois:

$ sudo systemd-analyze verify networkd-dispatcher.service
$ sudo systemd-analyze verify NetworkManager.service
$

Mas o log na verdade mostra muito mais ciclos de ordenação, e isso aparece em verify multi-user.target:

$ journalctl -b 0 | grep "break.*cycle"
...
$ sudo systemd-analyze verify multi-user.target
...

Por exemplo, a rede:

$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo
multi-user.target: Found dependency on network.target/start
ubuntu-advantage.service: Found ordering cycle on network.target/start
ubuntu-advantage.service: Job network.target/start deleted to break ordering cycle starting with ubuntu-advantage.service/start
multi-user.target: Found ordering cycle on networkd-dispatcher.service/start
multi-user.target: Job networkd-dispatcher.service/start deleted to break ordering cycle starting with multi-user.target/start
multi-user.target: Found ordering cycle on NetworkManager.service/start
multi-user.target: Job NetworkManager.service/start deleted to break ordering cycle starting with multi-user.target/start

Mas, parece que sudo systemd-analyze verify multi-user.target imprime coisas diferentes em quase toda vez que eu o executo ? Isso é possível? Às vezes, ele imprime muito mais, às vezes, apenas 1 unidade.

Tentei traçar as dependências multi-user.targetseguindo a resposta no Unix Stackexchange :

$ sudo systemd-analyze verify multi-user.target 2>&1 |\
  perl -lne 'print $1 if m{Found.*?on\s+([^/]+)}' |\
  xargs --no-run-if-empty systemd-analyze dot | dot -Tsvg > cycle.svg

Não consegui ver um ciclo ali. Além disso, o gráfico é grande e difícil de ler. Tentei "dar zoom" em algumas unidades como, mas também não vejo um ciclo ali:

$ echo multi-user.target networkd-dispatcher.service basic.target |\
  xargs --no-run-if-empty systemd-analyze dot |\
  dot -Tsvg > cycle.svg

Como systemd-analyze verifyele imprime coisas diferentes quase toda vez que é executado, esses gráficos provavelmente não são confiáveis.

Olhando para unidades individuais, não encontro problema. As NetworkManagerdependências parecem boas:

$ cat /usr/lib/systemd/system/NetworkManager.service
[Unit]
Description=Network Manager
Documentation=man:NetworkManager(8)
Wants=network.target
After=network-pre.target dbus.service
Before=network.target
BindsTo=dbus.service
...

[Install]
WantedBy=multi-user.target
Also=NetworkManager-dispatcher.service

Eu tive um problema parecido ao inicializar de uma unidade NVMe comum da Corsair. E nunca tive quando a inicialização do NVMe da Corsair era anormalmente lenta por causa de uma unidade específica. (Montando um disco HDD /etc/fstab- ele não está fstabmais lá, então não deixa a inicialização lenta.)

Ie Eu acho que esse problema acontece somente quando a sequência de boot é rápida. Embora eu não entenda por que isso seria o caso. Por que um problema no gráfico de dependência apareceria somente em boot rápido?

Alguém poderia sugerir como rastrear os ciclos de pedidos?

O que está acontecendo com systemd-analyze verify multi-user.targeta impressão de coisas diferentes a cada vez? Esse é um comportamento conhecido real? Como ele atravessa o gráfico de dependência, é de alguma forma aleatório? Isso pode estar relacionado à causa que faz o systemd excluir unidades durante a inicialização, mas as mesmas unidades rodam bem depois?