Re: [qubes-users] R4 system requirements; AMD compatibility?

[Claudia]

brendan.h...@gmail.com:


On Friday, July 26, 2019 at 1:24:57 PM UTC-4, Claudia wrote:


Just to humor myself, I was going to try testing if I could hear sound
from Qubes after resume, but it seems audio isn't working at all. Which
is a whole 'nother problem. Aplay says "... unable to open slave; audio
open error: no such file or directory." `echo -e '\a'` doesn't work even
on a TTY (lsmod shows pcspkr), and `beep` isn't installed.



Notably, Xen does not pass the real PC speaker device to dom0 and while it
simulates it for dom0, it does not actually invoke the hardware. Something
something considered dangerous to expose adjacent-to-speaker hardware in
dom0, apparently.

So terminal beeps, etc. do nothing (except maybe flash the terminal window,
depending on your config).

I use a snippet I got from google:
function create_beep () {
 # create our beep file as xen does not expose the real "bell" device w/i
n the Qubes configuration and a simple echo "\007" does not work.
 > /tmp/sinewave.wav
 printf "\x52\x49\x46\x46\x64\x1F\x00\x00\x57\x41\x56\x45\x66\x6D\x74\x20
\x10\x00\x00\x00\x01\x00\x01\x00\x40\x1F\x00\x00\x40\x1F\x00\x00\x01\x00\x08\x00
\x64\x61\x74\x61\x40\x1F\x00\x00" >> /tmp/sinewave.wav
 for n in {0..999}
 do
 printf "\x80\x26\x00\x26\x7F\xD9\xFF\xD9" >> /tmp/sinewave.wav
 done
}

And then invoke the following when I need a beep (probably should be made a
function) in scripts dom0:

   aplay -q /tmp/sinewave.wav --duration=1
  
Brendan




The OS comes with some default wave files. It's just that aplay doesn't 
seem to be able to play anything. It detects the audio devices 
correctly, but it errors out when I try to play something. That's why I 
was trying the console bell, as I thought it might use a different 
(simpler) interface or something. Thanks for the info about Xen. I don't 
suppose there's a flag or something to tell Xen to actually invoke the 
hardware?


Not a top priority at the moment, but some kind of audio could be 
helpful for debugging suspend.


-
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  


--
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/0df592c9-62fa-45e3-9623-4aaee0808d1f%40vfemail.net.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[brendan . hoar]

On Friday, July 26, 2019 at 1:24:57 PM UTC-4, Claudia wrote:

> Just to humor myself, I was going to try testing if I could hear sound 
> from Qubes after resume, but it seems audio isn't working at all. Which 
> is a whole 'nother problem. Aplay says "... unable to open slave; audio 
> open error: no such file or directory." `echo -e '\a'` doesn't work even 
> on a TTY (lsmod shows pcspkr), and `beep` isn't installed. 
>

Notably, Xen does not pass the real PC speaker device to dom0 and while it 
simulates it for dom0, it does not actually invoke the hardware. Something 
something considered dangerous to expose adjacent-to-speaker hardware in 
dom0, apparently.

So terminal beeps, etc. do nothing (except maybe flash the terminal window, 
depending on your config).

I use a snippet I got from google:
function create_beep () {
# create our beep file as xen does not expose the real "bell" device w/i
n the Qubes configuration and a simple echo "\007" does not work.
> /tmp/sinewave.wav
printf "\x52\x49\x46\x46\x64\x1F\x00\x00\x57\x41\x56\x45\x66\x6D\x74\x20
\x10\x00\x00\x00\x01\x00\x01\x00\x40\x1F\x00\x00\x40\x1F\x00\x00\x01\x00\x08\x00
\x64\x61\x74\x61\x40\x1F\x00\x00" >> /tmp/sinewave.wav
for n in {0..999}
do
printf "\x80\x26\x00\x26\x7F\xD9\xFF\xD9" >> /tmp/sinewave.wav
done
}

And then invoke the following when I need a beep (probably should be made a 
function) in scripts dom0: 

  aplay -q /tmp/sinewave.wav --duration=1
 
Brendan

-- 
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/cdc16c4b-a197-48e7-b9aa-6a487cd43383%40googlegroups.com.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Claudia]

Chris Laprise:

On 7/25/19 11:04 AM, brendan.h...@gmail.com wrote:
...there are very very early test-builds of Qubes R4.1 out there 
utilizing Xen 4.12 and Fedora 30. This 2019-07-01 build appears 
semi-stable in light testing. It is, at a high level (and Marek can 
correct me if I am wrong), the R4.01 codebase with up-to-date Xen and 
dom0 Fedora w/ any Qubes-related changes to ensure these work with the 
Qubes code base.


I was able to install that particular test build on a Thinkpad X230 
for testing: https://openqa.qubes-os.org/tests/3021


(note: click on assets tab for link to download the ISO)

It might be worth installing one of those as well on another drive to 
see if newer Xen/Fedora combinations resolve sleep issues or get you 
closer to resolution.


Interesting link!

I was just thinking this could be an "old Fedora" problem. But that also 
suggests there may be a way to patch the current dom0 to handle suspend 
correctly. Of course, domU is a factor if sys-net or sys-usb are running.


... But it works on Fedora 29 with 4.18, and not Qubes R4.0.1 with 4.19.

Is a Fedora 29 kernel 4.18 different than a Fedora 25 kernel 4.18? i.e. 
different branches/backports or something? Or could something besides 
the kernel be causing the difference in behavior?




Trying Fedora 25 with 4.8.6, just for good measure... This is 
interesting. At resume, the fan comes on but the screen doesn't power on 
(just as in Qubes), but this time, unlike in Qubes, pressing caps lock 
*does* turn on the light. Alt-SysRq-B doesn't do anything (it might be 
disabled), but incidentally, when I pressed Print Screen I heard a 
camera shutter sound effect, and Ctrl-Alt-Del powered it off after 60 
seconds. So, the OS is responsive after resume (unlike Qubes), just the 
screen is still powered off.


Also, instead of powering off the screen due to inactivity, it just 
turns it black instead, much like Qubes.


So it's almost starting to sound like it was a graphics driver issue or 
something that was fixed sometime between Fedora 25 and Fedora 29, but 
somehow still hasn't made it to Qubes. Still way too early to say, though.




Claudia:

Have you tried suspend/resume with no VMs running at all? This can be 
accomplished by manually shutting down appVMs then service VMs, or with 
the command 'qvm-shutdown --all --force --wait'.


Pretty sure I did, but re-tested to be certain. With all VMs stopped, 
resuming makes the fan come on, but the screen doesn't power on, and 
pressing the caps-lock key doesn't turn its light on. I have to 
long-press the power button and restart.


I could have sworn when I tested this before, resume wouldn't make the 
fan come on or anything at all. Although, it would be easy to mistake 
one for the other, because the fan isn't the most reliable output 
channel. From the time I tested Ubuntu onward, I started using 
`sha256sum /dev/urandom` to intentionally get the fan running before 
suspend. So it makes sense, in prior testing the fan probably just 
wasn't running loud enough to hear.


So, if that's the case, that means I'm getting the same result in normal 
Qubes as in Qubes with VT-x & VT-d disabled. This is good news, as means 
it's probably not some firmware-related virtualization problem, right?


Just to humor myself, I was going to try testing if I could hear sound 
from Qubes after resume, but it seems audio isn't working at all. Which 
is a whole 'nother problem. Aplay says "... unable to open slave; audio 
open error: no such file or directory." `echo -e '\a'` doesn't work even 
on a TTY (lsmod shows pcspkr), and `beep` isn't installed.


If this works, then the problem may be in the VMs such as sys-net or 
sys-usb. This is possible because those VMs control hardware that must 
also respond to special commands related to sleep/wake.


Makes sense, but unfortunately (or fortunately) I couldn't even get it 
to resume properly under Qubes even with VT-x & VT-d disabled.


If it doesn't work, then the problem is probably entirely in dom0 and 
Fedora 25. Assuming you already have the testing 4.19 kernel, have you 


Well, that's good news. At least, I'd rather the problem be in dom0 
kernel than in firmware! It also means it's probably not device-related, 
if I'm following correctly. But, there's still a chance it could be Xen, 
too, right?


I don't suppose it's possible to upgrade Qubes to Fedora 29, or so?

thought of upgrading it to the even newer 5.x one as 'latest'? The 
latest kernel is installed by specifying the special package named 
'kernel-latest'.




Installed 5.1.15-1. Hangs between Xen and dom0 kernel (blank screen with 
no underscore) about 50% of the time. Same result. Fan comes back on, 
but no caps lock light. Tried again with all VMs stopped. Same result.


So all this kind of makes me think
1) there are special kernel patches or something in Fedora and Ubuntu 
that aren't in Qubes, or

2) the issue is caused by something other than the kernel entirely, or
3) it's 

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Chris Laprise]

On 7/26/19 7:52 AM, brendan.h...@gmail.com wrote:



On Thursday, July 25, 2019 at 12:16:00 PM UTC-4, Chris Laprise wrote:

On 7/25/19 11:04 AM, brend...@gmail.com wrote:
 > I was able to install that particular test build on a Thinkpad
X230 for
 > testing: https://openqa.qubes-os.org/tests/3021

 >
 > (note: click on assets tab for link to download the ISO)

Interesting link!


As a side note, when you opened the ticket asking about back-porting 
"lvm-thin tools" to R4.01 (Fedora 25) for your backup tool work...I was 
wondering if you were aware that some of the (again, very very early 
test) builds of R4.1 were semi usable.


Not that we should have to wait to do fast, stable backups until R4.1... :)
Brendan


I wasn't aware, but there's no ETA for R4.1 anyway.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/aa4520d3-63d4-ee47-f417-57232b3ca610%40posteo.net.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[brendan . hoar]

On Thursday, July 25, 2019 at 12:16:00 PM UTC-4, Chris Laprise wrote:
>
> On 7/25/19 11:04 AM, brend...@gmail.com  wrote: 
> > I was able to install that particular test build on a Thinkpad X230 for 
> > testing: https://openqa.qubes-os.org/tests/3021 
> > 
> > (note: click on assets tab for link to download the ISO) 
>
> Interesting link! 
>

As a side note, when you opened the ticket asking about back-porting 
"lvm-thin tools" to R4.01 (Fedora 25) for your backup tool work...I was 
wondering if you were aware that some of the (again, very very early test) 
builds of R4.1 were semi usable. 

Not that we should have to wait to do fast, stable backups until R4.1... :)
 
Brendan

-- 
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/0f6a61b5-a5e4-4cc0-a5fa-ec1d55e80df9%40googlegroups.com.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Brendan Hoar]

On Thu, Jul 25, 2019 at 12:15 PM Chris Laprise  wrote:

> If it doesn't work, then the problem is probably entirely in dom0 and
> Fedora 25. Assuming you already have the testing 4.19 kernel, have you
> thought of upgrading it to the even newer 5.x one as 'latest'? The
> latest kernel is installed by specifying the special package named
> 'kernel-latest'.


qubes-dom0-update kernel-latest # will update available dom0 kernels list
and sets most recent as default

qubes-dom0-update kernel-latest-qubes-vm # will update available VM kernels
list and requires manual checking to see if it changed your global defaults
and/or changed a per-VM kernel setting when older ones are removed

I use both and generally pull from current + current-testing repos.
Currently running 5.1.17-1 in dom0 and a mix in VMs under R4.01.

B

-- 
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/CAOajFeeHFK_kngBYcPou%2BQLeqrg1Ef92j05_s7%3DGDUYXAE0iPw%40mail.gmail.com.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Chris Laprise]

On 7/25/19 11:04 AM, brendan.h...@gmail.com wrote:
...there are very very early test-builds of Qubes R4.1 out there 
utilizing Xen 4.12 and Fedora 30. This 2019-07-01 build appears 
semi-stable in light testing. It is, at a high level (and Marek can 
correct me if I am wrong), the R4.01 codebase with up-to-date Xen and 
dom0 Fedora w/ any Qubes-related changes to ensure these work with the 
Qubes code base.


I was able to install that particular test build on a Thinkpad X230 for 
testing: https://openqa.qubes-os.org/tests/3021


(note: click on assets tab for link to download the ISO)

It might be worth installing one of those as well on another drive to 
see if newer Xen/Fedora combinations resolve sleep issues or get you 
closer to resolution.


Interesting link!

I was just thinking this could be an "old Fedora" problem. But that also 
suggests there may be a way to patch the current dom0 to handle suspend 
correctly. Of course, domU is a factor if sys-net or sys-usb are running.


Claudia:

Have you tried suspend/resume with no VMs running at all? This can be 
accomplished by manually shutting down appVMs then service VMs, or with 
the command 'qvm-shutdown --all --force --wait'.


If this works, then the problem may be in the VMs such as sys-net or 
sys-usb. This is possible because those VMs control hardware that must 
also respond to special commands related to sleep/wake.


If it doesn't work, then the problem is probably entirely in dom0 and 
Fedora 25. Assuming you already have the testing 4.19 kernel, have you 
thought of upgrading it to the even newer 5.x one as 'latest'? The 
latest kernel is installed by specifying the special package named 
'kernel-latest'.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/02f1d4e0-f84c-d4b8-1f27-9924ab5a30bc%40posteo.net.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[brendan . hoar]

On Thursday, July 25, 2019 at 10:18:29 AM UTC-4, awokd wrote:
>
> > Are there any other Xen-based distros out there I could test? 
>
> You can add Xen to your stock Fedora install. That takes it roughly to 
> where Qubes begins, but you might want to use the same version of Fedora 
> dom0 uses. 
>
>
Claudia:

I'm sure the *last* thing you want to do is add additional variables, as 
things are easier to diagnose with fewer, but...

...there are very very early test-builds of Qubes R4.1 out there utilizing 
Xen 4.12 and Fedora 30. This 2019-07-01 build appears semi-stable in light 
testing. It is, at a high level (and Marek can correct me if I am wrong), 
the R4.01 codebase with up-to-date Xen and dom0 Fedora w/ any Qubes-related 
changes to ensure these work with the Qubes code base. 

I was able to install that particular test build on a Thinkpad X230 for 
testing: https://openqa.qubes-os.org/tests/3021

(note: click on assets tab for link to download the ISO)

It might be worth installing one of those as well on another drive to see 
if newer Xen/Fedora combinations resolve sleep issues or get you closer to 
resolution.

Brendan

-- 
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/141ed585-2869-485b-9716-33bb5b2a1c16%40googlegroups.com.

Re: [qubes-users] R4 system requirements; AMD compatibility?

['awokd' via qubes-users]

Claudia:

> This also really complicates the search process. It's not good enough to
> find a laptop that is known to suspend under Linux. It's a wonder
> *anyone* has working suspend in Qubes.

Unfortunately, this is true! Lots of things have to work together in
order for suspend to function. See
https://www.mail-archive.com/qubes-users@googlegroups.com/msg27682.html
for an example with my AMD laptop.

> Are there any other Xen-based distros out there I could test?

You can add Xen to your stock Fedora install. That takes it roughly to
where Qubes begins, but you might want to use the same version of Fedora
dom0 uses.

-- 
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/7bca61a9-e73b-5970-ef5a-43530343f602%40danwin1210.me.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Claudia]

Chris Laprise:

My experience is that consumer BIOS will result in poor suspend 
compatibility.


Not surprising :(  But there are indeed some Thinkpads, MSI, System76, 
Purism, and other high-end business-class machines on the HCL with 
suspend not working. So it's still a bit of crapshoot. Just don't want 
anyone thinking they're "safe" if they buy an expensive machine.





You should try these:

* Find which wifi modules are being used in sys-net (i.e. do "sudo 
lsmod") then add them to /rw/config/suspend-module-blacklist. I find 
this is usually required to get suspend working right. For an Intel wifi 
card, you would add both 'iwldvm' and 'iwlwifi' in that order.


I did that for ath, ath10k_pci, and ath10k_core in sys-usb. No dice. 
Would it help at all to try blacklisting them from dom0, just for 
testing purposes? Also: order matters?




* Upgrade the dom0 and vm kernels to 4.19 or later. The 4.19 versions 
from qubes*testing have been very stable for me. OTOH, there are also 
5.x versions available.




Upgraded to latest dom0-current-unstable, 4.19.something. Only thing 
this changed was that the boot process hangs between Xen and dom0 kernel 
about 50% of the time. Tried this and the above fix together. Where can 
I get these 5.x versions?


---

I also was able to upgrade the BIOS to 1.3.2 using Freedos. No dice.

BUT! I made a small breakthrough. It suspends and resumes flawlessly 
under Ubuntu and Fedora. This stands to reason, as according to Dell the 
machine officially supports Ubuntu. So it appears nothing is 
fundamentally broken here.


I did some testing to try and narrow it down and here's what I found so far:
Qubes R4 with 4.14 & 4.19 - doesn't work
Ubuntu 19.04 with 5.0.0 - works
Fedora 30 with 5.0.9 - works
Fedora 29 with 4.18.16 - works

Initially I was hoping the fix is already in ~5.0 mainline. But isn't 
the Qubes kernel based directly on the Fedora kernel? Why would it be 
working on an *older* Fedora kernel and not on a *newer* Qubes unstable 
kernel?


So what's the outlier here? Xen? IOMMU? XFCE? (test systems were all GNOME)

This part is interesting. I tried disabling VT-x and VT-d in BIOS and 
booting Qubes. It suspends as usual, except now, when I hit a key to 
resume it, the fan comes on (unlike before), and it sort of sounds like 
the disk spins up, but the display doesn't power back on. Also, the 
light on the caps lock key doesn't come on when I press it, and 
Alt-SysRq-B doesn't do anything in this state, even after enabling it 
beforehand. In other words it feels like it's trying, but won't fully 
resume.


So I guess this tells me that it's partly virtualization related 
(because it behaves slightly differently when virtualization is 
disabled) and partly not (because it behaves differently under Qubes 
with virtualization disabled than it does under Fedora). Maybe it's a 
Xen issue, regardless of virtualization enabled/disabled?


This also really complicates the search process. It's not good enough to 
find a laptop that is known to suspend under Linux. It's a wonder 
*anyone* has working suspend in Qubes.


Note I'm assuming it's a kernel-related issue, but I guess it could be 
something else entirely -- power management utility, udev, xfce, who 
knows what.


Point is, if it's just a version issue, I can deal without suspend for a 
while until the fix makes it to Qubes. But if it's some deeply-rooted 
virtualization issue, I sort of doubt it'll ever be fixed, whether in 
kernel or in BIOS.


Are there any other Xen-based distros out there I could test?

I know it's a lot of guesswork, but I value your advice.

-
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  


--
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/0379edd3-ebbe-ef01-27f3-42ff066f50ab%40vfemail.net.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[panina]

A lot of this sounds like my issues, so I thought I'd give my side. I
run an AMD thinkpad A485 with ryzen 2500u pro. Not what I'd call a
low-end laptop, but the issues are mostly the same.

On 7/22/19 11:09 PM, Claudia wrote:
> Claudia:
>> Chris Laprise:
>>> On 7/22/19 11:38 AM, Claudia wrote:
 So I finally got around to doing this.

 Qubes works and all the basic features are supported, VT-x VT-d, and
 so on, as far as I can tell.

 One major issue, hardware/firmware-wise:

 1) It doesn't come back from suspend. The fan stops, but there are
 no blinking lights (actually, no lights besides AC and caps lock),
 and nothing I do wakes it. I have to long-press the power button,
 then press again to turn on the machine. It's probably an ACPI
 issue, probably not a graphics driver issue as there's no dGPU. I
 played around with acpi_osi= and some basic troubleshooting but the
 odds of me being able to fix it are slim to none.
>>>
>>> This is good to hear!
>>

I've got the same issue on my thinkpad. It seems to suspend fine, but
when I try to wake it, only the fan and keyboard backlight turns on.
Nothing else. It seems, however, that when I hard reset it, it seems to
think it's resuming from suspend. Not sure if that's a clue.

I did try fedora on this machine though, and it had the same issues
there, so it doesn't look qubes-specific, at least for me.

>>>

 Minor issues:

 2) Buggy BIOS / ACPI impl. Dom0 kernel dmesg complains about
 "[Firmware bug]" and ACPI issues. Though no noticeable problems
 except suspend. The firmware's OS-less update-from-USB-drive feature
 seems broken, I tried several times. Still might be able to update
 from fwupd, though. No UI for managing secure boot keys, etc., it
 seems to only have the bare minimum options.

 So, it appears you were totally right about consumer-grade laptops
 and buggy firmware. But suspend/resume is problematic even among
 high-end/business-class laptops, too, isn't it? It's just something
 Linux has never been good at.

I think I have the same issue, I get ACPI errors, one for each CPU
kernel. So I'd say this is not a "cheap laptop" issue, mine is
mid-range, branded towards IT security staff.

>>>
>>> TBH, I haven't had long-term problems with suspend on Thinkpads
>>> _except_ when anti-evil-maid is enabled; that combo hasn't worked for
>>> about 2 years.
>>>
>>> My experience is that consumer BIOS will result in poor suspend
>>> compatibility.
>>
>> Not what I wanted to hear of course, but it does seem that way. I
>> can't say you didn't warn me. But that's the *only* firmware/hardware
>> issue I've run into so far. I feel like I'm so close!
>>
>>>

 3) USB qube isn't working. I installed with USB qube, and the
 microphone shows up fine. But flash drives and the card reader don't
 show up. When I plug in a USB drive, its LED blinks on for a
 fraction of a second, then turns off (on other machines it stays
 on). No sign of it in lsusb or lsblk in either sys-usb or dom0.

 However, when I remove the qubes.rd.hide_all_usb kernel flag, it
 works normally, so I think this is just a software issue.
>>>
>>> This could have to do with how the USB controllers respond to the
>>> steps involved in placing it under IOMMU passthrough. I think without
>>> hide_all_usb set, they get reset twice (once in dom0 and once in
>>> sys-usb)?
>>
>> As long as it's not strictly firmware/hardware-related, I'll worry
>> about it later and start another thread for it. If I have to get rid
>> of the USB qube or something it's not that big of a deal.

Same issue for me here as well. Mine looks to me to be
IOMMU-group-related. I believe that something in the usbs' IOMMU group
is connected to amdgpu. If I boot with rd.qubes.hide_all_usb, I have to
have nomodeset. It looks like a collision with something in the graphics
driver, think I saw somehting floating past the screen during one crash.
Sadly have no record.

>>
>>>

 4) Screen power management (turn off display) doesn't work, although
 I had the same problem with a machine where suspend does work, and I
 think I narrowed it down to a fedora/X11 issue. The display does
 turn off when the lid is closed and lid-switch is set to "do
 nothing," though.
>>>
>>> I usually have to switch to KDE with sddm to get this working.
>>
>> I think I had it working temporarily on my current machine by directly
>> using X11 commands, it was just XFCE not using them correctly or
>> something. It must happen to a lot of people, if you ran into it as
>> well. That's something I can worry about later too. I'll keep sddm in
>> mind and see if that fixes it.
>>

This one works for me, but I also run KDE. Don't remember it from XFCE
though, I think that worked for me there.

>>>

 5) ...plus a few other minor issues probably not hardware related.



 Right now I'm 

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Claudia]

Claudia:

Chris Laprise:

On 7/22/19 11:38 AM, Claudia wrote:

So I finally got around to doing this.

Qubes works and all the basic features are supported, VT-x VT-d, and 
so on, as far as I can tell.


One major issue, hardware/firmware-wise:

1) It doesn't come back from suspend. The fan stops, but there are no 
blinking lights (actually, no lights besides AC and caps lock), and 
nothing I do wakes it. I have to long-press the power button, then 
press again to turn on the machine. It's probably an ACPI issue, 
probably not a graphics driver issue as there's no dGPU. I played 
around with acpi_osi= and some basic troubleshooting but the odds of 
me being able to fix it are slim to none.


This is good to hear!






Minor issues:

2) Buggy BIOS / ACPI impl. Dom0 kernel dmesg complains about 
"[Firmware bug]" and ACPI issues. Though no noticeable problems 
except suspend. The firmware's OS-less update-from-USB-drive feature 
seems broken, I tried several times. Still might be able to update 
from fwupd, though. No UI for managing secure boot keys, etc., it 
seems to only have the bare minimum options.


So, it appears you were totally right about consumer-grade laptops 
and buggy firmware. But suspend/resume is problematic even among 
high-end/business-class laptops, too, isn't it? It's just something 
Linux has never been good at.


TBH, I haven't had long-term problems with suspend on Thinkpads 
_except_ when anti-evil-maid is enabled; that combo hasn't worked for 
about 2 years.


My experience is that consumer BIOS will result in poor suspend 
compatibility.


Not what I wanted to hear of course, but it does seem that way. I can't 
say you didn't warn me. But that's the *only* firmware/hardware issue 
I've run into so far. I feel like I'm so close!






3) USB qube isn't working. I installed with USB qube, and the 
microphone shows up fine. But flash drives and the card reader don't 
show up. When I plug in a USB drive, its LED blinks on for a fraction 
of a second, then turns off (on other machines it stays on). No sign 
of it in lsusb or lsblk in either sys-usb or dom0.


However, when I remove the qubes.rd.hide_all_usb kernel flag, it 
works normally, so I think this is just a software issue.


This could have to do with how the USB controllers respond to the 
steps involved in placing it under IOMMU passthrough. I think without 
hide_all_usb set, they get reset twice (once in dom0 and once in 
sys-usb)?


As long as it's not strictly firmware/hardware-related, I'll worry about 
it later and start another thread for it. If I have to get rid of the 
USB qube or something it's not that big of a deal.






4) Screen power management (turn off display) doesn't work, although 
I had the same problem with a machine where suspend does work, and I 
think I narrowed it down to a fedora/X11 issue. The display does turn 
off when the lid is closed and lid-switch is set to "do nothing," 
though.


I usually have to switch to KDE with sddm to get this working.


I think I had it working temporarily on my current machine by directly 
using X11 commands, it was just XFCE not using them correctly or 
something. It must happen to a lot of people, if you ran into it as 
well. That's something I can worry about later too. I'll keep sddm in 
mind and see if that fixes it.






5) ...plus a few other minor issues probably not hardware related.



Right now I'm trying to decide if I can live without suspend. But, 
this is such a common problem that I'm afraid the next one I trade it 
in for would have the same problem, and the next one after that. Then 
I spent twice the money and got nowhere. This issue is all-too-common 
on laptops running Linux. It could be fixed (or broken) on any 
machine at any time in a random kernel update, too, but who knows.


This is especially a problem because Xen doesn't support hibernation 
at all (not to mention whether it would actually work), and Qubes 
doesn't support Xen's "save VM state" feature, either of which I 
could live with instead. So my only choices are "on" and "off."


This is an excellent point, and I think there is a Qubes issue about 
VM hibernation...


#2414, which hasn't had any activity in two years.





Besides suspend being broken, I actually really like it, and you 
can't go wrong for the price.


I think I'm going to try installing Ubuntu and testing suspend from 
there, and also trying to update the firmware from fwupd, but I'm not 
holding my breath.


That's what I would also try first. Qubes 2.0 used to make my ethernet 
NIC go dead, but booting temporarily with an Ubuntu live cd would get 
it working again and I could use it in Qubes after that until I did a 
Qubes-to-Qubes reboot. Problem stopped around Qubes 4.0. :)




So, any advice on troubleshooting suspend... or advice on what to do 
next, I guess... would be appreciated. Ugh, this is totally frustrating.


You should try these:

* Find which wifi modules are being used in sys-net (i.e. do 

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Claudia]

Chris Laprise:

On 7/22/19 11:38 AM, Claudia wrote:

So I finally got around to doing this.

Qubes works and all the basic features are supported, VT-x VT-d, and 
so on, as far as I can tell.


One major issue, hardware/firmware-wise:

1) It doesn't come back from suspend. The fan stops, but there are no 
blinking lights (actually, no lights besides AC and caps lock), and 
nothing I do wakes it. I have to long-press the power button, then 
press again to turn on the machine. It's probably an ACPI issue, 
probably not a graphics driver issue as there's no dGPU. I played 
around with acpi_osi= and some basic troubleshooting but the odds of 
me being able to fix it are slim to none.


This is good to hear!






Minor issues:

2) Buggy BIOS / ACPI impl. Dom0 kernel dmesg complains about 
"[Firmware bug]" and ACPI issues. Though no noticeable problems except 
suspend. The firmware's OS-less update-from-USB-drive feature seems 
broken, I tried several times. Still might be able to update from 
fwupd, though. No UI for managing secure boot keys, etc., it seems to 
only have the bare minimum options.


So, it appears you were totally right about consumer-grade laptops and 
buggy firmware. But suspend/resume is problematic even among 
high-end/business-class laptops, too, isn't it? It's just something 
Linux has never been good at.


TBH, I haven't had long-term problems with suspend on Thinkpads _except_ 
when anti-evil-maid is enabled; that combo hasn't worked for about 2 years.


My experience is that consumer BIOS will result in poor suspend 
compatibility.


Not what I wanted to hear of course, but it does seem that way. I can't 
say you didn't warn me. But that's the *only* firmware/hardware issue 
I've run into so far. I feel like I'm so close!






3) USB qube isn't working. I installed with USB qube, and the 
microphone shows up fine. But flash drives and the card reader don't 
show up. When I plug in a USB drive, its LED blinks on for a fraction 
of a second, then turns off (on other machines it stays on). No sign 
of it in lsusb or lsblk in either sys-usb or dom0.


However, when I remove the qubes.rd.hide_all_usb kernel flag, it works 
normally, so I think this is just a software issue.


This could have to do with how the USB controllers respond to the steps 
involved in placing it under IOMMU passthrough. I think without 
hide_all_usb set, they get reset twice (once in dom0 and once in sys-usb)?


As long as it's not strictly firmware/hardware-related, I'll worry about 
it later and start another thread for it. If I have to get rid of the 
USB qube or something it's not that big of a deal.






4) Screen power management (turn off display) doesn't work, although I 
had the same problem with a machine where suspend does work, and I 
think I narrowed it down to a fedora/X11 issue. The display does turn 
off when the lid is closed and lid-switch is set to "do nothing," though.


I usually have to switch to KDE with sddm to get this working.


I think I had it working temporarily on my current machine by directly 
using X11 commands, it was just XFCE not using them correctly or 
something. It must happen to a lot of people, if you ran into it as 
well. That's something I can worry about later too. I'll keep sddm in 
mind and see if that fixes it.






5) ...plus a few other minor issues probably not hardware related.



Right now I'm trying to decide if I can live without suspend. But, 
this is such a common problem that I'm afraid the next one I trade it 
in for would have the same problem, and the next one after that. Then 
I spent twice the money and got nowhere. This issue is all-too-common 
on laptops running Linux. It could be fixed (or broken) on any machine 
at any time in a random kernel update, too, but who knows.


This is especially a problem because Xen doesn't support hibernation 
at all (not to mention whether it would actually work), and Qubes 
doesn't support Xen's "save VM state" feature, either of which I could 
live with instead. So my only choices are "on" and "off."


This is an excellent point, and I think there is a Qubes issue about VM 
hibernation...


#2414, which hasn't had any activity in two years.





Besides suspend being broken, I actually really like it, and you can't 
go wrong for the price.


I think I'm going to try installing Ubuntu and testing suspend from 
there, and also trying to update the firmware from fwupd, but I'm not 
holding my breath.


That's what I would also try first. Qubes 2.0 used to make my ethernet 
NIC go dead, but booting temporarily with an Ubuntu live cd would get it 
working again and I could use it in Qubes after that until I did a 
Qubes-to-Qubes reboot. Problem stopped around Qubes 4.0. :)




So, any advice on troubleshooting suspend... or advice on what to do 
next, I guess... would be appreciated. Ugh, this is totally frustrating.


You should try these:

* Find which wifi modules are being used in sys-net (i.e. do "sudo 
lsmod") 

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Chris Laprise]

On 7/22/19 11:38 AM, Claudia wrote:

So I finally got around to doing this.

Qubes works and all the basic features are supported, VT-x VT-d, and so 
on, as far as I can tell.


One major issue, hardware/firmware-wise:

1) It doesn't come back from suspend. The fan stops, but there are no 
blinking lights (actually, no lights besides AC and caps lock), and 
nothing I do wakes it. I have to long-press the power button, then press 
again to turn on the machine. It's probably an ACPI issue, probably not 
a graphics driver issue as there's no dGPU. I played around with 
acpi_osi= and some basic troubleshooting but the odds of me being able 
to fix it are slim to none.


This is good to hear!



Minor issues:

2) Buggy BIOS / ACPI impl. Dom0 kernel dmesg complains about "[Firmware 
bug]" and ACPI issues. Though no noticeable problems except suspend. The 
firmware's OS-less update-from-USB-drive feature seems broken, I tried 
several times. Still might be able to update from fwupd, though. No UI 
for managing secure boot keys, etc., it seems to only have the bare 
minimum options.


So, it appears you were totally right about consumer-grade laptops and 
buggy firmware. But suspend/resume is problematic even among 
high-end/business-class laptops, too, isn't it? It's just something 
Linux has never been good at.


TBH, I haven't had long-term problems with suspend on Thinkpads _except_ 
when anti-evil-maid is enabled; that combo hasn't worked for about 2 years.


My experience is that consumer BIOS will result in poor suspend 
compatibility.




3) USB qube isn't working. I installed with USB qube, and the microphone 
shows up fine. But flash drives and the card reader don't show up. When 
I plug in a USB drive, its LED blinks on for a fraction of a second, 
then turns off (on other machines it stays on). No sign of it in lsusb 
or lsblk in either sys-usb or dom0.


However, when I remove the qubes.rd.hide_all_usb kernel flag, it works 
normally, so I think this is just a software issue.


This could have to do with how the USB controllers respond to the steps 
involved in placing it under IOMMU passthrough. I think without 
hide_all_usb set, they get reset twice (once in dom0 and once in sys-usb)?




4) Screen power management (turn off display) doesn't work, although I 
had the same problem with a machine where suspend does work, and I think 
I narrowed it down to a fedora/X11 issue. The display does turn off when 
the lid is closed and lid-switch is set to "do nothing," though.


I usually have to switch to KDE with sddm to get this working.



5) ...plus a few other minor issues probably not hardware related.



Right now I'm trying to decide if I can live without suspend. But, this 
is such a common problem that I'm afraid the next one I trade it in for 
would have the same problem, and the next one after that. Then I spent 
twice the money and got nowhere. This issue is all-too-common on laptops 
running Linux. It could be fixed (or broken) on any machine at any time 
in a random kernel update, too, but who knows.


This is especially a problem because Xen doesn't support hibernation at 
all (not to mention whether it would actually work), and Qubes doesn't 
support Xen's "save VM state" feature, either of which I could live with 
instead. So my only choices are "on" and "off."


This is an excellent point, and I think there is a Qubes issue about VM 
hibernation...




Besides suspend being broken, I actually really like it, and you can't 
go wrong for the price.


I think I'm going to try installing Ubuntu and testing suspend from 
there, and also trying to update the firmware from fwupd, but I'm not 
holding my breath.


That's what I would also try first. Qubes 2.0 used to make my ethernet 
NIC go dead, but booting temporarily with an Ubuntu live cd would get it 
working again and I could use it in Qubes after that until I did a 
Qubes-to-Qubes reboot. Problem stopped around Qubes 4.0. :)




So, any advice on troubleshooting suspend... or advice on what to do 
next, I guess... would be appreciated. Ugh, this is totally frustrating.


You should try these:

* Find which wifi modules are being used in sys-net (i.e. do "sudo 
lsmod") then add them to /rw/config/suspend-module-blacklist. I find 
this is usually required to get suspend working right. For an Intel wifi 
card, you would add both 'iwldvm' and 'iwlwifi' in that order.


* Upgrade the dom0 and vm kernels to 4.19 or later. The 4.19 versions 
from qubes*testing have been very stable for me. OTOH, there are also 
5.x versions available.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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 

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Claudia]

Chris Laprise:

On 5/22/19 3:17 PM, Claudia wrote:
Thanks for all the info! All good news except for the part about 
BIOS/UEFI feature support, which doesn't come as a surprise.


I understand that, for maximum certainty, one should look at high-end, 
business-class, Linux-friendly product lines. However, this kind of 
defeats the whole point of looking for a laptop with a low-cost 
good-performance processor such as Ryzen. Those product lines are 
pricy to begin with (relative to specs), and they rarely ever go on sale.


Also, it stands to reason that low-cost processors are usually found 
in low-cost machines. I found a couple of lists[1][2] of laptops with 
these processors. While there is a Thinkpad on the list, it looks to 
be mostly consumer-level laptops (although I'm not real familiar with 
computer makes and product lines so I could be wrong).


To be honest, I was kind of looking this[3] Inspiron 5575 with 2500U 
available at Walmart for $350 (was down to $330 for a few days). After 
upgrading the RAM and perhaps adding an SSD, it still looks like a 
good deal for the money. Good enough to take a chance on, I think -- 
if it doesn't run Qubes, I'll just have to return it and look at some 
higher-end models.


It sounds like you have an approach worked out.

If the low cost model doesn't run Qubes, then consider: Now that AMD is 
being taken seriously for business laptops (where they used to be 
extremely rare), there should now be more choices that are lower cost 
_because_ they have an AMD processor.


FWIW, firmware compatibility isn't good on consumer models regardless of 
the CPU vendor: Intel based consumer products suffer from it, too.




I did some quick searching, and Inspirons appear to have reasonably 
good Linux compatibility, at least for consumer-level laptops. 
Inspiron 5575 is even on the arch wiki[4] (which is definitely not 
conclusive, but a good sign nonetheless, no?)


Dell is said to have a larger number of models that are _intentionally_ 
Linux compatible. Its worth checking their website to see if that model 
(or any adjacent to it) are labeled as Linux compatible. The Dell 
support page for Inspiron 5575 actually lists Ubuntu as a compatible 
OS... a good sign!




For what it's worth, I took a Qubes installer USB to Walmart, and 
tried it on a couple of consumer-level machines, although they did't 
have any Inspirons on display. The only one that didn't work was an 
older HP Pavilion with an A10 processor (it dropped to shell before 
graphical installer came up), but it did work on an HP Graphite Mist 
i5-8250U and one other machine which I can't recall at the moment. 
(Note by "worked" I mean it made it to the final point in the 
installer before you actually write to the disk.)


So, unless there are any red flags I'm not seeing, I'm leaning towards 
giving the Inspiron 5575 a try.


Only red flag is consumer designation. As is often the case, Dell may 
prefer to keep virtualization features turned off (and not provide a 
BIOS screen option to turn them on) to avoid support costs.




Thanks once again for your comprehensive and helpful reply! Any 
additional thoughts/advice welcome.


Good luck! And let us know how it goes and if you have any specific 
questions.





[1] https://www.notebookcheck.net/AMD-Ryzen-5-2500U-SoC.258646.0.html
[2] 
https://www.reddit.com/r/Amd/comments/8v6e1u/list_of_ryzen_and_vega_amd_laptops_6302018/ 

[3] 
https://www.walmart.com/ip/Dell-Inspiron-15-5000-5575-Laptop-15-6-AMD-Ryzen-5-2500U-with-Radeon-Vega8-Graphics-1TB-HDD-4GB-RAM-i5575-A410BLU-PUS/212669685 


[4] https://wiki.archlinux.org/index.php/Dell_Inspiron_5575




So I finally got around to doing this.

Qubes works and all the basic features are supported, VT-x VT-d, and so 
on, as far as I can tell.


One major issue, hardware/firmware-wise:

1) It doesn't come back from suspend. The fan stops, but there are no 
blinking lights (actually, no lights besides AC and caps lock), and 
nothing I do wakes it. I have to long-press the power button, then press 
again to turn on the machine. It's probably an ACPI issue, probably not 
a graphics driver issue as there's no dGPU. I played around with 
acpi_osi= and some basic troubleshooting but the odds of me being able 
to fix it are slim to none.


Minor issues:

2) Buggy BIOS / ACPI impl. Dom0 kernel dmesg complains about "[Firmware 
bug]" and ACPI issues. Though no noticeable problems except suspend. The 
firmware's OS-less update-from-USB-drive feature seems broken, I tried 
several times. Still might be able to update from fwupd, though. No UI 
for managing secure boot keys, etc., it seems to only have the bare 
minimum options.


So, it appears you were totally right about consumer-grade laptops and 
buggy firmware. But suspend/resume is problematic even among 
high-end/business-class laptops, too, isn't it? It's just something 
Linux has never been good at.


3) USB qube isn't working. I installed with USB qube, and the 

Re: [qubes-users] R4 system requirements; AMD compatibility?

[brendan . hoar]

On Thursday, May 30, 2019 at 10:01:07 AM UTC-4, Claudia wrote:
> 1) Should I update the BIOS before attempting to install Qubes? Is this 
> a generally recommended practice for Qubes, and if so, why isn't it 
> mentioned in the installation guide?

I know you're asking Chris, so feel free to discount my comments here. :)

My strategy before Qubes installation is:
1. Update the BIOS/UEFI PC firmware. Must be done on target workstation/server.
2. Update the SSD firmware. Can be done on a different workstation.
3. Reset the factory DEK on the SSD if it supports OPAL or OPALite. Can be done 
on a different workstation.
4. NEW: turn off hyperthreading in the BIOS/UEFI config.

> I wonder how many people gave up on 
> a Qubes install without ever trying a firmware update. Should I keep the 
> firmware up to date thereafter? Firmware updates used to be rare, and it 
> was only recommended to install them if something was actually broken. I 
> guess now that the firmware is practically an OS in itself, we should be 
> updating it like one?

I do, usually after some new Intel CPU vulnerability is published. :)

> Luckily, Dell provides a way to update firmware from Linux, and a way to 
> do it with no OS at all. However, I imagine some (most) vendors require 
> Windows in order to install firmware updates. Just out of curiosity, how 
> do Linux users do firmware updates on machines without fwupd or a 
> self-updating firmware?

I install a test Windows instance, download the firmware from the vendor and 
install it using the vendor tools. That's probably not the most secure method 
out there.

> Also, what about microcode? Can microcode updates affect Qubes 
> compatibility? I know microcode is typically loaded by Linux each boot, 
> but if the system can't boot, I guess you have to install a permanent 
> update through the BIOS?

One thing that enterprise-serving PC manufacturer *firmware* updates generally 
cover is the microcode updates. Dell, Lenovo, etc. generally update the 
firmware with the microcode. Sometimes the BIOS firmware might get the update 
first, sometimes Linux distros might.

> 2) Do you think 4GB RAM will be enough to do the install? The system 
> requirements list 4GB as minimum, so I'm assuming it'll work. I'd rather 
> not buy the RAM until I know I'm keeping the machine, although I will if 
> I have to. But if I am going to need RAM for the install, I should order 
> it ahead of time.

I semi-recently installed 4.0 (can't remember which ISO release) on a system w/ 
only 4GB of RAM and it installed fine. However, it freaked out trying to start 
up VMs, repeating and failing continuously. Part of the issue there, I think, 
is a defect that has already been fixed in testing (and recently pushed to 
current) where dom0 was reserved more RAM than necessary severing limiting RAM 
available to VMs.

So for 4.0 I recommend at least 8GB and preferably 12GB. If you'll be running 
HVMs and/or Windows VMs that cannot participate in memory balancing like the 
PVH VMs can, 16GB minimum.

Brendan

-- 
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/824c98c5-e15f-444c-a533-0a7af78d9f54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Claudia]

Chris Laprise:

On 5/22/19 3:17 PM, Claudia wrote:
Thanks for all the info! All good news except for the part about 
BIOS/UEFI feature support, which doesn't come as a surprise.


I understand that, for maximum certainty, one should look at high-end, 
business-class, Linux-friendly product lines. However, this kind of 
defeats the whole point of looking for a laptop with a low-cost 
good-performance processor such as Ryzen. Those product lines are 
pricy to begin with (relative to specs), and they rarely ever go on sale.


Also, it stands to reason that low-cost processors are usually found 
in low-cost machines. I found a couple of lists[1][2] of laptops with 
these processors. While there is a Thinkpad on the list, it looks to 
be mostly consumer-level laptops (although I'm not real familiar with 
computer makes and product lines so I could be wrong).


To be honest, I was kind of looking this[3] Inspiron 5575 with 2500U 
available at Walmart for $350 (was down to $330 for a few days). After 
upgrading the RAM and perhaps adding an SSD, it still looks like a 
good deal for the money. Good enough to take a chance on, I think -- 
if it doesn't run Qubes, I'll just have to return it and look at some 
higher-end models.


It sounds like you have an approach worked out.

If the low cost model doesn't run Qubes, then consider: Now that AMD is 
being taken seriously for business laptops (where they used to be 
extremely rare), there should now be more choices that are lower cost 
_because_ they have an AMD processor.


FWIW, firmware compatibility isn't good on consumer models regardless of 
the CPU vendor: Intel based consumer products suffer from it, too.


(Sorry it took me this long to reply.)

Indeed, that's what it sounded like to me from your initial reply. I was 
more worried about CPU vendor, mostly due to the way the system 
requirements page is worded, and lack of relevant search results for 
"Qubes on AMD." But as you pointed out, BIOS/UEFI support (and 
therefore, the specific computer/motherboard model) is a much more 
important consideration. So I'm glad I asked.


Also, just out of curiosity, as far as consumer vs. business and 
firmware support: in your experience does firmware support also depend 
significantly on the vendor, and not just product class? e.g. perhaps 
vendor A's consumer-level products work even better than B's 
business-class. Do any particular vendors use generally "better" 
firmwares? (I know you mentioned Lenovo, Dell, and HP with regards to 
Linux support.) Or is firmware support about the same across vendors, 
within each product class?


I did some quick searching, and Inspirons appear to have reasonably 
good Linux compatibility, at least for consumer-level laptops. 
Inspiron 5575 is even on the arch wiki[4] (which is definitely not 
conclusive, but a good sign nonetheless, no?)


Dell is said to have a larger number of models that are _intentionally_ 
Linux compatible. Its worth checking their website to see if that model 
(or any adjacent to it) are labeled as Linux compatible. The Dell 
support page for Inspiron 5575 actually lists Ubuntu as a compatible 
OS... a good sign!


Just to be clear, what relationship is there between Linux 
compatibility, and firmware support, if any? Are these the same thing? 
Roughly correlated? Or totally different?


Good luck! And let us know how it goes and if you have any specific 
questions.


I'll make sure to follow up. I'm waiting to order it until I know I'll 
have enough free time to play around with it, as I'll only have a 
limited time to decide if I'm keeping it or returning it. Hopefully 
within the next week or two.


I thought of some more questions in the meantime. Hope you don't mind me 
picking your brain a little.


1) Should I update the BIOS before attempting to install Qubes? Is this 
a generally recommended practice for Qubes, and if so, why isn't it 
mentioned in the installation guide? I wonder how many people gave up on 
a Qubes install without ever trying a firmware update. Should I keep the 
firmware up to date thereafter? Firmware updates used to be rare, and it 
was only recommended to install them if something was actually broken. I 
guess now that the firmware is practically an OS in itself, we should be 
updating it like one?


Luckily, Dell provides a way to update firmware from Linux, and a way to 
do it with no OS at all. However, I imagine some (most) vendors require 
Windows in order to install firmware updates. Just out of curiosity, how 
do Linux users do firmware updates on machines without fwupd or a 
self-updating firmware?


Also, what about microcode? Can microcode updates affect Qubes 
compatibility? I know microcode is typically loaded by Linux each boot, 
but if the system can't boot, I guess you have to install a permanent 
update through the BIOS?


These are just things I thought of and was curious about, but I guess I 
don't have to worry unless I actually hit a problem.


2) Do you 

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Claudia]

Chris Laprise:

On 5/22/19 9:44 AM, Claudia wrote:

Hello,

I've read the system requirements page, the HCL, and the "advice on 
finding a Qubes compatible notebook" thread, all of which seem to 
refer to Intel almost exclusively. I've also done some searching 
around, but there seems to be very little information about Qubes' 
compatibility on AMD machines.


I already know the conventional wisdom is "buy it, try it, and return 
it if it doesn't work," and that's basically what I intend to do. But 
before I do, I'm hoping for some reassurance, or advice on whether I 
should just skip over AMD altogether.


Is Qubes support for AMD about as good as it is for Intel? Or, is 
there a reason to pay the extra money for an Intel machine? Why is 
there so little information about Qubes on AMD, and so few AMD 
machines on the HCL? Surely I can't be the only person wondering about 
this.


A few things, more specifically:

1) The system requirements page says that Intel integrated graphics 
are strongly recommended over Nvidia or Radeon, for compatibility 
reasons. What about AMD's integrated "Vega" graphics?


That recommendation is overly conservative because early in Qubes' 
history only Intel processors had been explored and integrated graphics 
was the safe bet. If I were to re-word that phrase, I'd make it sound 
more like "avoid Nvidia unless you know exactly what you're doing". IOW, 
AMD is not a big worry when it comes to Linux graphics.




2) It's harder to find compatibility-related information for AMD 
processors. In particular, information about whether RVI ( = Intel 
EPT, = SLAT) is supported by a given processor. Official specs, and 
even sites like wikichip.org and cpu-monkey.com, often mention Intel 
EPT but not AMD RVI. (AMD-V and IOMMU are usually mentioned, though). 
Is there a specific cpu flag or something that I should be looking for 
in order to know if RVI is supported? Or is it pretty much safe to 
assume that any recent AMD processor with AMD-V and IOMMU will also 
support RVI?


I myself am just getting started with AMD on a circa 2013 laptop. Even 
on this 6yr old A10 laptop, all of the virtualization features are there 
– although coreboot is required for proper initialization (no surprise: 
the laptop is a Lenovo Ideapad, not a Thinkpad).


FWIW, I do think you're right that any x86 processor that supports both 
HVM (AMD-V) and IOMMU would also have RVI support. In the Qubes HCL, all 
of the Ryzen systems were reported to have RVI(SLAT) working. One entry 
also reports that IOMMU was present but not working on a "gaming" 
motherboard.


These days, the main issue with these virtualization features is not 
with the CPUs/chipsets themselves, but whether the BIOS/UEFI for a 
specific computer model enables these features and initializes them 
correctly. This is rarely an issue with business class computers from 
reputable vendors.




3) Do AMD processors have integrated chipsets like Intel (4th gen and 
up) processors? Or does the chipset remain on the motherboard in AMD 
machines. Not a dealbreaker, but integrated chipsets definitely make 
searching much easier.


Someone else with direct Ryzen experience could better answer this 
question. I know that in the 15h (2013) era the chipsets were separate 
(but this was also true for Intel at least up to 2012).




For what it's worth, in particular I'm looking at a few laptops with 
processors such as Ryzen 5 2500U, Ryzen 7 2700U, and Ryzen 5 3500U. 
They seem like great deal for the money. For example the 2500U has 
about the same specs/performance as an i5-8250U, but laptops with the 
2500U tend to be around $200 cheaper than the Intel version. But, if 
Qubes compatibility is most likely going to be an issue, then I'm 
willing to pay the extra money for an Intel machine and avoid the hassle.


So, can I expect to have about the same luck with AMD as Intel? Or 
should I just pay the extra money and play it safe with Intel? Any 
advice on these particular processors, or recent AMD processors in 
general, it would make me feel a lot better before I go buying and 
trying at random.


You can make the process less random by focusing on sources that have a 
history of delivering better quality BIOS/firmware. Systems with the 
best chance of compatibility will be business-class and indicate 
compatibility with Linux (or Ubuntu/Redhat) in addition to Windows, 
typically from vendors Lenovo, Dell, and HP. I would have included 
Purism and System76 except they don't offer AMD laptops. In general, 
avoid consumer and gaming models (e.g. choose Thinkpad over Ideapad).


Do I think its worth it to try? Definitely, as long as your choice isn't 
random consumer gear. AMD processors tend to be more secure in the face 
of sidechannel attacks and suffer less performance degradation[1] from 
resulting security patches; that's certainly a reason to go in AMD's 
direction.


1. 

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Chris Laprise]

On 5/22/19 3:17 PM, Claudia wrote:
Thanks for all the info! All good news except for the part about 
BIOS/UEFI feature support, which doesn't come as a surprise.


I understand that, for maximum certainty, one should look at high-end, 
business-class, Linux-friendly product lines. However, this kind of 
defeats the whole point of looking for a laptop with a low-cost 
good-performance processor such as Ryzen. Those product lines are pricy 
to begin with (relative to specs), and they rarely ever go on sale.


Also, it stands to reason that low-cost processors are usually found in 
low-cost machines. I found a couple of lists[1][2] of laptops with these 
processors. While there is a Thinkpad on the list, it looks to be mostly 
consumer-level laptops (although I'm not real familiar with computer 
makes and product lines so I could be wrong).


To be honest, I was kind of looking this[3] Inspiron 5575 with 2500U 
available at Walmart for $350 (was down to $330 for a few days). After 
upgrading the RAM and perhaps adding an SSD, it still looks like a good 
deal for the money. Good enough to take a chance on, I think -- if it 
doesn't run Qubes, I'll just have to return it and look at some 
higher-end models.


It sounds like you have an approach worked out.

If the low cost model doesn't run Qubes, then consider: Now that AMD is 
being taken seriously for business laptops (where they used to be 
extremely rare), there should now be more choices that are lower cost 
_because_ they have an AMD processor.


FWIW, firmware compatibility isn't good on consumer models regardless of 
the CPU vendor: Intel based consumer products suffer from it, too.




I did some quick searching, and Inspirons appear to have reasonably good 
Linux compatibility, at least for consumer-level laptops. Inspiron 5575 
is even on the arch wiki[4] (which is definitely not conclusive, but a 
good sign nonetheless, no?)


Dell is said to have a larger number of models that are _intentionally_ 
Linux compatible. Its worth checking their website to see if that model 
(or any adjacent to it) are labeled as Linux compatible. The Dell 
support page for Inspiron 5575 actually lists Ubuntu as a compatible 
OS... a good sign!




For what it's worth, I took a Qubes installer USB to Walmart, and tried 
it on a couple of consumer-level machines, although they did't have any 
Inspirons on display. The only one that didn't work was an older HP 
Pavilion with an A10 processor (it dropped to shell before graphical 
installer came up), but it did work on an HP Graphite Mist i5-8250U and 
one other machine which I can't recall at the moment. (Note by "worked" 
I mean it made it to the final point in the installer before you 
actually write to the disk.)


So, unless there are any red flags I'm not seeing, I'm leaning towards 
giving the Inspiron 5575 a try.


Only red flag is consumer designation. As is often the case, Dell may 
prefer to keep virtualization features turned off (and not provide a 
BIOS screen option to turn them on) to avoid support costs.




Thanks once again for your comprehensive and helpful reply! Any 
additional thoughts/advice welcome.


Good luck! And let us know how it goes and if you have any specific 
questions.





[1] https://www.notebookcheck.net/AMD-Ryzen-5-2500U-SoC.258646.0.html
[2] 
https://www.reddit.com/r/Amd/comments/8v6e1u/list_of_ryzen_and_vega_amd_laptops_6302018/ 

[3] 
https://www.walmart.com/ip/Dell-Inspiron-15-5000-5575-Laptop-15-6-AMD-Ryzen-5-2500U-with-Radeon-Vega8-Graphics-1TB-HDD-4GB-RAM-i5575-A410BLU-PUS/212669685 


[4] https://wiki.archlinux.org/index.php/Dell_Inspiron_5575


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/f66cfef4-1d92-6103-e820-c6b584ee7f77%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] R4 system requirements; AMD compatibility?

[Chris Laprise]

On 5/22/19 9:44 AM, Claudia wrote:

Hello,

I've read the system requirements page, the HCL, and the "advice on 
finding a Qubes compatible notebook" thread, all of which seem to refer 
to Intel almost exclusively. I've also done some searching around, but 
there seems to be very little information about Qubes' compatibility on 
AMD machines.


I already know the conventional wisdom is "buy it, try it, and return it 
if it doesn't work," and that's basically what I intend to do. But 
before I do, I'm hoping for some reassurance, or advice on whether I 
should just skip over AMD altogether.


Is Qubes support for AMD about as good as it is for Intel? Or, is there 
a reason to pay the extra money for an Intel machine? Why is there so 
little information about Qubes on AMD, and so few AMD machines on the 
HCL? Surely I can't be the only person wondering about this.


A few things, more specifically:

1) The system requirements page says that Intel integrated graphics are 
strongly recommended over Nvidia or Radeon, for compatibility reasons. 
What about AMD's integrated "Vega" graphics?


That recommendation is overly conservative because early in Qubes' 
history only Intel processors had been explored and integrated graphics 
was the safe bet. If I were to re-word that phrase, I'd make it sound 
more like "avoid Nvidia unless you know exactly what you're doing". IOW, 
AMD is not a big worry when it comes to Linux graphics.




2) It's harder to find compatibility-related information for AMD 
processors. In particular, information about whether RVI ( = Intel EPT, 
= SLAT) is supported by a given processor. Official specs, and even 
sites like wikichip.org and cpu-monkey.com, often mention Intel EPT but 
not AMD RVI. (AMD-V and IOMMU are usually mentioned, though). Is there a 
specific cpu flag or something that I should be looking for in order to 
know if RVI is supported? Or is it pretty much safe to assume that any 
recent AMD processor with AMD-V and IOMMU will also support RVI?


I myself am just getting started with AMD on a circa 2013 laptop. Even 
on this 6yr old A10 laptop, all of the virtualization features are there 
– although coreboot is required for proper initialization (no surprise: 
the laptop is a Lenovo Ideapad, not a Thinkpad).


FWIW, I do think you're right that any x86 processor that supports both 
HVM (AMD-V) and IOMMU would also have RVI support. In the Qubes HCL, all 
of the Ryzen systems were reported to have RVI(SLAT) working. One entry 
also reports that IOMMU was present but not working on a "gaming" 
motherboard.


These days, the main issue with these virtualization features is not 
with the CPUs/chipsets themselves, but whether the BIOS/UEFI for a 
specific computer model enables these features and initializes them 
correctly. This is rarely an issue with business class computers from 
reputable vendors.




3) Do AMD processors have integrated chipsets like Intel (4th gen and 
up) processors? Or does the chipset remain on the motherboard in AMD 
machines. Not a dealbreaker, but integrated chipsets definitely make 
searching much easier.


Someone else with direct Ryzen experience could better answer this 
question. I know that in the 15h (2013) era the chipsets were separate 
(but this was also true for Intel at least up to 2012).




For what it's worth, in particular I'm looking at a few laptops with 
processors such as Ryzen 5 2500U, Ryzen 7 2700U, and Ryzen 5 3500U. They 
seem like great deal for the money. For example the 2500U has about the 
same specs/performance as an i5-8250U, but laptops with the 2500U tend 
to be around $200 cheaper than the Intel version. But, if Qubes 
compatibility is most likely going to be an issue, then I'm willing to 
pay the extra money for an Intel machine and avoid the hassle.


So, can I expect to have about the same luck with AMD as Intel? Or 
should I just pay the extra money and play it safe with Intel? Any 
advice on these particular processors, or recent AMD processors in 
general, it would make me feel a lot better before I go buying and 
trying at random.


You can make the process less random by focusing on sources that have a 
history of delivering better quality BIOS/firmware. Systems with the 
best chance of compatibility will be business-class and indicate 
compatibility with Linux (or Ubuntu/Redhat) in addition to Windows, 
typically from vendors Lenovo, Dell, and HP. I would have included 
Purism and System76 except they don't offer AMD laptops. In general, 
avoid consumer and gaming models (e.g. choose Thinkpad over Ideapad).


Do I think its worth it to try? Definitely, as long as your choice isn't 
random consumer gear. AMD processors tend to be more secure in the face 
of sidechannel attacks and suffer less performance degradation[1] from 
resulting security patches; that's certainly a reason to go in AMD's 
direction.


1. 
https://www.tomshardware.com/news/intel-amd-mitigations-performance-impact,39381.html


--

[qubes-users] R4 system requirements; AMD compatibility?

[Claudia]

Hello,

I've read the system requirements page, the HCL, and the "advice on 
finding a Qubes compatible notebook" thread, all of which seem to refer 
to Intel almost exclusively. I've also done some searching around, but 
there seems to be very little information about Qubes' compatibility on 
AMD machines.


I already know the conventional wisdom is "buy it, try it, and return it 
if it doesn't work," and that's basically what I intend to do. But 
before I do, I'm hoping for some reassurance, or advice on whether I 
should just skip over AMD altogether.


Is Qubes support for AMD about as good as it is for Intel? Or, is there 
a reason to pay the extra money for an Intel machine? Why is there so 
little information about Qubes on AMD, and so few AMD machines on the 
HCL? Surely I can't be the only person wondering about this.


A few things, more specifically:

1) The system requirements page says that Intel integrated graphics are 
strongly recommended over Nvidia or Radeon, for compatibility reasons. 
What about AMD's integrated "Vega" graphics?


2) It's harder to find compatibility-related information for AMD 
processors. In particular, information about whether RVI ( = Intel EPT, 
= SLAT) is supported by a given processor. Official specs, and even 
sites like wikichip.org and cpu-monkey.com, often mention Intel EPT but 
not AMD RVI. (AMD-V and IOMMU are usually mentioned, though). Is there a 
specific cpu flag or something that I should be looking for in order to 
know if RVI is supported? Or is it pretty much safe to assume that any 
recent AMD processor with AMD-V and IOMMU will also support RVI?


3) Do AMD processors have integrated chipsets like Intel (4th gen and 
up) processors? Or does the chipset remain on the motherboard in AMD 
machines. Not a dealbreaker, but integrated chipsets definitely make 
searching much easier.


For what it's worth, in particular I'm looking at a few laptops with 
processors such as Ryzen 5 2500U, Ryzen 7 2700U, and Ryzen 5 3500U. They 
seem like great deal for the money. For example the 2500U has about the 
same specs/performance as an i5-8250U, but laptops with the 2500U tend 
to be around $200 cheaper than the Intel version. But, if Qubes 
compatibility is most likely going to be an issue, then I'm willing to 
pay the extra money for an Intel machine and avoid the hassle.


So, can I expect to have about the same luck with AMD as Intel? Or 
should I just pay the extra money and play it safe with Intel? Any 
advice on these particular processors, or recent AMD processors in 
general, it would make me feel a lot better before I go buying and 
trying at random.


-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  


--
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/116689b7-00ee-3070-cd76-0b8f4799c87e%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.