Please see the link below. I confirm this as many others do as well.
Beware! Don’t upgrade to linux kernel 5-19-12-arch1-1 on arch linux
3 Likes
Greetings.
Currently experiencing a very peculiar issue regarding hibernation on Arch Linux and the FW 12th, while using Xorg and i3 window manager.
Namely, whenever I resume from hibernation (suspend-to-disk), I am greeted by a blank screen.
The system effectively resumes, the screen does turn, and I can even see and move the mouse, I can interact with the terminal windows that were previously opened before entering hibernation, but beside that the whole screen just stays black.
I would really appreciate if someone could help by trying to run systemctl hibernate on their Framework with Arch, then resume and let me know if they have the same black screen problem on resume.
As a sanity check, I also ran systemctl hibernate from a tty instead of a graphical session, and it does not result in the black screen problem on resume. I suspect some i915 driver related error so far.
I tried many kernels such as linux-mainline, linux-clear, linux-lts already, but to no avail.
Thanks a lot for your time.
For reference, the relevant configuration files of the system would be as follows:
- FW i7-1280P; 2x8GiB
- Arch Linux 5.19.11 (not the recently broken kernel)
- GRUB Kernel parameters
linux /vmlinuz-linux root=UUID=unlocked_part_UUID rw
cryptdevice=UUID=encrypted_part_UUID :root:allow-discards
root=/dev/mapper/root resume=UUID=unlocked_part_UUID
resume_offset=swapfile_offset loglevel=3 quiet intel_pstate=disable
security=apparmor mitigations=auto mem_sleep_default=deep
nvme.noacpi=1 acpi_osi=!'Windows 2020'
echo 'Loading initial ramdisk ...'
initrd /intel-ucode.img /initramfs-linux.img
/etc/mkinitcpio.conf
MODULES=(i915)
BINARIES=()
FILES=()
HOOKS=(base udev autodetect keyboard keymap consolefont modconf block encrypt filesystems resume fsck)
- `/etd/modprob.d/i915.conf
options i915 enable_psr=0
# options i915 enable_guc=3
# options i915 enable_fbc=0
I run arch, no problems here. Im a n00b with i3 tho, still learning.
That kernel problem bugged me for 3 hours (gave up, fixed next day by LTS kernel) and due to my differences and not yet figured out how i want to suspend to disk, no swap. not sure if any of the following is going to be helpfull
I should keep an eye on the forums more often.
I use i3lock and GDM, as Nodm dint work for me (out of the box and the hours trying to make it work, it booted, started i3 fine, but wouldnt lock for a reason, havent revisited it with the new compositor im using now). got no swap part nor file, so im not truly suspending (to disk), just ram I guess.
- FW, i5-1240P; 1x32GiB
- Arch Linux framework 5.15.71-1-lts (was the easy for to not use the broken kernel)
Not using grub, since ever: EFI variable stuff:
Boot0000* Arch Linux HD(1,GPT,encrypted_part_UUID)/File(\EFI\arch\vmlinuz-linux.efi)cryptdevice=/dev/nvme0n1p2:root root=/dev/mapper/root rw initrd=\EFI\arch\intel-ucode.img initrd=\EFI\arch\initramfs-linux.img
mkinitcpio.conf:
MODULES=(i915)
BINARIES=()
FILES=()
HOOKS=(base udev autodetect keyboard keymap consolefont modconf block encrypt filesystems fsck)
/etc/modprob.d/i915.conf (I added these before I started using i3lock):
EDIT: commented these 2 away, system seems to boot just as fast and i can still suspend. no hibernation ofcourse (no swapspace).
#This should enable framebuffer compression
options i915 enable_fbc=1
# Faster boot, by preserving the framebuffer that has been setup by the bios/uefi
options i915 fastboot=1
question, how can i make Arch automaticly rename the vmlinuz-linux file to add .efi extension? the insideH2O bios doesnt read efi files without the extension. (mkinitcpio default preset kinda worked but also broke if i named it there)
1 Like
My friend has a 12th gen framework laptop running Arch Linux GNOME, but he experiences constant stutter in animations even if no power management tools (like tlp, powertop) is installed. Tried setting acpi_osi="Windows 2020" and i915 in MODULES inside mkinitcpio.conf, and disable psr. I’m not sure where the issue is.
1 Like
According to some discussion in Discord, it should be acpi_osi=!'Windows 2020' instead.
Disabling PSR seems to do the trick for most people over here. How exactly did you / he disable it ?
Also, what is the linux kernel version in use ? Some recent versin like 5.19.12 are known for graphics driver regressions.
Replying in this thread because it’s more fitting. Sorry I couldn’t get back to you earlier.
But I’ve been running 6.0.0-1-clear since the compile finished this morning and it’s running great. Hibernation worked fine every time as well as suspend-then-hibernate.
Can’t really say that was always the case earlier, more often than not it worked fine but every now and then it didn’t really wake from sleep or hibernation, sometimes the display would flicker or the screen appeared frozen until it somehow resumed but maybe that’s just me.
I want to say that it’s finally working flawless especially because it somehow feels smoother/more stable (at least in gnome) but I need to do more testing.
Anyway I’d recommend you give 6.0 a try and let is know how it goes.
For what it’s worth here’s some of my configs:
❯ cat /proc/cmdline
mem_sleep_default=deep nvme.noacpi=1 rd.luks.name=XXXXXX=cryptroot rd.luks.options=XXXXXX=discard root=/dev/mapper/root rootflags=subvol=@ rd.luks.options=discard resume=UUID=XXXXXX resume_offset=9261768 quiet splash vt.global_cursor_default=0 rw
❯ cat /etc/mkinitcpio.conf
# 'intel_agp' probably not useful here but didn't test it without yet
MODULES=(i915 intel_agp)
BINARIES=()
FILES=()
HOOKS=(base systemd sd-plymouth autodetect keyboard sd-vconsole modconf block sd-plymouth-tpm2-totp sd-encrypt btrfs filesystems fsck)
❯ systool -m i915 -av
Module = "i915"
Attributes:
coresize = "2732032"
initsize = "0"
initstate = "live"
refcnt = "24"
taint = ""
uevent = <store method only>
Parameters:
disable_display = "N"
disable_power_well = "-1"
dmc_firmware_path = "(null)"
edp_vswing = "0"
enable_dc = "-1"
enable_dp_mst = "Y"
enable_dpcd_backlight= "-1"
enable_fbc = "1"
enable_guc = "-1"
enable_gvt = "N"
enable_hangcheck = "Y"
enable_ips = "1"
enable_psr2_sel_fetch= "Y"
enable_psr = "1"
error_capture = "Y"
fastboot = "1"
force_probe = "*"
force_reset_modeset_test= "N"
guc_firmware_path = "(null)"
guc_log_level = "-1"
huc_firmware_path = "(null)"
invert_brightness = "0"
lmem_bar_size = "0"
lmem_size = "0"
load_detect_test = "N"
lvds_channel_mode = "0"
memtest = "N"
mitigations = "auto"
mmio_debug = "0"
modeset = "-1"
nuclear_pageflip = "N"
panel_use_ssc = "-1"
psr_safest_params = "N"
request_timeout_ms = "20000"
reset = "3"
vbt_firmware = "(null)"
vbt_sdvo_panel_type = "-1"
verbose_state_checks= "Y"
Most notably running i915 now with fastboot, fbc & psr = 1 without problems so far.
1 Like
@apol1o Thanks a lot for the detailed answer. Glad to know hibernation is working well on your side. Maybe there is some hope for me too.
Just wanted to make sure that linux-clear 6.0 was working well, because it takes quite a while to compile for me. Will be trying again.
Did you compile linux-clear with the 35. Intel Alder Lake (MALDERLAKE) option too ?
Just to be sure, are you setting those via /etc/modprob.d/i915.conf-like configuration ? Because I did not see anything related to i915 in your kernel parameter line.
Thanks again for the answer.
Yeah we’ll see how it goes tonight, last night on 5.19.10 when it woke up from sleep to go into hibernation it failed to actually go into hibernate or didn’t wake up correctly, I’m not sure. Anyway the battery was completely dead next morning.
Yes, doing the 35. Alder Lake build too, haven’t actually tried another one yet. How long does it take you?
I’m just about under 20min with my modified makepkg.conf, maybe take a loot below but MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN)" probably does the biggest difference.
makepkg.conf
#!/hint/bash
#
# /etc/makepkg.conf
#
#########################################################################
# SOURCE ACQUISITION
#########################################################################
#
#-- The download utilities that makepkg should use to acquire sources
# Format: 'protocol::agent'
DLAGENTS=('file::/usr/bin/curl -qgC - -o %o %u'
'ftp::/usr/bin/curl -qgfC - --ftp-pasv --retry 3 --retry-delay 3 -o %o %u'
'http::/usr/bin/curl -qgb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
'https::/usr/bin/curl -qgb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
'rsync::/usr/bin/rsync --no-motd -z %u %o'
'scp::/usr/bin/scp -C %u %o')
# Other common tools:
# /usr/bin/snarf
# /usr/bin/lftpget -c
# /usr/bin/wget
#-- The package required by makepkg to download VCS sources
# Format: 'protocol::package'
VCSCLIENTS=('bzr::bzr'
'fossil::fossil'
'git::git'
'hg::mercurial'
'svn::subversion')
#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"
#-- Compiler and Linker Flags
#CPPFLAGS=""
CFLAGS="-march=native -mtune=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -fno-plt \
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \
-fstack-clash-protection -fcf-protection"
CXXFLAGS="-march=native -mtune=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -fno-plt"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
LTOFLAGS="-flto=auto"
RUSTFLAGS="-C opt-level=2 -C target-cpu=native"
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN) --quiet"
#-- Debugging flags
DEBUG_CFLAGS="-g"
DEBUG_CXXFLAGS="$DEBUG_CFLAGS"
#DEBUG_RUSTFLAGS="-C debuginfo=2"
#########################################################################
# BUILD ENVIRONMENT
#########################################################################
#
# Makepkg defaults: BUILDENV=(!distcc !color !ccache check !sign)
# A negated environment option will do the opposite of the comments below.
#
#-- distcc: Use the Distributed C/C++/ObjC compiler
#-- color: Colorize output messages
#-- ccache: Use ccache to cache compilation
#-- check: Run the check() function if present in the PKGBUILD
#-- sign: Generate PGP signature file
#
BUILDENV=(!distcc color ccache check !sign)
#
#-- If using DistCC, your MAKEFLAGS will also need modification. In addition,
#-- specify a space-delimited list of hosts running in the DistCC cluster.
#DISTCC_HOSTS=""
#
#-- Specify a directory for package building.
#BUILDDIR=/tmp/makepkg
#########################################################################
# GLOBAL PACKAGE OPTIONS
# These are default values for the options=() settings
#########################################################################
#
# Makepkg defaults: OPTIONS=(!strip docs libtool staticlibs emptydirs !zipman !purge !debug !lto)
# A negated option will do the opposite of the comments below.
#
#-- strip: Strip symbols from binaries/libraries
#-- docs: Save doc directories specified by DOC_DIRS
#-- libtool: Leave libtool (.la) files in packages
#-- staticlibs: Leave static library (.a) files in packages
#-- emptydirs: Leave empty directories in packages
#-- zipman: Compress manual (man and info) pages in MAN_DIRS with gzip
#-- purge: Remove files specified by PURGE_TARGETS
#-- debug: Add debugging flags as specified in DEBUG_* variables
#-- lto: Add compile flags for building with link time optimization
#
OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug !lto)
#-- File integrity checks to use. Valid: md5, sha1, sha224, sha256, sha384, sha512, b2
INTEGRITY_CHECK=(sha256)
#-- Options to be used when stripping binaries. See `man strip` for details.
STRIP_BINARIES="--strip-all"
#-- Options to be used when stripping shared libraries. See `man strip` for details.
STRIP_SHARED="--strip-unneeded"
#-- Options to be used when stripping static libraries. See `man strip` for details.
STRIP_STATIC="--strip-debug"
#-- Manual (man and info) directories to compress (if zipman is specified)
MAN_DIRS=({usr{,/local}{,/share},opt/*}/{man,info})
#-- Doc directories to remove (if !docs is specified)
DOC_DIRS=(usr/{,local/}{,share/}{doc,gtk-doc} opt/*/{doc,gtk-doc})
#-- Files to be removed from all packages (if purge is specified)
PURGE_TARGETS=(usr/{,share}/info/dir .packlist *.pod)
#-- Directory to store source code in for debug packages
DBGSRCDIR="/usr/src/debug"
#########################################################################
# PACKAGE OUTPUT
#########################################################################
#
# Default: put built package and cached source in build directory
#
#-- Destination: specify a fixed directory where all packages will be placed
#PKGDEST=/home/packages
#-- Source cache: specify a fixed directory where source files will be cached
#SRCDEST=/home/sources
#-- Source packages: specify a fixed directory where all src packages will be placed
#SRCPKGDEST=/home/srcpackages
#-- Log files: specify a fixed directory where all log files will be placed
#LOGDEST=/home/makepkglogs
#-- Packager: name/email of the person or organization building packages
#PACKAGER="John Doe <john@doe.com>"
#-- Specify a key to use for package signing
#GPGKEY=""
#########################################################################
# COMPRESSION DEFAULTS
#########################################################################
#
COMPRESSGZ=(pigz -c -f -n)
COMPRESSBZ2=(pbzip2 -c -f)
COMPRESSXZ=(xz -T "$(getconf _NPROCESSORS_ONLN)" -c -z --best -)
COMPRESSZ=(compress -c -f)
COMPRESSLRZ=(lrzip -9 -q)
COMPRESSLZ=(lzip -c -f)
COMPRESSZ=(compress -c -f)
COMPRESSZST=(zstd -c -z -q --threads=0 -)
COMPRESSLZ=(lzip -c -f)
COMPRESSLZ=(lzip -c -f)
#########################################################################
# EXTENSION DEFAULTS
#########################################################################
#
PKGEXT='.pkg.tar.zst'
SRCEXT='.src.tar.gz'
#########################################################################
# OTHER
#########################################################################
#
#-- Command used to run pacman as root, instead of trying sudo and su
#PACMAN_AUTH=()
Yes, indeed. I believe with early KMS you should include these options in /etc/modprobe.d/*.
1 Like
Thanks a lot for the tip. I matched my makepkg.conf with yours, but it still takes around 2 to 3 hours to build.
Do you manually run makepkg -si in the same folder as the PKGBUILD file ? Maybe the make compilation parallelization gets overriden somewhere because I use paru -S linux-clear instead ?.
Compiled the linux-clear 6.0.0.1-clear and can confirm that PSR related issues on 5.19.11 are gone at least.
/etc/modprob.d/i915.conf was set as follows:
options i915 enable_psr=1
options i915 enable_fbc=1
options i915 fastboot=1
Also did my best to match your kernel parameters, but systemctl hibernate still breaks on resume for me even on linux-clear.
Running systool -m i915 -av and diff-ing with yours gives a single difference:
Attributes:
...
refcnt = "20" # Yours is 24
but looking it up does not bring anything relevant to the refcnt field.
I will try to use the sd-encrypt partition unlocking method, instead of encrypt (currently using), which seems one of the main difference between our configs.
Worst case, I will try to install a fresh Arch install without encryption and test check whether hibernation works or not.
Will be reporting in about 3 days.
Thanks again for the assistance.
EDIT: @apol1o One more thing, do you happen to use any composer ?
So I was curious and gave linux-clear a try yesterday just to see if there was much of a performance gain. Boot times were a few seconds faster, and single-threaded Geekbench numbers were about 2% faster, but the big surprise to me was that the power consumption was much worse than both the Arch linux kernel and linux-mainline.
powerstat reported average idle power consumption was 0.5W higher (3.7W vs 3.2W), and playing a YouTube video was 16-18W (vs 11-12W on the other kernels) eyeballing with powertop.
I think linux-clear has some extremely aggressive battery performance settings since even though I made no changes to thermald or tlp setup, linux-clear basically maintained almost full performance on benchmark runs on battery, while linux and linux-mainline both go into a less aggressive profile that shaves off about 50% on ST and 30% on MT Geekbench scores when unplugged.
If anyone is planning to regularly use linux-clear I’d be sure to do some perf/power benchmarking to make sure it’s worth it for your use case.
My tests were w/ 6.0 on linux-mainline and linux-clear and the fixed 5.9.13 w/ linux.
I’m using yay, perhaps paru or even yay for that matter don’t use the system makepkg.conf by default.
yay --save --makepkgconf /etc/makepkg.conf this will tell yay which makepkg.conf file to use. Maybe paru has something similar?
That’s too bad. Honestly, no idea where to go from here. Which bootloader do you use? And some kind of display/session manager like gdm?
You will need to use systemd in your hooks too. With sd-encrypt you won’t need the resume hook anymore.
https://wiki.archlinux.org/title/Dm-crypt/System_configuration#Examples
Also don’t forget to change your boot paremeters. For example cryptdevice=UUID:mapperName is equivalent to rd.luks.name=UUID=mapperName with sd-encrypt.
Good luck!
I’m using sway when I’m on the go and mostly Gnome when docked. Just woke up and suspend-then-hibernate seems to have worked once more.
That idle consumption seems to be a bit high, which command (options) exactly are you using to measure it?
Did you compile linux-clear yourself or did you install linux-clear-bin?
For me it was slightly lower when idle but much lower when watching Youtube and stuff but there’s too many variables here to make a real comparison.
I feel like OOTB tlp doesn’t do much these days. I set the EPP to 225 when on battery for example. Took the value from another thread but seems to be a good middleground for me.
(CPU_ENERGY_PERF_POLICY_ON_BAT=225)
Using GRUB as bootloader.
Xorg + i3wm for the GUI. No session manager. just login into the tty1, then running startx.
I just run powerstat -a. You can see details of how I do my idle power testing here. (basically it waits 180s and then does 300s of sampling to generated a result)
I am running linux-clear not linux-clear-bin so yes, it was a custom compile with MALDERLAKE.
Maybe I’ll play around w/ EPP and see w/ all the kernels since I’ve been pretty disappointed in general w/ how battery usage w/ YouTube playback, even in Firefox where I have full HW acceleration (it’s about 1-2W lower than Chrome, which doesn’t have working HW decode).
1 Like
I am using endeavor with XFCE here, and it has driven me up a wall.
To keep it short:
No tip has extended the four hour battery life for me. Certain programs, such as Discord, endeavor easy package install, will not redraw and will display a frozen image until the window border is changed in any way. Certain icons for window borders and menus will be tiny for zero reason. Scaling in general is broken and doesn’t cooperate with me.
Can someone please, please tell me what I’m doing wrong? I’ve tried two days worth of troubleshooting and absolutely nothing has fixed all of those issues.
1 Like
Update, found out my mic doesn’t work either. Fantastic.
1 Like
So I run Arch, not Endevour, but they are the same base. I’ve had really good luck reading the Arch Wiki to make most things work great. Lemme share a few things that might help… theres a Frame.work Arch wiki entry:
Framework Arch Wiki Entry
The newest kernel, 5.19+, sometimes creates several video-related bugs/issues. I install both Linux and Linux-LTS kernels; if the kernel is ever creating bugs, or updates and creates new ones, you can just select the Linux-LTS in GRUB and it’ll squash those. The forum is currently reporting issues on 5.19.12, so this might help you;
How to install Linux-LTS alongside Linux kernel
Remember, I’ve setup Arch from the ground up - so I don’t have experience using EndevourOS (on the frame, anyway)… I think you need to look at issues a different way. LIKE, are the video issues you mentioned because of the kernel? Etc…
One thing at a time, and many times where yer sniffing isn’t where the problem is. Sorry yer not loving Endevour on the frame. Heck; I installed Windows 11 just to see the difference. I’ve had the most luck with Fedora and Arch on the Frame, Linux side anyway. Hope you iron things out.
1 Like
Has anybody tried kernel 5.19.13 yet? If so, can you report whether it plays well with framework laptop display or not?
Thanks!
2 Likes
5.19.13 works fine. You can also see reports here of working versions at the end of this thread: PSA: don't upgrade to linux kernel 5.19.12
4 Likes
5.19.12 broke mine as described. Arch Linux LTS kernel temporarely fixed my system (could also have downgraded the kernel)
5.19.13 right now works great again. no display problems, just like before .12.
2 Likes
@CodeAsm I would really like to know how you have this setup and working. I cant for the life of me figure this out.
At the moment my screen locks up for about 10 seconds at a time and then is usable for about 10 seconds. This is where I’m currently at.
Framework 12th gen
Arch 5.19.13-arch1-1
i3-gaps for my window manager
Installed mesa, and my Xorg log contains:
[ 112.325] (II) LoadModule: “intel”
[ 112.326] (WW) Warning, couldn’t open module intel
[ 112.326] (EE) Failed to load module “intel” (module does not exist, 0)
[ 112.326] (II) LoadModule: “modesetting”
[ 112.326] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 112.328] (II) Module modesetting: vendor=“X.Org Foundation”
[ 112.328] compiled for 1.21.1.4, module version = 1.21.1
[ 112.328] Module class: X.Org Video Driver
[ 112.328] ABI class: X.Org Video Driver, version 25.2
[ 112.328] (II) LoadModule: “fbdev”
[ 112.328] (WW) Warning, couldn’t open module fbdev
[ 112.328] (EE) Failed to load module “fbdev” (module does not exist, 0)
[ 112.328] (II) LoadModule: “vesa”
[ 112.329] (WW) Warning, couldn’t open module vesa
[ 112.329] (EE) Failed to load module “vesa” (module does not exist, 0)
[ 112.329] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 112.351] (II) modeset(0): using drv /dev/dri/card0
[ 112.351] (II) modeset(0): Creating default Display subsection in Screen section
I have created the file /etc/modprobe.d/i915.conf and it contains:
options i916 enable_psr=0
options i915 enable_fbc=1
options i915 fastboot=1
options i915 enable_guc=2
I have also created /etc/modprobe.d/acpi.conf and it contains:
acpi_osi="!Windows 2020"
My dmesg shows:
[ 112.549672] i915 0000:00:02.0: [drm] Selective fetch area calculation failed in pipe A
[ 113.023362] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 117.110283] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[ 117.113929] mei_pxp 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: bound 0000:00:02.0 (ops i915_pxp_tee_component_ops [i915])
[ 158.671733] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000
[ 158.672100] i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
[ 158.773810] i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1
[ 158.773824] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
[ 158.788069] i915 0000:00:02.0: [drm] HuC authenticated
[ 158.789077] i915 0000:00:02.0: [drm] GuC submission enabled
[ 158.789084] i915 0000:00:02.0: [drm] GuC SLPC enabled
[ 193.838699] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000
[ 193.838954] i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
[ 193.941669] i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1
[ 193.941686] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
The gpu hang section keeps repeating over and over.
It seems as though the chip is being reset for a stopped heartbeat.
What is wrong in my config that would cause this?
Any help would be greatly appreciated!!
2 Likes