Open jeffkeller87 opened 3 years ago
jeffkeller87
commented
3 years ago Could it be that even though I have tried using the USB 2.0 ports in a couple locations, that because the underlying USB controller on the motherboard is USB 3.x, that I am actually running into the power management issues described in the README?
medusalix
commented
3 years ago @jeffkeller87 It doesn't look like the problem is caused by your USB controller at all. It seems like the newer Series X controller has that exact same issue on Windows too. There's a PR (#142) that apparently fixes those issues. You might want to give it a try.
jeffkeller87
commented
3 years ago Thanks for the tip @medusalix. Unfortunately, that PR did not fix the issue for me. I commented my results there.
yoyossef
commented
3 years ago I confirm this issue with my Xbox Series Controller (white one), one thing different though is that it's sometimes not reconnecting the controller after it gets disconnected.
Sometimes I'm able to reconnect it by pushing the Xbox button and it's not that big of a deal, but after a few times my controller won't turn on again, the led immediately turns off (instead of repeatedly blinking) as I stop pushing the Xbox button.
And the only solution to that is for me to put out the batteries, and I have to wait for the controller to reset itself for ~2-3 minutes, maybe my batteries are at fault, I'll check on that.
It feels very unstable and unreliable overall unfortunately, I'd be glad to help in any way.
jeffkeller87
commented
3 years ago So this issue has seemingly gone away for me.... the only material change I can think of has been changing the ports in which my USB hub is connected to the motherboard and also rebooting. Previously, I was just restarting the xow service between testing different ports. So something for others to try.
alkazar
commented
3 years ago @jeffkeller87 are you using this fix https://github.com/medusalix/xow/pull/142 or a release build?
I am also experiencing this issue. The timeout doesn't seem to be consistent. I have seen as short as 15 seconds and as long as 45 seconds.
I am using xow 0.5.
jeffkeller87
commented
3 years ago @alkazar I am back to using the 0.5 release build and the issue has still not returned for me.
Aside from what has already been mentioned, the only other thing I can think of that could have contributed to the fix was that I booted into my Windows partition. I did not use the controller while in Windows, but I suppose it is possible that a firmware update was applied by Windows Update automatically?
When I was having the issue, I did notice the timeout could be inconsistent as well, 15-45 seconds sounds about right.
alkazar
commented
3 years ago Switching USB ports did not seem to help. I am using the dongle I bought for use with the Xbox One S controller. I wonder if the dongle needs a firmware upgrade to work with the new controllers properly.
TheCraiggers
commented
3 years ago Switching entire computers hasn't helped, never mind USB ports. Meanwhile, my older xbox controller (no share button, microUSB) works just fine. As medusa said, people are having problems in windows as well so I don't think this is even a xow issue.
However, I'm worried that any fix released from MS will be difficult / impossible to apply without a windows computer or xbox game console, as it looks like it may involve a firmware update for the controllers. I don't know of a way to update them on Linux.
kakra
commented
3 years ago @TheCraiggers You can download an eval ISO of Windows 10 directly from Microsoft, install it into a VM, and run the Xbox accessories app from there to update the gamepad. You should do that with the dongle, tho, because the controller will reboot into a firmware download mode which would disconnect it from USB (and thus disable USB pass-thru to the VM) - using the dongle, the USB connection will be kept alive as only the controller reboots.
jeffkeller87
commented
3 years ago I will be doing another PC build in a few weeks which will take me away from this X370 motherboard and onto a B550. Will report back then as well.
Reporting back with more info now that I'm on an MSI B550 Tomahawk motherboard:
$ lspci | grep USB
02:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 43ee
2d:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host ControllerI had to re-pair the controller with the dongle and then proceeding to try every USB port on the back of the motherboard (rebooting in between) and found that the lone USB 2.0 port (not counting the BIOS flashback port) gave me the best results.
Interestingly, I was still experiencing disconnects when using the dongle with this port, but they were relatively infrequent. I turned the controller on and just let it sit without any input to see what happened. Disconnects happened at ever increasing intervals until the interval was long enough that the controller powered down due to inactivity (30 minutes I think).
Repeating the test, I still had disconnects but they continued to happen fairly infrequently.
TLDR; My earlier experience where I claimed the disconnects had stopped may have just been a case where the disconnects were happening quite far apart. Far enough apart that input activity from normal use (playing a game) would keep the connection alive. Not great, but a lot less annoying than a disconnect every 20-30 seconds on inactivity.
$ dmesg -w
[ 48.492762] input: Xbox One Wireless Controller as /devices/virtual/input/input34
[ 77.173289] input: Xbox One Wireless Controller as /devices/virtual/input/input35
[ 98.071499] input: Xbox One Wireless Controller as /devices/virtual/input/input36
[ 290.283890] input: Xbox One Wireless Controller as /devices/virtual/input/input37
[ 376.708101] input: Xbox One Wireless Controller as /devices/virtual/input/input38
[ 1250.907928] input: Xbox One Wireless Controller as /devices/virtual/input/input39
# controller shuts down due to inactivity around 1850s
# I turn the controller back on
[ 2325.424310] input: Xbox One Wireless Controller as /devices/virtual/input/input40
[ 2525.107803] input: Xbox One Wireless Controller as /devices/virtual/input/input41
[ 2743.736879] input: Xbox One Wireless Controller as /devices/virtual/input/input42
[ 2779.577636] input: Xbox One Wireless Controller as /devices/virtual/input/input43
[ 2894.985140] input: Xbox One Wireless Controller as /devices/virtual/input/input44Wasn't there something in the past that mentioned Wifi channel hopping of the dongle and how the controller may disconnect then? Do you have a lot of 5 GHz Wifi around? Maybe try turning 5 GHz off in your Wifi network for a test...
Or is it 2.4 GHz that the dongle is using? @medusalix Do you know?
jeffkeller87
commented
3 years ago In my case there are no 5 GHz WiFi networks in the vicinity, only two 2.4 GHz networks, and I am still experiencing intermittent disconnects.
medusalix
commented
3 years ago Wasn't there something in the past that mentioned Wifi channel hopping of the dongle and how the controller may disconnect then?
I believe channel hopping is implemented in the firmware of the dongle and the controller. The driver just supplies the available channel candidates.
Or is it 2.4 GHz that the dongle is using? @medusalix Do you know?
@kakra I'm pretty sure the firmware defaults to 5 GHz, although xow is configuring both 2.4 and 5 GHz channels. There's a Enable2Dot4GHz string in the binary of Microsoft's GIP driver, so I'm pretty sure there's a way to force the dongle to use 2.4 GHz (I'd really like to know how to enable it).
kakra
commented
3 years ago I wonder if it could be disassembled, tho that's probably not allowed by the TOS supplied with the driver.
movisman
commented
3 years ago Just to confirm, I see this exact issue on my MiSTer (linux). I had chance to test an Xbox Series X controller (1914) with it, and it works great except for this idle disconnect/reconnect thing which is quite bizarre. My firmware is fully up to date on the controller side of things. Mine disconnects and reconnects by itself in 3-4 seconds, I don't need to power it back on or anything like that. Timing can vary but seems to be around 25-30 seconds initially when left idle.
My Xbox One controllers (1708) do not exhibit this behaviour - they have worked robustly on RetroPie for a long while now. They also work great on my MiSTer.
For reference, I am using the slim wireless dongle.
There are a lot of threads all over the place about a similar issue with the controller disconnecting for people, and MS are still working on it - but it is not resolved yet. I hope this is the same issue, although curiously, when using the dongle in Windows, it doesn't seem to do the disconnect/reconnect thing - but I haven't tested in detail.
medusalix
commented
3 years ago We'll have to wait until Microsoft releases a firmware update.
movisman
commented
3 years ago No worries. I haven't managed to make it happen in Windows yet, but only did a little more testing today. Certainly seems like an MS thing though, so will hang tight and test again further once they release a firmware update for the controller. It's very easy to replicate on my MiSTer, intervals between each idle desync/resync can vary but ultimately it still happens on every boot and the first desync/resync is "usually" only after 30 seconds or so of idle time.
Thanks!
Bloodaxe95
commented
3 years ago I'm not seeing any of the disconnects when I'm connected to a Windows PC, and I've updated the controller to the latest firmware. This issue is still present, and it's annoying the crap out of me. Is there anything a non-coder can do to help finding and publishing a solution to this?
kakra
commented
3 years ago Maybe it could be worth it capturing the USB traffic from connect until the unexpected disconnect, then do the same in Windows, and compare both. If Windows does something different, it probably sends intermittent commands to the dongle which Linux doesn't - or reacts to some other events that xow does not support/care about.
You should probably not touch any controls while capturing the USB traffic to keep the protocol noise low. But I cannot help with how to correctly capture the traffic in both OS - but I'm pretty sure @medusalix already posted it somewhere (maybe in Discord only).
Pieman711
commented
3 years ago Just to confirm I'm getting exactly the same issue. 1914 controller with the wireless dongle. I'm playing through steamlink and the disconnect/reconnect cause a load of lag and glitches that can often stop the whole game.
I'll try and look through the discord, but if someone can point me to a bit of a guide on how to monitor USB traffic, or anything else useful, then I'll have a stab at it and feedback my findings.
djolker
commented
3 years ago Having a very similar experience to what's being described here.
I use a 1537 and 1914 controller with my 1790 Wireless Adapter
The 1537 works very well for the most part (doesn't disconnect early), but the 1914 will start to disconnect cycle after about 15 to 30 seconds (sometimes even less) of idle time, or occasionally just straight up in the middle of usage (very rarely for that though)
I've noticed the issue is worse when they are both attached to the wireless adapter, even causing the 1537 model to disconnect cycle occasionally.
Happy to assist in any way
samAnnisBrown
commented
3 years ago +1
Same issue on latest release of Rasbian. Using 1914 with wireless dongle since Bluetooth seemed impossible (pairing issues).
Dongle works a charm outside the connection issues. Same 15-30 sec idle disconnect. Wouldn’t bother me that much except I’m using with RetroPie, and the hotkey stops working after a disconnect, meaning i can no longer save states or exit emulators without a reboot.
Extremely frustrating and keen for a fix or workaround if someone finds one!
silvannn
commented
3 years ago Hi, I have the same issue. 1914 is constantly disconnecting and connecting but... I am just starting my journey with RetroPie and instead of installing it by myself I used ready ISO image which I downloaded from arcadepunk.com. I have checked two images created by RickDangerous for RaspberryPi 4 and on one of them my dongle and controller is working perfectly. No idle disconnection. On second image I have that issue. In both cases I installed xow drivers the same way. So now I have pendrive with retropie where controller is working fine and ssd with retropie where I am experiencing this issue. I am a noob and I do not know how to check differences between those versions but it looks like there is no problem with xow but with operation system itself. Some settings needs to be changed or something is missing. My 1914 is updated and working perfect on PC.
djolker
commented
3 years ago I'm curious if maybe there's two separate issues at play here that look very similar:
The title of this thread has to do with the controller timeing out when it idles, but it seems like a few of us are having disconnect problems in the middle of use.
I've noticed even my older controller will begin rapidly disconnecting and reconnecting after about an hour or two of constant play
OriginLegend
commented
3 years ago Not sure if this issue is related to one I am facing (seems like it is).
For me the issue was the empty-packet received by the driver results in an automatic disconnect: https://github.com/medusalix/xow/blob/master/dongle/dongle.cpp#L272
As a result, I added a build-flag to disable this behavior: EMPTY_PACKET_DISCONNECT Pull-Request: https://github.com/medusalix/xow/pull/185
If you want to test it make sure you clean your workspace and rebuild with this flag: make clean make BUILD=RELEASE EMPTY_PACKET_DISCONNECT=0
Let me know if this resolves the issues for y'all as well
samAnnisBrown
commented
3 years ago Thanks @OriginLegend - initial testing didn’t solve this for me.
After this I needed a reboot before controllers would connect. Stillhad a disconnect within 30 seconds of idle.
Very basic testing - might spend more time on it tonight.
OriginLegend
commented
3 years ago @samAnnisBrown Thanks for the feedback - do you have a model 1914 controller as well? I am trying to experiment with other solutions which might help, but so far I don't have any new things to test (all changes I have experimented with cause instability - crashing, etc).
Will try to take a look on Monday too when I have more time and see if there is anything else I can try to make this work.
samAnnisBrown
commented
3 years ago A little more testing - basically just uninstalls, reboots, and rebuilds in various orders to see if anything stuck. Still getting disconnects @OriginLegend.
I’ve the 1790 dongle and 1914 controllers.
Thanks for your efforts - happy to test anything you might come up with. The install and testing I’m good with, but the dev is a bit out of my depth.
silvannn
commented
3 years ago Can someone look on this retropie image: https://punkwhore.com/arcadepunks/2021-2/tor/64gb-Blue.Unicorn.RPi4.Kids-Rick.Dangerous.torrent? With this image and xow installed, controller doesn't disconnect when idle.
kakra
commented
3 years ago It may not be okay to share links to content which possibly contain copyrighted material. By the link name, this looks like the image may contain intellectual property of third parties.
Bloodaxe95
commented
3 years ago Is it possible to make a bounty on this? I really want this issue fixed, although I don't have a ton of cash to give xD But some cash is better than no cash, right?
OriginLegend
commented
3 years ago @Bloodaxe95 I'm happy to try to add to my own change* (which doesn't seem to work for everyone) without a bounty, but I would definitely need someone else on here (like yourself) to do some extensive back-and-forth testing since I can't reproduce this myself.
I will work on a separate branch that has a lot more debug info/statements for y'all to test in the next day or so that way I can try to get more context.
*See above for my current change
Bloodaxe95
commented
3 years ago @Bloodaxe95 I'm happy to try to add to my own change* (which doesn't seem to work for everyone) without a bounty, but I would definitely need someone else on here (like yourself) to do some extensive back-and-forth testing since I can't reproduce this myself.
I will work on a separate branch that has a lot more debug info/statements for y'all to test in the next day or so that way I can try to get more context.
*See above for my current change
I'd be happy to lend my time to test the change! I am unfortunately not very skilled with anything technical xD I'll do my best though :smile:
samAnnisBrown
commented
3 years ago Nice to see some more talk on this thread - this is still bugging me!
@OriginLegend - I’m technical (Linux Admin with some dev experience). Happy to help along with @Bloodaxe95 - can provide logs or whatever you need.
My problem is always time with 2 young kids, but could typically turn some testing around within 24 hours.
OriginLegend
commented
3 years ago @samAnnisBrown and @Bloodaxe95,
Thanks, I will try to update the project with a bit more targeted logging, etc sometime later tonight or early tomorrow for testing so I can get a better idea of what exactly is going on. I am also trying to do some of my own research into what might be the issue. I completely understand on time limitations (my time can be sparse too occasionally) so no rush on testing turn-around.
I will provide an update on this thread once this is done which will reference my forked repo here: https://github.com/OriginLegend/xow
If we get it working I will add it to my open pull-request: https://github.com/medusalix/xow/pull/185
OriginLegend
commented
3 years ago Apologies for the longer-than expected turn-around.
I have added a branch called "testing" in my fork: https://github.com/OriginLegend/xow/tree/testing It is built and tested the same way, just includes a lot more debug information while running for my context what is going on exactly.
You can follow these steps to update the version running on your computer:
To uninstall the service:
sudo systemctl stop xow
sudo systemctl disable xow
sudo make uninstallTo remove the currently cloned repo (or you can put it in a different directory):
cd ..
rm -r xowClone the forked repository (testing branch):
git clone -b testing https://github.com/OriginLegend/xow.git
cd xowBuild the new version with debugging added:
make BUILD=RELEASE EMPTY_PACKET_DISCONNECT=0
sudo make install
sudo systemctl enable xow
sudo systemctl start xowOnce the controller disconnects, you can view the last messages from the service and attach them to this issue by doing the following:
sudo systemctl status xow
# I believe you can also increate the line-count by doing the following (would be more helpful)
sudo systemctl status xow -n 50Thanks in advance, and no rush, I will check this thread periodically and investigate once I have more information and time - hopefully we can get to the root of the issue. 😄
samAnnisBrown
commented
3 years ago You're fixing a problem for free - no need to apologise!
So I did some cursory testing on this today. Installed as per your instructions - and my controllers no longer disconnect! (well, they didn't during the 5 mins I had to test - but they always disconnect within 30 seconds, so I took it as a tentative win).
I went back through my command history to see how I installed your fork last time, and it was the exact same process you've outlined. The only difference was I pulled from master of your fork. Should I have pulled from frequent-disconnects instead? (I see a later commit?).
Pulling from master at the time, there were no errors thrown during build with the EMPTY_PACKET_DISCONNECT=0 flag, so I assumed the required code was present.
I've not had the time to compare code between branches, but will spend more time in the next 24 hours testing the various branches and confirming which might solve the problem!
samAnnisBrown
commented
3 years ago I think I'm an idiot - I just compared code and can clearly see master doesn't contain the required code in your fork to resolve disconnects - I'll need to pull from frequent-disconnects. I figured it would throw an error during build if the flag didn't exist, but maybe not?
Let me try that branch and get back to you - but based off my testing earlier today, I suspect it's going to work!
samAnnisBrown
commented
3 years ago Ok, I’m an idiot - just installed from ‘frequent-disconnects’ instead of ‘master’ and it resolved my problem.
Sorry for the run around. Keen to hear if this was also @Bloodaxe95 ’s issue?
To be clear @Bloodaxe95, since you said you weren’t technical, I followed @OriginLegend ’s exact instructions above, but during the clone command, instead of:
git clone -b testing https://github.com/OriginLegend/xow.git
I put:
git clone -b frequent-disconnects https://github.com/OriginLegend/xow.git
Bloodaxe95
commented
3 years ago @OriginLegend @samAnnisBrown the frequent-disconnects branch is functioning as intended. At least I've yet to see my controller DC after several minutes of no input. This is amazing, thank you so much!!
OriginLegend
commented
3 years ago @samAnnisBrown @Bloodaxe95
Thanks for all the feedback, I am very happy to hear that the frequent-disconnects branch works for you all!
I'll leave my testing branch there just in-case the issue presents itself again we have the debugging capabilities.
Aside from that, we'll just wait for the pull-request to be merged.
@samAnnisBrown I will post updated directions on that pull-request to be more explicit about how to checkout/build that branch (since it is admittedly a bit unclear), but thanks for the efforts of going back and checking the frequent-disconnects specifically for functionality. Might be my bad since I have not done a GitHub-specific pull-request before, so I wasn't aware of conventions (i.e. if master-branch in forked repo is typically used).
samAnnisBrown
commented
3 years ago Not aware of conventions myself @OriginLegend , just made the perhaps incorrect assumption it would be in master.
Reporting back after a few days use, and this is definitely solved. I've now had several long play sessions without a single drop out. Thanks so much for the fix.
Pieman711
commented
3 years ago I've used it for a good few hours, including having two controllers attached for co-op. No disconnects whatsoever. Seems to have nailed it, thanks everyone!
To install it using SamAnnisBrowns suggestion of
git clone -b frequent-disconnects https://github.com/OriginLegend/xow.git
But otherwise followed the instructions as above.
Good work team!
OriginLegend
commented
3 years ago I am going to make one more change to the code to not require the additional build-flag (since this does seem to be a universal fix for all people with this controller).
I am assuming that the product id everyone is using is 0b12 so I will automatically enable the fix for this id.
But I will also leave in the build-flag for different controllers in-case they need this as well.
Logs showing the product id from original issue poster (matches with my own):
Dec 20 14:22:06 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:06 INFO - Controller '1' connected
Dec 20 14:22:07 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:07 INFO - Device announced, product id: 0b12
Dec 20 14:22:07 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:07 INFO - Serial number: 09711987454032
Dec 20 14:22:08 COOKIE-MONSTER xow[5905]: 2020-12-20 14:22:08 INFO - Battery level: 2
XirXes
commented
3 years ago I am assuming that the product id everyone is using is
0b12so I will automatically enable the fix for this id. But I will also leave in the build-flag for different controllers in-case they need this as well.
I just tested this branch with a 1708 on the new beta Bluetooth LE firmware 5.11.3118.0 and its finally working correctly again. It reports as 02ea which I'm pretty sure is the the same ID from the old firmware version.
Update, works ok, but crashed after about an hour of play.
Oct 31 16:54:04 nexus xow[62239]: 2021-10-31 16:54:04 INFO - Controller '1' connected
Oct 31 16:54:04 nexus xow[62239]: 2021-10-31 16:54:04 INFO - Device announced, product id: 02ea
Oct 31 16:54:04 nexus xow[62239]: 2021-10-31 16:54:04 INFO - Serial number: 02600214093643
Oct 31 16:54:06 nexus xow[62239]: 2021-10-31 16:54:06 INFO - Battery level: medium
Oct 31 17:04:44 nexus xow[62239]: 2021-10-31 17:04:44 INFO - Controller '2' connected
Oct 31 17:04:44 nexus xow[62239]: 2021-10-31 17:04:44 INFO - Device announced, product id: 02ea
Oct 31 17:04:44 nexus xow[62239]: terminate called after throwing an instance of 'InputException'
Oct 31 17:04:44 nexus xow[62239]: what(): Error adding key code: Invalid argument
Oct 31 17:04:45 nexus systemd[1]: xow.service: Main process exited, code=killed, status=6/ABRT
Oct 31 17:04:45 nexus systemd[1]: xow.service: Failed with result 'signal'.I'd really like to be able to replicate and fix this bug but the new firmware that @XirXes uses is unfortunately still not available in the Xbox Accessories App for Windows. Properly fixing this issue would require analyzing the USB packets sent between the Windows driver and the dongle. Capturing those packets can be done using Wireshark. I think a ~30 min capture should be sufficient to find out what the Windows driver does to prevent the controllers from disconnecting. Feel free to contact me on Discord if you need assistance with using Wireshark.
XirXes
commented
3 years ago I let it run for a bit over 30 minutes, and let it power off from inactivity. Let me know if you need any other captures on this firmware. https://drive.google.com/file/d/18HpBU6tkL1qVd8MP9ng4U07NZGAqjemt/view?usp=sharing
25minutes
commented
3 years ago @OriginLegend I'm trying to compile your code with static libraries on Ubuntu 18.04 LTS. I have searched the web and tried to modify Makefile by adding "-static", then it failed to compile with a lot of "undefined reference" errors. Below are the changes I made:
xow: $(OBJECTS) $(CXX) $(LDFLAGS) -o $@ $^ $(LDLIBS) -static
%.o: %.cpp $(CXX) $(CPPFLAGS) $(CXXFLAGS) -c -o $@ $< -static
As I have limited skills on coding, I couldn't work this out. I'd appreciate if anyone experienced could give me some advice.
Untz64
commented
2 years ago Mine was seemingly working fine on @OriginLegend's branch until recently. Now after about a minute of use the service crashes similarly to @XirXes, but I'm not on the same firmware. I rebuilt as DEBUG to see if there was any more relevant info, see below:
Dec 23 22:39:35 retropie xow[1510]: 2021-12-23 22:39:35 INFO - Battery level: medium
Dec 23 22:39:55 retropie xow[1510]: 2021-12-23 22:39:55 INFO - Controller '2' connected
Dec 23 22:39:56 retropie xow[1510]: 2021-12-23 22:39:56 INFO - Device announced, product id: 0b12
Dec 23 22:39:56 retropie xow[1510]: 2021-12-23 22:39:56 DEBUG - Firmware version: 5.9.2709.0
Dec 23 22:39:56 retropie xow[1510]: 2021-12-23 22:39:56 DEBUG - Hardware version: 1032.1.1.1
Dec 23 22:39:56 retropie xow[1510]: terminate called after throwing an instance of 'InputException'
Dec 23 22:39:56 retropie xow[1510]: what(): Error adding key code: Invalid argument
Dec 23 22:39:56 retropie systemd[1]: xow.service: Main process exited, code=killed, status=6/ABRT
Dec 23 22:39:56 retropie systemd[1]: xow.service: Failed with result 'signal'.Not sure why it's seeing the same controller as a "second" controller.
Model Number (as printed on box): "1904, 1790"
xowversion: 0.5The
xowdriver works flawlessly with this controller model as long as the controller is not idle for too long (~30s). This usually isn't a problem when gaming, since the user is often sending inputs from the controller more than once per 30 seconds.However, if left to idle, the wireless connection to the dongle will disconnect, and reconnect a few seconds later. Not a huge deal, but is somewhat annoying when resuming play after a cut scene or load screen. Sometimes I just flick one of the analog sticks to keep the connection alive as a workaround.
I have tried plugging the controller into:
The only other USB header in use on my motherboard is from my NZXT X62 Kraken AIO. I assume this is the ASMedia controller listed above.
Some other logs that are useful as a sanity check:
Please let me know if there is any other information I can provide. I know there is a section in the README that mentions USB incompatibilities. I think I have successfully avoided an ASMedia USB controller, but maybe AMD controllers are also incompatible?
I will be doing another PC build in a few weeks which will take me away from this X370 motherboard and onto a B550. Will report back then as well.