GTX 750 Ti安装391.35驱动后黑屏或无法进入桌面？

Question

GTX 750 Ti 安装 NVIDIA 官方驱动 391.35（发布于2018年3月，属较老的“Legacy”分支）后出现黑屏、卡死在登录界面或反复返回 GDM/LightDM 登录屏，是典型兼容性问题。该驱动虽标称支持 GTX 750 Ti（GM107架构），但实际对部分 Linux 内核（如 4.15+）、X.Org 1.20+ 及 Wayland 会触发 DRM/KMS 初始化失败或 Nouveau 冲突残留；Windows 下则常见于 Secure Boot 启用时驱动签名验证失败，或与旧版主板 UEFI/ACPI 表不兼容导致 GPU 初始化超时。此外，391.35 不包含对某些 GTX 750 Ti 厂商定制 BIOS（如技嘉 GV-N75TWF2-1GD）的完整供电管理支持，易引发显卡未被正确唤醒。用户常误以为“驱动安装成功即无问题”，却忽略内核模块加载状态（`lsmod | grep nvidia` 为空）、X 日志报错（`/var/log/Xorg.0.log` 中含 `(EE) Failed to load module "nvidia"` 或 `No devices detected`）等关键线索。

Answer 1

```html

一、现象层：黑屏与登录循环的表征识别

安装 NVIDIA 391.35 驱动后，系统在 GDM/LightDM 登录界面卡死、反复退回登录屏，或直接黑屏无响应——这是典型的“驱动加载成功但功能未就绪”假象。用户常误判为显示服务异常，实则底层 GPU 初始化已失败。该现象在 Ubuntu 18.04+（内核 4.15）、Fedora 28+（X.Org 1.20）、Debian 10（Wayland 默认会话）中高频复现；Windows 10/11 下则表现为登录前蓝屏（0x0000007E）、设备管理器中显卡显示黄色感叹号（代码 43），或启动日志中 ACPI BIOS Error (bug): Could not resolve symbol。

二、诊断层：从日志到模块的链路验证

• 内核模块状态：执行 lsmod | grep nvidia 返回空——说明 nvidia.ko 未加载，非“安装失败”，而是 modprobe 被 DRM/KMS 冲突拦截；
• X 日志关键线索：/var/log/Xorg.0.log 中高频出现：
  (EE) Failed to load module "nvidia"（模块路径错误或 ABI 不匹配）
  (EE) No devices detected（GPU 未被 PCI 设备枚举识别）
  (WW) Disabling Glamor + (EE) Screen(s) found, but none have a usable configuration（KMS 初始化失败导致 DDX 拒绝启用）；
• Secure Boot 影响：Windows 下可通过 bcdedit /set {current} testsigning on 临时绕过签名验证，Linux 下需用 mokutil --disable-validation 或重签名模块。

三、架构层：GM107 与 Legacy 驱动的兼容性断点

组件	391.35 支持上限	实际冲突点	典型报错来源
Linux 内核	4.14.x（官方文档标注）	4.15+ 引入 drm_kms_helper_poll_disable() 签名变更，导致 nvidia-modeset.ko init 失败	dmesg | grep -i "nvidia\|drm" 显示 nvkm: probe failed
X.Org Server	1.19.5	1.20+ 移除 xf86CrtcConfigPtr 兼容宏，391.35 的 nvidia_drv.so ABI 不匹配	Xorg.0.log 中 (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so 后无后续
UEFI/ACPI	ACPI 5.0	技嘉 GV-N75TWF2-1GD 等 OEM BIOS 使用 ACPI 4.0 旧表，_OSC 协商失败致 GPU 供电未唤醒	dmesg 含 pci 0000:01:00.0: can't derive routing for device

四、根因层：Nouveau 残留与 KMS 初始化时序竞争

Legacy 驱动 391.35 未完全实现 DRM_KMS 的原子提交流程，依赖 Nouveau 提前释放的 drm_device 资源。若系统未彻底禁用 Nouveau（仅 blacklist 不足），其 fbdev 模块仍会抢占 efifb 控制权，造成 KMS 初始化超时。验证命令：cat /sys/module/nouveau/initstate 应为 live（而非 unknown）；修复需在 /etc/default/grub 中追加 rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nouveau.modeset=0 并重建 initramfs。

五、方案层：分场景精准修复路径

graph TD
  A[问题现象] --> B{OS平台}
  B -->|Linux| C[内核降级至4.14或升级驱动至418.226+]
  B -->|Linux| D[强制禁用Wayland：/etc/gdm3/custom.conf 中启用 WaylandEnable=false]
  B -->|Windows| E[禁用Secure Boot + 更新主板UEFI至最新版]
  B -->|Windows| F[使用DDU彻底卸载后，以管理员权限静默安装391.35：setup.exe -s]
  C --> G[验证 lsmod | grep nvidia 非空 & dmesg | grep 'NVRM' 有 'Loading NVIDIA kernel module' ]
  D --> H[确认 /var/log/Xorg.0.log 中出现 '(II) NVIDIA(0): Initialized GPU at PCI:1:0:0']

六、加固层：BIOS/固件协同调优

针对技嘉 GV-N75TWF2-1GD 等定制 BIOS 显卡，需进入 UEFI 设置：关闭 Fast Boot（避免 ACPI 表跳过初始化）、启用 CSM Support（兼容传统 PCI enumeration）、将 PCIe Slot Configuration 设为 Gen2（GM107 在 Gen3 下易触发 ASPM L1.2 唤醒失败）。Linux 下可添加内核参数 pcie_aspm=off nvidia.NVreg_EnableGpuFirmware=0 强制绕过固件供电协商。

七、验证层：多维度交叉确认清单

1. lspci -k -s $(lspci | grep -i nvidia | cut -d' ' -f1) → 确认 Kernel driver in use: nvidia
2. nvidia-smi -q | grep -A5 "Product Name\|GPU Current Temp" → 验证用户态驱动通信
3. glxinfo | grep "OpenGL renderer" → 排查 GLX 扩展是否由 nvidia-drm 提供
4. systemctl status gdm3 | grep Active → 确保显示管理器未因 X session 崩溃而重启
5. journalctl -b -u display-manager | grep -i "nvidia\|drm\|fail" → 追踪启动期完整上下文

八、演进层：为何不应长期驻留于 391.35

NVIDIA 自 2021 年起终止对 390 系列（含 391.x）的安全更新，且其不支持 PRIME Synchronization、GBM modifiers 和 DRM lease 等现代显示栈特性。对于仍在运行 GTX 750 Ti 的生产环境，建议采用 LTS 策略：Linux 下迁移至 470.223.02（最后支持 GM107 的长期分支），Windows 下升级至 472.12（提供 ACPI 6.3 兼容补丁）。遗留系统若必须使用 391.35，则应锁定内核为 4.14.183（Ubuntu 16.04 ESM 最终版）并禁用所有自动更新通道。

```