# OnLogic Karbon K800 R1: Linux suspend causes unexpected reboot with Intel `igc` Ethernet driver loaded; S3 resume also fails - Reported: 15 October 2026 - Reproducible suspend/resume failure causing loss of the running desktop session - Affected areas: Linux power management, Intel `igc` Ethernet driver, PCIe/PTM, ACPI/firmware ## 1. Summary I am experiencing reproducible suspend/resume failures on an **OnLogic Karbon K800 R1 industrial computer** running **Debian 13**. The most significant finding is a controlled comparison involving the Intel `igc` Ethernet driver: - **With `igc` loaded:** Real suspend-to-idle (`s2idle`) repeatedly causes an unexpected system reset/reboot. The previous boot's journal generally ends at suspend entry, with no successful resume messages. - **With `igc` unloaded:** The same machine successfully enters and exits real `s2idle`, returning to the existing GNOME lock screen with the running session and applications preserved. Reloading `igc` restores Ethernet. This strongly implicates the six onboard Intel I225 Ethernet con#trollers, the `igc` driver, or their interaction with PCIe/platform power management. It does **not** yet establish the precise root cause. A second symptom exists with ACPI S3 (`deep`): the computer appears to enter real hardware sleep (fans off); on keyboard/mouse wake the fans restart but the display remains black. The available logs suggest this test also occurred with `igc` loaded. Real S3 with `igc` demonstrably absent **has not yet been tested**. The desired solution is **fully functional automatic suspend/resume while retaining Ethernet functionality**, not disabling sleep as a workaround. ## 2. Hardware | Component | Details | |---|---| | Computer | OnLogic Karbon K800 R1 industrial PC | | BIOS vendor | INSYDE Corp. | | BIOS version | `Z01-0005B017` | | BIOS release date | 2025-05-29 | | Firmware status | B017, the latest BIOS revision identified in the manufacturer's available documentation during troubleshooting | | Platform | Intel Alder Lake-S/Raptor Lake-S-generation desktop platform | | CPU | Intel desktop CPU; 32 logical CPUs observed in the kernel resume logs (exact SKU not captured) | | Integrated GPU | Intel `8086:a780`, Linux `i915` driver | | Ethernet | Six onboard Intel I225-family PCIe controllers using Linux `igc` | | Storage | Transcend NVMe SSD | | Network actually in use | `enp4s0`, connected at 1000 Mbps full duplex during testing | Ethernet PCI IDs and locations: ```text 0000:01:00.0 Intel [8086:0d9f] 0000:02:00.0 Intel [8086:0d9f] 0000:03:00.0 Intel [8086:0d9f] 0000:04:00.0 Intel [8086:0d9f], rev 03, I225-IT 0000:05:00.0 Intel [8086:15f2] 0000:06:00.0 Intel [8086:0d9f] ``` The six adapters sit behind Intel PCIe root ports `00:1a.0`–`00:1a.3`, `00:1c.0`, and `00:1c.3`. An independent Transcend NVMe endpoint is present at `07:00.0`. ### CPU | CPU | | | ------------------ | --------------------------------------- | | Architecture: | x86_64 | | CPU(s): | 32 | | Vendor ID: | GenuineIntel | | Model name: | 13th Gen Intel(R) Core(TM) i9-13900TE | | NUMA node0 CPU(s): | 0-31 | ### Motherboard and BIOS - Version: Z01-0005B017 - Release Date: 2025-05-29 - BIOS Revision: 2.17 - Manufacturer: OnLogic - Product Name: K800 - Version: R1 - Serial Number: E342202 - Manufacturer: OnLogic - Product Name: Karbon80X - Version: R1 - Serial Number: L259000899 ### Chipset and PCIe - 00:00.0 Host bridge [0600]: Intel Corporation Raptor Lake-S Host Bridge/DRAM Controller [8086:a700] (rev 01) - 00:1f.0 ISA bridge [0601]: Intel Corporation W680 Chipset LPC/eSPI Controller [8086:7a88] (rev 11) - 00:1f.4 SMBus [0c05]: Intel Corporation Alder Lake-S PCH SMBus Controller [8086:7aa3] (rev 11) - 01:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-IT [8086:0d9f] (rev 03) - 02:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-IT [8086:0d9f] (rev 03) - 03:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-IT [8086:0d9f] (rev 03) - 04:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-IT [8086:0d9f] (rev 03) - 05:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-LM [8086:15f2] (rev 03) - 06:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I225-IT [8086:0d9f] (rev 03) ### Ethernet Driver and Firmware - driver: igc - firmware-version: 1082:8770 - supports-statistics: yes - supports-test: yes - supports-eeprom-access: yes - supports-register-dump: yes - supports-priv-flags: yes - enp1s0 - bus-info: 0000:01:00.0 - enp2s0 - bus-info: 0000:02:00.0 - enp3s0 - bus-info: 0000:03:00.0 - enp4s0 - bus-info: 0000:04:00.0 - enp5s0 - bus-info: 0000:05:00.0 - enp6s0 - bus-info: 0000:06:00.0 ## 3. Operating system and software - Debian GNU/Linux 13 (Trixie) - GNOME 48, Wayland session, GDM - Original tested kernel: `6.12.111+deb13-amd64` - Additional tested kernel from Debian Trixie backports: `7.2.6+deb13-amd64` - Backports package version: `7.2.6-1~bpo13+1` - Ethernet driver: in-tree Linux `igc` - Kernel configuration on 7.2.6: ```text CONFIG_PCIE_PTM=y CONFIG_IGC=m CONFIG_IGC_LEDS=y ``` Both standard Debian kernels reproduce the `s2idle` problem with `igc` loaded. The machine originally reported: ```text s2idle [deep] ``` Thus `deep` was originally selected by the kernel. A systemd configuration was later installed to force `s2idle` while diagnosing the S3 black-screen problem: ```text /etc/systemd/sleep.conf.d/90-onlogic-s2idle.conf [Sleep] MemorySleepMode=s2idle ``` Its effective application was verified with `systemd-analyze cat-config systemd/sleep.conf`. The `s2idle` failure is also reproducible with a direct/manual suspend, so this is not solely an idle-policy, GNOME or lock-screen issue. ## 4. BIOS configuration verified on the actual machine The following settings were inspected in the InsydeH2O firmware setup. **ACPI:** ```text ACPI S3 Support Enabled Low Power S0 Idle Capability Disabled Native PCIe Enable Enabled Native ASPM Disabled ACPI Debug Disabled PCI Delay Optimization Disabled RTC S4 Wakeup Enabled IO APIC Mode Enabled ``` **PCH-IO:** ```text Foxville I225 LAN Controller Enabled Foxville I225 Wake on LAN Support Enabled DeepSx Power Policies Disabled State After G3 S0 State Enable TCO Timer Disabled ``` The kernel confirms that ACPI advertises: ```text ACPI: PM: (supports S0 S3 S4 S5) ``` Firmware settings were inspected but not modified as part of the later experiments. A K800-specific power-sequencing MCU exists according to OnLogic documentation. Its role in this failure has **not** been established. ## 5. Observed symptoms ### A. Real `s2idle` with `igc` loaded: spontaneous reboot Steps: 1. Boot normally with the standard `igc` module. 2. Select `s2idle`, either through the systemd sleep configuration or `/sys/power/mem_sleep`. 3. Initiate real system suspend using `systemctl suspend` or the kernel power interface. 4. The desktop disappears and the system begins suspending. 5. Instead of returning to the current session, the machine resets and boots Debian from scratch. This has also happened without a user-requested wakeup and without relying on an RTC alarm. It is not just a reset caused by pressing a wake key. An illustrative previous-boot journal ends with: ```text systemd-logind: The system will suspend now! systemd-sleep: Performing sleep operation 'suspend'... ``` In other runs the kernel reaches: ```text PM: suspend entry (s2idle) ``` There is no corresponding `PM: suspend exit` or successful resume trace from the failed attempts. A confirmed occurrence on 15 October 2026: ```text 10:43:57 systemd-logind: The system will suspend now! 10:43:58 systemd-sleep: Performing sleep operation 'suspend'... 10:44:58 Beginning of the next boot ``` The kernel command line on that failed boot was a normal boot command line, without an `igc` blacklist. **Impact:** The machine loses all unsaved desktop/application state. ### B. Real `s2idle` with `igc` unloaded: successful suspend/resume A key isolation test was conducted on kernel `6.12.111+deb13-amd64`: ```bash sudo modprobe -r igc sudo systemctl suspend ``` Result: - Display went black during suspend. - Fans continued spinning, consistent with `s2idle` behavior on this platform. - The machine did not reboot. - After a keyboard wake event, the existing GNOME lock screen returned. - The original desktop session and applications were preserved. - The journal recorded: ```text PM: suspend entry (s2idle) PM: suspend exit ``` - `/sys/power/suspend_stats` reported one success and zero failures for this test. - Reloading `igc` afterward restored Ethernet: ```bash sudo modprobe igc ``` This is the strongest evidence for involvement of the Intel Ethernet/PCIe subsystem. **Caveat:** This specific successful real suspend was demonstrated once. It was not yet repeated with `igc` absent on kernel 7.2.6. ### C. Real S3 (`deep`): screen remains black after apparent wake The firmware supports S3 and the original Linux default was `deep`. During a real S3 experiment on 14 October, apparently around **18:12:44**: - Fans turned completely off. - The machine remained asleep rather than automatically rebooting. - After keyboard/mouse activity, the fans restarted and the power LED reacted. - The monitor produced no usable display output. - The GNOME session was not recovered by the user. The historical journal for that boot ends after a manual write to `/sys/power/state`: ```text 18:12:40 Commands issued to set pm_test and mem_sleep 18:12:44 sudo ... /usr/bin/tee /sys/power/state ``` No successful real-S3 resume is recorded. **Important limitation:** That boot's `/proc/cmdline` did not contain the intended `igc` blacklist parameters, and `igc` had been confirmed active shortly beforehand. There is no evidence it was unloaded before the attempt. Therefore **real S3 without `igc` is still untested**. Attempts to arrange a one-time GRUB blacklist have not yet succeeded; the observed boot command line remained `ro quiet`, `lsmod` still listed `igc`, and `lspci` reported `Kernel driver in use: igc`. ## 6. Experiment and result matrix | Experiment | Result | |---|---| | Real `s2idle`, kernel 6.12, `igc` loaded | Unexpected reboot | | Real `s2idle`, kernel 7.2.6, `igc` loaded | Unexpected reboot | | Real `s2idle`, kernel 6.12, `igc` unloaded | Successful suspend/resume, same desktop session | | Disable PCIe wakeup on all six Ethernet controllers | No improvement; original wake settings restored | | Suspend with RTC wake alarm | Failure reproduced | | Suspend without RTC alarm or keyboard wake request | Spontaneous reset also observed | | `s2idle`, `pm_test=devices` | Passed | | `s2idle`, `pm_test=platform` | Passed | | `s2idle`, `pm_test=processors/core` | Unsupported for `s2idle`; these were not valid tests | | `deep`, `pm_test=platform` | Passed | | `deep`, `pm_test=processors` | Passed | | `deep`, `pm_test=core` | Passed, though Ethernet recovery occurred afterward | | Real `deep`, apparently `igc` loaded | Fans off during sleep; fans restart on wake; black monitor | | Real `deep`, definitely without `igc` | Not tested | | Custom `igc` driver with suspend-reset patch | Reboot still reproduced | | Complete PTM-disabled driver test | Not tested | | PCIe ASPM disable boot option | Not needed/tested; ASPM is already disabled | | Serial-console capture of real suspend failure | Not performed | ## 7. PCIe PTM findings Both an Intel I225 endpoint and its parent PCIe root port have **PCIe Precision Time Measurement (PTM) enabled**. Endpoint `01:00.0`: ```text Capabilities: Precision Time Measurement PTMCap: Requester+ Responder- Root- PTMClockGranularity: 4ns PTMControl: Enabled+ RootSelected- PTMEffectiveGranularity: 4ns ``` Parent root port `00:1a.0`: ```text Capabilities: Precision Time Measurement PTMCap: Requester- Responder+ Root+ PTMClockGranularity: 4ns PTMControl: Enabled+ RootSelected+ PTMEffectiveGranularity: Unknown ``` At boot the kernel logs: ```text pcieport 0000:00:1a.0: PTM enabled (root), 4ns granularity igc 0000:01:00.0: PTM enabled, 4ns granularity ``` Equivalent PTM initialization is reported for the other Ethernet controllers/root ports. During simulated suspend and resume, all six adapters repeatedly log: ```text igc 0000:01:00.0 enp1s0: Timeout reading IGC_PTM_STAT register igc 0000:02:00.0 enp2s0: Timeout reading IGC_PTM_STAT register igc 0000:03:00.0 enp3s0: Timeout reading IGC_PTM_STAT register igc 0000:04:00.0 enp4s0: Timeout reading IGC_PTM_STAT register igc 0000:05:00.0 enp5s0: Timeout reading IGC_PTM_STAT register igc 0000:06:00.0 enp6s0: Timeout reading IGC_PTM_STAT register ``` These warnings occur both while suspending and while restoring devices. **Important:** These timeouts also appear during simulated suspends that complete successfully. Therefore the warnings alone do not prove the cause of the full-system reset. ## 8. PCIe ASPM findings The ACPI FADT disables ASPM support: ```text ACPI FADT declares the system doesn't support PCIe ASPM, so disable it FADT indicates ASPM is unsupported, using BIOS configuration ``` Representative root ports: ```text 00:1a.0: LnkCap: ASPM not supported 00:1a.0: LnkCtl: ASPM Disabled 00:1c.0: LnkCap: ASPM not supported 00:1c.0: LnkCtl: ASPM Disabled ``` Representative Ethernet endpoint: ```text 01:00.0: LnkCap: ASPM L1 01:00.0: LnkCtl: ASPM Disabled 01:00.0: L1SubCtl1: PCI-PM_L1.1- ASPM_L1.1- ``` Conclusion: An experiment using `pcie_aspm=off` is unlikely to add useful information because ASPM is already disabled. **ASPM and PTM are separate PCIe features.** ## 9. PCIe runtime power-management findings All six Ethernet devices were checked: ```text /sys/bus/pci/devices/0000:01:00.0/power/ ... /sys/bus/pci/devices/0000:06:00.0/power/ ``` Every device reported: ```text control: on runtime_status: active runtime_suspended_time: 0 ``` Runtime autosuspend was not active. This does not prevent the system-suspend callbacks from being invoked. ## 10. PCIe AER errors on unloading `igc` A separate observation occurred during an `igc` module-removal operation. Several/all of the six associated Intel PCIe root ports reported **Advanced Error Reporting (AER)** messages, including: ```text AER: Uncorrectable (Non-Fatal) error message received PCIe Bus Error: severity=Uncorrectable (Non-Fatal) type=Transaction Layer error status/mask=00100000/00000000 pci 0000:06:00.0: AER: can't recover (no error_detected callback) pcieport ... AER: device recovery failed ``` The uncorrectable error-status value `0x00100000` corresponds to an **Unsupported Request** indication. These errors were observed **during driver unloading**, not proven to occur at the exact instant of a failed real suspend. They might be a consequence of device shutdown/removal rather than the underlying cause of the reset. They nevertheless indicate an additional area requiring review: PCIe transactions, endpoint power-state changes and `igc` teardown across the six controllers. ## 11. Simulated S3 tests: all passed With: ```bash echo deep | sudo tee /sys/power/mem_sleep echo platform | sudo tee /sys/power/pm_test echo mem | sudo tee /sys/power/state ``` The system completed the S3 platform preparation and returned, logging: ```text PM: suspend entry (deep) ACPI: PM: Preparing to enter system sleep state S3 ACPI: PM: Saving platform NVS memory PM: suspend debug: Waiting for 5 second(s). ACPI: PM: Waking up from system sleep state S3 PM: suspend exit ``` The `processors` and `core` tests also passed under `deep`. The `core` simulation successfully took the non-boot CPUs offline and restored all 32 logical CPUs before returning from the simulated suspend. No simulated test entered the final physical S3 sleep state. ### Additional network recovery after the `core` test Following the S3 `core` simulation on 14 October: ```text 18:06:21 PM: suspend entry (deep) 18:06:27 PM: suspend exit 18:06:29 igc 0000:04:00.0 enp4s0: Register Dump 18:06:29 igc 0000:04:00.0 enp4s0: Reset adapter 18:06:29 igc 0000:04:00.0 enp4s0: Timeout reading IGC_PTM_STAT register 18:06:32 igc 0000:04:00.0 enp4s0: NIC Link is Up 1000 Mbps Full Duplex ``` No explicit PCIe AER or transmit-timeout message explaining the reset was present in that 15-second excerpt. Later interface statistics showed: ```text RX errors: 0 TX errors: 0 RX dropped: 92 TX dropped: 7 ``` This indicates the driver performed an adapter recovery shortly after simulated suspend. It does not prove why the recovery was scheduled or whether it is causally connected to the system-wide reboot. ## 12. Existing upstream fixes reviewed and custom driver patch tested ### Historical fix: `igc: Fix suspending when PTM is active` (April 2022) Upstream commit: `822f52e7efdc88fccffb9fbf6250a4b7666a0b0f` Reference: https://lkml.iu.edu/2204.3/02747.html This existing Linux fix describes Alder Lake-S systems having suspend/resume hangs with PCIe PTM active, sometimes also during `igc` module removal. The patch was included in stable kernels years before either tested Debian kernel. Its symptoms are strikingly similar, but it is **not established that our case is a regression of the same bug**. ### Later patch: `igc: Don't reset the hardware on suspend path` (March 2026) Reference: https://www.spinics.net/lists/netdev/msg1172413.html This proposed patch explains how a PCIe core change can disable PTM before `igc` runs its suspend callback. The driver subsequently resets the device and polls `IGC_PTM_STAT`, leading to the observed timeout warnings. The exact kernel 7.2.6 source was inspected, and its `igc` implementation still had the earlier structure: ```c void igc_down(struct igc_adapter *adapter) ``` The suspend path still called `igc_down(adapter)`. ### Custom test on Debian kernel 7.2.6 A local module was built from the matching Debian 7.2 kernel source and compiled against the running 7.2.6 kernel headers. The changes followed the proposed patch's approach: - Modify `igc_down()` to take a `bool reset` argument. - Skip the hardware reset in the suspend path. - Preserve resets for ordinary shutdown/reinitialization paths. - Update the affected call sites in `igc_main.c`, `igc.h`, and `igc_ethtool.c`. Build/install details: ```text Source archive: /usr/src/linux-source-7.2.tar.xz Working directory: ~/igc-fix-7.2.6 Build: make -C /lib/modules/$(uname -r)/build M="$HOME/igc-fix-7.2.6" modules Result: igc.ko Vermagic: 7.2.6+deb13-amd64 SMP preempt mod_unload Temporary installation: /lib/modules/7.2.6+deb13-amd64/updates/igc.ko ``` Secure Boot was disabled. The patched module compiled successfully, loaded successfully, and Ethernet connectivity was restored. **Result: Actual `s2idle` still caused an unexpected reboot.** One failed patched-driver suspend occurred on 14 October at approximately 16:49:34, with the preceding boot ending at: ```text PM: suspend entry (s2idle) ``` The custom driver was later removed: ```bash sudo rm -f "/lib/modules/$(uname -r)/updates/igc.ko" sudo depmod -a sudo update-initramfs -u -k "$(uname -r)" ``` `modinfo -n igc` subsequently resolved to the original Debian module: ```text /lib/modules/7.2.6+deb13-amd64/kernel/drivers/net/ethernet/intel/igc/igc.ko.xz ``` **Qualification:** The module-path check establishes which module is selected from disk. For any experiment immediately after a driver replacement, the actual loaded module must also be verified after a reload or reboot. This patch did not resolve the observed reboot, so simply applying it again is unlikely to be a useful next step. ## 13. Watchdog and logging checks The following were investigated: - Intel `iTCO_wdt` hardware watchdog: not active during the checks. - systemd runtime watchdog: disabled / zero timeout. - No user process holding `/dev/watchdog*`. - BIOS `Enable TCO Timer`: disabled. - `/sys/power/pm_debug_messages`: available and enabled for diagnostics. - `/sys/power/pm_print_times`: available and enabled. - `/sys/power/pm_trace`: absent. - EFI pstore: no useful preserved failure record found. - Kernel `/sys/power/suspend_stats`: simulated tests and the successful real `s2idle` test reported success; the hard-reboot failures did not supply a useful suspend failure trace. The K800 has additional firmware/platform power-control facilities, including an independent power-sequencing MCU. Their firmware versions, reset reasons and watchdog configuration have not been fully examined. A serial console or another external tracing mechanism has **not yet** captured the final stages of a real failed suspend/resume. ## 14. Current conclusions, with confidence levels **High confidence** 1. The real `s2idle` failure is not exclusive to GNOME, the lock screen, or automatic idle triggering. 2. It reproduces on both tested Debian kernel versions. 3. Unloading the Intel `igc` driver changed the outcome from reboot to successful suspend/resume in a direct comparison. 4. PCIe ASPM is already disabled by the platform. 5. PCIe PTM is active on the Intel I225 links. 6. All S3 simulated tests up through `core` passed. 7. The attempted `igc` hardware-reset avoidance patch did not solve the reboot. **Plausible but unproven** 1. An interaction between `igc`, PCIe PTM, PCIe power transitions, and motherboard/firmware behavior causes the `s2idle` reset. 2. The all-port PCIe AER errors during module removal are related to the suspend failure. 3. S3's black-screen behavior is an additional failure during CPU/firmware resume or graphics initialization. 4. The K800's independent power controller participates in the reset behavior. **Not established** 1. Whether disabling PCIe PTM itself resolves the reboot while keeping Ethernet operational. 2. Whether real S3 works with all six `igc` controllers unbound/not loaded. 3. Whether the S3 black screen is only a display initialization failure or a broader kernel/firmware resume stall. 4. Whether an external reset controller, power-supply condition or firmware watchdog is resetting the machine. 5. Whether the issue reproduces on an unmodified upstream mainline kernel (tested kernels are Debian builds). ## 15. Questions and requested help I would appreciate engineering guidance on the following: 1. **Is this a known suspend/resume issue on the OnLogic K800 R1, particularly with six Intel I225 controllers and PCIe PTM enabled?** 2. Are there known firmware/BIOS/NIC NVM/MCU updates, PCIe quirks or power- sequencing settings relevant to this failure? 3. Is there a supported, reversible way to disable or bypass PCIe PTM for `igc` without disabling the Ethernet interfaces or preventing system suspend? 4. Does the 2022 upstream PTM suspend fix have known remaining edge cases on Alder Lake-S/W680 or similar platforms? 5. Could the PCIe Unsupported Request/AER events during `igc` removal be associated with the reset during real suspend? 6. What is the recommended way to capture the final failing suspend/resume stage on this particular hardware (serial console, firmware debug, external trace, reset-reason registers, etc.)? 7. Can S3 be made reliable on this BIOS, or is there a documented limitation requiring a different Linux sleep configuration? I am happy to provide additional logs, kernel configuration and PCIe register dumps and to perform specific, controlled experiments suggested by maintainers. **The primary requirement is reliable suspend/resume with normal Ethernet operation, preserving the existing Linux desktop session. Disabling automatic sleep is not an acceptable permanent fix.** ## 16. Logs and artifacts available The following can be provided as attachments: - Complete kernel/system journals around failed `s2idle` suspend attempts. - Complete kernel journal of the successful `s2idle` test with `igc` unloaded. - Journal from real S3 black-screen attempt on 14 October at approximately 18:12. - Logs of successful S3 `platform`, `processors`, and `core` simulated tests. - Detailed PCIe AER errors recorded during `igc` removal. - PCIe configuration (`lspci -vv`) for the I225 endpoints and root ports. - Kernel configuration, version information and module details. - Kernel-source patch/diff used for the unsuccessful custom-driver experiment. - Photographs of the BIOS power-management settings. Please indicate which additional evidence would be most useful before requesting more uncontrolled suspend attempts.