December 20, 2019 9:13 PM, "Claudia" <claud...@disroot.org 
(mailto:claud...@disroot.org?to=%22Claudia%22%20<claud...@disroot.org>)> wrote:
December 20, 2019 6:05 PM, brendan.h...@gmail.com 
(mailto:brendan.h...@gmail.com) wrote:
On Friday, December 20, 2019 at 9:29:55 AM UTC-5, Claudia wrote:December 19, 
2019 12:13 AM, "Claudia" <clau...@disroot.org (javascript:false)> wrote:

        > This is R4.1 build 20191013
>
> It works pretty well, definitely better than 4.0, but there are some weird 
> boot issues. If I let it
> boot with everything as default, it will boot loop before reaching the disk 
> password screen. I
...Looks like rd.qubes.hide_all_usb is what's causing it to crash. When I 
remove it, it boots fine with the graphical splash and passphrase prompt. 
Another AMD Ryzen user mentioned having the same problem a while back. 
Something about AMD's IOMMU grouping of USB controllers, or something.

Unfortunately, (my understanding is) that exposes the dom0 to the USB ports. 
Even if you have a sys-usb, dom0 is still exposed temporarily on boot.
Thanks for the tip. I actually thought removing that parameter just simply 
disabled USB Qube functionality and attached all devices to dom0, but I guess 
that's only when sys-usb is not running. Once sys-usb is running, it takes over 
the USB controllers from dom0, I guess. It's just that they're exposed before 
sys-usb starts, in that case.

It would be nice to have working, but I've never had a USB Qube before, even on 
my old machine, so I haven't lost anything. I don't use a lot of USB devices, 
and it's not a big part of my threat model. I'll play around with it when I 
have a chance.
I realized I had disabled autostart for all VMs including sys-usb to speed up 
boot time (systemctl disable sys-{net,usb,firewall,whonix}@qubesvm.se 
(mailto:whonix...@qubesvm.se)rvice), and I hadn't actually run sys-usb at all 
since then. I decided to start sys-usb while the system was running, and 
everything went to hell: the screen froze, audio stopped, even the caps lock 
light wouldn't come on.

So this isn't limited to hide_all_usb, just USB controller passthru in general 
on this machine.

So I reinstalled 4.0.2-rc3, once again, this time without USB Qube, and 
everything works (except suspend/resume which doesn't work anywhere except 
Fedora 30, not even F29 iirc), including audio and amdgpu without nomodeset. 
All this time I was blaming it on the old-ness of 4.0, but it was hide_all_usb 
all along. The only reason I tried getting rid of hide_all_usb in 4.1 is 
because the nomodeset trick didn't work in 4.1 so I had to continue 
troubleshooting, whereas in 4.0 it worked and I moved on. And also grub makes 
it way more convenient to modify boot options.

So in summary, for 4.0 and 4.1 alike, everything works except suspend/resume, 
as long as you don't set up a USB Qube. I attached updated HCL reports to 
reflect this, and will update them as I do more testing.

I'm going to try and figure out some of this IOMMU grouping stuff and start 
another thread about this issue. But like I said, I never had a USB Qube 
before, so I'm not going to miss it.

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bbffffdf183debac9338e0f46d32bbcb%40disroot.org.

Attachment: Qubes-HCL-Dell_Inc_-Inspiron_5575-20191220-220355.yml
Description: Binary data

Attachment: Qubes-HCL-Dell_Inc_-Inspiron_5575-20191221-021654.yml
Description: Binary data

Reply via email to