USB Keyboard & Mouse Intermittent v4.0rc3

[Ray Joseph]

The last 3 successful boots took 10 tries.
This is a Toshiba laptop (satellite). It has run Windows 8 & 10. Debian 8 & 9, Qubes-OS v3.2, v4.0 rc1. v4.0 rc two also had intermittent keyboard support. v4.0rc3 is a little more predictable, 2 out of 3 failed boots.

Reading forum messages, suggests this might be some kind of race on who gets control of the USB controller first. I looked in /etc/qubes-rpc/policy/InputKeyboard and it contains:
$anyvm $anyvm deny

OK, maybe that is not valuable.

One message said that the USB keyboard and mouse could be hidden during boot so it would be available for dom0. In order to do that, it seems I should open a terminal in USBvm and see what ports are there and what is connected. So I clicked on applications, scrolled down to USBvm | terminal and selected it. Nothing happened.

I opened xl top to see all vms. dom0 was there and the net family but they were all blocked probably because my network is down; I don't have my AP with me. So I went back and tried to start USBvm. It shows up in xl top as paused. After about 1 min, it disappear. So I closed all vms and tried to start USBvm. I got the same result.

I can't tell what is going on.

What might be stopping USBvm from running?

When it is running, I believe I can use lsusb to see what is connected. So I can plug USB sticks into the available ports to see what the system calls those ports. I expect that what is left over is the keyboard and mouse internal ports.

I would appreciate any information the help correct my understanding and solution method.

Ray

[Yethal]

It's possible that USBVM does not start due to disabled VT-d or pci strictreset set to true. Check xl dmesg for info on VT-d and qvm-prefs for info on pci strictreset

[Ray Joseph]

Yethal,

Thank you for your efforts.

I did not discover anything down this path. Further, when I booted today, the keyboard and mouse came up immediately. I also had my access point running and it was logged into during the boot. Although previously, with the AP available at boot, sometimes it came up without the keyboard and mouse. I am stating this as I had problems with a Debian correctly booting with out a wireless connection.

More directly to your suggestions, here are the transaction I performed:
OK, I don't know how to paste from dom0 to this fedora disposable vm.

I did a
sudo xl dmesg | grep VT
for VT-d
It displays supported pages sizes for iommu 0
It displays supported pages sizes for iommu 1
Snoop control not enabled.
dom0 dma passthrough not enabled
queued invalidation enabled
interrupt remapping enabled
shared ept tables enabled
"Its risky to assign' address 'with shared rmrr at" address for Dom1.

xl dmesg for strict displayed
(XEN) - Unrestricted Guest

xl dmesg for pci did not produce anything
xl dmesg for usb did not produce anything

I checked all the above just after booting into the system.

I then started up USBvm from the application menu while having
xl top
running.

As before, it showed paused for about a minute and then disappeared. I ran the above queries again and obtained the same results.

Any suggestions?

[Yethal]

the rmrr message suggests that your usb controllers do not support flr so run "qvm-prefs -s sys-usb pci_strictreset false" reboot the usbvm and it should work.

[Ray Joseph]

When I execute "qvm-prefs -s sys-usb pci_strictreset false",
the system responds with "no such property: 'pci_strictreset' "

I can query:
qvm-prefs -g sys-usb
and get a long list of properties. 'pci_strictreset' is not one of them, but I am guessing it can be added with the set (-s) command.

Please suggest what I may be doing wrong.

BTW, the FAQ list the syntax to be:
qvm-prefs sys-sub -g
but this produces the response
unrecognized arguments: pci_strictreset false

Actually, the FAQ states the syntax
qvm-prefs usbVM -s pci_strictreset false
but this produces the same result as above.

[Foppe de Haan]

qvm-pci attach --persistent -o no-strict-reset=True sys-usb dom0:00_12.3

[Ray Joseph]

Foppe,

Thank you for the command.

With out executing it, I ran
qvm-pci
which produced
dom0:00_14.0 USB controller: ... - LP USB xHCI Controller sys-usb (no-strict-reset=True)
dom0:00_1c.5 USB controller: ... - LP USB xHCI Controller sys-usb (no-strict-reset=True)

I searched for 'attach' and '-persistent' and did not find any descriptions that helped me understand the total functionality of the command.

Please help me understand how -persistent impacts this. Additionally, what does the -o do?

[Ray Joseph]

Correct to the above: EHCI not xHCI

qvm-pci
which produced
dom0:00_14.0 USB controller: ... - LP USB xHCI Controller sys-usb (no-strict-reset=True)

dom0:00_1d.0 USB controller: ... - LP USB EHCI Controller sys-usb (no-strict-reset=True)

Further -
I initiated a qvm-start for sys-usb which produced:
xl top
showed sys-usb as paused for about 60 seconds, then it disappeared from the display.
The CLI returned:
Start failed: internal error: Unable to reset PCI device 0000:00:14.0: internal error: libxenlight failed to create new domain 'sys-usb'

When I execute:
qvm-pci attach --persistent -o no-strict-reset=True sys-usb dom0:00_14.0
an error is produced:
"'device dom0:00_14.0 of class pci already attached to sys-usb'"

Since I don't know if this means the attachment is persistent (it was repeatable after a reboot), I attempted to detached
qvm-pci detach sys-usb dom0:00_14.0
qvm-pci detach sys-usb dom0:00_1d.0

Using qvm-pci list, both were gone, no longer listed.
So I again performed the attachment as above.
Both instances are back in. I do not see any difference from that display.

I started up sys-usb from CLI and received the same error about libxenlight failing.