HCL - Lenovo ThinkPad T460s (20F9CTO1WW)

[li...@mullvad.net]

I have now tested Qubes 3.1 on a new ThinkPad T460s. Here are my results.
Most of these things were tested after I upgraded the kernel to 4.2.8 from the unstable repo.

Installation and BIOS/UEFI:
I had to disable secure boot in the firmware before my USB stick would boot, just as expected. I could boot and install in both legacy and UEFI only mode. Installation went smooth in all cases.
I disabled Intel AMT, WiGig, wake on lan, and other features I did not want, still works fine.
This computer runs version 1.05 of the bios/firmware.

Graphics and resolution:
After the first boot when I logged into both KDE and xfce there were serious graphical glitches, but a reboot fixed this. The initial setup added the `i915.preliminary_hw_support=1` option to the kernel arguments and with this activated the glitches went away after the reboot. I still had some graphical glitches when I tried using two external monitors at the same time, but upgrading the kernel to 4.2.8 seem to have fixed this.

I have the 2560x1440 monitor on this laptop and the text is small but readable (subjective). In the long run my eyes will get weary from this, so I would like to scale things up in my desktop environment but I was unable to do that so far.

I didn't try to get sound from the HDMI yet.

Disk/filesystem:
In this laptop I have the 512 GB sata3 disk. I choose this over the NMVe option because I have read that it can cause problems.
I have tried installing both unencrypted directly to ext4 as well as encrypted (LUKS) with both LVM and Btrfs. Both work but Btrfs needs some manual fixes. When I installed on Btrfs I was dropped to the emergency shell on first boot and I got the exact same problem as in this thread:
https://groups.google.com/forum/#!searchin/qubes-users/os-release/qubes-users/iM_ZI0zqLKE/6WqgI-gZBwAJ
But I could fix it by moving everything from `/sysroot/root` into `/sysroot` with the help of this emergency shell/console.

LAN:
Wired LAN worked out of the box.

WLAN:
With the 4.1 kernel shipped with Qubes 3.1 the sys-net VM would not show my wifi card in ifconfig. Upgrading to kernel 4.2.8 fixed that problem, and the wifi worked flawlessly.

Webcam:
I started the 'cheese' program in my sys-usb VM and I got the webcam working directly. I think this was after the kernel upgrade to 4.2 so I'm not sure how it worked before that.

Sound:
The built in speakers and microphone work out of the box. Connecting headphones is also painless, both the headphone speakers and microphone work.
When logging in to the desktop environment there is a short crackling noise in the speakers, not too annoying though.

TrackPoint:
The red trackpoint stick itself works out of the box, the sensitivity is a bit low and I had a hard time to find a good setting, but it works. What work less well are the buttons that go along with the trackpoint, the three ones above the trackpad. Because of a bug/problem in the kernel a press of any of these buttons immediately registers as both a press and a release. Thus it's impossible to click and drag using these buttons. It's also impossible to scroll using the middle button and the trackpoint.
The bug is described here: https://bugzilla.kernel.org/show_bug.cgi?id=114321
A patch has been submitted, but it's unclear what kernel version it will be included in. It's probably going to take a long time before it's available in Qubes unless you build your own kernel.

Keyboard:
Volume and screen brightness hotkeys work. Keyboard works as expected (what is there to test?).

HVM:
I was able to install Ubuntu 14.04.4 in a HVM VM and boot it, worked fine.

Suspend/sleep/poweroff:
There seem to be some power state problem on this computer. First of all, when powering down the kernel stops at 'reboot: Power down' in the console and the led on the power button shuts down but the computer and monitor is still awake, I have to hold down the power button to actually kill it.

Suspending the computer shuts down the monitor and the power button starts to slowly pulsate, but I'm unable to wake it up after this. This is my biggest problem with this computer at the moment. Any help to fix suspend would be very appreciated.

-----------

Kernel upgrade:
To upgrade the kernel I simply did the following in dom0:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel-qubes-vm

-----------

Summary:

• Many things work out of the box
• Wifi and stable graphics require a kernel upgrade
• The trackpoint is not very useful without the buttons
• Suspend and powering off is broken!

I will try to monitor this thread, so if there is anything else you want me to try out on this computer just post here.

/Linus

[li...@mullvad.net]

 
I tried installing vanilla Fedora 23 on the laptop to test suspend there. Fedora 23 uses version 4.2.3 of the Linux kernel and is thus slightly older than the 4.2.8 version I tried in Qubes. In this fedora install I'm able to make the computer go to sleep with 'systemctl suspend' in a terminal. So far it's the same as in Qubes, the difference starts when I press the Fn-button (according to the laptop manual, this is how you wake it from suspend). When pressing the Fn-button the power led comes back to a steady glow, thus I suspect that the computer wakes up. The screen is still completely black, but I suspect this is a separate bug related to the quite unstable graphics drivers.

In the nightly build of Ubuntu running kernel 4.4.0 suspending and waking up works flawlessly.

Any ideas what Fedora does right that Qubes does not in order to be able to wake up from suspend? Xen-related maybe? I will try to see if I can find any logs in Qubes when I have installed it again. Any ideas what logs to check?

/Linus

[li...@mullvad.net]

Progress on the suspend/poweroff problem!

When I disable the security chip in the firmware setup Qubes is able to shut down the hardware completely on poweroff. It's waking up from suspend with the security chip disabled. So I have overcome the first problem here. Next problem is the graphics when the laptop wakes up again. I'm running the 4.2.8 kernel from qubes-dom0-unstable.

• With i915.preliminary_hw_support=0 the computer wakes up to a completely black screen. The backlight turns on but no picture.
• With i915.preliminary_hw_support=1 the computer wakes up with the screen full of colorful vertical lines. Moving the mouse causes a small square to move around according to how I use the touchpad.

I guess my only problem left with suspend now is graphics card driver related. Does anyone have any input on how to fix this? Reloading the driver on wakeup or getting a new driver are two things I'm thinking about, but am unsure on how to tackle.

/Linus

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sat, Mar 26, 2016 at 10:44:09AM -0700, li...@mullvad.net wrote:
> Progress on the suspend/poweroff problem!
>
> When I disable the security chip in the firmware setup Qubes is able to
> shut down the hardware completely on poweroff. It's waking up from suspend
> with the security chip disabled. So I have overcome the first problem here.
> Next problem is the graphics when the laptop wakes up again. I'm running
> the 4.2.8 kernel from qubes-dom0-unstable.
>

> - With *i915.preliminary_hw_support=0* the computer wakes up to a

> completely black screen. The backlight turns on but no picture.

> - With *i915.preliminary_hw_support=1* the computer wakes up with the

> screen full of colorful vertical lines. Moving the mouse causes a small
> square to move around according to how I use the touchpad.
>
> I guess my only problem left with suspend now is graphics card driver
> related. Does anyone have any input on how to fix this? Reloading the
> driver on wakeup or getting a new driver are two things I'm thinking about,
> but am unsure on how to tackle.

Maybe it is possible to somehow fix graphics problem after resume. Try
things like switching to text console, or calling xrandr with different
parameters (like xrandr --auto, or changing resolution to something
else, then back to the native one). Yes, you'll need to do it without
seeing actual terminal content, but I believe you'll manage :)
You can also try switching to text console before suspend.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJW+EWOAAoJENuP0xzK19csqaUIAIfi/G5h3wgZOJeePusD737U
ee86dIQWhUv1MhregRaqeMyGSdfRTSNzf2/08uzImCqu+Kxk5T8p4fp6zO/AT/0M
F94clHbxE7tl8pFqDRwxXFWbPL46roJyl6+sgFgLW5jZewvXjYf0qGZtpF8RcRrm
dbmsxwylnJWBttzUj/Of1g7PXqPOXmCIQBoXbHR52gsnBtAPrBvK1c9L+1w4O5GI
jlYH+lUV2tAddbd8/MONnt2zxtppWpeUb5J8LbyZhbIiyU2CodTzz5yOnsENeAr2
gx5UOpn6FdSPPmjqm9Ov7dz1uQ9Td9tfHfqav62SuEVBnDUejnw5ytfCae8ZtBs=
=LxIo
-----END PGP SIGNATURE-----

[li...@mullvad.net]

I tried executing 'systemctl suspend' from tty2 when I was not even logged in to xfce, same problem when the computer comes back on, colorful vertical lines.

I also tried execute the following script in a terminal within xfce (dom0):

#!/bin/bash
xrandr --output eDP1 --off
sleep 2
systemctl suspend
sleep 10
xrandr --output eDP1 --auto
echo 'sleep.sh done' > sleep.log

From the log I see that the entire script runs. When the computer comes back on the monitor is black (because it's turned off), but as soon as the sleep returns and it's turned on by xrandr it comes back on with the colorful lines.

If I try changing to a tty console nothing happens, the screen sometimes goes black for a second but then the lines come back.

I don't know exactly how the tty's interact with the graphics card, but since the same thing happens there I guess it's not because of the X graphics driver? Or it might be, since X was still running in the background when I did the test.

More clues and stuff to try appreciated :)

/Linus

[Kevin Moraga]

Hi,

Same here. But with a T460. I tried to compile kernel 4.4.6 also, but without any success. The kernel worked with my second laptop, but no with skylake processor :(

Also I tested skylake with linux kernel without xen. These are my results:

System: T460

Kernel 4.2: 
   - "echo freeze > /sys/power/state" works fine
   - "echo mem > /sys/power/state" not working

Kernel 4.3: 
   - "echo freeze > /sys/power/state" works fine
   - "echo mem > /sys/power/state" works fine

Kernel 4.4.5: 
   - "echo freeze > /sys/power/state" works fine
   - "echo mem > /sys/power/state" works fine

 

/Linus

[li...@mullvad.net]

Interesting. Maybe it's more of a xen + skylake problem rather than linux + skylake. Not very surprising. Maybe we need to wait for a newer xen release or maybe it's still possible to work around in some way. As I wrote earlier, everything worked fine for me in Ubuntu with kernel 4.4 as well. Trying to upgrade to xen 4.6.1 might be an idea. I didn't see any skylake/i915 related fixes, but worth a try.

I'm interested in how you compiled a 4.4 kernel. I tried following the instructions on https://groups.google.com/forum/#!searchin/qubes-users/building$20kernel$204.4/qubes-users/-OCnytFAZwI/oJuEwcxnAwAJ and https://www.qubes-os.org/doc/qubes-r3-building/ but the build failed. Did you use qubes-builder or did you just build a vanilla kernel? If you used the qubes-builder, did you comment out all the patches towards the kernel? I can't say I tried very much, but getting some hints from you would be easier than fumbling around myself again :)

I tried turning off the power saving states on the GPU with the boot argument i915.enable_rc6=0 but that didn't help either.

Also, I can't get echo freeze > /sys/power/state to work in Qubes either. It just makes the screen turn black and I can't find a way to make it wake up/turn the screen on again

/Linus

[li...@mullvad.net]

For people reading this thread to evaluate the Thinkpad T460s for either Qubes or other Linux usage I can report that battery life is approximately 5 hours in Qubes R3.1 for me when running Kernel 4.2.8. This is based on three almost full discharges of both internal batteries. I have applied all power saving that powertop suggested but the battery life was not affected much. For these 5 hours I was using wifi all the time, streaming music most of the time, having the screen at 50% brightness (OK brightness for the office I'm in during daytime). I also used an external hard drive for a few minutes and I did some intensive disk operations for some minutes (VM snapshotting, upgrading, cloning etc), otherwise I was mostly browsing the web.

I'm going to look into improving the battery life later sometime when I have time, but 5 hours is what I get out of a fairly default Qubes install. Any hints on how to improve it would be highly appreciated.

At the moment I run this script in dom0 for power saving:

#!/bin/bash

echo 5 > /proc/sys/vm/laptop_mode

# Increase timeout before writing caches to disk to 15 secs (default 5)
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs

echo 'Y' > /sys/module/snd_hda_intel/parameters/power_save_controller
echo 1 > /sys/module/snd_hda_intel/parameters/power_save

# Activate SATA power saving
echo 'min_power' > /sys/class/scsi_host/host0/link_power_management_policy
echo 'min_power' > /sys/class/scsi_host/host1/link_power_management_policy

# Activate driver power saving mode for all pci devices
for d in /sys/bus/pci/devices/*/power/control; do
    echo 'auto' > $d
done

/Linus

[gabi...@gmail.com]

Hi, Lenovo T460 with the same issues here.
I followed your hint about disabling the Security chip and it wake up now but with the lines. And the idea is to use the TPM, so stuck in the middle.

Another issue is that external usb keyboard does not work on dom0 or VMs, and it was never assigned to anything, when trying to look for the usb plugged using libusb, it returns "unable to run libusb: -99"

Another minor issue is that usb mouse is not working after turning on, I need to unplug/plug.

I am not that technical for working with the scripts.
I will submit all the details of my set up tomorrow.

Best regards,
gabi

[li...@mullvad.net]

I also want TPM working. However, I feel suspend is more important/convenient to have and I feel that I can start looking into TPM after solving the suspend issue so I have it deactivated at the moment. I didn't get any further than in my last post. Please post your setup.

I guess you are running a separate UsbVM? I am also doing that and had some forwarding problems for my mouse (same might apply to your keyboard). I would get the dialog asking me if I wanted to accept forwarding of qubes.InputMouse from sys-usb to dom0, but upon accept nothing happended. I did the forwarding manually, for debugging, with the following command in dom0:

$ qvm-run -p sys-usb 'sudo input-proxy-sender /dev/input/event1' | sudo input-proxy-receiver --mouse

and that made the mouse work. For some reason the automatic forwarding on newly plugged in mice magically started working after I had stopped using this hack. Try the same but replace --mouse with --keyboard and replace /dev/input/event1 with the keyboard in your sys-usb and see if that works for you.

When it comes to your mouse, I guess that is because the forwarding starts on plug events, so you have to plug it in when it's on. That is just a guess however.

/Linus

[gabi...@gmail.com]

Hi,
In my case when shutting down the pc is never turned off completely, I need to kill it.

The issue for waking up after sleep still remains, lines or black screen.

And about the keyboard and mouse, I do not remember if there was any option during the installation for running a separate usbVM neither that I created a dedicated one after that.
The usb keyboard works during start up for the encryption password, but is already not working during user login, and not in dom0 or any vm that I tested.

I found Marek replying about not elabling usb vm, "yes, you can simply not enable USB VM configuration in that case - you'll see such optioni during first boot after installtion" How can I find that?

I would try the command that you sent me, but how do you know what event is my keyboard?

qvm-block -l
returns no results

sudo udevadm trigger --action=change
returns no results

lsusb
on dom0 returns:
unable to initialize libusb: -99


This is all that I have thank you, this is the report:
---
layout:
'hcl'
type:
'notebook'
hvm:
'yes'
iommu:
'yes'
tpm:
'unknown'
brand: |
LENOVO
model: |
20FNCTO1WW
bios: |
R06ET33W (1.07 )
cpu: |
Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
cpu-short: |
FIXME
chipset: |
Intel Corporation Sky Lake Host Bridge/DRAM Registers [8086:1904] (rev 08)
chipset-short: |
FIXME
gpu: |
Intel Corporation Sky Lake Integrated Graphics [8086:1916] (rev 07) (prog-if 00 [VGA controller])
gpu-short: |
FIXME
network: |
Intel Corporation Ethernet Connection I219-V (rev 21)
Intel Corporation Wireless 8260 (rev 3a)
memory: |
15811
scsi: |
Samsung SSD 840 Rev: CB6Q
versions:

- works:
'FIXME:yes|no|partial'
qubes: |
R3.1
xen: |
4.6.0
kernel: |
4.1.13-9
remark: |
FIXME
credit: |
FIXAUTHOR
link: |
FIXLINK
1,1 Top

[gabi...@gmail.com]

Hi again, keyboard is working now!!!
I reviewed the issues list and I found the github.com/qubesos/qubes-issues/issues/1618 with the discussion about how to handle the keyboard: InputMouse / InputKeyboard, etc.


And from the releases note: Out of the box USB VM found https://github.com/QubesOS/qubes-app-linux-input-proxy/blob/master/README.md


And trying to use your command and the above link, first identified the device: ls /dev/input/by-path
(the README.md says "by-id" but this doesn't exist in input folder)
I found this device listed first, so I guess it would be event0:
platform-i8042-serio-0-event-kbd
and several mouse events...

Tried your command:
qvm-run -p <someVMhere> 'sudo input-proxy-sender /dev/input/event0' | sudo input-proxy-receiver --mouse

Instead of <someVMhere> I tried:
-sys-usb, returns not found (I don't have a VM with that name)
-dom0 get some python errors.
-a real VM says "input-proxy-sender command not found"


So, back to the README.md link, follow the Packages explanation section and run:
/etc/qubes-rpc/policy/qubes.InputMouse
Result:
sys-net dom0 allow,user=root
sys-net dom0 ask,user=root
$anyvm $anyvm deny

run:
/etc/qubes-rpc/policy/qubes.InputKeyboard
Result:
$anyvm $anyvm deny

So, I edited the InputKeyboard same as InputMouse, restarted, and Bingo!!!
It works on dom0 and all the VM that I tested.

Thank you for your help, sorry for too many details.
I will keep tunned about the screen issue.


Regards,
gabi

[gabi...@gmail.com]

In your command I did use --keyboard, no --mouse as I typed.
Tx.

[gabi...@gmail.com]

> Many things work out of the boxWifi and stable graphics require a kernel upgradeThe trackpoint is not very useful without the buttonsSuspend and powering off is broken!

>
> I will try to monitor this thread, so if there is anything else you want me to try out on this computer just post here.
>
> /Linus

Hi,
If i change the power options to turn off the screen with tmp disable, it shows the color lines, and when trying to log in I do not see the password field, but while moving the mouse, the lines move too.

with tpm enabled, the screen is blank, enter the password in the same way, and star moving the mouse or trackpad, and suddennly the screen is back but not really responding, seems that the mouse "drag" the desktop when moving mouse, desktop vibrates, moves a bit trying to re-arrange itself, and going blank for some moments.

With the color lines, first case above, or blank screen the behavior seemms similar

You can see this video,
https://www.youtube.com/watch?v=S3Bhomt7OrY&feature=youtu.be

Regards,
Gabriel

[li...@mullvad.net]

Would be interesting to upgrade the UEFI firmware and/or the microcode directly from Linux. My t460s is running firmware 1.05 but I see both 1.06 and 1.08 come with microcode patches[1]. According to some sites upgrading the microcode is the solution for some power problems on skylake [2]. Did anyone try patching this? Since suspend works in Ubuntu on my computer either Ubuntu patches the microcode or there is a fix that does not involve microcode, but I think it can't hurt to have the newest one.

[1]: https://download.lenovo.com/pccbbs/mobiles/n1cuj04w.txt
[2]: https://news.ycombinator.com/item?id=11492070 and https://mjg59.dreamwidth.org/41713.html

[Jacob Richard]

I can confirm that building kernel 4.5.3 fixed the sleep issues on my skylake x260. Sleep and wake work as they should, and battery life seems to be up (although still too low, at around 11 hours, i think).

-Jake

[li...@mullvad.net]

 That sounds very good Jacob. Could you provide any instructions or maybe a link to how you built kernel 4.5.3 for Qubes? did you apply any of the qubes specific patches, or did you build a vanilla kernel without any Qubes/Fedora specific stuff?

[Kevin Moraga]

oh cool!. Do you have any specific instructions or kernel configuration to share? :D because I still having issues with new kernels, I got a problem with a kernel's page fault on Xen at boot. (I tested it with 4.4.8 and 4.5.3).

Also I tested 4.1.23 and we had the same problem with the display after wake up.

This is what I got:

 Xen 4.6.0-13.fc20
(XEN) Xen version 4.6.0 (user@) (gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)) debug=n Thu Feb 11 03:34:22 UTC 2016
(XEN) Latest ChangeSet:
(XEN) Console output is synchronous.
(XEN) Bootloader: GRUB 2.00
(XEN) Command line: placeholder noreboot=true sync_console com1=115200,8n1,0xe080,0 console=com1,vga dom0_mem=min:1024M dom0_mem=max:4096M xsave=0
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009d000 (usable)
(XEN)  000000000009d000 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000b9ba4000 (usable)
(XEN)  00000000b9ba4000 - 00000000cca77000 (reserved)
(XEN)  00000000cca77000 - 00000000cca78000 (ACPI NVS)
(XEN)  00000000cca78000 - 00000000d7f77000 (reserved)
(XEN)  00000000d7f77000 - 00000000d7f78000 (ACPI NVS)
(XEN)  00000000d7f78000 - 00000000d7f79000 (reserved)
(XEN)  00000000d7f79000 - 00000000d7fc7000 (ACPI NVS)
(XEN)  00000000d7fc7000 - 00000000d7fff000 (ACPI data)
(XEN)  00000000d7fff000 - 00000000d8100000 (reserved)
(XEN)  00000000d8600000 - 00000000dc800000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fd000000 - 00000000fe800000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed00000 - 00000000fed01000 (reserved)
(XEN)  00000000fed10000 - 00000000fed1a000 (reserved)
(XEN)  00000000fed84000 - 00000000fed85000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000821800000 (usable)
(XEN) ACPI: RSDP 000F0120, 0024 (r2 LENOVO)
(XEN) ACPI: XSDT D7FD1188, 00CC (r1 LENOVO TP-R06          0 PTEC        2)
(XEN) ACPI: FACP D7FF6000, 00F4 (r5 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: DSDT D7FDF000, 12692 (r2 LENOVO TP-R06       1070 INTL 20141107)
(XEN) ACPI: FACS D7FAB000, 0040
(XEN) ACPI: UEFI D7FC2000, 0042 (r1 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: SSDT D7FF8000, 4E2E (r2 LENOVO  SaSsdt      3000 INTL 20141107)
(XEN) ACPI: SSDT D7FF7000, 05C5 (r2 LENOVO PerfTune     1000 INTL 20141107)
(XEN) ACPI: ECDT D7FF5000, 0052 (r1 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: HPET D7FF4000, 0038 (r1 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: APIC D7FF3000, 00BC (r3 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: MCFG D7FF2000, 003C (r1 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: SSDT D7FDD000, 18D2 (r1 LENOVO SataAhci     1000 INTL 20141107)
(XEN) ACPI: SSDT D7FDC000, 0152 (r1 LENOVO Rmv_Batt     1000 INTL 20141107)
(XEN) ACPI: DBGP D7FDB000, 0034 (r1 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: DBG2 D7FDA000, 0054 (r0 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: BOOT D7FD9000, 0028 (r1 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: BATB D7FD8000, 0046 (r1 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: SSDT D7FD7000, 0E73 (r2 LENOVO  CpuSsdt     3000 INTL 20141107)
(XEN) ACPI: SSDT D7FD6000, 03D9 (r2 LENOVO    CtdpB     1000 INTL 20141107)
(XEN) ACPI: MSDM D7FD5000, 0055 (r3 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: DMAR D7FD4000, 00A8 (r1 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: ASF! D7FD3000, 00A5 (r32 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: FPDT D7FD2000, 0044 (r1 LENOVO TP-R06       1070 PTEC        2)
(XEN) ACPI: UEFI D7FA9000, 012A (r1 LENOVO TP-R06       1070 PTEC        2)
(XEN) System RAM: 32179MB (32951556kB)
(XEN) Domain heap initialised
(XEN) ACPI: 32/64X FACS address mismatch in FADT - d7fab000/0000000000000000, using 32
(XEN) Processor #0 6:14 APIC version 21
(XEN) Processor #2 6:14 APIC version 21
(XEN) Processor #1 6:14 APIC version 21
(XEN) Processor #3 6:14 APIC version 21
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-119
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) Failed to enable Interrupt Remapping: Will not enable x2APIC.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2814.458 MHz processor.
(XEN) Initing memory sharing.
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d iommu 1 supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d Snoop Control not enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Shared EPT tables enabled.
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN)  -> Using old ACK method
(XEN) Platform timer is 23.999MHz HPET
(XEN) Allocated console ring of 16 KiB.
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN)  - VMCS shadowing
(XEN)  - VM Functions
(XEN)  - Virtualisation Exceptions
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB
(XEN) Brought up 4 CPUs
(XEN) Dom0 has maximum 696 PIRQs
(XEN) *** LOADING DOMAIN 0 ***
(XEN)  Xen  kernel: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x206c000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   0000000800000000->0000000804000000 (1022882 pages to be allocated)
(XEN)  Init. ramdisk: 000000081f3a2000->00000008217ff200
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: ffffffff81000000->ffffffff8206c000
(XEN)  Init. ramdisk: 0000000000000000->0000000000000000
(XEN)  Phys-Mach map: 0000008000000000->0000008000800000
(XEN)  Start info:    ffffffff8206c000->ffffffff8206c4b4
(XEN)  Page tables:   ffffffff8206d000->ffffffff82082000
(XEN)  Boot stack:    ffffffff82082000->ffffffff82083000
(XEN)  TOTAL:         ffffffff80000000->ffffffff82400000
(XEN)  ENTRY ADDRESS: ffffffff81d5a1f0
(XEN) Dom0 has maximum 4 VCPUs
(XEN) Scrubbing Free RAM on 1 nodes using 2 CPUs
(XEN) ...................................................................................................................................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) **********************************************
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
(XEN) ******* that all output is synchronously delivered on the serial line.
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
(XEN) ******* timekeeping. It is NOT recommended for production use!
(XEN) **********************************************
(XEN) 3... 2... 1...
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 304kB init memory.
mapping kernel into physical memory
about to get started...
[    0.000000] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WC  WP  UC  UC 
[    0.000000] Linux version 4.5.3-9.pvops.qubes.x86_64 (user@qubes-build) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Sun May 8 17:57:48 UTC 2016
[    0.000000] Command line: placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=luks-8b876045-76a7-44d1-a77b-2a7d8cff44d7 rd.lvm.lv=qubes_dom0/root vconsole.font=latarcyrheb-sun16 rd.lvm.lv=qubes_dom0/swap rootwait debug debug_locks_verbose=1 sched_debug initcall_debug mminit_loglevel=4 udev.log_priority=8 log_buf_len=10M print_fatal_signals=1 apm.debug=Y i8042.debug=Y drm.debug=1 scsi_logging_level=1 usbserial.debug=Y option.debug=Y pl2303.debug=Y firewire_ohci.debug=1 hid.debug=1 pci_hotplug.debug=Y pci_hotplug.debug_acpi=Y shpchp.shpchp_debug=Y apic=debug show_lapic=all hpet=verbose lmb=debug pause_on_oops=5 panic=10 sysrq_always_enabled earlyprintk=xen loglevel=8 crashkernel=128M console=hvc0
[    0.000000] x86/fpu: Legacy x87 FPU detected.
[    0.000000] x86/fpu: Using 'lazy' FPU context switches.
[    0.000000] Released 0 page(s)
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009cfff] usable
[    0.000000] Xen: [mem 0x000000000009d000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000b9ba3fff] usable
[    0.000000] Xen: [mem 0x00000000b9ba4000-0x00000000cca76fff] reserved
[    0.000000] Xen: [mem 0x00000000cca77000-0x00000000cca77fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000cca78000-0x00000000d7f76fff] reserved
[    0.000000] Xen: [mem 0x00000000d7f77000-0x00000000d7f77fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000d7f78000-0x00000000d7f78fff] reserved
[    0.000000] Xen: [mem 0x00000000d7f79000-0x00000000d7fc6fff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000d7fc7000-0x00000000d7ffefff] ACPI data
[    0.000000] Xen: [mem 0x00000000d7fff000-0x00000000d80fffff] reserved
[    0.000000] Xen: [mem 0x00000000d8600000-0x00000000dc7fffff] reserved
[    0.000000] Xen: [mem 0x00000000f8000000-0x00000000fbffffff] reserved
[    0.000000] Xen: [mem 0x00000000fd000000-0x00000000fe7fffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] Xen: [mem 0x00000000fed00000-0x00000000fed00fff] reserved
[    0.000000] Xen: [mem 0x00000000fed10000-0x00000000fed19fff] reserved
[    0.000000] Xen: [mem 0x00000000fed84000-0x00000000fed84fff] reserved
[    0.000000] Xen: [mem 0x00000000fed90000-0x00000000fed91fff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved
[    0.000000] Xen: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x00000001464befff] usable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
(XEN) d0v0: unhandled page fault (ec=0000)
(XEN) Pagetable walk from ffff8000006bdee0:
(XEN)  L4[0x100] = 000000081dac4067 ffffffffffffffff
(XEN)  L3[0x000] = 000000081dac2067 ffffffffffffffff
(XEN)  L2[0x003] = 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S: fault at ffff82d080226283 create_bounce_frame+0x12b/0x13a
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.6.0  x86_64  debug=n  Tainted:    C ]----
(XEN) CPU:    0
(XEN) RIP:    e033:[<ffffffff81007f4c>]
(XEN) RFLAGS: 0000000000000246   EM: 1   CONTEXT: pv guest (d0v0)
(XEN) rax: 0000000000000000   rbx: 00000000000d7bdc   rcx: ffff88000206c000
(XEN) rdx: ffff8000006bdee0   rsi: 80000000d7bdc063   rdi: 80000000d7bdc063
(XEN) rbp: ffffffff81c03cb8   rsp: ffffffff81c03c60   r8:  8000000000000063
(XEN) r9:  0000000000000ce1   r10: 0000000000007ff0   r11: 000000000000001f
(XEN) r12: 80000000d7bdc063   r13: 0000000000000001   r14: 00000000000005bf
(XEN) r15: 00000000d7bdc000   cr0: 0000000080050033   cr4: 00000000003126e0
(XEN) cr3: 0000000801c0a000   cr2: ffff8000006bdee0
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffffffff81c03c60:
(XEN)    ffff88000206c000 000000000000001f 0000000000000000 ffffffff81007f4c
(XEN)    000000010000e030 0000000000010046 ffffffff81c03ca0 000000000000e02b
(XEN)    ffffffffff240000 ffffffff81ed8200 0000000000000001 ffffffff81c03cc8
(XEN)    ffffffff8100c066 ffffffff81c03d20 ffffffff81007001 000000000000001f
(XEN)    0000000000007ff0 0000000000000ce1 8000000000000063 80000000d7bdc063
(XEN)    80000000d7bdc063 ffffffff81ed8200 ffff88000206c000 ffffffff81d5f45b
(XEN)    ffffffff81c03d40 ffffffff81d77dc8 00000000fffffa42 8000000000000163
(XEN)    ffffffff81c03db8 ffffffff81d8fd01 ffffffffff20f000 ffffffff81ed8078
(XEN)    0000000000000000 0000000000000001 00000000d7bdc000 0000000000000001
(XEN)    0000000000000000 0000000000001000 ffffffff81c03e28 0000000000000ce1
(XEN)    ffffffff81db6b3b ffffffffff210000 ffffffff81c03e38 ffffffff81c03dc8
(XEN)    ffffffff81d8ff4a ffffffff81c03df0 ffffffff81db635d ffffffff81c03e28
(XEN)    ffffffff81c03e38 0000000000000208 ffffffff81c03e18 ffffffff81db69bf
(XEN)    ffffffff81c03e28 ffffffffff200000 ffffffffff2000f0 ffffffff81c03e78
(XEN)    ffffffff81db70f6 08021f595f4d535f 000000000000011f 0ce1bd5f494d445f
(XEN)    90280042d7bdc000 218a79983291c7e7 0000000000000000 ffffffff81e03900
(XEN)    0000000001000000 0000000000000000 0000000000000000 ffffffff81c03ee0
(XEN)    ffffffff81d6364b ffffffff81c03f00 ffffffff00000010 ffffffff81c03ef0
(XEN)    ffffffff81c03eb0 218a79983291c7e7 218a79983291c7e7 ffffffffffffffff
(XEN)    ffffffff81e03900 0000000000000000 0000000000000000 0000000000000000
(XEN) Hardware Dom0 crashed: 'noreboot' set - not rebooting.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, May 08, 2016 at 11:24:42AM -0700, Kevin Moraga wrote:
> oh cool!. Do you have any specific instructions or kernel configuration to
> share? :D because I still having issues with new kernels, I got a problem
> with a kernel's page fault on Xen at boot. (I tested it with 4.4.8 and
> 4.5.3).

I've just pushed 4.4.8 sources here (including updated patches):
https://github.com/marmarek/qubes-linux-kernel devel-4.4 branch

It isn't thoroughly tested, but it builds fine and Qubes can be started
with it.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXL4oWAAoJENuP0xzK19csHfkH/RJUOFiJrUEN/XVCqavT/eEM
ahkQuzNamZLluFKgk3dxHPfVscxsHLWbk8Y2vrWqS/Lwnh3Mw3pk65Ek5KfUen2s
qviRwp7G3cisuPiBwdX54rzqtmjGukF5dyiywSWqH1UQ075hyJld9xODPauwNGdM
3j1I15ZrVDLsqtG7k9Dq+VV4ziUsKDPBtBRzfSoZgtw+6OczkseZ3FcVNakOYX0m
+P22EaI8/lyYPzif77Oad+nJL8kREcQHlf0v1tQq6kOKFv3CRUsshxu8iclp/Sh1
C8bNPRzMiP5fURT8gBuU4R32JAYVLMGIOyCabuPUhrvaqmw+Kd98mguibD17Cpk=
=wpMA
-----END PGP SIGNATURE-----

[Kevin Moraga]

On Sunday, May 8, 2016 at 12:49:04 PM UTC-6, Marek Marczykowski-Górecki wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, May 08, 2016 at 11:24:42AM -0700, Kevin Moraga wrote:
> oh cool!. Do you have any specific instructions or kernel configuration to
> share? :D because I still having issues with new kernels, I got a problem
> with a kernel's page fault on Xen at boot. (I tested it with 4.4.8 and
> 4.5.3).

I've just pushed 4.4.8 sources here (including updated patches):
https://github.com/marmarek/qubes-linux-kernel devel-4.4 branch

It isn't thoroughly tested, but it builds fine and Qubes can be started
with it.

Thanks Marek. :D
 

[Kevin Moraga]

Hi,

On Sunday, May 8, 2016 at 12:49:04 PM UTC-6, Marek Marczykowski-Górecki wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, May 08, 2016 at 11:24:42AM -0700, Kevin Moraga wrote:
> oh cool!. Do you have any specific instructions or kernel configuration to
> share? :D because I still having issues with new kernels, I got a problem
> with a kernel's page fault on Xen at boot. (I tested it with 4.4.8 and
> 4.5.3).

I've just pushed 4.4.8 sources here (including updated patches):
https://github.com/marmarek/qubes-linux-kernel devel-4.4 branch

It isn't thoroughly tested, but it builds fine and Qubes can be started
with it.

Just to report... Still getting the same error... :( Attached are some stack traces.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, May 08, 2016 at 02:09:26PM -0700, Kevin Moraga wrote:
> Hi,
>
> On Sunday, May 8, 2016 at 12:49:04 PM UTC-6, Marek Marczykowski-Górecki
> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > On Sun, May 08, 2016 at 11:24:42AM -0700, Kevin Moraga wrote:
> > > oh cool!. Do you have any specific instructions or kernel configuration
> > to
> > > share? :D because I still having issues with new kernels, I got a
> > problem
> > > with a kernel's page fault on Xen at boot. (I tested it with 4.4.8 and
> > > 4.5.3).
> >
> > I've just pushed 4.4.8 sources here (including updated patches):
> > https://github.com/marmarek/qubes-linux-kernel devel-4.4 branch
> >
> > It isn't thoroughly tested, but it builds fine and Qubes can be started
> > with it.
> >
>
> Just to report... Still getting the same error... :( Attached are some
> stack traces.

I recommend asking on xen-devel for help.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXL6vGAAoJENuP0xzK19cs0y8H/Rv9fJwuv5v6TcGp2KIHqgqB
x1sMYQBLLVljjXaWQ2rj2tpQ6Jcc5dtpZcFxim3iDlYCXB6c7heidiJI5t/BtbFi
vuBqycKZQjPtHqJM+MlehjSoy22ej8tOHWQ9m4BMojAhD3ZPBozv6+x5gGBq5Pub
SG8kzCJSgY0pG34qhiBWiNRSLM0wh9MePPCGvkAhfa9cDk985B27lUZCFOxbbZxg
g1edVje8zBZ3Un/EpPuhtuNHGFQ5blL+1A2CtvSjDlLiykWIasHRe7A+Oec8+7iW
xHJvpbV0c/81NM10pRY8jhpzhFDF92avojuz77o7ohMMskg+Zir22H4Ej3NXc5g=
=9c5F
-----END PGP SIGNATURE-----

[Holger Levsen]

On Sun, May 08, 2016 at 08:48:54PM +0200, Marek Marczykowski-Górecki wrote:
> I've just pushed 4.4.8 sources here (including updated patches):
> https://github.com/marmarek/qubes-linux-kernel devel-4.4 branch
>
> It isn't thoroughly tested, but it builds fine and Qubes can be started
> with it.

cool, thanks!

out of curiosity, why not 4.5? and why no binary packages? :)


--
cheers,
Holger

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, May 09, 2016 at 08:38:50AM +0000, Holger Levsen wrote:
> On Sun, May 08, 2016 at 08:48:54PM +0200, Marek Marczykowski-Górecki wrote:
> > I've just pushed 4.4.8 sources here (including updated patches):
> > https://github.com/marmarek/qubes-linux-kernel devel-4.4 branch
> >
> > It isn't thoroughly tested, but it builds fine and Qubes can be started
> > with it.
>
> cool, thanks!
>
> out of curiosity, why not 4.5?

I prefer to select longterm releases, to not switch major versions
constantly. 4.4 is going to be in Qubes 3.2.

> and why no binary packages? :)

I may upload it to unstable repo, but it will make things a little
harder to install 4.2.x from there (which is working fine for many
users). And 4.4 is almost untested.
On the other hand, this is unstable repo, isn't it? ;) Will be there in
half an hour.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXMFZKAAoJENuP0xzK19csGpsH/00joeP7WXN0DvyoNAnngfIo
QUJ27nddRLKxmHB7lnPTSBQDJ59f6dZ4bA9tYdneWpgwrqOA1vkT9g1vVZJrAe35
ao4CExB/wjTr/xZIZB8Nt9psnr2yABHk8mSyNr5Z2Fd4mkKvAQMqRh9xiZyzbW1g
7jLCPxZeibFjgzOgOF95rQIshfMJ90qRE7TdSUbMVtr7CHuMyO3AW2E7yhJH+tlk
c/0JPMLgT8Yy6I15FsCgA7f7LFE7X+wyVQxKqTE/wYhzrf19p/oHovtVPCdP+emm
7b9zBfcuLfkvQw+oVQB+F6tMmKKQ2nSEjDWF1jwIntJX9QPUPIWHSCh8AmXalPQ=
=Vn5n
-----END PGP SIGNATURE-----

[Holger Levsen]

On Mon, May 09, 2016 at 11:20:08AM +0200, Marek Marczykowski-Górecki wrote:
> > out of curiosity, why not 4.5?
> I prefer to select longterm releases, to not switch major versions
> constantly. 4.4 is going to be in Qubes 3.2.

makes sense, though might be unfortunate for skylake users…

when you say "longterm release" you are refering to the kernel (or)?

> > and why no binary packages? :)
> I may upload it to unstable repo, but it will make things a little
> harder to install 4.2.x from there (which is working fine for many
> users). And 4.4 is almost untested.
> On the other hand, this is unstable repo, isn't it? ;) Will be there in
> half an hour.

cool, thanks, I'll give it a try later then…


--
cheers,
Holger

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, May 09, 2016 at 09:27:28AM +0000, Holger Levsen wrote:
> On Mon, May 09, 2016 at 11:20:08AM +0200, Marek Marczykowski-Górecki wrote:
> > > out of curiosity, why not 4.5?
> > I prefer to select longterm releases, to not switch major versions
> > constantly. 4.4 is going to be in Qubes 3.2.
>
> makes sense, though might be unfortunate for skylake users…
>
> when you say "longterm release" you are refering to the kernel (or)?

Yes.

> > > and why no binary packages? :)
> > I may upload it to unstable repo, but it will make things a little
> > harder to install 4.2.x from there (which is working fine for many
> > users). And 4.4 is almost untested.
> > On the other hand, this is unstable repo, isn't it? ;) Will be there in
> > half an hour.
>
> cool, thanks, I'll give it a try later then…

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXMGdlAAoJENuP0xzK19csstcH/2TPiP5cc5G36klKUwytZlDM
iDhjXLQhhRMRjptGCp1ecOfWlURKj3aRan6XoPYuQUN4w8w9HmNoWBQAsV51wDlq
0fKd1B7LQH4rlRfg8tQ2lDZJK7DiGYdfIwl0ZpLiMzPfGCifVIv+3YCXCw3ssuRy
inh6G4U6+psvUYWCVOfhGftE71oSsdKlylIscm1e+fca/j57DMLuJJVdIjx9C867
81+M3iu4a9j0fBfe2g1CJGBIZxvI9HKGE3VQgpjGz9bDG5nMJLMlHMmbZLE/Ox6w
k5y6hjZ2CA/acEuWaH29IkeXl1SD3JLdoHBG5bqXoULHm6tzWWT+8/9ahEo+aAA=
=tGKF
-----END PGP SIGNATURE-----

[Holger Levsen]

On Mon, May 09, 2016 at 09:27:28AM +0000, Holger Levsen wrote:

> > I may upload it to unstable repo, but it will make things a little
> > harder to install 4.2.x from there (which is working fine for many
> > users). And 4.4 is almost untested.
> > On the other hand, this is unstable repo, isn't it? ;) Will be there in
> > half an hour.
> cool, thanks, I'll give it a try later then…

done so now with "sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel"
which worked nicely, just that now the system doesnt boot anymore, it
just immediatly reboots after loading the kernel…

replaced "quiet" in the grub module line with "debug" but that didnt
help, "loading initial ramdisk" is the only thing I see for half a
second and then it reboots.

it's nice that booting with the 4.1.13 kernel still works easily. :-)


--
cheers,
Holger

[Linus Färnstrand]

I compiled my own 4.4.8 kernel and installed the rpm in dom0 before I read Marek uploaded it to the testing repo. Anyhow I rebooted this T460s into the new kernel and it worked on the first try. Now suspend works even! I have only tried it twice and I have run the kernel for a total of 10 minutes, so I can't comment on the general stability yet.

My biggest problem with this laptop might just have been fixed, win.

Holger: I don't know enough to help you with that. I hope someone else is able to come to the rescue.

/Linus

--
cheers,
        Holger

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/-xXKdAkIjxU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20160509120218.GA21508%40matrix.athome.

For more options, visit https://groups.google.com/d/optout.

[Kevin Moraga]

On 05/09/2016 06:02 AM, Holger Levsen wrote:
> On Mon, May 09, 2016 at 09:27:28AM +0000, Holger Levsen wrote:
>>> I may upload it to unstable repo, but it will make things a little
>>> harder to install 4.2.x from there (which is working fine for many
>>> users). And 4.4 is almost untested.
>>> On the other hand, this is unstable repo, isn't it? ;) Will be there in
>>> half an hour.
>> cool, thanks, I'll give it a try later then…
> done so now with "sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel"
> which worked nicely, just that now the system doesnt boot anymore, it
> just immediatly reboots after loading the kernel…
>
> replaced "quiet" in the grub module line with "debug" but that didnt
> help, "loading initial ramdisk" is the only thing I see for half a
> second and then it reboots.

Which processor do you have? I have the same problem...

--
Sincerely,
Kevin Moraga
+506 88334088
ke...@kmoragas.com
ke...@gnupg.net
PGP: F258EDCB
Fingerprint: 3915 A5A9 959C D18F 0A89 B47E FB4B 55F5 F258 EDCB

[Jacob Richard]

I will do a short write up on how I did the kernel build. Its pretty straightfoward using the qubes-linux-kernel sources from github. 

I built a 'vanilla' kernel, but I should qualify that:

    - I did not apply the patches that qubes applies during the build process. To do so, I would have to create new patch files, since they do not apply cleanly to many of the updated kernel sources. 

    - I did use the qubes kernel build configuration. When using that as a base to generate a full config for 4.5.3 there are still quite a few questions you have to answer when you run 'make config'  to generate the file with full no-prompt action. If you don't do this step, the qubes 'make rpms' blows up, since it isnt expecting a stop in the run for user input, it seems. 

I'm sure i missed some optimizations in my config creation, and honestly, i probably should go back and review all the config deltas and create an updated set of patchfiles for 4.5.3. I'm sure this install would work even better yet if i would do so. 

For now though, I will try to get around to making a basic set of instructions on how to build a quick vanilla kernel for testing various kernel flavors with the kernel buildconfig as it is (mostly) already laid out. 

-Jake

[li...@mullvad.net]

On Monday, May 9, 2016 at 4:35:55 PM UTC+2, Kevin Moraga wrote:

On 05/09/2016 06:02 AM, Holger Levsen wrote:
> On Mon, May 09, 2016 at 09:27:28AM +0000, Holger Levsen wrote:
>>> I may upload it to unstable repo, but it will make things a little
>>> harder to install 4.2.x from there (which is working fine for many
>>> users). And 4.4 is almost untested.
>>> On the other hand, this is unstable repo, isn't it? ;) Will be there in
>>> half an hour.
>> cool, thanks, I'll give it a try later then…
> done so now with "sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel"
> which worked nicely, just that now the system doesnt boot anymore, it
> just immediatly reboots after loading the kernel…
>
> replaced "quiet" in the grub module line with "debug" but that didnt
> help, "loading initial ramdisk" is the only thing I see for half a
> second and then it reboots.

Which processor do you have? I have the same problem...

I don't know if this is related to your problem, but I can state my setup that works with the 4.4.8 kernel so we have a comparison. I have the t460s with the i5-6300U CPU. As I stated in the beginning of this thread I have disabled some firmware features to make the booting/acpi/shutdown work better/at all. For example I have disabled both the security chip (TPM) and secure boot. I have also disabled most other functionality I don't need/want, such as webcam, SD card reader, wireless WAN, Intel SGX etc.

I have now used the 4.4.8 kernel for over a day and it works really well so far.

/Linus