[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
On Sunday, December 2, 2018 at 10:59:14 AM UTC-8, Arthur B. wrote: > On Tuesday, November 20, 2018 at 4:03:17 PM UTC-8, richard...@gmail.com wrote: > > On Thursday, November 8, 2018 at 3:04:12 PM UTC-6, mark...@gmail.com wrote: > > > On Monday, November 5, 2018 at 7:20:17 PM UTC+2, pkra...@gmail.com wrote: > > > > Dan, > > > > Thank you for the instructions! I would like to confirm the patch still > > > > works against 4.14.72.1 > > > > > > > > The only problem I had with original instruction is that yum didn't > > > > want to install another kernel (compiled one) with identical version > > > > (one was already installed since I did upgrade first) - I had to > > > > increment value in qubes-linux-kernel/rel file and recompile again so > > > > my version named as 4.14.72.2. > > > > > > hi friends just update the bios and choose the linux sleep option in the > > > bios, the issue has been fixed > > > > Can confirm. Perform the BIOS update, and enter BIOS configuration at boot: > > > > Config -> Power -> Sleep State -> Linux > > > > I switched xen.cfg default kernel to 4.14.18-1.pvops.qubes.x86_64. > > > > Sleep now works great! Laptop even wakes to XScreenSaver when lid is opened. > > Just updated the bios to 1.34 (N23ET59W) on a 6th gen X1. Set Sleep State to > "Linux" and the laptop still does not wake up when the lid is closed and > re-opened. Running 4.14.74-1. > > Do I still need to downgrade the kernel and patch? It sounded like the bios > update would be enough. Ah, still needs to turn on the Thunderbolt assist on as well. -- 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/95d53a83-9ef3-4f72-b2a3-968ea5c772f1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
On Tuesday, November 20, 2018 at 4:03:17 PM UTC-8, richard...@gmail.com wrote: > On Thursday, November 8, 2018 at 3:04:12 PM UTC-6, mark...@gmail.com wrote: > > On Monday, November 5, 2018 at 7:20:17 PM UTC+2, pkra...@gmail.com wrote: > > > Dan, > > > Thank you for the instructions! I would like to confirm the patch still > > > works against 4.14.72.1 > > > > > > The only problem I had with original instruction is that yum didn't want > > > to install another kernel (compiled one) with identical version (one was > > > already installed since I did upgrade first) - I had to increment value > > > in qubes-linux-kernel/rel file and recompile again so my version named as > > > 4.14.72.2. > > > > hi friends just update the bios and choose the linux sleep option in the > > bios, the issue has been fixed > > Can confirm. Perform the BIOS update, and enter BIOS configuration at boot: > > Config -> Power -> Sleep State -> Linux > > I switched xen.cfg default kernel to 4.14.18-1.pvops.qubes.x86_64. > > Sleep now works great! Laptop even wakes to XScreenSaver when lid is opened. Just updated the bios to 1.34 (N23ET59W) on a 6th gen X1. Set Sleep State to "Linux" and the laptop still does not wake up when the lid is closed and re-opened. Running 4.14.74-1. Do I still need to downgrade the kernel and patch? It sounded like the bios update would be enough. -- 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/86a3ba6d-ecb8-441c-b7ee-f18dfb4c5c6b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
On Thursday, November 8, 2018 at 3:04:12 PM UTC-6, mark...@gmail.com wrote: > On Monday, November 5, 2018 at 7:20:17 PM UTC+2, pkra...@gmail.com wrote: > > Dan, > > Thank you for the instructions! I would like to confirm the patch still > > works against 4.14.72.1 > > > > The only problem I had with original instruction is that yum didn't want to > > install another kernel (compiled one) with identical version (one was > > already installed since I did upgrade first) - I had to increment value in > > qubes-linux-kernel/rel file and recompile again so my version named as > > 4.14.72.2. > > hi friends just update the bios and choose the linux sleep option in the > bios, the issue has been fixed Can confirm. Perform the BIOS update, and enter BIOS configuration at boot: Config -> Power -> Sleep State -> Linux I switched xen.cfg default kernel to 4.14.18-1.pvops.qubes.x86_64. Sleep now works great! Laptop even wakes to XScreenSaver when lid is opened. -- 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/9b063218-082f-483f-b9ee-dc6a0e6ece91%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
On Monday, November 5, 2018 at 7:20:17 PM UTC+2, pkra...@gmail.com wrote: > Dan, > Thank you for the instructions! I would like to confirm the patch still works > against 4.14.72.1 > > The only problem I had with original instruction is that yum didn't want to > install another kernel (compiled one) with identical version (one was already > installed since I did upgrade first) - I had to increment value in > qubes-linux-kernel/rel file and recompile again so my version named as > 4.14.72.2. hi friends just update the bios and choose the linux sleep option in the bios, the issue has been fixed -- 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/fbf925ef-d228-4927-a317-8a94ae9ec8cf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
Dan, Thank you for the instructions! I would like to confirm the patch still works against 4.14.72.1 The only problem I had with original instruction is that yum didn't want to install another kernel (compiled one) with identical version (one was already installed since I did upgrade first) - I had to increment value in qubes-linux-kernel/rel file and recompile again so my version named as 4.14.72.2. -- 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/0ad8a15c-7cf0-4385-9ecd-14fb294ae061%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
On Tuesday, September 4, 2018 at 10:01:08 PM UTC-7, aqeel...@gmail.com wrote:
> On Wednesday, 1 August 2018 12:04:13 UTC+10, D. J. Bernstein wrote:
> > I finally decided to resort to patching the kernel. Suspend now seems to
> > work normally in several tests on a Lenovo X1 ThinkPad Carbon 6th
> > generation under Qubes R4.0. The idea of the patch is to do
> >
> >if (sleep_state == ACPI_STATE_S3) {
> > *sleep_type_a = 5;
> > *sleep_type_b = 5;
> > return_ACPI_STATUS(AE_OK);
> >}
> >
> > near the top of acpi_get_sleep_type_data() (right after the "Validate
> > parameters" part) in linux/drivers/acpi/acpica/hwxface.c. This has the
> > same effect as the DSDT patches running around for this laptop: telling
> > the kernel that the laptop supports S3 state (which the hardware _does_
> > support---the starting problem is that the BIOS fails to announce this),
> > and more specifically that S3 is hardware sleep type 5.
> >
> > Of course, simply adding the lines above wouldn't be appropriate for
> > non-laptops, or laptops where S3 is another hardware sleep type. The
> > actual patch is instead triggered by
> >
> >* DMI reporting this laptop, or
> >* "acpi_force_s3=5" on the kernel command line (so users have a
> > relatively easy way to handle newer laptops with the same problem).
> >
> > If this patch survives more tests and review (I'm not a Linux kernel
> > expert) then it should be suitable for upstream adoption. I've attached
> > the patch, and some notes on how I compiled a patched kernel for Qubes
> > R4.0.
> >
> > Beyond the patch, I've put
> >
> >mem_sleep_default=deep
> >
> > into my /boot/efi/EFI/qubes/xen.cfg on the kernel= line for the patched
> > kernel, to tell the kernel to use S3 for suspend---otherwise it uses
> > s2idle. The importance of S3 vs. s2idle for this laptop is different on
> > Qubes from vanilla Linux: there are many reports of s2idle consuming
> > more power than S3 on vanilla Linux, but Qubes seems unique in s2idle
> > not waking up at all. I don't see a serious argument for s2idle when S3
> > is supported, so I'm not sure why mem_sleep_default prefers s2idle over
> > S3; even if there's a reason for this, maybe there would be general
> > interest in a second patch that disables s2idle on this laptop.
> >
> > ---Dan
>
> Hi Dan,
>
> I followed kernel-compile-notes.txt twice. The first time failed, the second
> time worked a charm with minor changes to the method. These are my notes on
> the experience.
>
> Before I proceed, I note that the current version of the qubes-linux-kernel
> git on stable-4.14 is 4.14.67-1. This is the version of the kernel that I
> have compiled and applied your patch to.
>
> The first (failed) attempted, I was on a fresh install of Qubes R4.0, kernel
> 4.14.18-1. Compiling the kernel seemed to work, as did installing. Upon boot
> and unlocking my hard-drive the system never seemed to get anywhere on the
> loading. Upon pressing escape I noticed I was being spammed with a `dracut`
> error before eventually it dropped to an emergency shell. A more forward
> thinking me would have written down the error message. I simply reinstalled
> Qubes R4.0 fresh to start over.
>
> The second (successful) attempt was after I had updated dom0. I was running
> kernel 4.14.57-2. I knew that this was an earlier version than the one I was
> going to compile so it wasn't going to be an issue (as you've described in
> your excellent notes). I doubt updating dom0 had anything to do with the
> success of this attempt, instead I did two things differently to your notes:
>
> 1. I ran the following command twice, superfluous I presume:
>
>make verify-sources
>
> 2. I ran the following command in dom0 after installing:
>
>dom0 $ sudo dracut -f "/boot/efi/EFI/qubes/initramfs-$version.img"
> "$version"
>
> Paying special attention that the variable $version was expanded correctly.
>
> After adding the kernel parameter:
>mem_sleep_default=deep
> to the appropriate line in /boot/efi/EFI/qubes/xen.cfg - again as you've
> described.
>
> To conclude, I can confirm that your patch works for version 4.14.67-1 of the
> qubes-linux-kernel too. That is, standby and wake from standby work as
> intended and the command:
>dmesg | grep ACPI | grep supports
> yields:
>ACPI: (supports S0 S3 S5)
> on my Carbon X1 Gen 6, i7 8550U.
>
> However, perhaps unrelated, I have noticed the CPU doesn't turbo boost.
> Running the following command in dom0:
>xenpm get-cpufreq-states
> shows that only 13 / 16 P-States are usable with P0, P1, P3 (the turbo
> states) clearly as the ones that aren't available.
>
> Regards,
> Aqeel
Dan's notes worked perfectly for me once I remembered to enable thunderbolt
assist. Thanks djb!
--
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
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
On Wednesday, 1 August 2018 12:04:13 UTC+10, D. J. Bernstein wrote:
> I finally decided to resort to patching the kernel. Suspend now seems to
> work normally in several tests on a Lenovo X1 ThinkPad Carbon 6th
> generation under Qubes R4.0. The idea of the patch is to do
>
>if (sleep_state == ACPI_STATE_S3) {
> *sleep_type_a = 5;
> *sleep_type_b = 5;
> return_ACPI_STATUS(AE_OK);
>}
>
> near the top of acpi_get_sleep_type_data() (right after the "Validate
> parameters" part) in linux/drivers/acpi/acpica/hwxface.c. This has the
> same effect as the DSDT patches running around for this laptop: telling
> the kernel that the laptop supports S3 state (which the hardware _does_
> support---the starting problem is that the BIOS fails to announce this),
> and more specifically that S3 is hardware sleep type 5.
>
> Of course, simply adding the lines above wouldn't be appropriate for
> non-laptops, or laptops where S3 is another hardware sleep type. The
> actual patch is instead triggered by
>
>* DMI reporting this laptop, or
>* "acpi_force_s3=5" on the kernel command line (so users have a
> relatively easy way to handle newer laptops with the same problem).
>
> If this patch survives more tests and review (I'm not a Linux kernel
> expert) then it should be suitable for upstream adoption. I've attached
> the patch, and some notes on how I compiled a patched kernel for Qubes
> R4.0.
>
> Beyond the patch, I've put
>
>mem_sleep_default=deep
>
> into my /boot/efi/EFI/qubes/xen.cfg on the kernel= line for the patched
> kernel, to tell the kernel to use S3 for suspend---otherwise it uses
> s2idle. The importance of S3 vs. s2idle for this laptop is different on
> Qubes from vanilla Linux: there are many reports of s2idle consuming
> more power than S3 on vanilla Linux, but Qubes seems unique in s2idle
> not waking up at all. I don't see a serious argument for s2idle when S3
> is supported, so I'm not sure why mem_sleep_default prefers s2idle over
> S3; even if there's a reason for this, maybe there would be general
> interest in a second patch that disables s2idle on this laptop.
>
> ---Dan
Hi Dan,
I followed kernel-compile-notes.txt twice. The first time failed, the second
time worked a charm with minor changes to the method. These are my notes on the
experience.
Before I proceed, I note that the current version of the qubes-linux-kernel git
on stable-4.14 is 4.14.67-1. This is the version of the kernel that I have
compiled and applied your patch to.
The first (failed) attempted, I was on a fresh install of Qubes R4.0, kernel
4.14.18-1. Compiling the kernel seemed to work, as did installing. Upon boot
and unlocking my hard-drive the system never seemed to get anywhere on the
loading. Upon pressing escape I noticed I was being spammed with a `dracut`
error before eventually it dropped to an emergency shell. A more forward
thinking me would have written down the error message. I simply reinstalled
Qubes R4.0 fresh to start over.
The second (successful) attempt was after I had updated dom0. I was running
kernel 4.14.57-2. I knew that this was an earlier version than the one I was
going to compile so it wasn't going to be an issue (as you've described in your
excellent notes). I doubt updating dom0 had anything to do with the success of
this attempt, instead I did two things differently to your notes:
1. I ran the following command twice, superfluous I presume:
make verify-sources
2. I ran the following command in dom0 after installing:
dom0 $ sudo dracut -f "/boot/efi/EFI/qubes/initramfs-$version.img" "$version"
Paying special attention that the variable $version was expanded correctly.
After adding the kernel parameter:
mem_sleep_default=deep
to the appropriate line in /boot/efi/EFI/qubes/xen.cfg - again as you've
described.
To conclude, I can confirm that your patch works for version 4.14.67-1 of the
qubes-linux-kernel too. That is, standby and wake from standby work as intended
and the command:
dmesg | grep ACPI | grep supports
yields:
ACPI: (supports S0 S3 S5)
on my Carbon X1 Gen 6, i7 8550U.
However, perhaps unrelated, I have noticed the CPU doesn't turbo boost. Running
the following command in dom0:
xenpm get-cpufreq-states
shows that only 13 / 16 P-States are usable with P0, P1, P3 (the turbo states)
clearly as the ones that aren't available.
Regards,
Aqeel
--
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/473a1a33-a7cb-45e3-8d2b-38fb7802bda0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
On Saturday, August 11, 2018 at 6:28:41 PM UTC-4, rich...@gmail.com wrote: > Success! > > By process of elimination, I was able to pinpoint the wakeup issue to sys-usb. > > With further testing, I found that removing the USB-C Thunderbolt 3 > Controller from sys-usb's device list resolved the issue. > > Will test further to see if fiddling with Thunderbolt BIOS assist mode will > help. Might a BIOS update might fix this? (The BIOS is on N23ET40W v1.15 from > 2018-04-13). Is there a way to update the BIOS without a Windows 10 utility? > > Side notes: > > 1. Despite dmidecode reporting back the proper magic LENOVO and X1 Carbon > magic strings, I still need to manually specify acpi_force_s3=5 into my > xen.cfg, otherwise the kernel patch does not appear to work. > > 2. My aside about needing the LiveCD Lenovo trick was irrelevant. I can > install from an install disk created with dd, so I don't know what I was > doing wrong the first time. Turning Thunderbolt BIOS assist on should be the solution. I had the same issue in Linux and fixed it by turning that on. -- 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/9f7a0488-6b32-4e9e-a003-3c86679b6fe2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
You can check the steps documented in this wiki. http://thinkwiki.de/BIOS-Update_ohne_optisches_Laufwerk_unter_Linux You basically need to download the BIOS update as ISO image, then use 'geteltorito' to convert it to an image. Then 'dd' it to a USB stick. -- 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/f2dc22a3-e9c1-495b-ba29-46a22b84ced9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
Success! By process of elimination, I was able to pinpoint the wakeup issue to sys-usb. With further testing, I found that removing the USB-C Thunderbolt 3 Controller from sys-usb's device list resolved the issue. Will test further to see if fiddling with Thunderbolt BIOS assist mode will help. Might a BIOS update might fix this? (The BIOS is on N23ET40W v1.15 from 2018-04-13). Is there a way to update the BIOS without a Windows 10 utility? Side notes: 1. Despite dmidecode reporting back the proper magic LENOVO and X1 Carbon magic strings, I still need to manually specify acpi_force_s3=5 into my xen.cfg, otherwise the kernel patch does not appear to work. 2. My aside about needing the LiveCD Lenovo trick was irrelevant. I can install from an install disk created with dd, so I don't know what I was doing wrong the first time. -- 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/c57c198f-d566-4b77-b1d8-74dbe051d898%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
Success! By process of elimination, I was able to pinpoint the wakeup issue to sys-usb. With further testing, I found that removing the USB-C Thunderbolt 3 Controller from sys-usb's device list resolved the issue. Will test further to see if fiddling with Thunderbolt BIOS assist mode will help. Might a BIOS update might fix this? (The BIOS is on N23ET40W v1.15 from 2018-04-13). Is there a way to update the BIOS without a Windows 10 utility? Side notes: 1. Despite dmidecode reporting back the proper magic LENOVO and X1 Carbon magic strings, I still need to manually specify acpi_force_s3=5 into my xen.cfg, otherwise the kernel patch does not appear to work. 2. My aside about needing the LiveCD Lenovo trick was irrelevant. I can install from an install disk created with dd, so I don't know what I was doing wrong the first time. -- 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/30f2ccdf-eb0c-4cef-aa4b-5acb9cc8ae80%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
I have followed these steps with a degree of success. >From a fresh Qubes install, I have compiled the patched kernel and specified >the following kernel command options in my /boot/efi/EFI/qubes/xen.cfg file: acpi_force_s3=5 mem_sleep_default=deep The system now responds to the power button being pushed or the lid being opened in a sleep state. The pulsing power button light turns to a steady light. So that's nice. Unfortunately, the system freezes within seconds. Sometimes at the X lock screen. Sometimes it just remains blank. (Given that this is a UEFI install using the Lenovo Red Hat LiveCD usb disk creation trick, I do not know how to otherwise specify kernel command options at boot. Should I get a menu similar to the GRUB menu I see on a legacy install? Because I don't. I see a row of penguins and then the typical scrolling wall of linux boot text) Any thoughts? -- 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/2ea17c71-0bcf-4dd3-95da-102037d7ee6d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
On Wednesday, August 1, 2018 at 12:11:10 PM UTC+2, jdow...@gmail.com wrote: > You my friend are a hero. > > I get inspired by people like you to contribute to open source projects. > > I followed your guide to the letter and got the results you were describing > exactly. > > I believe your efforts should be documented in the qubes wiki. > > Let me know how you are getting along with the set up, did you try any under > volting? I can also confirm initial success with these instructions. Should we be on the lookout for any other issues with suspend, now that waking up works? -- 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/f82c3032-d658-4511-a53b-a53747d46f6e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
