New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kernel 4.14.13-3 in dom0 breaks resume on a thinkpad x230 #3555

Open
h01ger opened this Issue Feb 8, 2018 · 13 comments

Comments

Projects
None yet
4 participants
@h01ger

h01ger commented Feb 8, 2018

Qubes OS version:

3.2

Affected TemplateVMs:

all


Steps to reproduce the behavior:

install kernel and kernel-qubes-vm 4.14.13-3 from qubes-dom0-current-testing on a thinkpad x230 with coreboot, reboot into it, and suspend. then resume, and the screen stays black, forcing one into a reboot. also could reproduce this without starting any app-vms.

Expected behavior:

resume works.

Actual behavior:

screen stays black. the disk activity led is on though.

General notes:

running kernel 4.9 in dom0 and 4.14.3 in the VMs seems to be a working workaround.


Related issues:

@h01ger

This comment has been minimized.

Show comment
Hide comment
@h01ger

h01ger Feb 10, 2018

so 4.14.18-1 seems to work at least a little better, so far it has survived one suspend/resume cycle, but then the external display didnt work anymore (which is not a regression as it happened before on Qubes 3.2), so I had to reboot anyway.

I will keep this bug updated about how further suspend/resume cycles behave.

I just now wonder: I have 4.14.18, 4.14.13 and 4.9.56 installed. The next kernel update will thus remove 4.9.56 - how can I instead remove 4.14.13 so that 4.9.56 is kept?

h01ger commented Feb 10, 2018

so 4.14.18-1 seems to work at least a little better, so far it has survived one suspend/resume cycle, but then the external display didnt work anymore (which is not a regression as it happened before on Qubes 3.2), so I had to reboot anyway.

I will keep this bug updated about how further suspend/resume cycles behave.

I just now wonder: I have 4.14.18, 4.14.13 and 4.9.56 installed. The next kernel update will thus remove 4.9.56 - how can I instead remove 4.14.13 so that 4.9.56 is kept?

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Feb 10, 2018

Member

so 4.14.18-1 seems to work at least a little better, so far it has survived one suspend/resume cycle, but then the external display didnt work anymore (which is not a regression as it happened before on Qubes 3.2), so I had to reboot anyway.

In some cases switching to text console and back helps.

I just now wonder: I have 4.14.18, 4.14.13 and 4.9.56 installed. The next kernel update will thus remove 4.9.56 - how can I instead remove 4.14.13 so that 4.9.56 is kept?

Yes. Or increase installonly_limit in /etc/dnf/dnf.conf.

Member

marmarek commented Feb 10, 2018

so 4.14.18-1 seems to work at least a little better, so far it has survived one suspend/resume cycle, but then the external display didnt work anymore (which is not a regression as it happened before on Qubes 3.2), so I had to reboot anyway.

In some cases switching to text console and back helps.

I just now wonder: I have 4.14.18, 4.14.13 and 4.9.56 installed. The next kernel update will thus remove 4.9.56 - how can I instead remove 4.14.13 so that 4.9.56 is kept?

Yes. Or increase installonly_limit in /etc/dnf/dnf.conf.

@h01ger

This comment has been minimized.

Show comment
Hide comment
@h01ger

h01ger Feb 10, 2018

h01ger commented Feb 10, 2018

@h01ger

This comment has been minimized.

Show comment
Hide comment
@h01ger

h01ger Feb 12, 2018

so 4.14.18-1 seems to work at least a little better, so far it has survived one suspend/resume cycle, but then the external display didnt work anymore (which is not a regression as it happened before on Qubes 3.2), so I had to reboot anyway.

I will keep this bug updated about how further suspend/resume cycles behave.

I just now wonder: I have 4.14.18, 4.14.13 and 4.9.56 installed. The next kernel update will thus remove 4.9.56 - how can I instead remove 4.14.13 so that 4.9.56 is kept?

h01ger commented Feb 12, 2018

so 4.14.18-1 seems to work at least a little better, so far it has survived one suspend/resume cycle, but then the external display didnt work anymore (which is not a regression as it happened before on Qubes 3.2), so I had to reboot anyway.

I will keep this bug updated about how further suspend/resume cycles behave.

I just now wonder: I have 4.14.18, 4.14.13 and 4.9.56 installed. The next kernel update will thus remove 4.9.56 - how can I instead remove 4.14.13 so that 4.9.56 is kept?

@h01ger

This comment has been minimized.

Show comment
Hide comment
@h01ger

h01ger Feb 12, 2018

4.14.18 is not much better, after the initial success I do not remember one working resume in the last two days, maybe there was one, but I dont think there were two :(

h01ger commented Feb 12, 2018

4.14.18 is not much better, after the initial success I do not remember one working resume in the last two days, maybe there was one, but I dont think there were two :(

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Feb 13, 2018

Member

I can't reproduce... tried about 10 times suspend/resume cycles on x230 (+coreboot) and it just works. 4.14.18 in dom0 and all VMs.

Member

marmarek commented Feb 13, 2018

I can't reproduce... tried about 10 times suspend/resume cycles on x230 (+coreboot) and it just works. 4.14.18 in dom0 and all VMs.

@h01ger

This comment has been minimized.

Show comment
Hide comment
@h01ger

h01ger Feb 13, 2018

h01ger commented Feb 13, 2018

@h01ger

This comment has been minimized.

Show comment
Hide comment
@h01ger

h01ger Feb 13, 2018

4.14.18 is not much better, after the initial success I do not remember one working resume in the last two days, maybe there was one, but I dont think there were two :(

h01ger commented Feb 13, 2018

4.14.18 is not much better, after the initial success I do not remember one working resume in the last two days, maybe there was one, but I dont think there were two :(

@h01ger

This comment has been minimized.

Show comment
Hide comment
@h01ger

h01ger Feb 13, 2018

marmarek: does your coreboot use the intel vga blob or the free vga bios written in ada? (thinking about what else than hardware could cause this…)

h01ger commented Feb 13, 2018

marmarek: does your coreboot use the intel vga blob or the free vga bios written in ada? (thinking about what else than hardware could cause this…)

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Feb 13, 2018

Member

intel one

Member

marmarek commented Feb 13, 2018

intel one

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Feb 13, 2018

Member

In .config I see also CONFIG_S3_ROM_RUN=y, not sure if relevant.

Member

marmarek commented Feb 13, 2018

In .config I see also CONFIG_S3_ROM_RUN=y, not sure if relevant.

@grote

This comment has been minimized.

Show comment
Hide comment
@grote

grote May 31, 2018

@h01ger any update here? Which kernel works best for you? I seem to have run into the same problem on an X230 (still without coreboot).

grote commented May 31, 2018

@h01ger any update here? Which kernel works best for you? I seem to have run into the same problem on an X230 (still without coreboot).

@h01ger

This comment has been minimized.

Show comment
Hide comment
@h01ger

h01ger May 31, 2018

h01ger commented May 31, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment