[qubes-users] Re: T490 HCL / power consumption after suspend
It appears this a result of hyperthreading being enabled, see conversation in https://github.com/QubesOS/qubes-issues/issues/5210 On Friday, July 26, 2019 at 10:15:31 PM UTC-7, andrew...@gmail.com wrote: > > Ok, this wasn't expected but I actually see similar behavior on my T470 - > power consumption is roughly 2X on the T470 after suspend/resume, and 3-4x > on the T490. Can someone else try measuring power consumption before and > after the first suspend/resume cycle and report back? I have a feeling this > could be impacting more people. > > On Friday, July 26, 2019 at 5:36:58 PM UTC-7, Andrew Sorensen wrote: >> >> I didn't see any reports of Qubes on the T490, so I figured I'd start >> one: I just got a T490 (i7 model with 32GB of ram), and was able to get >> Qubes 4.0.2rc1 installed and usable (after excluding the network card from >> FLR). For the most part, it appears it will be as usable as Qubes on my >> T470 with one problem: power consumption. On a cold boot, everything seems >> acceptable and I get a good number of hours of battery life, however after >> suspending the laptop and resuming, power consumption spikes from 4W to >> 15W+, reducing battery life down to a few hours and keeping the fan pegged. >> >> I've tried upgrading to kernel-latest (e.g. 5.x) and using >> tlp/powertop/xenpm to troubleshoot further, but nothing stuck out. I also >> downloaded Fedora 30 and was able to suspend and resume without seeing the >> additional power increase. My understanding is that power management is >> handled by Xen, and not Dom0 so I think I'm pretty much out of options, but >> figured I'd drop a note in case anyone else runs into this. I don't plan to >> investigate much further since I also have the T470, but look forward to >> trying again when Qubes 4.1 is available in some form. >> >> Also - if someone else wants to test/play around - make sure to use the >> latest qubes release. I first tried with the version I used to setup my >> T470 since I didn't have a lot of time, but there were graphical issues >> (*very* slow painting of the installer/desktop UI), and wireless and wired >> networking were unavailable. >> > -- 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/5b5d11d5-0db8-426c-89d0-4b8f30ca4136%40googlegroups.com.
Re: [qubes-users] Thinkpad T490 HCL report
On Sun, Jul 28, 2019 at 11:44 wrote: > Hi all, > > I recently got access to an T490 and wanted to migrate my Qubes > installation to the machine. I can say that the latest rc release for 4.0.2 > works ok. Although I had to put the PCIe devices to "no-strict-reset=true" > so my sys-net VM would start. > > Hope that's useful for someone in the future. > > Some tidbits from improving the situation: > > First of all, I had trouble with suspend on my t480+qubes until I > disabled Thunderbolt completely in the BIOS. I have no idea why this was > interfering, but since i'm not using it, whatever. > > I tried to get the Qubes stable release 4.0.1 to work, but it had really > buggy graphics drivers. After attempting the Qubes Release 4.0.2-rc1, > the graphics are super smooth. You might also have luck with installing > the stable, do the PCIe trick I had to pull off (more on that later) and > install a newer dom0 kernel. But I haven't tried that. > > ```qvm-pci``` > > this gives back a list of devices, you'll see some devices added to > sys-net. Perfect! We're going to detach them and then attach them with > an extra option and make that persistent. > > qvm-pci detach sys-net dom0: > qvm-pci detach sys-net dom0: > > qvm-pci-attach --persistent --option no-strict-reset=true sys-net > dom0: > qvm-pci-attach --persistent --option no-strict-reset=true sys-net > dom0: > > After this, start sys-net VM and subsequently the sys-firewall Vm and > everything should work fine. > > I also updated to a latest kernel, but it didn't change anything for me, > so it isn't necessary. > > sudo qubes-dom0-update > sudo qubes-dom0-update kernel-latest > > I noticed that batterylife on the t490 and qubes is super super super > sad. It lasts 2.5 maybe 3 without wifi and low lighting for the display. > > The HCL: > > --- > layout: > 'hcl' > type: > 'notebook' > hvm: > 'yes' > iommu: > 'yes' > slat: > '' > tpm: > 'unknown' > remap: > 'no' > brand: | > LENOVO > model: | > 20N3S2MV00 > bios: | > N2IET61W (1.39 ) > cpu: | > Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz > cpu-short: | > FIXME > chipset: | > Intel Corporation Device [8086:3e34] (rev 0b) > chipset-short: | > FIXME > gpu: | > Intel Corporation Device [8086:3ea0] (prog-if 00 [VGA controller]) > gpu-short: | > FIXME > network: | > Intel Corporation Device 9df0 (rev 30) > Intel Corporation Ethernet Connection (6) I219-V (rev 30) > memory: | > 32550 > scsi: | > > usb: | > 1 > versions: > > - works: > 'partial' > qubes: | > R4.0 > xen: | > 4.8.5-7.fc25 > kernel: | > 5.1.15-1 > remark: | > dTPM 2.0 doesn't work. > credit: | > DrWhax > link: | > FIXLINK > I also posted about the T490 recently - I saw similar issues with battery life, but only after a suspend/resume cycle - on first boot it’s ok. Battery life in Fedora 30 directly installed is pretty good (at least double, if not more). -- 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/CAJkkfNjHW3mSZf9go3tiwSBe_GNiag_ebtDaBsPBbN4Hv3dNew%40mail.gmail.com.
[qubes-users] T490 HCL / power consumption after suspend
I didn't see any reports of Qubes on the T490, so I figured I'd start one: I just got a T490 (i7 model with 32GB of ram), and was able to get Qubes 4.0.2rc1 installed and usable (after excluding the network card from FLR). For the most part, it appears it will be as usable as Qubes on my T470 with one problem: power consumption. On a cold boot, everything seems acceptable and I get a good number of hours of battery life, however after suspending the laptop and resuming, power consumption spikes from 4W to 15W+, reducing battery life down to a few hours and keeping the fan pegged. I've tried upgrading to kernel-latest (e.g. 5.x) and using tlp/powertop/xenpm to troubleshoot further, but nothing stuck out. I also downloaded Fedora 30 and was able to suspend and resume without seeing the additional power increase. My understanding is that power management is handled by Xen, and not Dom0 so I think I'm pretty much out of options, but figured I'd drop a note in case anyone else runs into this. I don't plan to investigate much further since I also have the T470, but look forward to trying again when Qubes 4.1 is available in some form. Also - if someone else wants to test/play around - make sure to use the latest qubes release. I first tried with the version I used to setup my T470 since I didn't have a lot of time, but there were graphical issues (*very* slow painting of the installer/desktop UI), and wireless and wired networking were unavailable. -- 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/10248715-2b1f-483f-be80-7c3c7300e7b5%40googlegroups.com.
Re: [qubes-users] New HCL Entry: Lenovo ThinkPad T470 (20HDCTO1WW)
On Saturday, December 2, 2017 at 1:02:52 AM UTC-8, Joe Hemmerlein wrote: > On Friday, December 1, 2017 at 2:01:47 PM UTC-8, Stephan Marwedel wrote: > > I have installed Qubes 3.2 successfully on my Thinkpad T470p > > (20J6CTO1WW). This machine is pretty similar to the T470, except > > that is has a quad-core i7 CPU. It runs perfectly and all Qubes > > functionality is available on that machine. The installation, > > however, was not an easy task. > > > > > > > > 1. Booting: UEFI is not a problem for the Qubes installer, but > > you must pay attention on how you created the bootable install > > media. Just using dd is not sufficient. I had to use the > > livecd-tools from Fedora to create the install media. After > > creating the media I had to manually set the partition label to > > BOOT using the dosfslabel utility. Otherwise, I was unable to boot > > from the media. It was not necessary to fall back to legacy boot > > or to mess around with the Grub configuration. > > > > > > 2. Networking: The onboard ethernet hardware is only supported by a > > 4.9 kernel or later, but the installer containts a 4.4 kernel. So > > you have no network in teh sys-net vm. You have to manually download > > the source of the Intel network driver, compile it and install it > > using a USB media in the template vm. As soon as you have network > > access, upgrade dom0 to using the testing or unstable repository. > > > > > > > > 3. Graphics: The Kaby Lake Intel graphics works well with a newer > > kernel. > > > > > > > > Summary: Prepare the boot media with more care than for older > > machines. Compile the ethernet network driver manually to enable > > network access after the install. Upgrade to kernel 4.9 in dom0 as > > soon as possible to enable graphics and networking support of your > > Thinkpad. > > Danke, Stephan, your pointers were very valuable! > > At first, I decided to just borrow an external DVD drive and boot off a DVD > burned from the ISO, in UEFI mode. The result however was the same as when > booting from my previously-created USB stick: grub boots, but no matter what > i select, the screen briefly flashes and takes me back to grub. So.. yeah, > the ISO image does not appear to be usable out of the box on some UEFI > devices, even when burning it to a DVD. > > Your description of the livecd-tools helped make good progress, but still > without ability to boot the installer completely, but they sent me in the > right direction. I then found > https://groups.google.com/forum/#!topic/qubes-users/4VsKdxnKHBk, which > described a process very similar to yours (it omits the part about using > dosfslabel, but has a part about also updating the xen.cfg file). > > Altogether, this did the trick! > > In condensed form, this is what i did to create a USB install stick that > works with UEFI on the T470: > 1. Use the "livecd-iso-to-disk" utility from fedora livecd-tools to put the > ISO image onto an USB stick > 2. rename the USB stick's partition label to BOOT > 3. edit the /BOOT/EFI/xen.cfg file on the USB stick's partition to make sure > all LABEL= instances are replaced with LABEL=BOOT > > In a bit more detail: > - booted Fedora 26 live USB stick in UEFI mode > - installed livecd-tools: sudo dnf install livecd-tools > - attached a USB stick that contains the Qubes 4 RC3 x86-64 ISO image file > - verified digests and signatures for ISO image > - attached another USB stick to the fedora live instance to put the Qubes > installer on (/dev/sdd) > - repartitioned /dev/sdd USB stick with a single (8GB) FAT32 partition and > MBR, and marked bootable > - started imaging: sudo livecd-iso-to-disk > /run/media/liveuser/qsrc/Qubes-R4.0-rc3-x86_64.iso /dev/sdd1 > - waited for everything to complete (took quite a while) > - used dosfslabel to rename the qubes installer USB stick: sudo dosfslabel > /dev/sdd1 BOOT > - manually edited the xen.cfg file on the install stick (located at > /BOOT/EFI): replaced all instances of > "LABEL=Qubes-R4.0-rc3-x86_64" with "LABEL=BOOT" > > Success! > > Now one thing that is different is that after installation, the > correct/selected keyboard layout (in my case English-Dvorak) isn't active > when prompted for the LUKS passphrase; but after entering it in QWERTY, Qubes > OS boots and completes configuration. > > But the primary issue, not being able to boot in UEFI mode, is solved. > > Thanks everyone for your input! > > Cheers, > -joe Thanks for the detailed write-up. Based on the steps you've provided, it appears that the TPM is present in /sys/class/devices/tpm, but no PCRs are present and it's not possible to take ownership of the TPM with tpm_takeownership. Did you get further on this, e.g. to setup anti-evil-maid? -- You received this message because you are subscribed to the Google Groups
