如果你天天被版权方寄信 罚款 2500 欧一次 你就不会说 pt 没用了

duckdns

解锁了以后, 因为内核没有开源, 就连刷 GSI 都有各种奇怪的驱动 bug.
个人建议内核不开源的还是别折腾了, 就算能解锁, 也没有 rom 可用或者 rom 有比较严重的 bug.
比如联想的机器, 虽然解锁 bl 很方便, 但是内核不开源, 第三方 rom 一堆 bug.

日常就 wsl2+ssh+ansible
出问题就 windterm

@ysc3839 这.... 你 homelab 或者其它服务器上弄个 dns 服务器不就解决了....然后光猫的 DHCP 指定分配的 DNS 服务器为内网的 DNS 服务器, 而且新光猫不都是支持 upnp igd 的吗. 可能只有很老款的才不支持.

学习 arch
工作 fedora workstation
服务器 ubuntu server
个人建议你去整个私人用的 lab 配置不用很高, RAM 弄大一点, 装个 hyperviser 比如 proxmox/exsi, 然后随便你练习 k8s, 想装什么发行版装什么发行版
完毕

有没有有测试资格的说一下和 wine qq 比哪个占用小一点

truenas scale 自带的 k8s 建议别用, 半成品, 要用 k8s 建议自己起一个完整版的 k8s 体验可比 truenas 自带的好多了..
truenas 就适合安心把它当 nas 系统用, 吃 RAM 是 zfs 特色和 truenas 没什么关系.

单 GPU 可以 passthrough, 前提是你的 gpu 是专业卡(比如 telsa)或者改过 bios 的支持虚拟成多个 gpu.
锐龙的核显就很难受了, 不支持 sriov(amd 的消费级独显也不支持, 都是为了和企业级产品区分).

这就是 truenas scale 当宿主机很烦人的坑. 建议换个 hyperviser 比如 proxmox, 里面给 truenas scale 一个 vm, 然后再来个 pve 的容器给你需要显卡的应用, 让 pve 来给你直通.

这算啥，还有逗号作为小数点，分号作为表格分隔符的 bug. 牵扯到 locale 的问题，需要花很多精力维护，没有国际化的业务，不考虑这些“特殊”用户才是上策。

@mxT52CRuqR6o5 可以参考这篇文章
https://3os.org/infrastructure/proxmox/gpu-passthrough/igpu-passthrough-to-vm/
我 host 内核参数只保留了 quiet intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1
显卡屏蔽只屏蔽了 Intel 驱动 i915 和 nvidia 的驱动(我上面还接了一张 n 卡)

12 代的区别就是 VM 的内核, 驱动和相关依赖得非常新, 稍微旧一点的内核比如 5.19.10 在我这 intel_gpu_top 都会报错
Failed to detect engines! (No such file or directory)

最新的 6.0.0 内核什么参数都不需要加直接就支持 12 代核显
以前的内核还需要加 i915.force_probe=4690
在直通了核显的 VM 上 dmesg | grep i915
内容应该和下面的差不多
[ 5.060294] i915 0000:01:00.0: [drm] VT-d active for gfx access
[ 5.060351] i915 0000:01:00.0: [drm] Using Transparent Hugepages
[ 5.076393] i915 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xbbcf
[ 5.076673] i915 0000:01:00.0: [drm] Failed to find VBIOS tables (VBT)
[ 5.077164] i915 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none
[ 5.093245] i915 0000:01:00.0: firmware: direct-loading firmware i915/adls_dmc_ver2_01.bin
[ 5.093696] i915 0000:01:00.0: [drm] Finished loading DMC firmware i915/adls_dmc_ver2_01.bin (v2.1)
[ 6.619475] i915 0000:01:00.0: [drm] failed to retrieve link info, disabling eDP
[ 6.628504] i915 0000:01:00.0: firmware: direct-loading firmware i915/tgl_guc_70.1.1.bin
[ 6.629399] i915 0000:01:00.0: firmware: direct-loading firmware i915/tgl_huc_7.9.3.bin
[ 6.725923] i915 0000:01:00.0: [drm] GuC firmware i915/tgl_guc_70.1.1.bin version 70.1
[ 6.725931] i915 0000:01:00.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
[ 6.734941] i915 0000:01:00.0: [drm] HuC authenticated
[ 6.734945] i915 0000:01:00.0: [drm] GuC submission disabled
[ 6.734946] i915 0000:01:00.0: [drm] GuC SLPC disabled
[ 6.736822] [drm] Initialized i915 1.6.0 20201103 for 0000:01:00.0 on minor 1
[ 6.737161] i915 0000:01:00.0: [drm] Cannot find any crtc or sizes
[ 6.737255] i915 0000:01:00.0: [drm] Cannot find any crtc or sizes

intel_gpu_top 应该可以正常启动:
intel-gpu-top: Intel Alderlake_s (Gen12) @ /dev/dri/card1 - 0/ 0 MHz; 100% RC6; 0 irqs/s

然后此时, 你就可以调用核显, 比如硬解视频, 看看实际的核显占用情况和稳定性了.

我 VM 的内核升级到 6.0.0 内核以后硬解就没崩溃过了(连续测试了 3 天, 硬解了超过 20 小时不同编码码率的视频无崩溃, qsv 的性能还是很让人满意的), VM 系统为 Debian sid, 内核版本 6.0.0-2-amd64. 仅供参考.
如果你和我一样在 vm 里跑的是 docker 容器硬解, 容器镜像的 intel compute runtime 和 ffmpeg 版本也非常重要, 一定要选择驱动和相关依赖库都比较新的容器!! 否则很可能就不能正常调用 12 代核显进行 qsv 硬解, 只能退而求其次用 vaapi 硬解.

宿主机 proxmox 的内核还是 5.19.7-2-pve, 它只需要负责把核显交给 VM, 并不需要最新的 intel compute runtime 之类的, 所以内核不用太新问题也不大.

@mxT52CRuqR6o5 它用的 arch 自己修改的 i915 驱动放在 AUR 上. 我的 debian sid 看来要用还得改.
而且看回帖, 目前 windows vm 上能打驱动但是无法使用.

单个直通其实在最新的内核上已经挺稳定了, 但是 sriov 多个直通有人说做到了, 却暂时还没有稳定性的报告(因为之前旧驱动就算单个直通成功, 运行大概 2 个小时左右就会崩溃 GPU HANG, 实际是不可用的).

LTS 和 upstream 差了 N 个版本吧, 再说安全问题这种东西和内核新老根本无关.

而且有安全问题的时候 patch 基本上都会 backport 到旧内核上的.

linux 的内核新旧只是对新硬件的支持有区别, 还有一些核心依赖库的版本区别.

@f165af34d4830eeb 我试过了，需要 6.0 以上的内核并集成了最新的 intel compute runtime （这个需要最新的 libc6 等依赖，很多稳定版的 linux 发行版都版本过低） 和 最新的 i915 驱动才能比较完整的支持大小核调度和新核显。
目前就算是最新的 debian 和 ubuntu 稳定版都不行，得用 sid 或者 unstable 。

@chenjiangui998 移动端和桌面端不一样, 12 代移动端还需要 guc huc 那些电源管理驱动, 不然 lowpower encode decode 那些功能启用的时候会出错.
至于稳定性, 我手上没有, 没法测试.

pve 的 host 插个 pcie 设备, 网卡序号不会自动更新导致 host 断网的问题到现在还不修, 就一个脚本的事情...

webui 的强制重启根本不是 force kill 的问题也是不修.

还是自己撸脚本靠谱

@f165af34d4830eeb windows 看评论情况好一些, 要根据自己的硬件配置找一个不崩溃的特定版本驱动, 因为最新的崩, 旧版本也崩...
只是要关掉 windows 更新避免自动更新到崩溃的版本.