FW 13 AMD 7640U Strange Power Issue

Which Linux distro are you using?
NIXOS 25.05, Ubuntu 24.04

Which kernel are you using?
6.12.65

Which BIOS version are you using?
3.07,3.09,3.16,3.17

Which Framework Laptop 13 model are you using?
AMD Ryzen™ 7040 Series

Hello, I have a strange issue where my laptop powers off and restarts at about 1 hour after launch.

This behavior only started after I updated my BIOS from ~3.03 (Or whatever the laptop shipped with) to 3.17.
The behavior doesn’t depend on battery level, “Battery Life Extension Mode”, “Battery Charge Limit”, external power, or charger (Anker 65W and Lenovo 45W).

I tried a few different linux kernels, base installs (Nixos and Ubuntu), and downgrading my BIOS all the way to 3.06.
Sadly, I cannot revert to the older BIOS which gave me acceptable reliability.

The journal does not contain errors, but shows a pattern of power loss happens consistently at the one hour mark.

I ran this overnight with a logging service and found the pattern.
I enabled battery disconnect for my safety.

journalctl -b -3
START
Jan 21 10:17:04 fwnix kernel: Linux version 6.12.65 (nixbld@localhost) (gcc (GCC) 15.2.0, GNU ld (GNU Binutils) 2.44) #1-NixOS SMP PREEMPT_DYNAMIC Sun Jan 11 14:25:22 UTC 2026

Jan 21 11:17:17 fwnix mgn62yxj4lj6x23g5wpry6bc3snanmnr-log-metrics[5288]: METRICS | Time: 2026-01-21 16:17:16 | Battery: N/A (No battery) | CPU: 0.17% | Memory: 656Mi / 14Gi (4685.7%) | Temp: 30°C | Disk: 126G / 192G (70%) | Uptime: 1 hour, 0 minutes
Jan 21 11:17:17 fwnix systemd[1]: system-metrics-logger.service: Deactivated successfully.
Jan 21 11:17:17 fwnix systemd[1]: Finished Log system metrics to journald.
END

journalctl -b -4
START
Jan 21 08:26:51 fwnix kernel: Linux version 6.12.65 (nixbld@localhost) (gcc (GCC) 15.2.0, GNU ld (GNU Binutils) 2.44) #1-NixOS SMP PREEMPT_DYNAMIC Sun Jan 11 14:25:22 UTC 2026

Jan 21 09:26:26 fwnix mgn62yxj4lj6x23g5wpry6bc3snanmnr-log-metrics[2842]: METRICS | Time: 2026-01-21 09:26:25 | Battery: N/A (No battery) | CPU: 0.17% | Memory: 1.0Gi / 14Gi (7.1%) | Temp: 27°C | Disk: 126G / 192G (70%) | Uptime: 59 minutes
Jan 21 09:26:26 fwnix systemd[1]: system-metrics-logger.service: Deactivated successfully.
Jan 21 09:26:26 fwnix systemd[1]: Finished Log system metrics to journald.
END

journalctl -b -5
Jan 21 07:26:08 fwnix kernel: Linux version 6.12.65 (nixbld@localhost) (gcc (GCC) 15.2.0, GNU ld (GNU Binutils) 2.44) #1-NixOS SMP PREEMPT_DYNAMIC Sun Jan 11 14:25:22 UTC 2026

Jan 21 08:25:44 fwnix mgn62yxj4lj6x23g5wpry6bc3snanmnr-log-metrics[2841]: METRICS | Time: 2026-01-21 08:25:43 | Battery: N/A (No battery) | CPU: 0.08% | Memory: 1.0Gi / 14Gi (7.1%) | Temp: 27°C | Disk: 126G / 192G (70%) | Uptime: 59 minutes
Jan 21 08:25:44 fwnix systemd[1]: system-metrics-logger.service: Deactivated successfully.
Jan 21 08:25:44 fwnix systemd[1]: Finished Log system metrics to journald.
END

Anyway, this issue started because I thought a firmware update would help the issues with my dock. Now I’ll be on the queue for a loaner laptop and maybe on the hunt for a replacement.

Hi,

Is there any chance you could try a more modern Linux kernel. E.g. 6.18.x or as close to that as you can get.
After the reboot, it might put an extra message in the logs that looks something like this:
“x86/amd: Previous system reset reason…” where … will be different depending on what it finds.

It is reporting the AMD S5_RESET_STATUS that can give some idea as to why a reboot happen.
It is useful, when the reboot happens and there are no other logs that help.

What were you doing at the time of the restart? Watching videos? what?

There are some known problems that cause the restarts, so it would be useful to know which one you are seeing.

James,

Thank you for the Kernel 6.18 suggestion. I obtained this:
[ 0.446751] x86/amd: Previous system reset reason [0x01000800]: system failed to boot before failed boot timer expired.

The restart occurs pretty consistently at an hour of uptime regardless of desktop or text-only. I was thinking that videos might trigger it early, but I’m fairly confident that is not true.

I can’t find much about the error right now. My best estimate is that the kernel or EC is failing to acknowledge a hardware timer.

I’ll try to replicate this tonight so I can ensure this is the source of my restart, then I can make progress on kernel/hardware issues.

Thank you very much for your help!

That particular reset reason is normally a result of one pressing and keeping one’s finger on the power button, to force it off. Is that what you needed to do, or did it restart itself?

1 Like

It restarts by itself. I checked the area surrounding the power button and cleared the area of other devices (in fear of magnets).

I confirmed it again and found the same 1 hr of uptime, resulting with the same reset reason.

journalctl -b -1:

Jan 21 12:19:39 fwnix kernel: Linux version 6.18.6 (nixbld@localhost) (gcc (GCC) 15.2.0, GNU ld (GNU Binutils) 2.44) #1-NixOS SMP PREEMPT_DYNAMIC Sat>
…

Jan 21 13:19:08 fwnix mgn62yxj4lj6x23g5wpry6bc3snanmnr-log-metrics[6364]: METRICS | Time: 2026-01-21 13:19:07 | Battery: N/A (No battery) | CPU: 6.42>
Jan 21 13:19:08 fwnix systemd[1]: system-metrics-logger.service: Deactivated successfully.
Jan 21 13:19:08 fwnix systemd[1]: Finished Log system metrics to journald.

dmesg (Taken during the following boot.)

[ 0.449851] x86/amd: Previous system reset reason [0x01000800]: system failed to boot before failed boot timer expired”.

Thanks again for your help!

Here are the various status I see and what I have seen trigger them:

  1. “software wrote 0x6 to reset control register 0xCF9” means you asked the laptop to reboot normally, from the menu or the reboot command.
  2. “system failed to boot before failed boot timer expired” means you booted the system from cold. It might also be seen if the EC (embedded controller) crashed and restarted the laptop.
  3. “an uncorrected error caused a data fabric sync flood event” means something went wrong, and we (other users) have not worked out the cause yet. This is the one we have been associated with FTR (Freeze then reboot).
  4. “ACPI power state transition occurred”. I have no idea what causes this one. It is not output after a suspend. It is just in my logs, but I have not associated any actions with it.

So, as you are seeing (2) with unexpected reboots, I don’t know what is causing that. It is a new one as far as I know.
Maybe the BIOS / EC is misconfiguration or something.

You could raise a FW support issue via the FW web site support form.

See if you can get the “ectool” program working.
Do an “ectool console” after the reboot and post the output here.

1 Like

I see, thank you for the detailed response!

I’m unsure of the workings of ectool (it seems like it auto-detects the interface), but I gave it a try without success:

sudo ectool console
_reg8 failed: ctrl=0x0, reg=0x00]
[935.616500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.621700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.627000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.632300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.638800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.644300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.649700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.656200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.661700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.667100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.673800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.679200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.684600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.691200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.696600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.702000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.708700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.714000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.719500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.724700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.731300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.736700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.742100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.748600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.754200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.759500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.766200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.771500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.776800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.783300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.788600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.794100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.800800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.806100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.811500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.816900 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.823500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.828900 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.834100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.840800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.846100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.851200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.857900 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.863100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.868500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.875100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.880500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.885800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.892500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.897800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.903100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.908500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.915000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.920400 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.925800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.932300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.937800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.943200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.949900 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.955400 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.960700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.967400 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.972900 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.978300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.985000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.990400 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[935.995700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[936.001100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[936.007500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[936.013000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[936.018300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[936.024800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[936.022200 HC 0x0002]
[936.030200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[936.035700 HC 0x000b]

Again, I doubt I’m using ectool correctly, but I think your right about the potential for an EC misconfiguration.

I’m out of support for the mainboard, so I might get a friend or repair shop to look into re-flashing the BIOS or EC.

Since you seem knowledgeable about these failure modes, would you personally recommend replacing the mainboard with another 7640u? Or are the newer AMD or Intel boards more trustworthy?

I thank you sincerely for your help.

Well, interesting ectool console output.

Your laptop might not be recharging the battery any more. Please keep an eye on the battery charge. If it is not charging any more, you might not have much time to fix this before the battery fails.

The “935.656200” are timestamps.
They are seconds since the EC (Embedded Controller) rebooted itself.
When your system next reboots, when it starts, see if the timestamps have started again from near zero. I.e. indicating that the reboot might be caused by the EC rebooting.

Also, please do an “ectool version” and post the output.
I think their might be something wrong with the ec firmware and that command will confirm it or not.

According to the BIOS release notes, you can downgrade the BIOS back as far as 3.06 if you wish.

If you still get new repeated cypd_read_reg8 failed messages, try redoing the BIOS update.
The theory I have at the moment, is that your BIOS update did not work properly.
You can use “fwupdmgr” to try to repeat the process, or downgrade the BIOS.

The cypd_read_reg8 failed messages mean the EC cannot reach the USB controllers, and the message is being repeated very quickly. If there is too much being sent to the EC console, it hits a watchdog timeout and resets itself. I think this is what is happening to your mainboard.

So, you will know it is fixed once those cypd_read_reg8 failed messages stop happening.

Just throwing this out there…@James3 is much more versed in Linux and EC messages though.

It is possible that updating the BIOS somehow did not reset or clear all the values it was supposed to. I remember reading guidance that after a BIOS update to go into the BIOS and load the optimized defaults helps to clear up this state sometimes.

Out of curiosity I wonder if running the Ubuntu Live from a USB gets the same result after an hour? I know it might be possible to reflash the BIOS with the EFI tools but that would take some extra switches on the command line and probably best with Framework support guidance to ensure everything goes smoothly.

Just some thoughts as I was reading the detailed posts. Best of luck.

@James3 (pkunk, I address your concerns below),
I took these readings as soon as I reached the desktop, following the restart.

[john@fwnix:~]$ sudo ectool version
RO version: azalea_v3.4.113391-ec:03829d,os
RW version: azalea_v3.4.113391-ec:03829d,os
Firmware copy: RO
Build info: azalea_v3.4.113391-ec:03829d,os:7b88e1,cmsis:4aa3ff 2025-08-26 08:08:58 marigold1@ip-172-26-3-226
Tool version: 0.0.1-isolate Jan 1 1980 none
[john@fwnix:~]$ sudo ectool console
ed: ctrl=0x0, reg=0x00]
[64.796100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.802700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.808000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.813300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.818700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.825200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.830700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.836000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.841400 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.848000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.853300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.858700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.864100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.870900 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.876200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.881600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.886900 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.893600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.898800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.904200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.909700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.916200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.921500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.926800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.932100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.938600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.937200 Sustainer disabled]
[64.944000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.953600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.958900 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.964300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.970900 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.976300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.981600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.986900 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.993600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[64.999000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.004300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.009800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.016300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.021700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.027100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.032500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.039000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.044400 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.049800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.055200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.061900 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.067300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.072600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.078000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.084600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.090000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.095300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.100500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.107200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.112600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.118000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.123200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.129900 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.135300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.140600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.146000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.152500 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.158100 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.163300 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.168600 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.175200 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.180400 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.185700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.190900 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.197700 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.203000 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.208400 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.209500 HC 0x0002]
[65.213800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00]
[65.220500 HC 0x000b]

Attached later is a screenshot comparing the ectool console and system uptime timestamps, I think that indicates the EC reset right before the boot.

If the EC is not supposed to reboot with the system (only on power loss?), then I see how that may be the issue.

“The cypd_read_reg8 failed messages mean the EC cannot reach the USB controllers,”
This is very interesting, I should have mentioned earlier that the USB controllers act up intermittently (only on the right side).
I have been avoiding them long enough that I forgot how strange that is. If the USB issue is clogging up the EC/Kernel communication, that may be my issue.

I also went ahead and downgraded + redo the upgraded from 3.7 to 3.17 without progress on the issue or any update-related error messages.
john@fwnix ~/nixcfg (master)> sudo fwupdmgr get-updates
Devices with no available firmware updates:
• KEK CA
• Option ROM UEFI CA
• SHPP41-2000GM
• Windows Production PCA
• frame.work-LaptopAMDDB
• frame.work-LaptopAMDKEK
Devices with the latest available firmware version:
• UEFI dbx
• Fingerprint Sensor
• System Firmware
• UEFI CA
────────────────────────────────────────────────
Devices that have been updated successfully:
• System Firmware (0.0.3.7 → 0.0.3.17)

pkunk,
I followed your good suggestion on the resetting to the default BIOS settings, I definitely should have tried that earlier.
Sadly it did not work.

And yes, the same results happen on Ubuntu Live, but I think finding a live image with kernel 6.18.x might give valuable results.

I thank both of you again for your hard work and skills, I would never have imagined how helpful this community can be.

Ok. From your tests so far:

  1. The EC has the correct firmware on it.
  2. The EC is rebooting itself, probably due to the watchdog being triggered by too many console messages. cypd_read_reg8 failed. The EC is not supposed to reboot, even if the CPU is rebooted.

Try the following:

  1. Power off the laptop
  2. Remove all the usb slot cards.
  3. Leave it unplugged for 120 seconds.
  4. Plug one usb slot card it, the one needed for the PSU.
  5. Power on.
  6. See if the cypd_read_reg8 failed have stopped or not.

There is another thing to try, but you need a EC CCD to do it.
If you had one, there is a command that can switch off the logging on the EC. Thus none of those EC console messages would be written, and therefore, less likely to trigger the EC watchdog, and thus your laptop would stay on longer without resets.

I guess the next steps would be modifying the EC firmware, so that after too many failed messages, it simply gives up on the USB device, until restarted again. That would at least keep your system running.

Summary:
If none of the above helps, I think we can conclude that you have a hardware fault.

Thanks for the final test.

Sadly, I’m still getting these [63.699800 cypd_read_reg8 failed: ctrl=0x0, reg=0x00] at a rate of 175.52 errors/sec.

I agree with your conclusion that the hardware is faulty. If you have a guide somewhere for the EC Firmware I would like to read it. I don’t have an EC CCD but a lab with decent SMD equipment and probably a programmer for the flash. Since I’ll need to buy a new motherboard or laptop, I’m fine with some risk in attempting to repair it (once I get a loaner laptop of course).

Thanks!

The details about the EC CCD is here:

Contact him and he might have one he can send you.
There is a git with all the design files, so you might be able to build one yourself.
All it really is, is a USB-C port with some resistors, and then you get a serial port access to the EC.
Once you have that, you will have access to the “chan” command. The chan command is used to switch on/off various console messages.

Another approach it to use my EC firmware.
Note: its a pretty complex process to do it.
Available here:

Where it talks about “lotus”, you need to replace that with “azalea”.
lotus == FW16.
azalea == FW13.

There is some precompiled azalea EC firmware here:

ec-azalea.bin
If you follow the wiki instructions on how to install that EC firmware, follow the commands to activate it (reboot RW)
It will have the “chan” command implemented so that the “ectool chan” command can then be used to switch off the console messages.

This is a bit of work around for a faulty hardware, but it might be a good stepping stone.

Summary:
I think the simplest work around will be getting the EC CCD and using the “chan” command to switch off the logging.