You are not logged in.
I'm experiencing some weird issues with my Arch setup. On newer kernel versions (incl. the latest 5.11.1) I cannot use my Openbox desktop. All I see is black screen and mouse cursor. The only thing I can do is switching to another TTY and using CLI. However, when I downgrade (tried with 5.10.10-arch1-1), then I'm able to work with my GUI as I usually do. I have no idea what's wrong and how to fix it.
Here's my "lspci":
$ lspci
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5)
00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 (rev d5)
00:1c.3 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation B85 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05)
01:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host Controller (rev 01)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
04:00.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 41)
And "lsusb":
$ lsusb
Bus 002 Device 002: ID 8087:8000 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 0c45:8502 Microdia USB DEVICE
Bus 003 Device 003: ID 1ea7:0066 SHARKOON Technologies GmbH [Mediatrack Edge Mini Keyboard]
Bus 003 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Here goes "dmesg" output taken when GUI did not work:
https://pastebin.pl/view/87b5a482
And this is "dmesg" when desktop is functional:
https://pastebin.ubuntu.com/p/kWdYn4hQD8/
What else should I provide?
Last edited by Hwiparam (2021-03-10 13:28:22)
Offline
[ 10.591924] i915 0000:00:02.0: [drm] GPU HANG: ecode 7:1:85dffffd, in systemd-logind [339]
[ 10.591928] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[ 10.591928] Please file a _new_ bug report at https://gitlab.freedesktop.org/drm/intel/issues/new.
[ 10.591929] Please see https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for details.
[ 10.591929] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[ 10.591930] The GPU crash dump is required to analyze GPU hangs, so please always attach it.
[ 10.591930] GPU crash dump saved to /sys/class/drm/card0/error
[ 10.591962] i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
[ 10.694548] i915 0000:00:02.0: [drm] systemd-logind[339] context reset due to GPU hang
[ 13.578621] i915 0000:00:02.0: [drm] GPU HANG: ecode 7:1:85dffffd, in systemd-logind [339]
[ 13.578657] i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
[ 13.681214] i915 0000:00:02.0: [drm] systemd-logind[339] context reset due to GPU hang
[ 14.034823] kauditd_printk_skb: 68 callbacks suppressed
[ 14.034826] audit: type=1130 audit(1614168821.219:61): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 14.174976] audit: type=1130 audit(1614168821.359:62): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=blueman-mechanism comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 19.553983] i915 0000:00:02.0: [drm] GPU HANG: ecode 7:1:85dffffd, in systemd-logind [339]
[ 19.554019] i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
[ 19.655370] i915 0000:00:02.0: [drm] systemd-logind[339] context reset due to GPU hang
https://gitlab.freedesktop.org/drm/intel/-/issues/2024 but that issues dates back to 5.7 so something new triggered it.
Offline
Okay, I guess it will take some time to solve it
BTW, when I launch XTERM in fullscreen (must be in fullscreen!), it's usable, keyboard and mouse works, but the only thing I can use is that XTERM in fullscreen mode. Nothing else seems to work.
Offline
Please test the three linked kernels below
https://drive.google.com/file/d/1oQUdNT … sp=sharing linux-loqs-5.10-1-x86_64.pkg.tar.zst good?
https://drive.google.com/file/d/1vHLWtt … sp=sharing linux-loqs-5.11-1-x86_64.pkg.tar.zst bad?
https://drive.google.com/file/d/1jp6str … sp=sharing linux-loqs-5.10.r7737.g538fcf57aaee-1-x86_64.pkg.tar.zst ??
Offline
I'm not sure whether I should trust packages posted by someone on Google Drive. But there's yet another thing I forgot to mention. Once I press the POWER button on my PC, it takes about 10 to 15 seconds for the mobo's usual "beep" sound to be heard. Before this started happening, I did not have to wait this long for the "beep", so I'm afraid this may be a kind of hw-related issue. Is it possible that something is going wrong with my hardware?
Offline
If the beep being the system firmware passing its power on self test then a long delay for that could indicate a hardware issue.
I do not have any other available storage to provide the built packages on. I can provide you step by step instructions instead to replicate them.
I would not have expected downgrading to the kernel to resolve the issue if it was hardware though.
Offline
Okay, now I'm pretty sure I've found the solution. Turns out that my printer got broken for some reason and was slowing down the boot process somehow. I've just disconnected the printer from USB and suddenly BOOM!!! Everything works properly! No delays, no slowdown, no problems so far. Installed the latest kernel and it's fine. Thanks for your support, I think it is solved.
Offline