Open StefanLobbenmeier opened 3 years ago
Is there a way to get further logs than this? I used journalctl -u xow.service
to get those logs
Is there a way to get further logs than this? I used journalctl -u xow.service to get those logs
@StefanLobbenmeier Probably not. That error code is coming directly from libusb
.
I wonder if this problem could be avoided by starting the service after the dongle is plugged in (there are two PRs for that).
I see, do you mean physically plugged in or „plugged in“ by the kernel~
Because it would be really nice if I could always leave the adapter plugged in. I am doing that at the moment.
I noticed this issue too, I have to unplug and then plug the dongle to make it work
@Hedronmx you have to plug out and plugin the dongle in addition to restarting the service?
Nevermind!! I had some issues with usb hub bandwidth! Seems to be working fine just now
Happening for me with latest source on Linux 5.11.7-arch1-1 x86_64.
With dongle already inserted in PC, service fails to start at boot on a regular basis. Manually starting service after failure is always successful. Same log output as OP.
I have tried the dongle on various USB buses and the issue still occurs. libusb
version 1.0.24-21
@mundifex Could you try if https://github.com/medusalix/xow/pull/156 solves the problem for you? If it does, one of the PRs should be merged that activate the xow service on udev event.
@mundifex Could you try if #156 solves the problem for you? If it does, one of the PRs should be merged that activate the xow service on udev event.
Your PR has resolved the issue for me. I performed 10 reboots and the xow
service started automatically and successfully each and every time. The controller was in varying states of off, connecting, and connected. I verified connection with sdl2-jstest
a few times and everything works like I'd expect.
Thanks so much for your PR and your advice!
Thanks! I cannot reproduce for some time so I will close it and try #156 in a few weeks, since the issue of @mundifex match my issue.
Is closing this issue the best decision? Until https://github.com/medusalix/xow/pull/156 gets merged, the error persists and I'd rather close this issue only if and when the PR gets merged.
No it's not. It's better if the commit that fixes it has a "Closes" github tag.
Oh Sorry, will wait for the merge
I am also experiencing the same error on kernel 5.11.16. #156 doesn't appear to fix this issue in my case although I only modified my current install with the udev and service file changes.
EDIT: Looks like the patch does work. I forgot to run systemctl disable xow
to prevent the service from starting at boot up and failing.
Today I had a different issue:
Jun 13 21:01:22 stefan-manjaro systemd[1]: Started Xbox One Wireless Dongle Driver.
Jun 13 21:01:28 stefan-manjaro xow[488]: 2021-06-13 21:01:28 INFO - xow ©Severin v. W.
Jun 13 21:01:28 stefan-manjaro xow[488]: 2021-06-13 21:01:28 INFO - Waiting for device...
Jun 13 21:01:29 stefan-manjaro xow[488]: 2021-06-13 21:01:29 ERROR - Error in control transfer: LIBUSB_ERROR_TIMEOUT
Jun 13 21:01:29 stefan-manjaro xow[488]: 2021-06-13 21:01:29 ERROR - Firmware part loading timed out
Jun 13 21:01:29 stefan-manjaro xow[488]: 2021-06-13 21:01:29 ERROR - Failed to write ILM
Jun 13 21:01:29 stefan-manjaro xow[488]: terminate called after throwing an instance of 'Mt76Exception'
Jun 13 21:01:29 stefan-manjaro xow[488]: what(): Failed to load firmware
Jun 13 21:01:29 stefan-manjaro systemd[1]: xow.service: Main process exited, code=dumped, status=6/ABRT
Is it related or should I open a new issue?
I use the xow.service so that I do not have to worry about having to launch xow in the terminal everytime before I start a game.
Anyway, once or twice a week the xow service does not boot up. I checked the logs and I found this: