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 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") 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 didn't think of wifi modules preventing suspend. I'll definitely
>> give it a try, but I'm not sure it could cause the kind of problem I'm
>> having. It doesn't seem like it's even trying to wake up when I press
>> a key or the power button. It just stays sleeping. The only observable
>> difference between sleep and off is that in sleep pressing the power
>> button doesn't turn the machine on until I power cycle. Also, I tried
>> enabling "USB Wake Support" in BIOS, but it didn't seem to make a
>> difference.

This looks interesting, I'll give this a try. I just shelved my
suspension issues, since I thought it wasn't qubes-specific, was going
to nag lenovo about it...

>>
>>>
>>> * 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.
>>>
>>
>> I did `qubes-dom0-upgrade --enablerepo=qubes-dom0-unstable kernel` and
>> I still couldn't get a newer kernel. 4.14.199-2 popped up and it said
>> "nothing to do." What am I doing wrong?
> 
> Got it. current-testing, not -unstable. Sometimes I don't know how to
> read, haha. I guess I just assumed unstable was newer than testing.
> 

Confused me as well... But yeah, 4.19 seems really important for ryzen,
a lot apparently happened there.

>>
>> It doesn't seem like VM kernels would make a difference with suspend,
>> but I can try upgrading them anyways.
>>
>> Thanks again
> 
> 
> -------------------------------------------------
> 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! 

So yeah, a lot of this looks like it's ryzen-specific, and not due to
consumer-grade hardware. Mine isn't the most expensive thinkpad around,
I guess, but I can't really call it cheapish.

<3
/panina

-- 
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/97da8240-54be-4086-a22f-45b595065868%40nonbinary.me.

Attachment: 0x6648B5C5E394CC24.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to