创建仓库
This commit is contained in:
120
系统基座文件/1/1.1/1.1.1 发行版与内核版本指纹.md
Normal file
120
系统基座文件/1/1.1/1.1.1 发行版与内核版本指纹.md
Normal file
@@ -0,0 +1,120 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 3:10:38 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 5:42:25 下午
|
||||
---
|
||||
|
||||
# 1.1.1 发行版与内核版本指纹
|
||||
|
||||
**1. OS 发行版完整标识 (Distro Full ID)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：确认具体的 SP 版本（如 V10 SP1/SP2/SP3），不同版本的 Glibc 和内核基线差异极大。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /etc/kylin-release /etc/os-release 2>/dev/null | grep -E "PRETTY_NAME|VERSION_ID|Kylin Linux Advanced Server"
|
||||
Kylin Linux Advanced Server release V10 (GFB)
|
||||
NAME="Kylin Linux Advanced Server"
|
||||
VERSION_ID="V10"
|
||||
PRETTY_NAME="Kylin Linux Advanced Server V10 (GFB)"
|
||||
```
|
||||
|
||||
**2. CPU 架构与字节序 (Arch & Endianness)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：必须确认为 aarch64 且为 Little Endian（小端序），这是 Feiteng S5000C 的基础特征。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
lscpu | grep -E "Architecture|Byte Order"
|
||||
空
|
||||
```
|
||||
|
||||
**3. 内核发布版本号 (Kernel Release)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：精确的内核版本字符串。驱动源码的 Header Path 必须与此完全一致。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
uname -r
|
||||
4.19.90-52.23.v2207.gfb08.ky10.aarch64
|
||||
```
|
||||
|
||||
**4. 内核构建编译器版本 (Kernel GCC Version)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：提取圆括号内的 gcc version。如果此版本与当前环境中 gcc 版本差异过大，编译内核模块时极易报错。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /proc/version
|
||||
Linux version 4.19.90-52.23.v2207.gfb08.ky10.aarch64 (KYLINSOFT@localhost.localdomain) (gcc version 7.3.0 (GCC)) #1 SMP Tue Apr 23 18:20:01 CST 2024
|
||||
```
|
||||
|
||||
**5. 内核启动参数全集 (Kernel Boot Cmdline)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：检查是否已有预设的 isolcpus、hugepages 或 iommu 参数，判断基线是否纯净。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /proc/cmdline
|
||||
BOOT_IMAGE=/vmlinuz-4.19.90-52.23.v2207.gfb08.ky10.aarch64 root=/dev/mapper/klas-root ro rd.lvm.lv=klas/root rd.lvm.lv=klas/swap acpi=on rhgb quiet console=tty0 crashkernel=1024M,high smmu.bypassdev=0x1000:0x17 smmu.bypassdev=0x1000:0x15 video=efifb:off module_blacklist=phytium_mci_pci module_blacklist=phytium_mci audit=0
|
||||
```
|
||||
|
||||
**6. 内核构建时间戳 (Kernel Build Timestamp)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **预期信息**：确认内核是原厂构建还是用户自行重新编译过的版本。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
uname -v
|
||||
#1 SMP Tue Apr 23 18:20:01 CST 2024
|
||||
```
|
||||
|
||||
**7. 内核模块签名强制性 (Module Signing Policy)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：检查 CONFIG_MODULE_SIG_FORCE。如果是 y，则加载未签名的自研驱动会被拒绝。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
grep "CONFIG_MODULE_SIG" /boot/config-$(uname -r) 2>/dev/null || echo "Config check failed"
|
||||
CONFIG_MODULE_SIG=y
|
||||
# CONFIG_MODULE_SIG_FORCE Is not Set
|
||||
CONFIG_MODULE_SIG_ALL=y
|
||||
# CONFIG_MODULE_SIG_SHA1 is not set
|
||||
# CONFIG_MODULE_SIG_SHA224 is not set
|
||||
CONFIG_MODULE_SIG_SHA256=y
|
||||
# CONFIG_MODULE_SIG_SHA384 is not set
|
||||
# CONFIG_MODULE_SIG_SHA512 is not set
|
||||
CONFIG_MODULE_SIG_HASH="sha256"
|
||||
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
|
||||
```
|
||||
|
||||
**8. 安全模块状态 (LSM Status)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：确认 SELinux 或 Kysec（麒麟安全子系统）的状态，这是导致设备节点无权限访问的常见原因。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
sestatus 2>/dev/null; getenforce 2>/dev/null; ls -d /sys/kernel/security/lsm
|
||||
SELinux status: disabled
|
||||
Disabled
|
||||
/sys/kernel/security/lsm
|
||||
```
|
||||
|
||||
**9. 页大小配置 (Page Size Configuration)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：aarch64 架构下可能存在 4KB 或 64KB 页大小的差异。页大小不匹配会导致内存映射（mmap）失败。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
getconf PAGESIZE
|
||||
65536
|
||||
```
|
||||
77
系统基座文件/1/1.1/1.1.2 内存子系统策略 (Memory Subsystem Policy).md
Normal file
77
系统基座文件/1/1.1/1.1.2 内存子系统策略 (Memory Subsystem Policy).md
Normal file
@@ -0,0 +1,77 @@
|
||||
---
|
||||
tags:
|
||||
aliases:
|
||||
- 1.1.2 内存子系统策略 (Memory Subsystem Policy)
|
||||
date created: 星期三, 十一月 19日 2025, 3:48:55 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 3:49:00 下午
|
||||
---
|
||||
|
||||
# 1.1.2 内存子系统策略 (Memory Subsystem Policy)
|
||||
|
||||
**1. 透明大页状态 (Transparent HugePages Status)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：查看当前状态是 `[always]` 还是 `[never]`。在 64KB 基础页宽的系统上，THP 机制更为激进，极易导致内存碎片化和不可预测的内核态 CPU 占用（sys cpu high）。雷达实时处理业务通常强制要求设为 `never` 或 `madvise`。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /sys/kernel/mm/transparent_hugepage/enabled
|
||||
always [madvise] never
|
||||
```
|
||||
|
||||
**2. 标准大页尺寸 (Default Hugepage Size)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：确认系统默认的大页物理尺寸。在 x86 (4KB 页) 上通常是 2MB；但在 64KB 页宽的 aarch64 系统上，一级大页通常是 **512MB**。这直接决定了驱动程序（如 DMA 缓冲）申请连续物理内存时的对齐粒度和最小单元。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
grep "Hugepagesize" /proc/meminfo
|
||||
Hugepagesize: 524288 kB
|
||||
```
|
||||
|
||||
**3. 大页内存预留量 (Total HugePages)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：检查系统是否在启动阶段通过 Boot Args 预留了物理大页。若显示 `0`，说明完全依赖运行时分配。对于从 ADC 采集的高速数据流，运行时动态申请大页极易失败，必须确认是否有静态预留。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
grep "HugePages_Total" /proc/meminfo
|
||||
HugePages_Total: 0
|
||||
```
|
||||
|
||||
**4. 虚拟内存交换倾向 (Swappiness)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：数值范围 0-100。对于实时雷达系统，任何形式的 Swap-out（内存换出）都是致命的，会导致毫秒级的处理中断。该值应被严格限制在 `0` 或 `10` 以内。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/vm/swappiness
|
||||
10
|
||||
```
|
||||
|
||||
**5. 内存过载分配策略 (Overcommit Memory Policy)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **预期信息**：返回值为 `0` (启发式), `1` (总是允许), 或 `2` (严格限制)。GPGPU 驱动初始化时常需预分配巨大的虚拟地址空间，若此值为 `2` (禁止过载) 且无足够 Swap，驱动初始化（`cudaMalloc` 等价调用）可能会直接崩溃。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/vm/overcommit_memory
|
||||
0
|
||||
```
|
||||
|
||||
**6. 物理内存全景 (Physical Memory Overview)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **预期信息**：获取 `Total`（物理总内存）与 `Available`（实际可用）。需特别关注在 64KB 页系统下，内核自身的数据结构（Page Tables）会消耗比 x86 更多的内存，需评估剩余内存是否满足信号处理算法的峰值需求。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
free -h
|
||||
total used free shared buff/cache available
|
||||
Mem: 62Gi 2.8Gi 58Gi 81Mi 1.2Gi 54Gi
|
||||
Swap: 8.0Gi 0B 8.0Gi
|
||||
```
|
||||
115
系统基座文件/1/1.1/1.1.3 CPU 调度与核心隔离 (CPU Scheduling & Isolation).md
Normal file
115
系统基座文件/1/1.1/1.1.3 CPU 调度与核心隔离 (CPU Scheduling & Isolation).md
Normal file
@@ -0,0 +1,115 @@
|
||||
---
|
||||
tags:
|
||||
date created: 星期三, 十一月 19日 2025, 3:56:35 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 3:56:46 下午
|
||||
---
|
||||
|
||||
# 1.1.3 CPU 调度与核心隔离 (CPU Scheduling & Isolation)
|
||||
|
||||
**1. CPU 物理拓扑与 NUMA 布局 (CPU Topology & NUMA Layout)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：确认物理核心数、Socket 数量及 NUMA 节点分布。Feiteng S5000C 通常为多路多核架构，跨 NUMA 节点的内存访问会导致显著的时延抖动，需确认 CPU 核心与 NUMA 节点的亲和性映射。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
lscpu -e=CPU,NODE,SOCKET,CORE,CACHE
|
||||
CPU NODE SOCKET CORE L1d:L1i:L2:L3
|
||||
0 0 0 0 0:0:0:0
|
||||
1 0 0 1 1:1:1:0
|
||||
2 0 0 2 2:2:2:0
|
||||
…
|
||||
15 0 0 15 15:15:15:0
|
||||
16 1 0 16 16:16:16:1
|
||||
17 1 0 17 17:17:17:1
|
||||
…
|
||||
31 1 0 31 31:31:31:1
|
||||
```
|
||||
|
||||
**2. 运行时核心隔离状态 (Runtime CPU Isolation)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：检查内核是否已成功隔离指定核心（返回核心列表）。被隔离的核心将不再接收操作系统的常规任务调度，仅处理绑定到该核心的实时雷达信号处理线程。若为空，说明未配置隔离。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /sys/devices/system/cpu/isolated
|
||||
|
||||
```
|
||||
|
||||
**3. CPU 频率调节模式 (Frequency Scaling Governor)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：确认 CPU 调频策略。应为 `performance`（定频/高性能）。若为 `powersave` 或 `ondemand`，CPU 频率随负载波动会破坏信号处理的时间确定性（Jitter）。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | sort | uniq
|
||||
performance
|
||||
```
|
||||
|
||||
**4. 自动 NUMA 平衡策略 (Automatic NUMA Balancing)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：返回 `0` (禁用) 或 `1` (启用)。在实时系统中应设为 `0`。若启用，内核会自动迁移内存页以试图优化局部性，这会引发不可控的 Page Fault 和延迟，严重干扰 DSP 算法运行。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/kernel/numa_balancing
|
||||
1
|
||||
```
|
||||
|
||||
**5. 实时调度节流阈值 (Real-time Throttling)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：默认通常为 `950000` (μs)，即预留 5% CPU 给非实时任务。若雷达处理线程独占核心且需 100% 占用（死循环轮询），需设为 `-1` 以关闭节流，否则线程会被强制挂起。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/kernel/sched_rt_runtime_us
|
||||
950000
|
||||
```
|
||||
|
||||
**6. 中断负载均衡服务状态 (IRQ Balance Service)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **预期信息**：确认 `irqbalance` 服务状态。对于高性能网卡或 PCIe 采集卡，通常需要关闭自动均衡，手动将硬中断（IRQ）绑定到特定核心，以避免中断处理在不同核心间漂移导致缓存失效。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
systemctl status irqbalance 2>/dev/null | grep -E "Active|Loaded"
|
||||
Loaded: loaded (/usr/lib/systemd/system/irqbalance.service; enabled; vendor preset: enabled)
|
||||
Active: active (running) since Wed 2025-11-19 14:12:35 CST; 1h 41min ago
|
||||
```
|
||||
|
||||
**7. 离线核心状态 (Offline CPUs)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **预期信息**：检查是否有核心被逻辑关闭（Hotplug off）。这有时用于节能或规避硬件故障，需确认所有预期可用的物理核心均处于 Online 状态（此处为空表示全在线）。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /sys/devices/system/cpu/offline
|
||||
|
||||
```
|
||||
|
||||
**8. 现有实时进程分布 (Existing RT Processes)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **预期信息**：扫描当前系统中是否已有运行在 `RR` (Round Robin) 或 `FIFO` 策略下的实时进程，防止它们与未来的雷达业务产生资源争抢。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
ps -eo pid,cls,rtprio,cmd --sort=-rtprio | grep -E "RR|FF" | head -n 10
|
||||
13 FF 99 [migration/0]
|
||||
16 FF 99 [migration/1]
|
||||
21 FF 99 [migration/2]
|
||||
26 FF 99 [migration/3]
|
||||
31 FF 99 [migration/4]
|
||||
36 FF 99 [migration/5]
|
||||
41 FF 99 [migration/6]
|
||||
46 FF 99 [migration/7]
|
||||
51 FF 99 [migration/8]
|
||||
56 FF 99 [migration/9]
|
||||
```
|
||||
|
||||
145
系统基座文件/1/1.1/1.1.4 系统级资源限制 (System Resource Limits).md
Normal file
145
系统基座文件/1/1.1/1.1.4 系统级资源限制 (System Resource Limits).md
Normal file
@@ -0,0 +1,145 @@
|
||||
---
|
||||
tags:
|
||||
date created: 星期三, 十一月 19日 2025, 3:57:04 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 4:02:26 下午
|
||||
---
|
||||
|
||||
# 1.1.4 系统级资源限制 (System Resource Limits)
|
||||
|
||||
**1. 进程级资源配额 (Process Limits / ulimit)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **信息解析**：
|
||||
- **关键风险点**：`max locked memory` (锁定内存) 仅为 **64KB**。这是致命配置。雷达实时程序必须通过 `mlock()` 锁定物理内存以防止被 Swap 换出。此限制会导致锁定失败，进而引发不可控的缺页中断（Page Fault），破坏实时性。
|
||||
- **有利配置**：`open files` (文件句柄) 已达 **524288**，`core file size` 为 `unlimited`，这有利于高并发 Socket 通信和崩溃现场保留。
|
||||
- **注意点**：`stack size` 为 **8192KB (8MB)**。对于深度递归或在栈上分配大型矩阵的 DSP 算法，可能面临 Stack Overflow 风险，建议在工程中调整或改为堆分配。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
ulimit -a
|
||||
core file size (blocks, -c) unlimited
|
||||
data seg size (kbytes, -d) unlimited
|
||||
scheduling priority (-e) 0
|
||||
file size (blocks, -f) unlimited
|
||||
pending signals (-i) 255853
|
||||
max locked memory (kbytes, -l) 64
|
||||
max memory size (kbytes, -m) unlimited
|
||||
open files (-n) 524288
|
||||
pipe size (512 bytes, -p) 8
|
||||
POSIX message queues (bytes, -q) 819200
|
||||
real-time priority (-r) 0
|
||||
stack size (kbytes, -s) 8192
|
||||
cpu time (seconds, -t) unlimited
|
||||
max user processes (-u) 255853
|
||||
virtual memory (kbytes, -v) unlimited
|
||||
file locks (-x) unlimited
|
||||
```
|
||||
|
||||
**2. 系统级文件句柄上限 (System-wide File Handles)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- `file-max` 约为 $9.22 \times 10^{18}$，`nr_open` 约为 $10.7$ 亿。
|
||||
- 结论：内核层面的文件描述符限制极其宽裕，不存在系统级瓶颈。任何 "Too many open files" 错误均将源自进程级（ulimit）限制。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/fs/file-max
|
||||
9223372036854775807
|
||||
```
|
||||
|
||||
```bash
|
||||
cat /proc/sys/fs/nr_open
|
||||
1073741816
|
||||
```
|
||||
|
||||
**3. 线程与进程容量 (Thread & Process Capacity)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- `pid_max` (419 万) 和 `threads-max` (51 万) 提供了充足的 ID 空间。
|
||||
- 结论：系统支持高并发多线程模型，能够容纳雷达处理管线中密集的数据分发线程。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/kernel/pid_max
|
||||
4194304
|
||||
```
|
||||
|
||||
```bash
|
||||
cat /proc/sys/kernel/threads-max
|
||||
511707
|
||||
```
|
||||
|
||||
**4. 核心转储策略 (Core Dump Strategy)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- `core_pattern` 被重定向至 `systemd-coredump`。这意味着 Core 文件会被压缩并统一存储在 `/var/lib/systemd/coredump/`，而非散落在当前目录。这对长期运行的无人值守系统有利，便于统一回溯。
|
||||
- `suid_dumpable` 为 `0`。这意味着如果雷达主程序使用了 `setuid` 提权或文件 capabilities，崩溃时将**不会**产生 Core Dump。调试阶段建议临时设为 `1`。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/kernel/core_pattern
|
||||
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
|
||||
```
|
||||
|
||||
```bash
|
||||
cat /proc/sys/fs/suid_dumpable
|
||||
0
|
||||
```
|
||||
|
||||
**5. 管道缓冲区限制 (Pipe Buffer Limits)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- `pipe-max-size` 为 **1MB**。
|
||||
- 结论：如果进程间通信（IPC）大量依赖 Pipe，单次原子写入不应超过此值。对于高吞吐雷达数据，建议使用共享内存而非管道。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/fs/pipe-max-size
|
||||
1048576
|
||||
```
|
||||
|
||||
**6. System V IPC 限制 (Shared Memory & Semaphores)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- **共享内存**：最大段大小 (Max Segment Size) 极为巨大（PB 级），完全满足 GPGPU 异构计算中零拷贝（Zero-copy）或大块内存共享的需求。
|
||||
- **消息队列**：`max message size` 仅为 **8192 字节**。这表明 System V 消息队列仅适用于传递极小的控制指令（Control Plane），严禁用于传输雷达回波数据（Data Plane）。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
ipcs -l
|
||||
---------- 消息限制 -----------
|
||||
系统最大队列数量 = 32000
|
||||
最大消息尺寸 (字节) = 8192
|
||||
默认的队列最大尺寸 (字节) = 16384
|
||||
|
||||
---------- 同享内存限制 ------------
|
||||
最大段数 = 4096
|
||||
最大段大小 (千字节) = 18014398509465599
|
||||
最大总共享内存 (千字节) = 18014398509481920
|
||||
最小段大小 (字节) = 1
|
||||
|
||||
--------- 信号量限制 -----------
|
||||
最大数组数量 = 32000
|
||||
每个数组的最大信号量数目 = 32000
|
||||
系统最大信号量数 = 1024000000
|
||||
每次信号量调用最大操作数 = 500
|
||||
信号量最大值=32767
|
||||
```
|
||||
|
||||
**7. 持久化资源配置文件 (Persistent Config File)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- 输出为空。说明 `/etc/security/limits.conf` 中没有显式配置。
|
||||
- 结论：当前的系统限制值（如 `open files = 524288`）可能来自于 systemd 的全局默认配置或 `/etc/security/limits.d/` 下的子文件。但 `memlock` 的 64KB 限制必须在此文件中显式覆盖，否则每次重启都会面临实时性风险。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
grep -vE "^#|^$" /etc/security/limits.conf
|
||||
(空)
|
||||
```
|
||||
110
系统基座文件/1/1.1/1.1.5 设备节点与总线映射 (Device Nodes & Bus Mapping).md
Normal file
110
系统基座文件/1/1.1/1.1.5 设备节点与总线映射 (Device Nodes & Bus Mapping).md
Normal file
@@ -0,0 +1,110 @@
|
||||
---
|
||||
tags:
|
||||
date created: 星期三, 十一月 19日 2025, 4:05:45 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 4:06:00 下午
|
||||
---
|
||||
|
||||
# 1.1.5 设备节点与总线映射 (Device Nodes & Bus Mapping)
|
||||
|
||||
**1. 核心加速卡与显示设备识别 (GPU & Display Recognition)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **信息解析**：
|
||||
- **设备状态**：成功识别到 ID 为 `1e3e:0002` 的 Processing accelerator，此即 **天数智芯（Iluvatar）智铠 GPU**。物理总线地址为 `0001:01:00.0`。
|
||||
- **设备节点**：`/dev/iluvatar0` 已创建，且权限为 `666` (crw-rw-rw-)，这意味着用户态程序可以直接访问，驱动加载正常。
|
||||
- **显示设备**：检测到 Phytium 原生显示控制器 (`0001:02:00.0`)，映射为 `/dev/dri/card0`。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
lspci -nn | grep -E "VGA|3D|Display|Processing|Accelerator"
|
||||
0001:01:00.0 Processing accelerators [1200]: Device [1e3e:0002] (rev 01)
|
||||
0001:02:00.0 Display controller [0380]: Phytium Technology Co., Ltd. Device [1db7:dc3e]
|
||||
```
|
||||
|
||||
```bash
|
||||
ls -lR /dev/dri /dev/vfio /dev/iluvatar* 2>/dev/null
|
||||
crw-rw-rw- 1 root root 239, 0 11月 19 14:12 /dev/iluvatar0
|
||||
…
|
||||
```
|
||||
|
||||
**2. PCIe 链路带宽与完备性 (PCIe Link Status)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **信息解析**：
|
||||
- **严重告警 (Network)**：`dmesg` 显示网迅网卡（ngbe）带宽受限。
|
||||
|
||||
> `8.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x2 link`
|
||||
> 网卡能力为 x4，但实际协商或插槽仅支持 x2。**这导致物理带宽上限仅为 8Gbps，无法跑满双口万兆，雷达高吞吐传输存在丢包风险。**
|
||||
|
||||
- **链路降级 (Link Downgrade)**：`lspci` 统计显示有多个设备状态为 `downgraded`。需确认 GPU (`0001:01:00.0`) 当前是跑在 `Speed 16GT/s, Width x16` 还是被降级。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
dmesg | grep -iE "smmu|iommu|pci|aer|firmware" | tail -n 20
|
||||
[ 7.267461] ngbe 0000:0d:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x2 link at 0000:09:04.0
|
||||
```
|
||||
|
||||
```bash
|
||||
lspci -vv | grep -E "LnkCap:|LnkSta:" | grep -E "Speed|Width" | sort | uniq -c
|
||||
1 LnkSta: Speed 16GT/s (downgraded), Width x8 (ok)
|
||||
1 LnkSta: Speed 16GT/s (ok), Width x8 (downgraded)
|
||||
```
|
||||
|
||||
**3. IOMMU 组别与隔离 (IOMMU Groups)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- **功能状态**：IOMMU 已激活。
|
||||
- **分组详情**：
|
||||
- GPU (`0001:01:00.0`) 被分配在 **Group 18**。
|
||||
- 网卡 (`0000:0d:00.x`) 被分配在 **Group 19**。
|
||||
- **结论**：GPU 独占 Group 18，这非常有利于通过 VFIO 进行直通（Passthrough）或用户态驱动开发，隔离性良好。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
dmesg | grep -iE "smmu|iommu|pci|aer|firmware"
|
||||
[ 6.942440] iommu: Adding device 0001:01:00.0 to group 18
|
||||
[ 7.112576] iommu: Adding device 0000:0d:00.0 to group 19
|
||||
```
|
||||
|
||||
**4. 中断亲和性与分布 (Interrupt Affinity)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- **NVMe 风险**：NVMe SSD 的中断 (`nvme0q0`, IRQ 124) 在终端输出时刻仅触发在 CPU0 上（Count=37）。
|
||||
- **USB 干扰**：大量的 `xhci_hcd` (USB) 中断分布在 IRQ 128-146。
|
||||
- **建议**：必须将雷达的高速信号采集卡中断和 NVMe 落盘中断手动绑定到不同的 CPU 核心，避免与 CPU0（通常处理 OS 杂项）争抢。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /proc/interrupts | grep -i "MSI" | head -n 20
|
||||
124: 37 0 … 0 ITS-MSI 135790592 Edge nvme0q0
|
||||
```
|
||||
|
||||
**5. 块设备 IO 调度器 (Block Device IO Scheduler)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- **NVMe 配置**：`nvme0n1` 当前调度器为 `[none]`。
|
||||
- **结论**：**优秀配置**。对于 NVMe SSD，使用 `none` (多队列直通) 能最大程度降低 CPU 开销，最适合雷达原始数据（Raw Data）的高速落盘场景。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
grep "" /sys/block/*/queue/scheduler
|
||||
/sys/block/nvme0n1/queue/scheduler:[none] mq-deadline kyber bfq
|
||||
```
|
||||
|
||||
**6. PCIe 最大有效载荷 (Max Payload Size)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- 多数设备协商在 `512 bytes`，但也有一部分在 `128 bytes` 或 `256 bytes`。
|
||||
- 若 GPU 或采集卡的 MPS (Max Payload Size) 不匹配（如一个 128 一个 512），PCIe 控制器会强制按照木桶效应（最低值）传输，导致 DMA 效率下降 15%-30%。需确认 GPU 具体协商值。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
lspci -vv | grep -E "DevCtl:|DevCap:" | grep -E "MaxPayload|MaxReadReq" | sort | uniq -c
|
||||
15 DevCap: MaxPayload 128 bytes…
|
||||
23 DevCap: MaxPayload 512 bytes…
|
||||
```
|
||||
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
tags:
|
||||
date created: 星期三, 十一月 19日 2025, 4:10:16 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 4:10:27 下午
|
||||
---
|
||||
|
||||
# 1.1.6 时间同步与系统关键疑点深挖 (Time Synchronization & Deep-Dive)
|
||||
|
||||
**1. 时间同步服务健康度 (Time Synchronization Health)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- **时钟源 (Clocksource)**：系统正确使用了 `arch_sys_counter`，这是 ARM64 架构下的高精度硬件计数器，基准可靠。
|
||||
- **同步偏差 (Offset)**：当前与 NTP 服务器的偏差约为 **6ms - 7ms** (`-6106us` \~ `+7072us`)。对于毫秒级雷达应用尚可接受，但若涉及多站协同或相控阵微秒级同步，此偏差**过大**，建议改用 PTP (Precision Time Protocol) 或连接本地高精度 GPS 时钟源。
|
||||
- **频率漂移 (Frequency Skew)**：`89.988 ppm`，表明本地晶振走得稍快，但在 Chrony 修正范围内。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
|
||||
arch_sys_counter
|
||||
|
||||
chronyc sources -v
|
||||
^* 113.141.164.38 … -6106us[-6155us] +/- 35ms
|
||||
^+ 223.4.249.80 … +7072us[+7072us] +/- 34ms
|
||||
```
|
||||
|
||||
**2. GPU 链路降级确认 (GPU Link Downgrade Verification)**
|
||||
|
||||
- **关键性**：P0 (Critical)
|
||||
- **信息解析**：
|
||||
- **链路状态**：明确确证 **GPU 运行在 PCIe 4.0 x8 模式** (`Speed 16GT/s (ok), Width x8 (downgraded)`)。
|
||||
- **根本原因**：物理插槽可能仅为 `x8` 电气连接，或者 GPU 金手指接触不良，亦或是主板 BIOS 设置了通道拆分（Bifurcation）。
|
||||
- **后果**：理论带宽上限从 32GB/s (x16) 降至 16GB/s (x8)。若雷达回波数据量巨大（如多通道宽带信号），这将成为数据传输的硬瓶颈。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
lspci -s 0001:01:00.0 -vv | grep -E "LnkCap:|LnkSta:"
|
||||
LnkCap: Port #0, Speed 16GT/s, Width x16 …
|
||||
LnkSta: Speed 16GT/s (ok), Width x8 (downgraded)
|
||||
```
|
||||
|
||||
**3. 系统性能配置档 (System Performance Profile)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- **激活策略**：`throughput-performance` 已激活。
|
||||
- **缺陷**：尽管使用了高性能配置，但前序审计发现 `numa_balancing=1` 依然开启。这说明 Kylin 默认的 `throughput-performance` 策略并未激进地关闭 NUMA 自动均衡，后续需创建自定义 Tuned Profile 来覆盖此项。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
tuned-adm active
|
||||
Current active profile: throughput-performance
|
||||
```
|
||||
|
||||
**4. 透明大页整理策略 (THP Defrag Policy)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- **当前状态**：`[madvise]`。
|
||||
- **评价**：这是一个**相对安全**的设置。意味着内核仅在应用程序通过 `madvise(MADV_HUGEPAGE)` 显式请求时才整理大页，避免了全局强制整理带来的随机延迟。与 1.1.2 节建议一致。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /sys/kernel/mm/transparent_hugepage/defrag
|
||||
always defer defer+madvise [madvise] never
|
||||
```
|
||||
|
||||
**5. 网络接口映射概览 (Network Interface Mapping)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- **接口列表**：
|
||||
- `ens4f0` - `ens4f3`：这极有可能是那是那块**带宽受限**的网迅四口千兆/万兆网卡。目前 `ens4f1` 为 `UP` 状态。
|
||||
- `ens2f7u1u2`：USB 网卡或转接设备，当前处于 `UP` 状态。
|
||||
- **下一步行动**：后续网络调优时，需重点针对 `ens4f*` 系列接口使用 `ethtool` 检查 Ring Buffer 大小和硬中断聚合（Coalesce）设置。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
ip -br link show
|
||||
ens4f0 DOWN …
|
||||
ens4f1 UP …
|
||||
```
|
||||
|
||||
-----
|
||||
|
||||
### 1\. 开发环境与构建生态 - 审计总结
|
||||
|
||||
至此，**1.1 操作系统与内核基座** 的深度审计已全部完成。我们已经掌握了这台机器的“体检报告”：
|
||||
|
||||
- **底座**：Kylin V10 SP1 (aarch64), Kernel 4.19 (GCC 7.3 构建), **64KB PageSize**。
|
||||
- **算力**：Feiteng S5000C + Iluvatar 智铠 GPU (PCIe x8 降级运行)。
|
||||
- **风险**：PageSize 兼容性、GPU 带宽减半、NVMe 中断挤压在 CPU0、系统时钟偏差较大。
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 1.1.7 实时性与吞吐量配置补丁 (Real-time & Throughput Patches)
|
||||
date created: 星期三, 十一月 19日 2025, 4:31:12 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 4:31:40 下午
|
||||
---
|
||||
|
||||
# 1.1.7 实时性与吞吐量配置补丁 (Real-time & Throughput Patches)
|
||||
|
||||
| **组件** | **状态** | **说明** |
|
||||
| :--- | :--- | :--- |
|
||||
| **limits.conf** | 已修复 | 解决了 `max locked memory` 64KB 的致命限制。 |
|
||||
| **sysctl.conf** | 已优化 | 解决了 `numa_balancing` 抖动和网络缓冲不足的问题。 |
|
||||
| **GRUB CMDLINE** | 已加固 | 解决了 USB 设备的自动挂起风险。 |
|
||||
|
||||
-----
|
||||
|
||||
**1. 进程级资源锁定限制 (Process Memory Locking)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **信息解析**：已通过修改 `/etc/security/limits.conf`，将**锁定内存限制**从原先的致命值 **64KB** 提升至 `unlimited`。这确保了雷达实时线程和 DMA 缓冲区能成功调用 `mlock()`，杜绝内存换出导致的延迟。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
ulimit -l
|
||||
unlimited
|
||||
```
|
||||
|
||||
**2. 核心调度与实时节流策略 (CPU Scheduling & Throttling)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **信息解析**：已停止并禁用 `irqbalance` 服务，并强制将内核 `numa_balancing` 设置为 `0`，消除了自动化的内存和中断迁移，以保障信号处理的时序确定性。同时，通过 `sched_rt_runtime_us = -1` 解除了对实时线程的 CPU 时间节流。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
systemctl status irqbalance | grep Active
|
||||
Active: inactive (dead) since …
|
||||
|
||||
sysctl kernel.numa_balancing
|
||||
kernel.numa_balancing = 0
|
||||
```
|
||||
|
||||
**3. 网络 UDP 缓冲区优化 (Network UDP Buffers)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：已通过 `/etc/sysctl.d/99-radar-tuning.conf` 文件，将内核接收 (`rmem_max`) 和发送 (`wmem_max`) 缓冲区最大值从默认值提升至 25MB 以上，同时优化了 ARP 表大小。这对于处理降级 PCIe 链路 上的雷达高速 UDP 数据流是必要的。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
sysctl net.core.rmem_max
|
||||
net.core.rmem_max = 26214400
|
||||
```
|
||||
|
||||
**4. 硬件电源管理修正 (USB Power Management)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：已通过 GRUB 引导参数，追加 `usbcore.autosuspend=-1`。这防止了连接的 USB 设备（如网卡）因系统默认的节能策略而进入休眠，保障了数据流的持续性。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /proc/cmdline
|
||||
… usbcore.autosuspend=-1 …
|
||||
```
|
||||
Reference in New Issue
Block a user