New Install Reboots Every X Minutes in Graphical Target? d-bus?

drankinatty · 2025-02-18 23:37:02

I just installed Arch on a HP ProOne 600 (i5 8500, intel Gen 9.5 integrated graphics). After completing the install, I do a minimum desktop with fluxbox and parcellite (for clipboard manager). I used startx to launch fluxbox and all looked well. System idles at 0.0% processor utilization, so there is no heating/overdemand involved. About 6 minutes or so after last use, I noticed the computer had dropped back to multiuser target and thought that was odd. Checking uptime - it hadn't changed targets, it had rebooted automagically.

Checking the journal and there is nothing odd. Whatever is causing it must be an event the journal can't catch. The only errors shown in the journal are:

Feb 18 08:05:00 ragnarok lightdm[754]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
Feb 18 08:05:01 ragnarok lightdm[776]: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
Feb 18 08:05:01 ragnarok lightdm[776]: pam_unix(lightdm-greeter:session): session opened for user lightdm(uid=971) by (uid=0)
Feb 18 08:05:01 ragnarok systemd-logind[467]: New session c1 of user lightdm.
Feb 18 08:05:01 ragnarok systemd[1]: Created slice User Slice of UID 971.
Feb 18 08:05:01 ragnarok systemd[1]: Starting User Runtime Directory /run/user/971...
Feb 18 08:05:01 ragnarok systemd[1]: Finished User Runtime Directory /run/user/971.
Feb 18 08:05:01 ragnarok systemd[1]: Starting User Manager for UID 971...
Feb 18 08:05:01 ragnarok (systemd)[782]: pam_warn(systemd-user:setcred): function=[pam_sm_setcred] flags=0x8002 service=[systemd-user] terminal=[] user=[lightdm] ruser=[<unknown>] rhost=[<unknown>]
Feb 18 08:05:01 ragnarok (systemd)[782]: pam_unix(systemd-user:session): session opened for user lightdm(uid=971) by lightdm(uid=0)
Feb 18 08:05:01 ragnarok systemd-logind[467]: New session 3 of user lightdm.

The "GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown" is a bit odd, but it's not clear that is the issue. The issue occurs when not using lightdm as well, so the problem getting the user list from org.freedesktop.Accounts doesn't seem fatal. It finds my account fine, and it finds fluxbox fine.

Checking last to look at the logins, it does show some type "crash" is occurring:

david    pts/0        :0.0             Tue Feb 18 17:01   still logged in
david    tty7         :0               Tue Feb 18 17:00   still logged in
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 17:00   still running
david    pts/0        192.168.6.104    Tue Feb 18 16:27 - crash  (00:33)
david    pts/0        192.168.6.104    Tue Feb 18 16:18 - 16:26  (00:07)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 16:14   still running
david    pts/0        192.168.6.104    Tue Feb 18 16:03 - 16:09  (00:06)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 16:02 - 16:09  (00:07)
david    pts/2        192.168.6.104    Tue Feb 18 15:51 - crash  (00:10)
david    pts/1        :0.0             Tue Feb 18 15:27 - crash  (00:34)
david    pts/0        :0.0             Tue Feb 18 15:27 - crash  (00:35)
david    tty7         :0               Tue Feb 18 15:25 - crash  (00:36)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 14:43 - crash  (01:18)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 14:24 - crash  (00:18)
david    pts/0        :0.0             Tue Feb 18 13:29 - 14:24  (00:54)
david    tty7         :0               Tue Feb 18 13:28 - 14:24  (00:55)
david    tty1                          Tue Feb 18 13:27 - 13:28  (00:00)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 13:27 - 14:24  (00:57)
david    tty7         :0               Tue Feb 18 08:05 - crash  (05:21)
david    pts/0        :0.0             Tue Feb 18 07:29 - 08:04  (00:34)
david    tty1                          Tue Feb 18 07:28 - 08:05  (00:36)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 07:13 - crash  (06:13)
david    pts/0        :0.0             Tue Feb 18 05:15 - crash  (01:57)
david    tty1                          Tue Feb 18 05:14 - crash  (01:58)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 05:11 - crash  (02:01)
david    pts/2        :0.0             Tue Feb 18 04:23 - crash  (00:48)
david    pts/1        192.168.6.111    Tue Feb 18 04:16 - crash  (00:54)
root     pts/1        192.168.6.111    Tue Feb 18 03:26 - 03:26  (00:00)
david    tty1                          Tue Feb 18 02:48 - crash  (02:22)
david    pts/0        192.168.6.104    Tue Feb 18 02:42 - crash  (02:29)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 02:34 - crash  (02:37)
david    tty1                          Tue Feb 18 02:32 - 02:33  (00:00)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 02:32 - 02:33  (00:01)
david    tty1                          Tue Feb 18 02:20 - 02:31  (00:10)
david    pts/0        192.168.6.104    Tue Feb 18 01:19 - 02:31  (01:11)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 01:19 - 02:31  (01:11)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 01:10 - 01:11  (00:00)
david    pts/0        192.168.6.104    Mon Feb 17 18:36 - 01:10  (06:34)
david    tty1                          Mon Feb 17 18:00 - 01:10  (07:10)
reboot   system boot  6.13.2-arch1-1   Mon Feb 17 17:59 - 01:10  (07:10)
reboot   system boot  6.13.2-arch1-1   Mon Feb 17 17:54 - 17:54  (00:00)

But that isn't much help identifying what. The Xorg.0.log files have no errors. I've looked though /var/log and nothing is interesting. I know correlation is not causation, but the first "crash" noted in the "last" log above seems to correspond to the first reboot when startx was used and each subsequent crash would correspond to when lightdm was used and the system just magically rebooted.

What to check to find the cause of what is happening?

I've updated the BIOS and firmware from HP, and everything is now current. However the issue still occurs. I think I was off on the initial time, or this may be more random, the last reboot (which just happened), occurred right at about 30 minutes after the last journal entry. Could this be some type of ACPI or dpms power issue? This is an all-in-one computer, and other than the "crash" listed with the last command, there is no other indication I can find of any "crash" happening, so could this be some strange display powerdown (or poweroff) that is being seen by the kernel as a shutdown of the system instead of just the display? (seems far fetched, but I'm guessing here). How would you go about finding the cause?

There is a i915 kernel parameter that keeps writing a long after a crash for diagnostic purposes, I'll look up what that one is and add it and see if anything turns up on next crash. Any other ideas, please let me know.

Last edited by drankinatty (2025-02-19 06:42:54)

Lone_Wolf · 2025-02-19 12:44:03

Is xf86-video-intel installed ?

If yes, remove it .

The log snippet shows you are running lightdm .
Try booting to multi-user target so lightdm will not be started , then use startx and test.

drankinatty · 2025-02-19 19:17:36

xf86-video-intel is not installed. I had temporarily installed it to test, then removed it when the "legacy boot enabled, secure boot disabled" choice was changed both disabled and the boot worked fine-

I originally was using startx from multiuser target when this reboot issue started. I added lightdm at the point you see in the logs above. I've disabled it and have rebooted to multiuser and used startx again as a test.

I really think this looks like some kind of power saving level that is causing this. The history in the last[ log is looking that way, but I've got no clue what. The journal contains nothing sleep or hibernate related. The current last log showing the reboot history (picking up from where the original left off) is:

david    pts/0        :0.0             Wed Feb 19 12:29   still logged in
david    tty7         :0               Wed Feb 19 12:28   still logged in
reboot   system boot  6.13.2-arch1-1   Wed Feb 19 12:19   still running
reboot   system boot  6.13.2-arch1-1   Wed Feb 19 12:05   still running
reboot   system boot  6.13.2-arch1-1   Wed Feb 19 11:33   still running
reboot   system boot  6.13.2-arch1-1   Wed Feb 19 11:12   still running
reboot   system boot  6.13.2-arch1-1   Wed Feb 19 09:15   still running
david    pts/1        :0.0             Wed Feb 19 08:42 - crash  (00:32)
david    pts/1        :0.0             Wed Feb 19 08:40 - 08:42  (00:02)
david    pts/2        :0.0             Wed Feb 19 08:39 - crash  (00:35)
david    pts/2        :0.0             Wed Feb 19 08:31 - 08:36  (00:05)
david    pts/1        :0.0             Wed Feb 19 08:25 - 08:40  (00:14)
david    pts/0        :0.0             Wed Feb 19 07:45 - 08:29  (00:44)
david    tty7         :0               Wed Feb 19 07:45 - crash  (01:29)
reboot   system boot  6.13.2-arch1-1   Wed Feb 19 07:44   still running
reboot   system boot  6.13.2-arch1-1   Wed Feb 19 07:24   still running
reboot   system boot  6.13.2-arch1-1   Wed Feb 19 06:45   still running
david    pts/2        :0.0             Wed Feb 19 04:48 - crash  (01:57)
david    pts/1        192.168.6.104    Wed Feb 19 04:39 - crash  (02:06)
david    pts/0        :0.0             Wed Feb 19 04:20 - crash  (02:25)
david    tty7         :0               Wed Feb 19 04:19 - crash  (02:26)
reboot   system boot  6.13.2-arch1-1   Wed Feb 19 04:19   still running
david    pts/0        :0.0             Wed Feb 19 03:51 - crash  (00:28)
david    pts/1        192.168.6.104    Wed Feb 19 03:45 - crash  (00:33)
david    pts/1        192.168.6.104    Wed Feb 19 01:34 - 03:45  (02:11)
david    pts/0        :0.0             Wed Feb 19 00:31 - 03:51  (03:19)
david    tty7         :0               Wed Feb 19 00:31 - crash  (03:47)
reboot   system boot  6.13.2-arch1-1   Wed Feb 19 00:31   still running
david    pts/2        :0.0             Tue Feb 18 23:46 - crash  (00:44)
david    pts/0        :0.0             Tue Feb 18 23:41 - crash  (00:49)
david    pts/0        :0.0             Tue Feb 18 23:38 - 23:41  (00:02)
david    pts/2        :0.0             Tue Feb 18 23:25 - 23:38  (00:13)
david    pts/0        :0.0             Tue Feb 18 23:13 - 23:38  (00:24)
david    pts/1        192.168.6.104    Tue Feb 18 23:06 - crash  (01:24)
david    pts/0        :0.0             Tue Feb 18 23:03 - 23:13  (00:09)
david    tty7         :0               Tue Feb 18 23:03 - crash  (01:27)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 23:03   still running
david    pts/0        :0.0             Tue Feb 18 18:16 - 18:37  (00:20)
david    pts/2        :0.0             Tue Feb 18 18:10 - 18:37  (00:26)
david    pts/0        :0.0             Tue Feb 18 18:10 - 18:16  (00:06)
david    tty7         :0               Tue Feb 18 18:09 - 18:37  (00:27)
david    pts/2        :0.0             Tue Feb 18 18:09 - 18:09  (00:00)
david    pts/3        :0.0             Tue Feb 18 17:57 - 18:09  (00:11)
david    pts/1        192.168.6.104    Tue Feb 18 17:21 - 18:37  (01:15)
david    pts/0        :0.0             Tue Feb 18 17:01 - 18:09  (01:08)
david    tty7         :0               Tue Feb 18 17:00 - 18:09  (01:08)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 17:00 - 18:37  (01:37)
david    pts/0        192.168.6.104    Tue Feb 18 16:27 - crash  (00:33)
david    pts/0        192.168.6.104    Tue Feb 18 16:18 - 16:26  (00:07)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 16:14 - crash  (00:45)
david    pts/0        192.168.6.104    Tue Feb 18 16:03 - 16:09  (00:06)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 16:02 - 16:09  (00:07)
david    pts/2        192.168.6.104    Tue Feb 18 15:51 - crash  (00:10)
david    pts/1        :0.0             Tue Feb 18 15:27 - crash  (00:34)
david    pts/0        :0.0             Tue Feb 18 15:27 - crash  (00:35)
david    tty7         :0               Tue Feb 18 15:25 - crash  (00:36)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 14:43 - crash  (01:18)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 14:24 - crash  (00:18)
david    pts/0        :0.0             Tue Feb 18 13:29 - 14:24  (00:54)
david    tty7         :0               Tue Feb 18 13:28 - 14:24  (00:55)
david    tty1                          Tue Feb 18 13:27 - 13:28  (00:00)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 13:27 - 14:24  (00:57)
david    tty7         :0               Tue Feb 18 08:05 - crash  (05:21)
david    pts/0        :0.0             Tue Feb 18 07:29 - 08:04  (00:34)
david    tty1                          Tue Feb 18 07:28 - 08:05  (00:36)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 07:13 - crash  (06:13)
david    pts/0        :0.0             Tue Feb 18 05:15 - crash  (01:57)
david    tty1                          Tue Feb 18 05:14 - crash  (01:58)
reboot   system boot  6.13.2-arch1-1   Tue Feb 18 05:11 - crash  (02:01)
david    pts/2        :0.0             Tue Feb 18 04:23 - crash  (00:48)

Nobody was even using the machine this morning from 9:00 - 12:00 - that's all magical rebooting on its own. The journals all end similar to:

$ tail journal-20250219-123510.txt
Feb 19 12:05:30 ragnarok dbus-broker-launch[560]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored
Feb 19 12:05:30 ragnarok systemd[547]: Started D-Bus User Message Bus.
Feb 19 12:05:30 ragnarok dbus-broker-launch[560]: Ready
Feb 19 12:05:30 ragnarok systemd[547]: Starting Accessibility services bus...
Feb 19 12:05:30 ragnarok systemd[547]: Started Accessibility services bus.
Feb 19 12:05:30 ragnarok dbus-broker-launch[568]: Ready
Feb 19 12:05:30 ragnarok systemd[547]: Created slice Slice /app/dbus-:1.4-org.a11y.atspi.Registry.
Feb 19 12:05:30 ragnarok systemd[547]: Started dbus-:1.4-org.a11y.atspi.Registry@0.service.
Feb 19 12:05:30 ragnarok at-spi2-registryd[575]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
Feb 19 12:05:38 ragnarok dhcpcd[463]: eno1: no IPv6 Routers available

and

$ tail journal-2-20250219-123641.txt
Feb 19 11:33:55 ragnarok systemd[546]: Starting Accessibility services bus...
Feb 19 11:33:55 ragnarok systemd[546]: Started Accessibility services bus.
Feb 19 11:33:55 ragnarok dbus-broker-launch[567]: Ready
Feb 19 11:33:55 ragnarok systemd[546]: Created slice Slice /app/dbus-:1.4-org.a11y.atspi.Registry.
Feb 19 11:33:55 ragnarok systemd[546]: Started dbus-:1.4-org.a11y.atspi.Registry@0.service.
Feb 19 11:33:55 ragnarok at-spi2-registryd[574]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
Feb 19 11:34:00 ragnarok dhcpcd[456]: eno1: no IPv6 Routers available
Feb 19 11:48:58 ragnarok systemd[1]: Starting Cleanup of Temporary Directories...
Feb 19 11:48:58 ragnarok systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.
Feb 19 11:48:58 ragnarok systemd[1]: Finished Cleanup of Temporary Directories.

Really weird... No related errors in any of them.

Occurs with only startx - and - with console only in multiuser-target

This is really really weird. The reboots occur when lightdm is use, when no lightdm is used and startx is used, and when no X is started at all booted to multiuser target. This isn't hardware, this computer will run for weeks with windows. This is something unique to the kernel and this hardware. Some kernel parameter? Something unique with the i5 8500 processor with Gen 9.5 graphics? Some IOMMU issue? ACPI?

Last two reboots. First fluxbox was running started from startx. I was logged in via ssh running makepkg building gtk2 and it rebooted (nothing in journal other than normal entries above). Next, the box was booted to multiuser with no X and I was logged in via ssh simply typing mkdir and about to type the name when the reboot happened.

memtest86+ PASS - all tests

The RAM was new, so I din't expect to see anything, and I didn't. An hour or so after starting memtest, the wonderful big banner with PASS appeared in the middle of the display. I know Arch will work on this box, it looks like it's a matter of finding the necessary kernel parameters to pass to the i5 8500 with Gen 9.5 graphics. I've searched, read the wiki until I'm blue, and doesn't seem to be a "for this processor/chip, use XYZ parameters." Any other ideas?

microcode current - nothing in intel_ucode

This processor uses the 06-9e-0a microcode and there is no update for it in the Intel-Linux-Processor-Microcode-Data-Files github repository.

This CPU

For completeness, and if anyone recognizes anything funny about this CPU, the lscpu info is:

$ lscpu
Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          39 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   6
  On-line CPU(s) list:    0-5
Vendor ID:                GenuineIntel
  Model name:             Intel(R) Core(TM) i5-8500 CPU @ 3.00GHz
    CPU family:           6
    Model:                158
    Thread(s) per core:   1
    Core(s) per socket:   6
    Socket(s):            1
    Stepping:             10
    CPU(s) scaling MHz:   26%
    CPU max MHz:          4100.0000
    CPU min MHz:          800.0000
    BogoMIPS:             6000.00
    Flags:                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi
                          mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon
                           pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monit
                          or ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe p
                          opcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault
                          epb pti ssbd ibrs ibpb stibp tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust
                          bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec
                          xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clea
                          r flush_l1d arch_capabilities
Virtualization features:
  Virtualization:         VT-x
Caches (sum of all):
  L1d:                    192 KiB (6 instances)
  L1i:                    192 KiB (6 instances)
  L2:                     1.5 MiB (6 instances)
  L3:                     9 MiB (1 instance)
NUMA:
  NUMA node(s):           1
  NUMA node0 CPU(s):      0-5
Vulnerabilities:
  Gather data sampling:   Mitigation; Microcode
  Itlb multihit:          KVM: Mitigation: Split huge pages
  L1tf:                   Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled
  Mds:                    Mitigation; Clear CPU buffers; SMT disabled
  Meltdown:               Mitigation; PTI
  Mmio stale data:        Mitigation; Clear CPU buffers; SMT disabled
  Reg file data sampling: Not affected
  Retbleed:               Mitigation; IBRS
  Spec rstack overflow:   Not affected
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; IBRS; IBPB conditional; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected
                          ; BHI Not affected
  Srbds:                  Mitigation; Microcode
  Tsx async abort:        Mitigation; TSX disabled

Update - multiuser without console-blanking - No reboots so far

I disabled console-blanking (I had used setterm --blank=4 --powerdown=5 --powersave powerdown), and the box was up for 3+ hours without a reboot. I'm not sure this is conclusive, but it would explain additional interrupts triggered with the dpms in X and blanking without X set with setterm. However, if I'm running this all-in-one without X, then I need blanking as there is no way to turn the monitor off -- it's the computer itself. I can set /sys/class/backlight/intel_backlight/brightness to 0, but that really doesn't turn the backlight off and the text is still faintly visible.

This is good because the random reboots have made this box unusable with Linux. It rebooted during an update right as pacman triggered :: Running post-transaction hooks... which damn near fried the system installing devtools (and all dependencies) There were so many 0-byte files scattered around it took a few remove/reinstall attempts to identify and remove them all. But all ended well, building in a clean chroot is now ready, as long as it can complete before a reboot occurs.

dmesg startup info for graphics, drm and bus-id

There is a stray error during startup that looks like a regression from [SOLVED] no hdmi out (Failed to probe LSPCON), but not harmful overall. That said, for completeness here is the complete graphics, drm and bus-id information from boot:

$ sudo dmesg | grep -i 'drm\|i915\|00:02.0'
[    0.306200] pci 0000:00:02.0: [8086:3e92] type 00 class 0x030000 PCIe Root Complex Integrated Endpoint
[    0.306208] pci 0000:00:02.0: BAR 0 [mem 0xf0000000-0xf0ffffff 64bit]
[    0.306214] pci 0000:00:02.0: BAR 2 [mem 0xe0000000-0xefffffff 64bit pref]
[    0.306218] pci 0000:00:02.0: BAR 4 [io  0x3000-0x303f]
[    0.306236] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[    0.317372] pci 0000:02:00.0: [10ec:522a] type 00 class 0xff0000 PCIe Endpoint
[    0.317447] pci 0000:02:00.0: BAR 0 [mem 0xf1000000-0xf1000fff]
[    0.317931] pci 0000:02:00.0: supports D1 D2
[    0.317933] pci 0000:02:00.0: PME# supported from D1 D2 D3hot D3cold
[    0.344688] pci 0000:00:02.0: vgaarb: setting as boot VGA device
[    0.344688] pci 0000:00:02.0: vgaarb: bridge control possible
[    0.344688] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[    0.572970] ACPI: bus type drm_connector registered
[    0.598372] simple-framebuffer simple-framebuffer.0: [drm] Registered 1 planes with drm panic
[    0.598373] [drm] Initialized simpledrm 1.0.0 for simple-framebuffer.0 on minor 0
[    0.602594] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
[    1.592331] rtsx_pci 0000:02:00.0: enabling device (0100 -> 0102)
[    2.170958] i915 0000:00:02.0: [drm] Found coffeelake (device ID 3e92) display version 9.00 stepping N/A
[    2.203370] i915 0000:00:02.0: vgaarb: deactivate vga console
[    2.254635] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    2.255530] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[    2.545911] i915 0000:00:02.0: [drm] *ERROR* Failed to probe lspcon
[    2.545950] [drm] Initialized i915 1.6.0 for 0000:00:02.0 on minor 1
[    2.596925] fbcon: i915drmfb (fb0) is primary device
[    3.735209] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[    4.395109] systemd[1]: Starting Load Kernel Module drm...
[    4.415754] systemd[1]: modprobe@drm.service: Deactivated successfully.
[    4.415963] systemd[1]: Finished Load Kernel Module drm.
[    4.872882] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
[    4.946318] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])

Does the "[drm] *ERROR* Failed to probe lspcon" have any bearing on the reboot issue? Is this a possible regression of what was fixed in linux-5.14.7?

If the reboot is cause by an interrupt related to the display power management, what kernel parameters to start with to try and solve the issue? I'm drawing blanks on this one

It's a BUG

I'm just lucky... This is a bug that was fixed and is now back, drm:intel_dp_detect [i915] *ERROR* LSPCON init failed on port D. So it looks like we can put this matter on hold until the freedesktop folks work their magic again. I'll update when I get further information.

Last edited by drankinatty (2025-02-20 09:15:26)

seth · 2025-02-21 08:08:49

I disabled console-blanking (I had used setterm --blank=4 --powerdown=5 --powersave powerdown), and the box was up for 3+ hours without a reboot.
…
https://gitlab.freedesktop.org/drm/i915 … ssues/4458

\o/
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

drankinatty · 2025-03-01 23:18:13

The bug is actually several bugs that differ in severity based on kernel version. The bug posted above deals with earlier kernels and a failure to "init" lspcon. Current kernel fails to even "probe" the device. I have a bug open with openSUSE and progress is being made Bug 1238185 - i915 dpms Bug Triggers Reboot, lspcon probe failed - untainted kernel. I'll post here when we have a solution. Right now Arch fails to "probe", we have patched 6.13.5 (Takashi did), and now probe succeeds, but the reboot still occurs about 2 minutes after dpms powerdown.

The following repeats 5-6 times over approximately 2.5 minutes after dpms is triggered before the reboot occurs: The current debug output shows an issue with kernel: i915 0000:00:02.0: ACPI _REG connect evaluation failed (5) and the error repeats but as a "disconnect" error at the end of the save config block. The debug output is:

Mar 01 15:52:39 niflheim kernel: i915 0000:00:02.0: power state changed by ACPI to D3hot
Mar 01 15:52:49 niflheim kernel: i915 0000:00:02.0: power state changed by ACPI to D0
Mar 01 15:52:49 niflheim kernel: i915 0000:00:02.0: ACPI _REG connect evaluation failed (5)
Mar 01 15:52:49 niflheim kernel: i2c i2c-0: NAK from device addr 0x50 msg #0
Mar 01 15:52:49 niflheim kernel: i2c i2c-0: NAK from device addr 0x50 msg #0
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x00: 0x3e928086
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x04: 0x00100407
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x08: 0x03000000
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x0c: 0x00000000
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x10: 0xf0000004
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x14: 0x00000000
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x18: 0xe000000c
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x1c: 0x00000000
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x20: 0x00003001
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x24: 0x00000000
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x28: 0x00000000
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x2c: 0x83eb103c
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x30: 0x00000000
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x34: 0x00000040
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x38: 0x00000000
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: save config 0x3c: 0x000001ff
Mar 01 15:53:00 niflheim kernel: i915 0000:00:02.0: ACPI _REG disconnect evaluation failed (5)

Last edited by drankinatty (2025-03-02 00:22:25)

seth · 2025-03-02 09:36:01

https://bugzilla.opensuse.org/show_bug. … 1238185#c5

1. nomodeset will pretty much prevent any GUI target, pair it w/ the multi-user.target (nd link below)
2. try to limit the c-state and or keep the CPU busy during the DPMS, https://wiki.archlinux.org/title/Intel_ … Intel_CPUs

echo "scale=5000; a(1)*4" | bc -l # raise the scale if that's not "busy enough" - and don't psot the result ;)

drankinatty · 2025-03-06 00:02:43

The openSUSE bug, after multiple attempts with nomodeset, configuring kdump, etc. and coming up short, has resulted in a new bug filed with freedesktop as i915 with i5-8500 Gen 9.5 graphics - dpms triggers crash/reboot on activation (untainted kernel). This is an i915 kernel bug. It will have to be resolved in order for this HP box to use dpms.

Update From freedesktop Bug

There are several known issues with the i915 kernel driver. One kernel parameter that has allowed the display to blank and suspect without rebooting is i915.enable_dc=0`. Though this is not a complete fix. From startx, when blanking (without dpms) the display goes into suspend/powerdown mode. However when using a display manager and desktop, the display goes into suspend and powerdown, but then the backlight immediately turns back on (the display is still blank, but backlight is back on). Hopefully the bug will provide a solution, because having the backlight turn off without a reboot is what is needed.

Last edited by drankinatty (2025-03-08 02:53:02)

Arch Linux

#1 2025-02-18 23:37:02

New Install Reboots Every X Minutes in Graphical Target? d-bus?

#2 2025-02-19 12:44:03

Re: New Install Reboots Every X Minutes in Graphical Target? d-bus?

#3 2025-02-19 19:17:36

Re: New Install Reboots Every X Minutes in Graphical Target? d-bus?

#4 2025-02-21 08:08:49

Re: New Install Reboots Every X Minutes in Graphical Target? d-bus?

#5 2025-03-01 23:18:13

Re: New Install Reboots Every X Minutes in Graphical Target? d-bus?

#6 2025-03-02 09:36:01

Re: New Install Reboots Every X Minutes in Graphical Target? d-bus?

#7 2025-03-06 00:02:43

Re: New Install Reboots Every X Minutes in Graphical Target? d-bus?

Board footer