TPCast: Still 10% CPU Load of virtualhere after quitting SteamVR 37% on the powerbox

Hi,

I just exited SteamVR and the Vive is now soft-off but the VH is sill connected.
Additional to that i am still having some ghost drivers, even I turn VH off before I unplug the battery.
the Powerbox has a hight load too, I add a link to a screenshot to the current situation.
We found a workaround with the camera so its enabled on the REV1-Vive.

[img]https://cloud.r-d-w.net/index.php/apps/files_sharing/ajax/publicpreview…]

#2

in the logs on the server I only see:

Jan 6 20:12:47 tpcast vhusbdtpcast[438]: Found Full speed device [28de:2101] "Valve Software, Watchman Dongle" at address 1126
Jan 6 20:12:47 tpcast vhusbdtpcast[438]: Found Full speed device [28de:2101] "Valve Software, Watchman Dongle" at address 1127
Jan 6 20:12:48 tpcast vhusbdtpcast[438]: Found Full speed device [28de:2000] "Valve Software, Lighthouse FPGA RX" at address 1121
Jan 6 20:12:48 tpcast kernel: [ 2541.861067] hid-generic 0003:0D8C:0012.002A: input,hidraw4: USB HID v1.00 Device [C-Media Electronics Inc. USB Audio Device] on usb-3f980000.usb-1.2.4/input3
Jan 6 20:12:48 tpcast vhusbdtpcast[438]: Found High speed device [0bb4:2c87] "Alpha Imaging Tech, HTC Vive" at address 1122
Jan 6 20:12:48 tpcast vhusbdtpcast[438]: Found Full speed device [0d8c:0012] "C-Media Electronics Inc., USB Audio Device" at address 1124
Jan 6 20:12:48 tpcast mtp-probe: checking bus 1, device 42: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2.4"
Jan 6 20:12:48 tpcast mtp-probe: bus: 1, device: 42 was not an MTP device
Jan 6 20:12:48 tpcast kernel: [ 2541.970422] usb 1-1.2.6: reset full-speed USB device number 38 using dwc_otg
Jan 6 20:12:48 tpcast vhusbdtpcast[438]: Device 1126 [28de:2101] BOUND to connection 7
Jan 6 20:12:48 tpcast kernel: [ 2542.200399] usb 1-1.2.7: reset full-speed USB device number 39 using dwc_otg
Jan 6 20:12:48 tpcast vhusbdtpcast[438]: Device 1127 [28de:2101] BOUND to connection 7
Jan 6 20:12:48 tpcast kernel: [ 2542.430383] usb 1-1.2.6: reset full-speed USB device number 38 using dwc_otg
Jan 6 20:12:48 tpcast kernel: [ 2542.660388] usb 1-1.2.1: reset full-speed USB device number 40 using dwc_otg
Jan 6 20:12:48 tpcast vhusbdtpcast[438]: Device 1121 [28de:2000] BOUND to connection 7
Jan 6 20:12:49 tpcast vhusbdtpcast[438]: Executed "" for onReset.0bb4.2c87
Jan 6 20:12:49 tpcast kernel: [ 2542.890443] usb 1-1.2.7: reset full-speed USB device number 39 using dwc_otg
Jan 6 20:12:49 tpcast vhusbdtpcast[438]: Device 1122 [0bb4:2c87] BOUND to connection 7
Jan 6 20:12:49 tpcast kernel: [ 2543.140414] usb 1-1.2.4: reset full-speed USB device number 42 using dwc_otg
Jan 6 20:12:49 tpcast vhusbdtpcast[438]: Device 1124 [0d8c:0012] BOUND to connection 7
Jan 6 20:12:49 tpcast kernel: [ 2543.380422] usb 1-1.2.1: reset full-speed USB device number 40 using dwc_otg
Jan 6 20:12:49 tpcast vhusbdtpcast[438]: Executed "" for onReset.0bb4.2c87
Jan 6 20:12:49 tpcast kernel: [ 2543.770428] usb 1-1.2.4: reset full-speed USB device number 42 using dwc_otg
Jan 6 20:18:58 tpcast vhusbdtpcast[438]: Executed "" for onReset.0bb4.2c87
Jan 6 20:19:11 tpcast vhusbdtpcast[438]: Executed "" for onReset.0bb4.2c87
Jan 6 20:20:02 tpcast vhusbdtpcast[438]: Executed "" for onReset.0bb4.2c87
Jan 6 20:20:04 tpcast vhusbdtpcast[438]: Executed "" for onReset.0bb4.2c87

strace on the server shoed nothing
and gdb only showed:

Attaching to process 438
[New LWP 439]
[New LWP 440]
[New LWP 441]
[New LWP 442]
[New LWP 443]
[New LWP 444]
[New LWP 445]
[New LWP 464]
[New LWP 465]
[New LWP 1323]
[New LWP 1324]
[New LWP 1325]
[New LWP 1326]
[New LWP 27136]
[New LWP 27137]
[New LWP 27138]
[New LWP 27189]
[New LWP 27190]
[New LWP 27191]
[New LWP 27192]
[New LWP 27193]
[New LWP 27194]
[New LWP 27196]
[New LWP 27197]
[New LWP 27198]
[New LWP 27201]
[New LWP 27202]
[New LWP 27203]
[New LWP 27204]
[New LWP 27205]
[New LWP 27206]
0x00245bbc in ?? ()

lsof shows:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
vhusbdtpc 438 root cwd DIR 179,2 4096 2 /
vhusbdtpc 438 root rtd DIR 179,2 4096 2 /
vhusbdtpc 438 root txt REG 179,2 644925 6657 /usr/sbin/vhusbdtpcast
vhusbdtpc 438 root 0r CHR 1,3 0t0 1028 /dev/null
vhusbdtpc 438 root 1w CHR 1,3 0t0 1028 /dev/null
vhusbdtpc 438 root 2u CHR 1,3 0t0 1028 /dev/null
vhusbdtpc 438 root 3u unix 0xb66ad500 0t0 10299 type=DGRAM
vhusbdtpc 438 root 4u IPv4 10302 0t0 TCP *:7575 (LISTEN)
vhusbdtpc 438 root 5u IPv4 10610 0t0 UDP *:35997
vhusbdtpc 438 root 6u IPv4 10614 0t0 UDP *:mdns
vhusbdtpc 438 root 7u netlink 0t0 10615 ROUTE
vhusbdtpc 438 root 8u IPv4 31437 0t0 TCP 192.168.1.90:7575->192.168.1.3:60257 (ESTABLISHED)
vhusbdtpc 438 root 9u netlink 0t0 10308 ROUTE
vhusbdtpc 438 root 11w CHR 189,43 0t0 31328 /dev/bus/usb/001/044
vhusbdtpc 438 root 12w CHR 189,42 0t0 31327 /dev/bus/usb/001/043
vhusbdtpc 438 root 13w CHR 189,44 0t0 31344 /dev/bus/usb/001/045
vhusbdtpc 438 root 14w CHR 189,42 0t0 31327 /dev/bus/usb/001/043
vhusbdtpc 438 root 15w CHR 189,45 0t0 31351 /dev/bus/usb/001/046
vhusbdtpc 438 root 16w CHR 189,42 0t0 31327 /dev/bus/usb/001/043
vhusbdtpc 438 root 17w CHR 189,46 0t0 31361 /dev/bus/usb/001/047
vhusbdtpc 438 root 18w CHR 189,42 0t0 31327 /dev/bus/usb/001/043
vhusbdtpc 438 root 19w CHR 189,47 0t0 31377 /dev/bus/usb/001/048
vhusbdtpc 438 root 20u netlink 0t0 12379 KOBJECT_UEVENT
vhusbdtpc 438 root 21u netlink 0t0 12380 ROUTE
vhusbdtpc 438 root 22w CHR 189,42 0t0 31327 /dev/bus/usb/001/043
vhusbdtpc 438 root 23w CHR 189,48 0t0 31407 /dev/bus/usb/001/049
vhusbdtpc 438 root 24w CHR 189,42 0t0 31327 /dev/bus/usb/001/043

#3

Thanks devzero, yes probably the ghost mic issue is the cause of this, I'm on holiday but when I'm back I'll buy a vive to test with, the one I made an offer on a few days ago got sold

#6

devzero, is your a rev2 or a rev1? (im having trouble finding a rev1 so i might just buy a new rev2)

#8

Hi DevZero, actually testing with my vive1 connected, it sits on about 6-10% cpu usage as well.

Looking at the messages being transmitted, it shows that the "Lighthouse FPGA RX" is being used by windows even if steamvr is not running.

That is why it is using some CPU even when you arent running a game. The Lighthouse FPGA RX might be listening for movement or something of the controls.

Basically its normal behaviour.