[Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

laggykiller · 2021-12-12 07:03:28

Hello, my computer (https://gmktec.com/products/nucbox2-int … 4k-mini-pc) is multibooted using grub2, and is connected to a HDMI display (https://www.dell.com/support/home/en-us … fp/drivers) via KVM switch (http://www.mt-viki.net/product/91-en.html).

Only when I reboot from Arch Linux to Windows, my display receives no signal. This includes the installation on my hard drive, as well as installation USB.

If I reboot from Arch Linux to Arch Linux, I cannot see the boot process, but I can still see the GUI once it finishes booting.

Things return to normal if I turn off the KVM switch and turn it back on again by unplugging all HDMI on the switch when booted to Windows (The switch receives custom HDMI that also serves power to the switch).

This does not happen when I reboot from Windows to Arch Linux, Xubuntu to Windows, and even macOS (Hackintosh) to Windows.

This does not happen if I connect the computer directly to the display.

Any idea?

Please tell me if I need to provide more information. Thank you.

Last edited by laggykiller (2021-12-16 04:06:07)

Lone_Wolf · 2021-12-12 11:47:00

is multibooted

HDMI requires iniitlaisation, it could be that windows thinks it doesn't need to do that because of fast startup / hibernation .

Did you disable fast startup & hibernation in windows ?

See https://wiki.archlinux.org/title/Dual_b … ibernation for more info

laggykiller · 2021-12-12 15:25:42

Lone_Wolf wrote:

is multibooted
HDMI requires iniitlaisation, it could be that windows thinks it doesn't need to do that because of fast startup / hibernation .
Did you disable fast startup & hibernation in windows ?

See https://wiki.archlinux.org/title/Dual_b … ibernation for more info

Yes, I have disabled fast startup & hibernation in Windows.

As mentioned, the issue does not occur if I reboot from Xubuntu to Windows, plus when I reboot from Arch Linux, there is no display even before booting into any OS, so the culprit should be Arch Linux.

Last edited by laggykiller (2021-12-12 15:26:46)

seth · 2021-12-12 16:34:55

If I reboot from Arch Linux to Arch Linux, I cannot see the boot process, but I can still see the GUI once it finishes booting.

How's the framebuffer console/grub configured? (Stuff around this section: https://wiki.archlinux.org/title/GRUB/T … figuration )

laggykiller · 2021-12-12 16:57:57

# GRUB boot loader configuration

GRUB_DEFAULT="saved"
GRUB_TIMEOUT="2"
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet"
GRUB_CMDLINE_LINUX=""

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to enable booting from LUKS encrypted devices
#GRUB_ENABLE_CRYPTODISK="y"

# Set to 'countdown' or 'hidden' to change timeout behavior,
# press ESC key to display menu.
GRUB_TIMEOUT_STYLE="menu"

# Uncomment to use basic console
GRUB_TERMINAL_INPUT="console"

# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT="console"

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE="auto"

# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX="keep"

# Uncomment if you want GRUB to pass to the Linux kernel the old parameter
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"
#GRUB_DISABLE_LINUX_UUID="true"

# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY="true"

# Uncomment and set to the desired menu colors.  Used by normal and wallpaper
# modes only.  Entries specified as foreground/background.
#GRUB_COLOR_NORMAL="light-blue/black"
#GRUB_COLOR_HIGHLIGHT="light-cyan/blue"

# Uncomment one of them for the gfx desired, a image background or a gfxtheme
#GRUB_BACKGROUND="/path/to/wallpaper"
#GRUB_THEME="/path/to/gfxtheme"

# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"

# Uncomment to make GRUB remember the last selection. This requires
# setting 'GRUB_DEFAULT=saved' above.
GRUB_SAVEDEFAULT="true"

# Uncomment to disable submenus in boot menu
#GRUB_DISABLE_SUBMENU="y"

GRUB_DISABLE_OS_PROBER="false"

I should clarify: If I reboot from Windows to Arch Linux, I can see everything, including the boot process. Only if I reboot from Arch Linux to Arch Linux, I cannot see the boot process. For this reason and Xubuntu (booted from grub) did not produce same problem, I do not think grub is the culprit.

Or in other words, if I boot into Arch Linux, my setup enter the weird state until I restart my KVM switch.

Last edited by laggykiller (2021-12-12 17:03:03)

seth · 2021-12-12 21:29:37

Do you enter the weird state if you only boot the multi-user.target (and not X11 or wayland), see the 2nd link below.
If not, please post an xorg log.

laggykiller · 2021-12-13 05:16:38

seth wrote:

Do you enter the weird state if you only boot the multi-user.target (and not X11 or wayland), see the 2nd link below.
If not, please post an xorg log.

Yes, I still enter weird state, even booting without xorg.

Surprisingly, once in weird state, the only thing that can be displayed is Arch Linux xorg. Not even POST screen, GRUB, verbose boot.

The weird state also occur if I boot arch linux installation media (without GUI), but not for xubuntu installation media (with GUI)

Last edited by laggykiller (2021-12-13 05:22:54)

seth · 2021-12-13 07:19:04

Does it happen w/ the lts kernel?

laggykiller · 2021-12-13 11:39:21

seth wrote:

Does it happen w/ the lts kernel?

You gave me the idea of testing previous kernel versions...

Knowing that the Xubuntu image I used for testing is 18.04 (kernel 4.15), I went to https://archlinux.org/releng/releases/ and tried Arch Linux Installation Media version 2018.03.01 (kernel 4.15.6). It did not cause the weird state.

I then try different iso at different time and different kernel version.

The last iso that did not cause the weird state is 2021.02.01 (kernel 5.10.11). The first iso that cause the weird state is 2021.03.01 (kernel 5.11.2).

The versions of kernel in between are:
- 5.10.12
- 5.10.13
- 5.10.14
- 5.10.15
- 5.10.16
- 5.11
- 5.11.1

I shall deduce which one of them started this by using https://archive.archlinux.org/packages/l/linux/

At the meantime, anyone has any idea?

(btw, I tried Manjaro latest installation iso with kernel 5.15 and the same weird state occured)

Last edited by laggykiller (2021-12-13 13:25:07)

seth · 2021-12-13 12:01:26

Comparative dmesg outputs?
I guess this is just one intel IGP?
Do you get weirdstate™ when booting "nomodeset"?

laggykiller · 2021-12-13 12:31:41

The last kernel that did not cause the weird state is kernel 5.10.16. The first kernel that cause the weird state is kernel ~~5.11.1~~ 5.11.

With kernel ~~5.11.1~~ 5.11, I do not get weird state when booting with nomodeset.

I have created the dmesg by booting with the kernel with xorg disabled, then reboot and use

sudo journalctl -b -1

Here are the results:

dmesg with kernel 5.10.16: https://pastebin.com/pXt7rHSn

dmesg with kernel 5.11.1: https://pastebin.com/gbayrfzP

Last edited by laggykiller (2021-12-13 13:24:31)

laggykiller · 2021-12-13 13:00:54

I created a python script for processing the log, such that only logs from kernel are kept:

#!/usr/bin/env python3
with open('original.log') as f, open('new.log', 'w+') as g:
	for line in f:
		if "kernel:" in line:
			g.write(line.split("kernel: ")[1])

Then I compared the filtered dmesg: https://www.diffchecker.com/pom5oRLN

Hope this makes the log comparison easier

Anyone can help interpret it?

---

Ammendment: The first kernel that has such problem is 5.11, not 5.11.1

---

btw, is this a bug in linux kernel? Should I report it somewhere?

The changelog of kernel 5.11 is: https://cdn.kernel.org/pub/linux/kernel … geLog-5.11

My programming sucks. Which commit is likely the culprit?

Last edited by laggykiller (2021-12-13 13:23:37)

seth · 2021-12-13 13:40:20

So, the IGP comes up fairly late in either case, but in the bad version it notably only picks up i915_hdcp_component_ops *after*

Dec 13 20:18:28 gmknuc chrome-remote-desktop[332]: 2021-12-13 20:18:28,095:INFO:Launching X server and X session.

Just a hunch, but could be as easy as https://wiki.archlinux.org/title/Kernel … _KMS_start

laggykiller · 2021-12-13 13:50:58

seth wrote:

So, the IGP comes up fairly late in either case, but in the bad version it notably only picks up i915_hdcp_component_ops *after*
Dec 13 20:18:28 gmknuc chrome-remote-desktop[332]: 2021-12-13 20:18:28,095:INFO:Launching X server and X session.
Just a hunch, but could be as easy as https://wiki.archlinux.org/title/Kernel … _KMS_start

I am now using 5.11.

I have modified /etc/mkinitcpio.conf:

MODULES=(i915)

I have regenerated initramfs:

sudo mkinitcpio -P

Unfortunately, it still causes the weird state...

Here is the dmesg log: https://pastebin.com/0Wp3PRuB

Last edited by laggykiller (2021-12-13 13:54:22)

seth · 2021-12-13 16:12:15

Happy bisection day… https://wiki.archlinux.org/title/Bisect … s_with_Git
https://git.kernel.org/pub/scm/linux/ke … 15?h=v5.11
https://git.kernel.org/pub/scm/linux/ke … 15?h=v5.10

https://git.kernel.org/pub/scm/linux/ke … 5efaddf118 kinda looks at me, but that's baseless speculation.

laggykiller · 2021-12-14 16:12:28

I am back!

https://git.kernel.org/pub/scm/linux/ke … b9bd1f291c

fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c is the first bad commit
commit fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Oct 1 18:16:35 2020 +0300

    drm/i915: Shut down displays gracefully on reboot
    
    Implement the pci .shutdown() hook in order to quiesce the
    hardware prior to reboot. The main purpose here is to turn
    all displays off. Some displays/other drivers tend to get
    confused if the state after reboot isn't exactly as they
    expected.
    
    One specific example was the Dell UP2414Q in MST mode.
    It would require me to pull the power cord after a reboot
    or else it would just not come back to life. Sadly I don't
    have that at hand anymore so not sure if it's still
    misbehaving without the graceful shutdown, or if we
    managed to fix something else since I last tested it.
    
    For good measure we do a gem suspend as well, so that
    we match the suspend flow more closely. Also stopping
    all DMA and whatnot is probably a good idea for kexec.
    I would expect that some kind of GT reset happens on
    normal reboot so probably not totally necessary there.
    
    v2: Use the pci .shutdown() hook instead of a reboot notifier (Lukas)
        Do the gem suspend for kexec (Chris)
    
    Cc: Lukas Wunner <lukas@wunner.de>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-1-ville.syrjala@linux.intel.com
    Reviewed-by: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

 drivers/gpu/drm/i915/i915_drv.c | 16 ++++++++++++++++
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_pci.c |  8 ++++++++
 3 files changed, 25 insertions(+)

$ git bisect log
git bisect start
# good: [2c85ebc57b3e1817b6ce1a6b703928e113a90442] Linux 5.10
git bisect good 2c85ebc57b3e1817b6ce1a6b703928e113a90442
# bad: [f40ddce88593482919761f74910f42f4b84c004b] Linux 5.11
git bisect bad f40ddce88593482919761f74910f42f4b84c004b
# bad: [538fcf57aaee6ad78a05f52b69a99baa22b33418] Merge branches 'acpi-scan', 'acpi-pnp' and 'acpi-sleep'
git bisect bad 538fcf57aaee6ad78a05f52b69a99baa22b33418
# bad: [15b447361794271f4d03c04d82276a841fe06328] mm/lru: revise the comments of lru_lock
git bisect bad 15b447361794271f4d03c04d82276a841fe06328
# bad: [b10733527bfd864605c33ab2e9a886eec317ec39] Merge tag 'amd-drm-next-5.11-2020-12-09' of git://people.freedesktop.org/~agd5f/linux into drm-next
git bisect bad b10733527bfd864605c33ab2e9a886eec317ec39
# bad: [9713158cb2a918c3f6f5522eed23cdeb61f22e75] drm/amdgpu: Add and use seperate reg headers for dcn302
git bisect bad 9713158cb2a918c3f6f5522eed23cdeb61f22e75
# bad: [c0f98d2f8b076bf3e3183aa547395f919c943a14] Merge tag 'drm-misc-next-2020-11-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
git bisect bad c0f98d2f8b076bf3e3183aa547395f919c943a14
# good: [6a6e5988a2657cd0c91f6f1a3e7d194599248b6d] drm/ttm: replace last move_notify with delete_mem_notify
git bisect good 6a6e5988a2657cd0c91f6f1a3e7d194599248b6d
# bad: [f566fdcd6cc49a9d5b5d782f56e3e7cb243f01b8] drm/i915: Force VT'd workarounds when running as a guest OS
git bisect bad f566fdcd6cc49a9d5b5d782f56e3e7cb243f01b8
# good: [b50b7991b739c6d63658e3324a01eaa0fafe8b7f] drm/i915/dg1: add more PCI ids
git bisect good b50b7991b739c6d63658e3324a01eaa0fafe8b7f
# bad: [0a5991f5d022235ba085001e2a3926f83a0aed1b] drm/i915: Simplify the link training functions
git bisect bad 0a5991f5d022235ba085001e2a3926f83a0aed1b
# bad: [0f8d2a2b9fd52a554a3e00f415baf2f7eed9e9af] drm/i915: Rename i915_{save,restore}_state()
git bisect bad 0f8d2a2b9fd52a554a3e00f415baf2f7eed9e9af
# good: [67807f52e395be751fb665511d1a9a5e6a93f1f7] drm/i915/dg1: provide port/phy mapping for vbt
git bisect good 67807f52e395be751fb665511d1a9a5e6a93f1f7
# bad: [063348f6a72634c8825e500bd315892a9de6a13a] drm/i915: Replace the VLV/CHV eDP reboot notifier with the .shutdown() hook
git bisect bad 063348f6a72634c8825e500bd315892a9de6a13a
# bad: [100fe4c01efff5e3b930c7aaff9c2ebeb78d1b87] drm/i915: Add an encoder .shutdown() hook
git bisect bad 100fe4c01efff5e3b930c7aaff9c2ebeb78d1b87
# bad: [fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c] drm/i915: Shut down displays gracefully on reboot
git bisect bad fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c
# first bad commit: [fe0f1e3bfdfeb53e18f1206aea4f40b9bd1f291c] drm/i915: Shut down displays gracefully on reboot

Should I submit a bug report to https://bugzilla.kernel.org/ ?

seth · 2021-12-14 16:23:27

bugzilla wrote:

Please file new drm/i915 bugs at https://bugs.freedesktop.org. Product: DRI. Component: DRM/Intel.

Though this will likely require a quirk (unless maybe a single item, hpd, is the cause here and less relevant to the original problem)

laggykiller · 2021-12-14 16:54:48

Reported to https://gitlab.freedesktop.org/drm/intel/-/issues/4784

laggykiller · 2021-12-16 04:05:37

From https://gitlab.freedesktop.org/drm/intel/-/issues/4784

vsyrjala wrote:

Could be fixed with
commit cecbc0c7eba7 ("drm/i915/hdmi: Turn DP++ TMDS output buffers back on in encoder->shutdown()")
Looks like that hasn't trickled down to any stable kernels yet, so you'd need to test with 5.16-rc1+ or drm-tip.

Compiled latest linux kernel (5.16.0-rc5), can confirm that the problem was solved.

For anyone suffering from same issue, install linux kernel >=5.16 (which may require manual compiling depending on time of you reading this) or install linux kernel <=5.10.16.

Marking as solved.

Last edited by laggykiller (2021-12-16 04:15:00)

Arch Linux

#1 2021-12-12 07:03:28

[Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#2 2021-12-12 11:47:00

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#3 2021-12-12 15:25:42

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#4 2021-12-12 16:34:55

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#5 2021-12-12 16:57:57

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#6 2021-12-12 21:29:37

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#7 2021-12-13 05:16:38

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#8 2021-12-13 07:19:04

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#9 2021-12-13 11:39:21

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#10 2021-12-13 12:01:26

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#11 2021-12-13 12:31:41

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#12 2021-12-13 13:00:54

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#13 2021-12-13 13:40:20

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#14 2021-12-13 13:50:58

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#15 2021-12-13 16:12:15

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#16 2021-12-14 16:12:28

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#17 2021-12-14 16:23:27

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#18 2021-12-14 16:54:48

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

#19 2021-12-16 04:05:37

Re: [Solved] Reboot from Arch to Windows cause no signal (w/ KVM switch)

Board footer