[Intel Ice Lake] Hard lockups avoided by intel_idle.max_cstate=1

Dear Linux Kernel Maintainers,

## Summary

I am experiencing intermittent complete system freezes on a BMAX B6
Plus Mini PC with an Intel Ice Lake CPU and integrated Intel graphics.

The lockup is not deterministic. I have not found a specific
application or user action that triggers it. It occurs during ordinary
desktop use, apparently after several hours.

The keyboard becomes completely unresponsive and the machine appears
to be hard-locked. I have not been able to recover it through the
usual userspace mechanisms.

## Hardware

* BMAX B6 Plus Mini PC
* Intel Core i3-1000NG4 (Ice Lake)
* Intel Iris Plus Graphics G4
* 32 GB RAM
* Integrated Intel GPU
* X11 desktop environment (MATE)

## Software

* Manjaro Linux
* Linux 6.18-x86_64
* i915 DRM driver

The GPU is using the i915 driver and DRI acceleration works normally.
MATE, Firefox and Zed work normally, including hardware-accelerated
graphics.

## Kernel command line

The configuration with which I experienced the lockups was:

```
i915.enable_psr=0
i915.enable_fbc=0
i915.enable_dc=0
video=HDMI-A-1:1920x1080@60e
```

I also tested the system with:

```
intel_idle.max_cstate=1
```

## Important finding

Adding:

```
intel_idle.max_cstate=1
```

appears to prevent the lockups.

With this parameter enabled, the system has remained stable during
normal desktop use. Without it, the system eventually hard-locks
again.

With the workaround enabled, the available CPU idle states are:

```
POLL
C1_ACPI
```

The active cpuidle driver is `intel_idle`.

This makes me suspect an interaction involving CPU
idle/power-management states, ACPI/firmware, and possibly the graphics
stack. I cannot determine whether the underlying problem is in i915,
CPU idle, ACPI, or an interaction between these components.

## Reproducer

Unfortunately, I do not currently have a deterministic reproducer.

The lockup happens intermittently during normal desktop use,
apparently after several hours. I have not found a particular
application, operation, or sequence of actions that reliably triggers
it.

The most useful observation I can provide is that the lockup can be
avoided by limiting the CPU to C1 with:

```
intel_idle.max_cstate=1
```

## Expected behavior

The system should remain responsive indefinitely during normal desktop
use with the default CPU idle states and the i915 driver enabled.

## Additional observations

I initially suspected i915 because the system only exhibited the
problem when using the Intel graphics driver. However, disabling
`i915` avoids the graphics path entirely, while limiting CPU C-states
also appears to eliminate the problem while leaving i915 and DRI fully
functional.

I have therefore not concluded that i915 itself is responsible. The
`intel_idle.max_cstate=1` result makes a power-management/idle-state
interaction seem worth investigating.

I am reporting this because the workaround has a significant
functional impact: it requires disabling deeper CPU idle states,
presumably increasing idle power consumption, in order to obtain a
stable system.

I would be happy to provide additional logs or hardware information if
there are specific diagnostics that would help identify the cause.

best regards
Pablo De Nápoli