[qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
On 6/13/19 11:06 PM, Jon deps wrote: On 6/13/19 8:55 PM, 'awokd' via qubes-users wrote: Jon deps: in my case turns out, I have an Intel i5 which apparently doesn't have multithreading, I did look around the UEFI anyway, and see no references to it sudo cat /boot/efi/EFI/qubes/xen.cfg has 4.19.43-1 smt=off on cold reboot I don't see the kernel vuln journal entry If your system doesn't even have multithreading, that warning on resume from suspend must be a bug and is safe for you to ignore. so I guess its as I suspected qubes isn't going to suspend well and may break various things ?? Yes, the threading warning is unrelated to the sys-usb suspend issues you were having. Did you try Daniel's suggestions up thread? well Daniel said -- This is a long-standing issue for some, resolved for some but not for others at different times. See https://github.com/QubesOS/qubes-issues/issues/4042 The situation has improved for me by getting kernel 4.19.43-1 from qubes-dom0-security-testing. You could try the new kernel. (But note that our problems might be a bit different, I never had a qrexec problem when restarting sys-usb after resume.) If you need to automate restarting of sys-usb because you can't avoid this problem, you can add commands in /usr/lib64/pm-utils/sleep.d/52qubes-pause-vms for suspend and resume, e.g., qvm-shutdown sys-usb and qvm-start sys-usb. You might need to qvm-kill sys-usb before suspend to get this to work reliably. -- but curiously, AFAIK per dom0 uname -a I am already using Linux dom0 4.19.43-1.pvops.qubes.x86_64 #1 SMP but I shouldn't be on security-testing otherwise I don't see much advantage to doing the 2nd paragraph and maybe potential for badthings so ... don't suppose it matter than my active kernel says #1 SMP but my i5-6500 doesn't have SMT ? if xen.cfg says smt=off maybe the UEFI is smart enough to not show me what my CPU doesn't have, as I saw no references to SMT multithreading at all ? this is a Z170 Asrock UEFI -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/efd35a89-138d-ced5-379b-5e2a4573b7f0%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
On Thu, 13 Jun 2019 19:28:38 + "'awokd' via qubes-users" wrote: > Mike Keehan: > > > There has been a thread on the Linux Kernel mailing list recently, > > discussing the need to re-enable the SMT chips during resume else > > something breaks, and then turn them off again. You may be one > > of the unlucky ones to heave this affecting your system. I'm not > > sure which new kernel the fix is in - may not be until 5.2 comes > > out. > > Did they happen to mention if disabling it in UEFI config works > around the problem? > I think the kernel issue was with hibernation and resume, not with suspend to memory and resume. So it is probably a different issue with the Qubes suspend/resume problems. I often have to restart the NetVM after suspend (even with the net modules on the blacklist), and occasionally the usbVM. Oddly enough, those two VMs sometimes don't work properly at boot time, but very rarely. Could be a race condition or something. Mike. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190614150608.40f27b93.mike%40keehan.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
On Thu, 13 Jun 2019 19:28:38 + "'awokd' via qubes-users" wrote: > Mike Keehan: > > > There has been a thread on the Linux Kernel mailing list recently, > > discussing the need to re-enable the SMT chips during resume else > > something breaks, and then turn them off again. You may be one > > of the unlucky ones to heave this affecting your system. I'm not > > sure which new kernel the fix is in - may not be until 5.2 comes > > out. > > Did they happen to mention if disabling it in UEFI config works > around the problem? > Disabling doesn't help. I'm not sure why it hasn't affected more systems than it has, it seems odd that it only appeared recently. Suspend/resume has always been a bit iffy on my laptops, so I don't use it much. I think all you can do is try whatever options are available to you and see if anything helps. Mike. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190614094226.241e90c5.mike%40keehan.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
On 6/13/19 8:55 PM, 'awokd' via qubes-users wrote: Jon deps: in my case turns out, I have an Intel i5 which apparently doesn't have multithreading, I did look around the UEFI anyway, and see no references to it sudo cat /boot/efi/EFI/qubes/xen.cfg has 4.19.43-1 smt=off on cold reboot I don't see the kernel vuln journal entry If your system doesn't even have multithreading, that warning on resume from suspend must be a bug and is safe for you to ignore. so I guess its as I suspected qubes isn't going to suspend well and may break various things ?? Yes, the threading warning is unrelated to the sys-usb suspend issues you were having. Did you try Daniel's suggestions up thread? well Daniel said -- This is a long-standing issue for some, resolved for some but not for others at different times. See https://github.com/QubesOS/qubes-issues/issues/4042 The situation has improved for me by getting kernel 4.19.43-1 from qubes-dom0-security-testing. You could try the new kernel. (But note that our problems might be a bit different, I never had a qrexec problem when restarting sys-usb after resume.) If you need to automate restarting of sys-usb because you can't avoid this problem, you can add commands in /usr/lib64/pm-utils/sleep.d/52qubes-pause-vms for suspend and resume, e.g., qvm-shutdown sys-usb and qvm-start sys-usb. You might need to qvm-kill sys-usb before suspend to get this to work reliably. -- but curiously, AFAIK per dom0 uname -a I am already using Linux dom0 4.19.43-1.pvops.qubes.x86_64 #1 SMP but I shouldn't be on security-testing otherwise I don't see much advantage to doing the 2nd paragraph and maybe potential for badthings so ... -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/898af278-785c-9be5-6e50-035c5142f26c%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
Jon deps: in my case turns out, I have an Intel i5 which apparently doesn't have multithreading, I did look around the UEFI anyway, and see no references to it sudo cat /boot/efi/EFI/qubes/xen.cfg has 4.19.43-1 smt=off on cold reboot I don't see the kernel vuln journal entry If your system doesn't even have multithreading, that warning on resume from suspend must be a bug and is safe for you to ignore. so I guess its as I suspected qubes isn't going to suspend well and may break various things ?? Yes, the threading warning is unrelated to the sys-usb suspend issues you were having. Did you try Daniel's suggestions up thread? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/45dae97c-b8ea-dce6-1d62-e2dc83500975%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
On 6/13/19 7:14 AM, 'awokd' via qubes-users wrote: Jon deps: On 6/12/19 8:14 AM, Jon deps wrote: Jun 12 07:52:01 dom0 kernel: MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details. .any idea on the "data leak possible" journal entry? sounds a bit scary, maybe I need to look around in my UEFI to disable some cache-ing ? SMT should be off. Do you see that same message if you do a cold power on? Also, in "sudo cat /boot/efi/EFI/qubes/xen.cfg", do you see "smt=off" in the Xen options lines? I wonder if there is a Xen bug making SMT re-enable after a resume. Please check the above, then look in your UEFI options to disable Hyperthreading/SMT. in my case turns out, I have an Intel i5 which apparently doesn't have multithreading, I did look around the UEFI anyway, and see no references to it sudo cat /boot/efi/EFI/qubes/xen.cfg has 4.19.43-1 smt=off on cold reboot I don't see the kernel vuln journal entry so I guess its as I suspected qubes isn't going to suspend well and may break various things ?? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f9d75e67-730b-d3b0-11af-1e099b144fa7%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
Mike Keehan: There has been a thread on the Linux Kernel mailing list recently, discussing the need to re-enable the SMT chips during resume else something breaks, and then turn them off again. You may be one of the unlucky ones to heave this affecting your system. I'm not sure which new kernel the fix is in - may not be until 5.2 comes out. Did they happen to mention if disabling it in UEFI config works around the problem? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5048ace0-918f-b860-1b93-deabbd5b2bf9%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
On Thu, 13 Jun 2019 07:14:47 + "'awokd' via qubes-users" wrote: > Jon deps: > > On 6/12/19 8:14 AM, Jon deps wrote: > > >> Jun 12 07:52:01 dom0 kernel: MDS CPU bug present and SMT on, data > >> leak possible. See > >> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html > >> for more details. > > > > > .any idea on the "data leak possible" journal entry? > > > > sounds a bit scary, maybe I need to look around in my UEFI to > > disable some cache-ing ? > > SMT should be off. Do you see that same message if you do a cold > power on? Also, in "sudo cat /boot/efi/EFI/qubes/xen.cfg", do you see > "smt=off" in the Xen options lines? > > I wonder if there is a Xen bug making SMT re-enable after a resume. > Please check the above, then look in your UEFI options to disable > Hyperthreading/SMT. > There has been a thread on the Linux Kernel mailing list recently, discussing the need to re-enable the SMT chips during resume else something breaks, and then turn them off again. You may be one of the unlucky ones to heave this affecting your system. I'm not sure which new kernel the fix is in - may not be until 5.2 comes out. Mike. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190613153859.0ed532ef.mike%40keehan.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
Jon deps: On 6/12/19 8:14 AM, Jon deps wrote: Jun 12 07:52:01 dom0 kernel: MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details. .any idea on the "data leak possible" journal entry? sounds a bit scary, maybe I need to look around in my UEFI to disable some cache-ing ? SMT should be off. Do you see that same message if you do a cold power on? Also, in "sudo cat /boot/efi/EFI/qubes/xen.cfg", do you see "smt=off" in the Xen options lines? I wonder if there is a Xen bug making SMT re-enable after a resume. Please check the above, then look in your UEFI options to disable Hyperthreading/SMT. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9d32dbb4-ae44-19c7-e3ed-e22887f4125d%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
On 6/12/19 8:14 AM, Jon deps wrote: Hello, using the suspend function, when I awake the desktop, the usb mouse non longer functions. have a PS2 keyboard so was able to qvm-kill sys-usb and do qvm-start sys-usb but it complained couldn't connect to qrexec or so and failed. so qvm-start sys-usb a 2nd time and then the mouse functions again is this to be expected, or is there something to fix ? --- looking around journalctl I didn't find much but did find this un 12 07:52:01 dom0 kernel: sd 5:0:0:0: [sdb] Starting disk Jun 12 07:52:01 dom0 kernel: sd 1:0:0:0: [sda] Starting disk Jun 12 07:52:01 dom0 kernel: pcieport :00:1d.7: Intel SPT PCH root port ACS workaround enabled Jun 12 07:52:01 dom0 kernel: pcieport :00:1d.3: Intel SPT PCH root port ACS workaround enabled Jun 12 07:52:01 dom0 kernel: ACPI: Waking up from system sleep state S3 Jun 12 07:52:01 dom0 kernel: CPU3 is up Jun 12 07:52:01 dom0 kernel: cache: parent cpu3 should not be sleeping Jun 12 07:52:01 dom0 kernel: cpu 3 spinlock event irq 147 Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 3 Jun 12 07:52:01 dom0 kernel: CPU2 is up Jun 12 07:52:01 dom0 kernel: MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details. Jun 12 07:52:01 dom0 kernel: cache: parent cpu2 should not be sleeping Jun 12 07:52:01 dom0 kernel: cpu 2 spinlock event irq 140 Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 2 Jun 12 07:52:01 dom0 kernel: CPU1 is up Jun 12 07:52:01 dom0 kernel: cache: parent cpu1 should not be sleeping Jun 12 07:52:01 dom0 kernel: cpu 1 spinlock event irq 133 Jun 12 07:52:01 dom0 kernel: installing Xen timer for CPU 1 Jun 12 07:52:01 dom0 kernel: Enabling non-boot CPUs ... went to the URL says something like I should be "enable CPU buffer clearing" but can't find how to do that, curious if it's actual needed ? moral of the story don't suspend your qubes desktop ? .any idea on the "data leak possible"journal entry? sounds a bit scary, maybe I need to look around in my UEFI to disable some cache-ing ? BTW, kudos to qubes team for the dom0 copy to clipboard widget , sure makes it easier to get dom0 notes out ! -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/619dd1d0-45f6-e271-c4de-2eb2303a0a8c%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present
On Wednesday, June 12, 2019 at 2:29:12 PM UTC-4, Jon deps wrote: > Hello, using the suspend function, when I awake the desktop, the usb > mouse non longer functions. > > have a PS2 keyboard so was able to qvm-kill sys-usb and do qvm-start > sys-usb but it complained couldn't connect to qrexec or so and failed. > > so qvm-start sys-usb a 2nd time and then the mouse functions again This is a long-standing issue for some, resolved for some but not for others at different times. See https://github.com/QubesOS/qubes-issues/issues/4042 The situation has improved for me by getting kernel 4.19.43-1 from qubes-dom0-security-testing. You could try the new kernel. (But note that our problems might be a bit different, I never had a qrexec problem when restarting sys-usb after resume.) If you need to automate restarting of sys-usb because you can't avoid this problem, you can add commands in /usr/lib64/pm-utils/sleep.d/52qubes-pause-vms for suspend and resume, e.g., qvm-shutdown sys-usb and qvm-start sys-usb. You might need to qvm-kill sys-usb before suspend to get this to work reliably. Daniel -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9e6909ec-4055-416b-9db6-720f6c1363dd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
