X2L Random Reboots

I have the 8GB X2L with an Inland 1TB SSD and the Radxa A8 wireless module and the heatsink. It’s powered by a 65W laptop power supply.

I’ve tried Linux Mint 21.3 (xfce) with the 5.15 kernel initially, then upgraded to the 6.5 kernel to get the A8 to work. However, after a bit of time, it would reboot.

I then tried Fedora 39 (xfce) with 6.8.6 kernel. However, the behavior is the same. The system will be up and running for a bit of time, and then reboot without warning.

Here is an example of the reboots by searching for the start of a reboot:

# grep ': microcode:' /var/log/messages | grep Current
Apr 19 11:29:55 excalibur kernel: microcode: Current revision: 0x00000022
Apr 19 11:40:41 excalibur kernel: microcode: Current revision: 0x00000022
Apr 19 12:08:24 excalibur kernel: microcode: Current revision: 0x00000022
Apr 19 12:35:19 excalibur kernel: microcode: Current revision: 0x00000022
Apr 19 13:02:36 excalibur kernel: microcode: Current revision: 0x00000022
Apr 19 13:29:49 excalibur kernel: microcode: Current revision: 0x00000022

While the system is up, everything is stable. I’m connected via Wifi and am able to perform system updates, install software. But I can walk away with the system completely idle and come back to find that it rebooted.

$ uptime
 13:38:52 up 9 min,  1 user,  load average: 0.36, 0.25, 0.13
$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +43.0°C  (high = +105.0°C, crit = +105.0°C)
Core 0:        +41.0°C  (high = +105.0°C, crit = +105.0°C)
Core 1:        +41.0°C  (high = +105.0°C, crit = +105.0°C)
Core 2:        +41.0°C  (high = +105.0°C, crit = +105.0°C)
Core 3:        +41.0°C  (high = +105.0°C, crit = +105.0°C)

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +42.0°C  

nvme-pci-0100
Adapter: PCI adapter
Composite:    +39.9°C  (low  =  -5.2°C, high = +82.8°C)
                       (crit = +84.8°C)
Sensor 1:     +39.9°C  (low  = -273.1°C, high = +65261.8°C)

Any ideas on what I can check next to find out what’s wrong?

Thanks,
Anthony

Find the last startup log through

journalctl --list-boots

The sequence number of the last startup is usually -1, and then execute

journalctl -b -1

Maybe we can find out from the log why it restarted.

The last three lines of journalctl --list-boots:

 -2 d7b09e40f1b34de69e38e0d7eb2d244d Sat 2024-04-20 07:41:08 EDT Sat 2024-04-20 08:01:01 EDT
 -1 dadb68781d93400d95e610d3a666d142 Sat 2024-04-20 08:08:25 EDT Sat 2024-04-20 08:26:27 EDT
  0 ccc8f8d6c2f143c0b4c3413be698589d Sat 2024-04-20 08:35:42 EDT Sat 2024-04-20 08:41:16 EDT

This is the last few lines of the -1 boot: Nothing jumps out at me:

Apr 20 08:09:02 excalibur systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Apr 20 08:09:02 excalibur audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 20 08:09:02 excalibur audit: BPF prog-id=73 op=UNLOAD
Apr 20 08:09:08 excalibur avahi-daemon[786]: Leaving mDNS multicast group on interface wlp3s0.IPv6 with address fe80::972d:b8a6:7391:57f.
Apr 20 08:09:08 excalibur avahi-daemon[786]: Joining mDNS multicast group on interface wlp3s0.IPv6 with address fd0e:6044:f77f:a671:dfff:c7da:9437:596f.
Apr 20 08:09:08 excalibur avahi-daemon[786]: Registering new address record for fd0e:6044:f77f:a671:dfff:c7da:9437:596f on wlp3s0.*.
Apr 20 08:09:08 excalibur avahi-daemon[786]: Withdrawing address record for fe80::972d:b8a6:7391:57f on wlp3s0.
Apr 20 08:09:11 excalibur systemd[1]: fprintd.service: Deactivated successfully.
Apr 20 08:09:11 excalibur audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 20 08:09:11 excalibur audit: BPF prog-id=76 op=UNLOAD
Apr 20 08:10:55 excalibur chronyd[827]: Can't synchronise: no selectable sources
Apr 20 08:10:56 excalibur chronyd[827]: Selected source 66.205.249.28 (2.fedora.pool.ntp.org)
Apr 20 08:11:26 excalibur wpa_supplicant[961]: wlp3s0: WPA: Group rekeying completed with 20:c0:47:6a:b1:2c [GTK=CCMP]
Apr 20 08:14:27 excalibur systemd[1060]: Created slice background.slice - User Background Tasks Slice.
Apr 20 08:14:27 excalibur systemd[1060]: Starting systemd-tmpfiles-clean.service - Cleanup of User's Temporary Files and Directories...
Apr 20 08:14:27 excalibur systemd[1060]: Finished systemd-tmpfiles-clean.service - Cleanup of User's Temporary Files and Directories.
Apr 20 08:23:27 excalibur systemd[1]: Starting systemd-tmpfiles-clean.service - Cleanup of Temporary Directories...
Apr 20 08:23:27 excalibur systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.
Apr 20 08:23:27 excalibur systemd[1]: Finished systemd-tmpfiles-clean.service - Cleanup of Temporary Directories.
Apr 20 08:23:27 excalibur audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 20 08:23:27 excalibur audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 20 08:26:27 excalibur systemd[1]: Starting dnf-makecache.service - dnf makecache...
Apr 20 08:26:27 excalibur dnf[1166]: Metadata cache refreshed recently.
Apr 20 08:26:27 excalibur systemd[1]: dnf-makecache.service: Deactivated successfully.
Apr 20 08:26:27 excalibur systemd[1]: Finished dnf-makecache.service - dnf makecache.
Apr 20 08:26:27 excalibur audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 20 08:26:27 excalibur audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

I’m going to shutdown the X2L, remove the A8 module, and the SSD, and try:

  1. Sitting in the BIOS setup screen for an hour and see if that’s stable, maybe run something like memtest86 while no devices are connected.
  2. If that works, I’ll boot the fedora live USB and leave it for an hour.
  3. If that works, I’ll add in just the SSD and retest.
  4. If that works, I’ll add in the A8 module and retest.

I would expect something to fail before #4 succeeds.

1 Like

TL/DR: The problem was the power supplies. (Yes, that’s plural.)

I bought the X2L to replace a Raspberry Pi 5 because I wanted to use a power bank to power it on the go, and not have to deal with the stupid 5.1v/5a PD that the rPi5 uses.

I started with a Baseus 65W USB C Wall Charger, and the port I was using was supposed to supply 12v 3a. To test to make sure the problem wasn’t the wall charger, I also tried a Baseus Portable Charged, 30,000mAh Power Bank 65W Battery, which supports pass-through charging, and here the port I was using was supposed to supply 12v, 2.5a. Both of these chargers allow the X2L to run for around 27min before rebooting. No indication why. This combination was perfect for how I wanted to use my system, but I need it to run more than 27min.

I removed the SSD and the A8 and booted to the BIOS screen and left it. I came back after 30 minutes and it had rebooted. I then changed the power supply for the 3rd time to a Geekworm 27W PD power supply I use with my Raspberry Pi 5, and it works perfectly. I was able to run memtest86+ for over an hour. I put the SSD and the A8 WiFi module back in, rebooted to Fedora 39 running 6.8.6-200 kernel, has it has been stable for over 6hrs now.

The end goal is to build a portable laptop-like computer around the X2L, so I need to find a power bank that supports pass-through charging and can run the X2L in a stable manner and leaves me hopefully 8hrs+ of battery time.

But the end result is that the problem is not with the X2L, but with both of the Baseus power sources.

Thanks,
Anthony

I’m glad you found the problem.