[qubes-users] USB controllers

Hello all,

After standard installation using a PS2 keyboard, I should have two separate usb controllers in the same sys-usb qube. I would prefer to have two distinct sys-usb so using one more secure for the mouse (PS2 mouse does not work) that should be somehow connected to dom0 and the other less secure for external USB disks.

i carefully examined the Qubes papers

https://www.qubes-os.org/doc/usb-qubes/#enable-a-usb-keyboard-for-login
but I am still very confused.
Which is the proper way to do that?
Best Franz

You can simply qvm-clone the existing sys-usb, and then fix up the
controller allocation between the two.
You can also set autostart with qvm-prefs for the "less secure" so that
it is not started by default. This will mean that you have to
consciously start that usb qube if you want to use external devices.
You might also consider using udev rules, or blacklisting modules in the
"mouse" usb, so that it cannot be used with other USB devices.

The idea to clone sys-usb is brilliant and seems easy, Unman. I will try to do that. Many thanks

So, I did the cloning, but without a mouse I am unable to detach the relevant US usb controller from the second sys-usb, using Qubes Manager because the keyboard seems unable to move it from Selected to Available.

So followed the CLI instructions https://www.qubes-os.org/doc/pci-devices/
qvm-pci gives the address of the usbcontroller to be detached dom0:00_.14.5 and tells the following:
sys-2usb (no-strict-rest=True), sys-usb (no-strict-reset=true)

Because the linked Qubes instructions apparently only teach how to attach, but not how to detach, I tried the following:
qvm-pci attach sys-usb dom0:00_14.5
but it replies: device dom0:00_14.5 of class pci already attached to sys-usb
and nothing is done.

So, I do not know how to go on. I would need a command to detach dom0:00_14.5 from sys-2usb without attaching it elsewhere.

Best.

– You received this message because you are subscribed to the Google Groups “qubes-users” group. To unsubscribe from this group and stop receiving emails from it, send an email to . To view this discussion on the web visit .

Many thanks it worked perfectly

take a look to the qvm-pci man page, it explains how to detach.

Many thanks it worked perfectly

It worked perfectly for a week or so, then the mouse stopped working. Thomas at Vikings, who built the D8 computer with preinstalled coreboot, says it should be a Qubes issue.

How may I tell if it is a Qubes issue or a hardware issue?
best

You aren't clear on what is happened here, because you haven't provided
sufficient detail..
Do you mean that you allocated a USB controller to a sys-usb, to use
with the mouse. After a week, the mouse stopped working.
When both controllers were attached to a single usb-qube the mouse
worked without interruption.
Is that the position?

Did the other USB qube continue to work?
If you type lsusb in the "mouse"-usb do you see the mouse attached?
If you attach another usb device, does lsusb and dmesg show the device
being attached?
If you attach the mouse to the *other* usb qube, does it appear there?
If you revert to a single usb qube, does the mouse work for more than a
week there?
If you move the mouse to the other controller, does the mouse work for
more than a week?

Let's think about this.
Many Qubes users will be using coreboot.
Many Qubes users will be using more than one usb qube.
Many Qubes users use a usb mouse for more than one week without
incident.
What is different about you? Coreboot, Your hardware.
I am not saying that your hardware is at fault - it's just that the most
likely source is *your configuration and hardware in Qubes*.

Of course, if Vikings can point to other users with your hardware and
coreboot build who use Qubes without a problem, that would help too.

I would prepare another usb mouse, that can work with the other usb
qube. Use your mouse-usb qube until it "breaks". Plug the mouse in to
the other usb qube, and start looking at the "broken" usb qube.
Look in logs, for any events that might be associated with the loss of
mouse. Remove and reinsert the broken mouse to see how it is handled.
Remove and reinsert other usb devices to see how they are handled.
journalctl, dmesg are your friends, as well as basic troubleshooting.
(Another mouse, use the other controller, etc)

1 Like

take a look to the qvm-pci man page, it explains how to detach.

Many thanks it worked perfectly

It worked perfectly for a week or so, then the mouse stopped working.
Thomas at Vikings, who built the D8 computer with preinstalled coreboot,
says it should be a Qubes issue.

How may I tell if it is a Qubes issue or a hardware issue?
best

You aren’t clear on what is happened here, because you haven’t provided
sufficient detail…
Do you mean that you allocated a USB controller to a sys-usb, to use
with the mouse. After a week, the mouse stopped working.
When both controllers were attached to a single usb-qube the mouse
worked without interruption.
Is that the position?

Yes, but it worked also when only one USB controller was allocated to the mouse qube.

Did the other USB qube continue to work?

yes it works, I am able to mount an external USB drive. Also lsusb works and shows the external USB drive

If you type lsusb in the “mouse”-usb do you see the mouse attached?

No, lsusb hangs, with no output
.

If you attach another usb device, does lsusb and dmesg show the device
being attached?

dmesg on mouse qube gives a lot of errors, even various red ones. But I am totally unable to understand if they are serious or related to the mouse issue.

If you attach the mouse to the other usb qube, does it appear there?

yes lsusb shows it there.

If you revert to a single usb qube, does the mouse work for more than a
week there?

I have not tried it yet, but I no longer have the original single USB qube, so I should reinstall Qubes from zero.

If you move the mouse to the other controller, does the mouse work for
more than a week?

I have not tried it yet, because I wanted to keep it separated. The controller allocated to the mouse qube is on the motherboard and administered by coreboot, but the controller allocated on the USB-key qube is on a PCI card and I know nothing about it. But I am quite sure it would work because lsusb works, mouse is recognized and disks are mounted.

Let’s think about this.
Many Qubes users will be using coreboot.
Many Qubes users will be using more than one usb qube.
Many Qubes users use a usb mouse for more than one week without
incident.
What is different about you? Coreboot, Your hardware.
I am not saying that your hardware is at fault - it’s just that the most
likely source is your configuration and hardware in Qubes.

Of course, if Vikings can point to other users with your hardware and
coreboot build who use Qubes without a problem, that would help too.

I asked but Thomas suggested asking the Qubes ML.

I would prepare another usb mouse, that can work with the other usb
qube. Use your mouse-usb qube until it “breaks”. Plug the mouse in to
the other usb qube, and start looking at the “broken” usb qube.
Look in logs, for any events that might be associated with the loss of
mouse. Remove and reinsert the broken mouse to see how it is handled.
Remove and reinsert other usb devices to see how they are handled.
journalctl, dmesg are your friends, as well as basic troubleshooting.
(Another mouse, use the other controller, etc)

I understand what you mean. Your suggestions are all well thought, very sound and give some hope. The weak point is my capacity to make use of the error messages of dmesg and journalctl.

Really I am a bit depressed about it. I spent $5000 on that computer ($2500 for the computer and 2500 for importation tax to South America) and also for some reason it is unable to reboot and also the fans go full speed all the time because coreboot is unable to administer it. It makes a terrible noise. Well years ago Taiidan on this ML said there is a way to administer the fans of D8 by buying some additional equipment, but nobody really knows what to buy and how to make it work.

So even basic things like mouse, reboot and noise are super complicated and time consuming. I wonder how it is that on the Qubes HCL this computer is marked as fully working.

But Unman really many thanks. Your effort to help and your brilliant expertise are obvious. At least now there is some hope. Before your intervention I was already contemplating using the computer as a $5000 bedside table, at least it has a nice black mirror door that can accomodate a book to read before sleeping.

Very sorry to hear of your problems.
Equally happy to help you (as far as I can) with resolving these issues,
so if you do want to keep working on this, let the list know how it
goes, and we will provide whatever help we can.

Hello all,

I abandoned the computer for a week or so, without doing anything, then, for some mysterious reason the mouse worked again. So I am profiting doing the tests Unman asked

Many thanks it worked perfectly

It worked perfectly for a week or so, then the mouse stopped working.
Thomas at Vikings, who built the D8 computer with preinstalled coreboot,
says it should be a Qubes issue.

How may I tell if it is a Qubes issue or a hardware issue?
best

You aren’t clear on what is happened here, because you haven’t provided
sufficient detail…
Do you mean that you allocated a USB controller to a sys-usb, to use
with the mouse. After a week, the mouse stopped working.
When both controllers were attached to a single usb-qube the mouse
worked without interruption.
Is that the position?

Yes, but it worked also when only one USB controller was allocated to the mouse qube.

Did the other USB qube continue to work?

yes it works, I am able to mount an external USB drive. Also lsusb works and shows the external USB drive

If you type lsusb in the “mouse”-usb do you see the mouse attached?

No, lsusb hangs, with no output

Now lsusb on mouse-usb gives the following output:

[user@sys-usb ~]$ lsusb
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 002: ID 046d:c408 Logitech, Inc. Marble Mouse (4-button)
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

So yes, I see the mouse attached

.

If you attach another usb device, does lsusb and dmesg show the device
being attached?

dmesg on mouse qube gives a lot of errors, even various red ones. But I am totally unable to understand if they are serious or related to the mouse issue.

Yes I see a usb key attached

dmesg and journalctl are enclosed as an html files with full colors

(Attachment dmesg.html is missing)

(Attachment journalctl.html is missing)

Other strange things happened:
To restore a backup I connected an external USB disk with the backup to the second USB qube and under the restore command I clicked on the external USB disk to mount it. When I did that, a black background message on the upper right part of the screen told me that the disk was removed, while, at the same time it was NOT removed at all because the triangle showed that the disk was mounted and the content of the external USB disk was shown. Using my old and trusted x230 for many years this never happened. So I suppose it is strange.

Also, the computer seems much slower than my old x230, which is strange being a new computer

If you want me to try commands and report results, just ask, I am very willing to do anything that may be helpful to solve these problems.
best

Hi Franz

Sorry for the radio silence. I'll dig in to the logs you provided in
the morning.
At this stage I would *seriously* be thinking of looking for a refund or
replacement - you simply shouldn't be having these issues with a new
computer, particularly if you had told them you would be running Qubes.

Is it possible for you to boot a live distro from USB and see if the
same issues exist?