intel / intel/ethernet-linux-ice

ice: GNSS kthread worker causes hung task warnings when no GPS signal available

Open
#56 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
60
Forks
21
PR merge metrics
No merged PRs in 30d

Description

## Description

When using Intel E810 NICs with GNSS capability, the `ice-gnss-*` kthread workers cause hung task warnings when the GNSS receiver has no signal (e.g., no antenna connected or weak signal).

## Environment

- Driver version: ice 2.5.4
- Kernel version: 6.18.21 / 6.18.22
- Hardware: Dell PowerEdge XR11
- NICs:
- Intel E810-C for SFP (0000:51:00.x) - with GNSS antenna, working
- Intel E810-C for QSFP (0000:8a:00.x) - no GNSS antenna connected

## Steps to reproduce

1. Install E810 NIC with GNSS capability
2. Do not connect GNSS antenna (or have weak/no GPS signal)
3. Load ice driver
4. Wait ~120 seconds

## Expected behavior

Driver should handle missing GNSS signal gracefully without blocking.

## Actual behavior

Hung task warnings appear in dmesg:

```
[ 248.064851] INFO: task ice-gnss-0000:5:603 blocked for more than 124 seconds.
[ 248.064879] Tainted: G OE 6.18.21-xxx #8
[ 248.064886] task:ice-gnss-0000:5 state:D stack:0 pid:603 tgid:603 ppid:2
[ 248.064898] Call Trace:
[ 248.064902]
[ 248.064908] __schedule+0x474/0x1210
[ 248.064950] schedule+0x27/0xf0
[ 248.064959] schedule_preempt_disabled+0x15/0x30
[ 248.064968] kthread+0xa4/0x220
[ 248.064985] ret_from_fork+0x273/0x2a0
[ 248.065003] ret_from_fork_asm+0x1a/0x30
[ 248.065018]
```

## GNSS status

```bash
# Working NIC (with antenna):
$ cat /dev/gnss0

# NIC without antenna (causes hung task):
$ cat /dev/gnss1
$GNRMC,,V,,,,,,,,,,N,V*37
$GNGGA,,,,,,0,00,99.99,,,,,,*56
```

## Root cause analysis

In `ice_gnss_read()` (src/ice_gnss.c), the polling loop iterates up to `ICE_MAX_UBX_READ_TRIES` (255) times with `msleep(20)` between attempts. When GNSS has no signal, this can block for ~5 seconds per cycle.

Additionally, during module unload, `kthread_cancel_delayed_work_sync()` waits for the work to complete, which can take a long time if stuck in the polling loop.

## Suggested fix

Add a `stopping` flag to allow graceful termination of the read loop during shutdown:

1. Add `bool stopping` field to `struct gnss_serial`
2. Check `stopping` flag at the beginning of `ice_gnss_read()` and exit early
3. Check `stopping` flag inside the polling loop
4. Don't requeue the delayed work if `stopping` is true
5. Set `stopping = true` in `ice_gnss_exit()` before calling `kthread_cancel_delayed_work_sync()`

See attached patch for implementation.

## Workaround

Connect GNSS antenna to all E810 NICs with GNSS capability, or disable hung task warnings:

```bash
sysctl -w kernel.hung_task_timeout_secs=0
```

[0001-ice-gnss-fix-hung-task-when-GNSS-has-no-signal.patch](https://github.com/user-attachments/files/26799805/0001-ice-gnss-fix-hung-task-when-GNSS-has-no-signal.patch)

[0001-ice-gnss-fix-hung-task-when-kthread-misses-initial-w.patch](https://github.com/user-attachments/files/26813729/0001-ice-gnss-fix-hung-task-when-kthread-misses-initial-w.patch)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.