So the boot at 12:38 (the last one), was with mouse? I can see:
Nov 17 12:38:15 sys-usb kernel: hid-generic 0003:046D:C077.0002: input,hidraw1: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:06.0-2/input0
So it seems like it has detected it successfully, but i think that is the last boot. Did that work?
The two boots before, sys-usb cannot even find the controller usb-4-2.
well ok, your log confuses me, the first two boots do not have any mention of sys-usb at all. Does this qube even start if you have no mouse?
That was the log of sys-usb right?
So basically it must have booted. But somehow the sys-usb stuff is not working. Maybe in the dom0s journal is some stuff?
Boot 1: Mouse disconnected during boot. Mouse reconnected after login and works.
Boot2: Mouse connected during boot. Mouse not working.
Boot3 (Currently running): Mouse disconnected during boot. Mouse reconnected after login and works.
Wait a sec… sys-usb is disposable on this install. Crap, only the current one is visible.
Now I need to figure out how to get the log when the mouse isn’t working.
That explains a lot about the weirdness of the logs.
You could try to open a dom0 terminal and copy out the logs from the running disposable. A bit cumbersome, but certainly possible if you have a dom0-terminal shortcut.
Log4: boot with mouse → mouse not working
Log5: boot without mouse, then plugged in after login → mouse not working
Log6: boot with mouse → mouse working
Mouse light does not turn on when it doesn’t work.
Mouse light is on when it works.
Yes, it seems like your machine does not recognize the whole usb 4-2 controller sometimes.
But unfortunately i am not that into debugging USB stuff…
You tried giving it more RAM and disabled memory balancing, which is what i would suggest you should do, so i am pretty much out of ideas. Maybe there is something in the dom0 logs.
Not sure of which commit this corresponds from a coreboot perspective, would have to dig libreboot to find out if necessary…
A quick search didn’t provide direct bug report neither from coreboot nor libreboot for usb controller.
Logs from appvms (console logs, which includes dmesg report from qubes) are present, and rotated, under dom0’s /var/log/xen/console directory (from memory here).
You might want to provide clear logs from there, bringing them to qubes through qvm-copy-to-vm calls for working/non-working scenarios.
Insight is that coreboot is not initializing usb controllers properly/iommu is not setuped properly in firmware.
2016 firmware might be before cbmem was integrated into coreboot so that coreboot logs are reported to OS (to be figured out if debugging coreboot is needed).
The best place to discuss that might be on libreboot mailing list. From recent merge of osboot into libreboot, I expect more people to have interest into libreboot for their Qubes supported boards.
Some kind of behavior isolation might be needed here to make sure of the nature of the problem. We are actually talking about a pci passthrough of a usb controller into a HVM (sys-usb) so we are talking about iommu reliable support from firmware, ACPI enumaration from firmware and then Xen passthrough to sys-usb under qubes use case.
A good first step would be to confirm that booting for example Tails LiveCD results in the same 50% usb contoller discovery/usage rate? If its 100% success, then going into digging IOMMU issues and CPU version/ microcode applied versions and then digging into IOMMU issues might be helpful to resolve the issue. Goal here is to isolate causes.
Next steps:
expose failing/success logs from dom0 for sys-usb attempting to get that usb controller passethrough
confirmation that a normal (non-xen, no passthrough) is able to deal with usb controller 100%of the time.
Got curious and took your two log6 (working) and log4(not-working) for comparison.
Applied some filtering to not diff on timestamps with user@Insurgo:~$ meld <(grep pci ~/Downloads/log6.log | cut -b17- ) <(grep pci ~/Downloads/log4.log| cut -b17- )
To filter only pci related messages, and then cut everything before the 17th caracter.
With the following showing interesting behavior difference for pci controllers:
@Litter_Box Insurgo mention my speculation (concern). Not sure libreboot cause as kgpe-d16 forum hcl report use oem bios and appear similar. If you willing to continue troubleshoot I very much appreciate. Think this could benefit qubes community and in my opinion kcma-d8 underappreciated qubes desktop option. Either way thank you!
Might have been too technical here, but OHCI and EHCI is different. USB controller being detected as OHCI controller works, where when it is detected as EHCI it doesn’t, saying that the IRQ in question was never polled, and stating that a kernel option should be specified to make it polled manually, otherwise that IRQ is being deactivated, which seems to result into your mouse to go undetected. Makes sense?
@confused has a point. Kcma-d8 and kgpe-d16 being really similar, looking at HCL reports, with coreboot/libreboot tells us that they were functional with libreboot release. I do not see HCL reports with Asus firmware there. They were both reported with 2016 release of libreboot, either by Timothy or Vikings. The new HCL report is on a different version of Qubes as well, meaning its a whole different test case (Xen and kernel being different).
You might want to add irqpoll kernel option as suggested. But as of now, the reason why that USB controller is detected non consistently as OHCI/EHCI seems to be the visible cause of the behavior observed.
Adding more memory would doubtfully have any impact here, where this can change something for high throughput devices (camera and usb proxy, network drivers) on really tight HVMs having to keep cache to pass that data to other VMs.
I’m not sure if I understand the above statement. I quicly reviewed past HCL reports which are either reported by Timothy for a really old version of Qubes (kgpe-d16 on libreboot) or Vikings (libreboot). I haven’t read a HCL that was reporting using stock firmware? Maybe I missed it.
The external usb hub is still working great. I sometimes get two prompts to attach my mouse to dom0. If two prompts come up, it’s the second one that is real.
Have you tried upgrading to Qubes 4.2 yet? Your descriptions above sound just like my experience with the D16. However, since installing 4.2 my onboard USB never works for my mouse (I have to boot with it in the onboard USB and switch to a PCI USB card after boot to use my mouse). And any USB connections for powered devices cannot be shared outside of sys-usb.