Re: [qubes-users] HCL - Gigabyte B650E Aorus Master - AMD Ryzen 9 7950X
On Thu, 2023-08-10 at 21:36 +, 51li...@ileg.al wrote: > Its interesting, since my amd legion is testing machine, i never use > sys-usb, and yeah i found that usb passthrough lead system to reboot. > can you provide a more detail about step by step what have you done ? > At install time untick the 'sysusb' creation, and then create sysusb by hand and attach just 1 USB controller at a time (following the instructions here https://www.qubes-os.org/doc/usb-qubes/#how-to-create-a-usb-qube-for-use-with-a-usb-keyboard) Another way to find out which device is causing the system to poweroff is to use any other VM (e.g. 'personal'), change it to HVM, and go to the devices tab in settings and try passing through one controller at a time, and make a note which one worked and which one didn't. If it works, power off the VM, remove the device from it and try the other ones in turn. If the machine gets instantly powered off instead then make a note about the broken device. I'll write some step-by-step examples once I got it working a bit more reliably, but for now the next device that is misbehaving sometimes is the network card: 0e:00.0 Network controller: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter Sometimes it just keeps printing messages that it is waiting after FLR, and the boot doesn't actually finish (or maybe I didn't wait long enough, I gave up after half a minute after it has printed a few retry messages about FLR). Other times it works reliably (it seems to misbehave if I boot into Qubes directly after the machine has been powered off, but seems to work if I first boot into native Fedora and then reboot into Qubes). Best regards, --Edwin -- 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/bc0382033f36b0bc7ed70d6cd3bc17cb7d6383de.camel%40etorok.net.
Re: [qubes-users] HCL - Gigabyte B650E Aorus Master - AMD Ryzen 9 7950X
Its interesting, since my amd legion is testing machine, i never use sys-usb, and yeah i found that usb passthrough lead system to reboot. can you provide a more detail about step by step what have you done ? Thanks -- 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/3b6782cde8516de9106ad8062fca81c8%40ileg.al.
Re: [qubes-users] HCL - Gigabyte B650E Aorus Master - AMD Ryzen 9 7950X
Edwin, your findings are interesting, but hard to follow, because you didn't write which devices are connected to which USB port; or did I miss it? Kind regards, Ulrich -- 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/64c73a47-595c-43fe-8240-52ff08fa4313%40gmail.com.
Re: [qubes-users] HCL - Gigabyte B650E Aorus Master - AMD Ryzen 9 7950X
On Wed, 2023-08-09 at 20:53 +0100, Edwin Török wrote: > On Mon, 2023-08-07 at 21:45 +0100, 'Edwin Török' via qubes-users > wrote: > > > > Must NOT use a USB qube. Using a USB qube results in an > > instant > > host reboot as soon as the USB qube is booted (same issue happen on > > KVM > > when attempting to pass through any USB controller, even if the > > controller is in an IOMMU group of its own). There is a newer BIOS > > with > > newer AGESA available, I'll have to retry using that. Using > > permissive > > mode or non-strict PCI reset doesn't help: > > New BIOS doesn't help, but I found one source of the host reboot: bus > reset of the USB3 controller PCI device. > > /sys/bus/pci/devices/:13:00.0/reset_method has 'bus', > and its parent /sys/bus/pci/devices/:00:08.3/reset_method has > 'pm'. > No FLR on these (which is confirmed by 'lspci' it says FLReset-). > > Changing 'bus' to 'pm', and performing an unbind from > /sys/bus/pci/drivers/xhci_hcd, and then echoing '1' to 'reset' seems > to > survive and it no longer causes the system to power off. > (now I don't know whether the problem is with reseting the device, or > resetting the parent's secondary bus, IIUC even if parent device's > reset method is pm, secondary bus will still be reset if that is what > the child does). > > Note that all the other USB controller's reset_method is already > 'pm'. > > All but one USB controller is in D3hot (which is expected), the other > is D0. Is a bus reset of a device in D3hot even valid? I tried plugging a USB device in the controller so it went to D0 and changes reset method to pm on its own, but that didn't help. However I found out that I *can* pass-through 2/4 USB controllers, these ones are safe to pass through: ``` +-02.1-[06-10]00.0-[07-10]--+-00.0-[08]-- | +-0c.0-[0f]00.0 Advanced Micro Devices, Inc. [AMD] Device [1022:43f7] +-08.1-[12]--+-00.0 Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] |+-00.3 Advanced Micro Devices, Inc. [AMD] Device [1022:15b6] ``` These ones are NOT safe to pass through, they result in instant power off of the host, followed by a poweron couple of seconds later: ``` +-08.1-[12]--+-00.0 Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] |+-00.4 Advanced Micro Devices, Inc. [AMD] Device [1022:15b7] +-08.3-[13]00.0 Advanced Micro Devices, Inc. [AMD] Device [1022:15b8] ``` This is very weird because 12.03 and 12.04 are quite similar from a topology point of view. I'm not sure what Qubes could do to detect or avoid this situation, but perhaps just hiding the USB controllers that are in D3hot instead of passing them through is the safer option? But even that becomes unsafe if I plug a USB device into 12.04. Anyway I have a workaround now to at least pass some of my USB devices through, and I have my Yubikey working in my 'vault' VM. Best regards, --Edwin > > Although changing the 'reset_method' still doesn't make device pass- > through work: attempting to pass it through still causes a host > reboot > (although more like a poweroff followed by a powerup than a warm > reboot, I tried disabling various options in the BIOS but it still > powers off directly, e.g. the PSP/SMU debug mode appeared promising > but > didn't help). > > Best regards, > --Edwin -- 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/f88f1793125271923f2b884139d3a336a608599b.camel%40etorok.net.
Re: [qubes-users] HCL - Gigabyte B650E Aorus Master - AMD Ryzen 9 7950X
On Mon, 2023-08-07 at 21:45 +0100, 'Edwin Török' via qubes-users wrote: > > Must NOT use a USB qube. Using a USB qube results in an instant > host reboot as soon as the USB qube is booted (same issue happen on > KVM > when attempting to pass through any USB controller, even if the > controller is in an IOMMU group of its own). There is a newer BIOS > with > newer AGESA available, I'll have to retry using that. Using > permissive > mode or non-strict PCI reset doesn't help: New BIOS doesn't help, but I found one source of the host reboot: bus reset of the USB3 controller PCI device. /sys/bus/pci/devices/:13:00.0/reset_method has 'bus', and its parent /sys/bus/pci/devices/:00:08.3/reset_method has 'pm'. No FLR on these (which is confirmed by 'lspci' it says FLReset-). Changing 'bus' to 'pm', and performing an unbind from /sys/bus/pci/drivers/xhci_hcd, and then echoing '1' to 'reset' seems to survive and it no longer causes the system to power off. (now I don't know whether the problem is with reseting the device, or resetting the parent's secondary bus, IIUC even if parent device's reset method is pm, secondary bus will still be reset if that is what the child does). Note that all the other USB controller's reset_method is already 'pm'. All but one USB controller is in D3hot (which is expected), the other is D0. Is a bus reset of a device in D3hot even valid? Although changing the 'reset_method' still doesn't make device pass- through work: attempting to pass it through still causes a host reboot (although more like a poweroff followed by a powerup than a warm reboot, I tried disabling various options in the BIOS but it still powers off directly, e.g. the PSP/SMU debug mode appeared promising but didn't help). Best regards, --Edwin -- 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/f7cc0221505a19385893017a4d04800607e02802.camel%40etorok.net.
Re: [qubes-users] HCL - Gigabyte B650E Aorus Master - AMD Ryzen 9 7950X
Thank you Edwin for your HCL report, which is online now: https://www.qubes-os.org/hcl/#gigabyte_b650e-aorus-master_ryzen-9-7950x_integrated-graphics-amd-radeon-rx-navi-10_edwin-t%C3%B6r%C3%B6k_4-2-0-alpha /Sven -- https://keys.openpgp.org/vks/v1/by-fingerprint/DA5975C9ABC40C833B2F620B2A632C537D744BC7 -- 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/470aefb0-70b8-c58c-fb2c-d4fb9bb16e0c%40SvenSemmler.org.
