OsmoTRX+B205mini crashes when having another USB device on a different port

Hello everyone, I am experiencing problems when trying to run osmotrx with a b205mini and I connect another USB device to a different port on the machine. When I do this, osmotrx crashes instantly. Also, when I have the other device already plugged in when I start osmotrx, it takes ~20 seconds to crash. Sometimes it just crashes without giving a reason, like here: DLGLOBAL NOTICE Setting SCHED_RR priority 18 (cpu_sched_vty.c:471) DLGLOBAL NOTICE Setting SCHED_RR priority 18 (cpu_sched_vty.c:471) DLGLOBAL NOTICE Available via telnet 127.0.0.1 4237 (telnet_interface.c:88) DLCTRL NOTICE CTRL at 127.0.0.1 4236 (control_if.c:1024) [INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3 DMAIN NOTICE -- Transceiver active with 1 channel(s) (osmo-trx.cpp:621) DLSTATS NOTICE Stats timer expire_count=7: We missed 6 timers (stats.c:169) DLGLOBAL NOTICE Stats timer expire_count=31: We missed 30 timers (rate_ctr.c:350) DTRXCTRL NOTICE Changing TSC from 0 to 7 (Transceiver.cpp:1032) DTRXCTRL NOTICE [chan=0] switching to TRXD version 1 (Transceiver.cpp:1059) DMAIN NOTICE Starting the transceiver (Transceiver.cpp:287) LLDTRXCLK NOTICE Sending CLOCK indications (Transceiver.cpp:1198) UDDEV ERROR No packet received, implementation timed-out (UHDDevice.cpp:782) DDEV FATAL UHD: Receive timed out (UHDDevice.cpp:786) DMAIN FATAL Receive error 0 (radioInterface.cpp:340) DTRXDUL FATAL Something went wrong in thread RxLower, requesting stop (Transceiver.cpp:1359) DMAIN NOTICE Shutting down transceiver... (osmo-trx.cpp:588) DMAIN NOTICE Stopping the transceiver (Transceiver.cpp:345) terminate called without an active exception Aborted And sometimes it reports an USB error and shows the talloc report: DMAIN NOTICE -- Transceiver active with 1 channel(s) (osmo-trx.cpp:621) DLSTATS NOTICE Stats timer expire_count=6: We missed 5 timers (stats.c:169) DLGLOBAL NOTICE Stats timer expire_count=26: We missed 25 timers (rate_ctr.c:350) DTRXCTRL NOTICE Changing TSC from 0 to 7 (Transceiver.cpp:1032) DTRXCTRL NOTICE [chan=0] switching to TRXD version 1 (Transceiver.cpp:1059) DMAIN NOTICE Starting the transceiver (Transceiver.cpp:287) DTRXCLK NOTICE Sending CLOCK indications (Transceiver.cpp:1198) LLUterminate called after throwing an instance of 'uhd::io_error'  what():  EnvironmentError: IOError: usb rx6 transfer status: LIBUSB_TRANSFER_OVERFLOW signal 6 received talloc report on 'OsmoTRX' (total   8531 bytes in  29 blocks)    rate_ctr.c:233                 contains   1160 bytes in   1 blocks (ref 0) 0x559c72388720    trx_rate_ctr.cpp:343           contains      8 bytes in   1 blocks (ref 0) 0x559c723886b0    trx_rate_ctr.cpp:342           contains     40 bytes in   1 blocks (ref 0) 0x559c72389540    trx_rate_ctr.cpp:341           contains     32 bytes in   1 blocks (ref 0) 0x559c723895d0    telnet_connection              contains      1 bytes in   1 blocks (ref 0) 0x559c723893d0    struct sched_vty_opts          contains     72 bytes in   1 blocks (ref 0) 0x559c723489f0    logging                        contains   6197 bytes in  13 blocks (ref 0) 0x559c722c5d10    struct trx_ctx                 contains   1021 bytes in   8 blocks (ref 0) 0x559c722a0e80    msgb                           contains      0 bytes in   1 blocks (ref 0) 0x559c722c3ac0 full talloc report on 'OsmoTRX' (total   8531 bytes in  29 blocks)    rate_ctr.c:233                 contains   1160 bytes in   1 blocks (ref 0) 0x559c72388720    trx_rate_ctr.cpp:343           contains      8 bytes in   1 blocks (ref 0) 0x559c723886b0    trx_rate_ctr.cpp:342           contains     40 bytes in   1 blocks (ref 0) 0x559c72389540    trx_rate_ctr.cpp:341           contains     32 bytes in   1 blocks (ref 0) 0x559c723895d0    telnet_connection              contains      1 bytes in   1 blocks (ref 0) 0x559c723893d0    struct sched_vty_opts          contains     72 bytes in   1 blocks (ref 0) 0x559c723489f0    logging                        contains   6197 bytes in  13 blocks (ref 0) 0x559c722c5d10        vty_logp_doc_str               contains   1377 bytes in   1 blocks (ref 0) 0x559c7231c040        vty_logp_cmd_str               contains    260 bytes in   1 blocks (ref 0) 0x559c7231ba00        vty_log_level_doc_str          contains   1170 bytes in   1 blocks (ref 0) 0x559c722ff430        vty_log_level_cmd_str          contains    236 bytes in   1 blocks (ref 0) 0x559c722ff2d0        vty_log_level_doc_str          contains   1305 bytes in   1 blocks (ref 0) 0x559c722fc610        vty_log_level_cmd_str          contains    257 bytes in   1 blocks (ref 0) 0x559c722fc4a0        struct log_target              contains    330 bytes in   3 blocks (ref 0) 0x559c7220c550            struct osmo_wqueue             contains     96 bytes in   1 blocks (ref 0) 0x7ff689ff4090            struct log_category            contains     74 bytes in   1 blocks (ref 0) 0x559c722c6290        struct log_info                contains   1261 bytes in   3 blocks (ref 0) 0x559c722ac370            uint8_t                        contains     37 bytes in   1 blocks (ref 0) 0x559c722c6350            struct log_info_cat            contains   1184 bytes in   1 blocks (ref 0) 0x559c722c5d80    struct trx_ctx                 contains   1021 bytes in   8 blocks (ref 0) 0x559c722a0e80        127.0.0.1                      contains     10 bytes in   1 blocks (ref 0) 0x559c722c5c20        127.0.0.1                      contains     10 bytes in   1 blocks (ref 0) 0x559c722c5ba0        struct cmd_element             contains    122 bytes in   2 blocks (ref 0) 0x559c72369030            logging level lms (debug|info|notice|error|fatal) contains     50 bytes in   1 blocks (ref 0) 0x559c7236c1a0        utils.c:386                    contains    405 bytes in   1 blocks (ref 0) 0x559c7225e5b0        utils.c:386                    contains     65 bytes in   1 blocks (ref 0) 0x559c723524f0                                       contains      1 bytes in   1 blocks (ref 0)    msgb                           contains      0 bytes in   1 blocks (ref 0) On the BTS side I see several messages of missed timers, but this is something I see also when I don't have the USB plugged in: <0006> scheduler_trx.c:489 GSM clock started, waiting for clock indications <0006> scheduler_trx.c:578 GSM clock skew: old fn=0, new fn=2555007 <0006> scheduler_trx.c:428 FN timer expire_count=4: We missed 3 timers <0006> scheduler_trx.c:606 We were 1 FN slower than TRX, compensated <0006> scheduler_trx.c:606 We were 1 FN slower than TRX, compensated <0006> scheduler_trx.c:428 FN timer expire_count=6: We missed 5 timers <0006> scheduler_trx.c:593 We were 1 FN faster than TRX, compensating <0006> scheduler_trx.c:606 We were 1 FN slower than TRX, compensated <0006> scheduler_trx.c:593 We were 1 FN faster than TRX, compensating <0006> scheduler_trx.c:606 We were 2 FN slower than TRX, compensated <0006> scheduler_trx.c:428 FN timer expire_count=7: We missed 6 timers <0006> scheduler_trx.c:593 We were 1 FN faster than TRX, compensating <0006> scheduler_trx.c:606 We were 1 FN slower than TRX, compensated <0006> scheduler_trx.c:593 We were 1 FN faster than TRX, compensating <0006> scheduler_trx.c:606 We were 1 FN slower than TRX, compensated <0006> scheduler_trx.c:428 FN timer expire_count=7: We missed 6 timers <0006> scheduler_trx.c:593 We were 1 FN faster than TRX, compensating <0006> scheduler_trx.c:606 We were 1 FN slower than TRX, compensated <0006> scheduler_trx.c:428 FN timer expire_count=7: We missed 6 timers <0006> scheduler_trx.c:435 No more clock from transceiver Does anyone know if this is a software or hardware problem? I am thinking maybe it is related to the power supply of the USB port, but I have no idea. I really need to have both devices connected at the same time. Any help or suggestion is appreciated, Jonathan