2025-07-29 19:36:51
很简单的一个问题，但过程比较难绷，所以特此记录
为了能方便的既跑虚拟机，又跑Docker容器，我经常使用Fedora Server来作为宿主系统，配合红帽官方的Cockpit面板进行管理，其对虚拟机（基于libvirt/qemu/kvm）和容器（官方只支持Podman）的支持尚可。
但其在关机时虚拟机会直接被强制停止，并不安全。我们希望在直接对宿主机进行关机或重启时，其能够像PVE、EXSi等虚拟化系统一样发起并等待虚拟机的安全关机。
首先这个功能libvirt是提供了的，由libvirt-guests.service实现，但不知为何在Fedora并没有被默认启用。
进一步的，我们发现其配置文件/etc/sysconfig/libvirt-guests从某个版本起被移除了（你还能搜到关于这件事的相关讨论，暴躁用户 vs 倔强maintainer），更不方便我们配置了，因此首先恢复其内容：
# URIs to check for running guests
# example: URIS='default xen:/// vbox+tcp://host/system lxc:///'
#URIS=default
# action taken on host boot
# - start all guests which were running on shutdown are started on boot
# regardless on their autostart settings
# - ignore libvirt-guests init script won't start any guest on boot, however,
# guests marked as autostart will still be automatically started by
# libvirtd
#ON_BOOT=start
# Number of seconds to wait between each guest start. Set to 0 to allow
# parallel startup.
#START_DELAY=0
# action taken on host shutdown
# - suspend all running guests are suspended using virsh managedsave
# - shutdown all running guests are asked to shutdown. Please be careful with
# this settings since there is no way to distinguish between a
# guest which is stuck or ignores shutdown requests and a guest
# which just needs a long time to shutdown. When setting
# ON_SHUTDOWN=shutdown, you must also set SHUTDOWN_TIMEOUT to a
# value suitable for your guests.
ON_SHUTDOWN=shutdown
# If set to non-zero, shutdown will suspend guests concurrently. Number of
# guests on shutdown at any time will not exceed number set in this variable.
#PARALLEL_SHUTDOWN=0
# Number of seconds we're willing to wait for a guest to shut down. If parallel
# shutdown is enabled, this timeout applies as a timeout for shutting down all
# guests on a single URI defined in the variable URIS. If this is 0, then there
# is no time out (use with caution, as guests might not respond to a shutdown
# request). The default value is 300 seconds (5 minutes).
#SHUTDOWN_TIMEOUT=300
# If non-zero, try to bypass the file system cache when saving and
# restoring guests, even though this may give slower operation for
# some file systems.
#BYPASS_CACHE=0注意我这里设置的是ON_SHUTDOWN=shutdown，因为对于有PCIe设备直通的虚拟机suspend可能无法使用。
然后启用libvirt-guests.service服务：
sudo systemctl enable --now libvirt-guests然后在虚拟机关机时（或libvirt-guests服务关闭时）正在运行的虚拟机应当能正常关机，并且这些虚拟机会在宿主机下次启动时自动启动（恢复状态）。
这里不得不吐槽一下红帽经常搞一些breaking change，之前升级就被Network UPS Tools (NUT)的服务配置坑过一次
2025-03-04 11:23:37
来自每天一个没用的小知识
对一个挂掉SATA固态做数据恢复，症状大概是可以读，但一旦进行写入就会掉盘。在对数据做镜像时，直接通过USB3.0转SATA线插在群晖NAS机器上，并将镜像保存在其中的大容量硬盘上是个方便的做法。
首先安装ddrescue，添加SynoCommunity软件源，并安装SynoCli Disk Tools软件包即可。（如果你的网不是很好，也可以从这里手动下载：https://synocommunity.com/package/synocli-disk）
接下来，由于群晖会自动挂载USB外接硬盘等设备，会对其产生写入，这是我们不希望发生的。群晖没有选项可以关闭自动挂载功能，但经过一些尝试发现，我们可以通过暂停（SIGSTOP）/usr/syno/sbin/hotplugd进程的方法暂时阻止其自动挂载的行为。
登入SSH后执行：
sudo pkill -STOP -f /usr/syno/sbin/hotplugd注意不要直接将其杀死，否则其会自动重启。若再去阻止其自启就太过麻烦了，我们只需要暂时用SIGSTOP信号暂停其执行，让其失去功能即可。之后使用sudo pkill -CONT ...或直接重启机器后便可恢复。
而后便可以接入硬盘并使用ddrescue进行数据恢复。
2024-12-13 01:31:47
近日OpenWrt官方出了台MT7981的路由器，就是价格非常感人，不过看在它带RTC、POE、GPIO、nor/nand双启动、type-c转串口、还有M2 nvme槽（以及情怀）的份上还是买了一台玩玩。这机器最大的短板就是弱鸡的双核1.3G的MT7981，跑NAT + WiFi到千兆就几乎吃满了CPU（无offload情况），所以想着超个频。
前置知识：MT7981是一个ARMv8-A SoC，一般使用ARM Trusted Firmware（ATF）方式启动，启动顺序为：BL1（BOOT ROM）-> BL2 -> BL31 -> U-boot -> Linux Kernel，BL位于SoC内的ROM，本机从BL2开始位于外置SPI NAND Flash中（通过切换开关进入恢复模式时会使用SPI NOR Flash）。BL2包含了诸多SoC设备初始化代码，其中包含ARMPLL的初始化代码，其为CPU提供高速时钟（PLL初始化前CPU直接使用外部晶振的40MHz时钟）
参考了恩山论坛里的帖子：MT798X CPU超频1.65G/一键修改无线最大功率方法，不过里面的nand固件只有开NMBM（一种NAND Flash坏快管理机制）的，这台机器的主线OpenWrt不使用NMBM，所以用不了。于是自己研究了下，发在这里以供参考，其他没NMBM的nand理论上也能用（但请先确定自己的环境能成功救砖bl2再刷）。
我手里这台能从1.3GHz超到1.7GHz，跑源里的coremark能从4400分提高到5750分。之后再到1.76G时无线高负载时会崩溃重启，到1.8GHz时开机到一半就会死机，大概是这SoC的极限了，求稳可以只超到1.6GHz（此时coremark为5400分）。
方法简而言之就是修改bl2的pll初始化代码，源码位置：arm-trusted-firmware/plat/mediatek/mt7981/drivers/pll/pll.c (mtk-openwrt/arm-trusted-firmware)，需要修改其中PLL的频率值和分频值
以下是详细步骤：
./build_dir/target-aarch64_cortex-a53_musl/arm-trusted-firmware-mediatek-mt7981-spim-nand-ubi-ddr4/arm-trusted-firmware-mediatek-2024.01.17~bacca82a/plat/mediatek/mt7981/drivers/pll/pll.c文件（注意这样直接编辑的话make clean后这个文件的改动就丢了，标准做法是写个patch，这里只是图省事），其他机型请根据实际情况修改路径中的spim-nand-ubi-ddr4，找到正确的软件包/* Set PLL frequency */这段，具体修改后的代码和解释如下： /* Set PLL frequency */
// 241208: overclock hack
NOTICE("THIS IS AN OVERCLOKING BL2!\n");
NOTICE("set arm freq to 1.60 GHz:\n");
// 设置频率值，SDMPLL fractional mode，这里只需修改高8位
// 原始为2分频，0x82 = 130，实际对应1.3GHz：
// mmio_write_32(ARMPLL_CON1, 0x82000000); /* 1.3G */）
// 由于这个值再大一些的话会设置失败，所以我们要使用1分频（不分频）：
// 例如：0x50 = 80，此时对应1.6G； 0x55 = 85，对应1.7G，一次类推
mmio_write_32(ARMPLL_CON1, 0x50000000); /* 1.6G */
// mmio_write_32(ARMPLL_CON1, 0x55000000); /* 1.7G */
NOTICE("ARMPLL_CON1 = 0x%x\n", mmio_read_32(ARMPLL_CON1));
// 设置分频比，原始为2分频，还有个注释掉的4分频（用这个就是650MHz）：
// //mmio_setbits_32(ARMPLL_CON0, 0x124); /* divider for 650M */
// mmio_setbits_32(ARMPLL_CON0, 0x114); /* divider for 1.3G */
// 修改为不分频，这个寄存器的4～6位（从0开始数）为分频值，由于默认是001（2分频），这里要将其清零（1分频），然后再设置其余bits
mmio_clrbits_32(ARMPLL_CON0, 0x70); /* divider for >1.3G */
mmio_setbits_32(ARMPLL_CON0, 0x104);
NOTICE("ARMPLL_CON0 = 0x%x\n", mmio_read_32(ARMPLL_CON0));
bin/targets/mediatek/filogic/openwrt-mediatek-filogic-openwrt_one-snand-preloader.bin到nand中的bl2分区：
opkg install mtd kmod-mtd-rw
insmod mtd-rw.ko i_want_a_brick
mtd write /tmp/openwrt-mediatek-filogic-openwrt_one-snand-preloader.bin bl2
mtd verify /tmp/openwrt-mediatek-filogic-openwrt_one-snand-preloader.bin bl2
reboot下面是我编译的bl2：
对于OpenWrt One，可以直接刷入；
对于其他spim-nand-ubi-ddr4且非NMBM机型，也可以尝试直接刷入；
对于NMBM机型，请使用之前论坛里大佬发的超频bl2，也可以自己参考此方法编译，不要直接刷这个版本；
免责声明：由于刷bl2和超频有不小风险，请在刷之前一定要保证有救砖手段；同时超频会导致功耗增加，会增加供电电路的负荷，会有硬件损坏或者折寿的风险。
参考资料：https://mirror2.openwrt.org/docs/MT7981B_Wi-Fi6_Platform_Registers_Open_Part1_V1.0.pdf ，Page 310～311：
2024-07-04 21:24:10
400多块买了个便宜的单盘位DS118白群晖当容灾备份机器用，到手发现这个机型居然不支持创建btrfs的存储空间，这就十分难绷了，毕竟数据校验、快照等功能都用不了。
然后发现，尽管最近一代的新品在售的机器都支持btrfs了，但直到2020年群晖NAS的很多低端型号都不支持btrfs，其中20、19、18系列就包括：DS420j，DS220j，DS120j，DS419slim，DS119j，DS418j，DS218play，DS218j，DS118
尽管这些机型的配置确实不高，但btrfs其实也不是会费太多资源的东西，DS118这种机型完全能够支持，毕竟同为RTD1296 CPU的DS218或者同为1G内存的机器DS216+都是支持btrfs的，这么搞大概只是为了差别对待。
实际上，群晖在这些型号上用的系统都是差不多的，底层其实都带有btrfs功能，只是在Web UI上被隐藏了，这些功能的差异被定义在了/etc.defaults/synoinfo.conf中，因此只需要打开SSH功能，连接后执行sudo vim /etc.defaults/synoinfo.conf，加入以下内容即可：
support_btrfs="yes"
support_btrfs_dedupe="yes"
support_iscsi_btrfs_lun="yes"
support_share_snapshot="yes"
support_share_quota="yes"
support_share_user_quota="yes"
support_dr_snap="yes"
support_dr_replica="yes"
max_btrfs_snapshots="65536"
max_snapshot_per_lun="256"
max_snapshots_per_share="1024"
max_dr_replica="64"
max_sdr_replica="64"若不会使用vim，也可以使用winscp等软件。此时btrfs存储池便可以被创建和使用，但若想使用群晖的快照套件还需要继续操作。
DSM 7的快照功能需要使用套件SnapshotReplication和其依赖ReplicationService，然而这两个套件默认无法在不支持btrfs的机型上安装，但我们可以通过暂时修改机型的方式来强行安装，然后修改软件包信息。
1. 首先找到一个相似架构且支持btrfs的机器，比如对于我的DS118，我找到了DS218，然后在 群晖官网 -> DS218下载中心 -> DSM 套件 中找到SnapshotReplication和ReplicationService的安装包，上传到home目录中。
2. 编辑/etc.defaults/synoinfo.conf，修改synobios和unique字段中的机型，例如synobios=”ds118″和unique=”synology_rtd1296_ds118″中的“ds118”改为“ds218”，然后保存。注意：修改机型后，一定要在稍后改回来，期间不要重启，否则系统会无法启动。
3. 安装软件包，在终端中执行（.spk文件的文件名按实际修改）：
sudo synopkg install ReplicationService-ds218-1.3.0-0409.spk
sudo synopkg start ReplicationService
sudo synopkg install SnapshotReplication-ds218-7.4.5-1698.spk
sudo synopkg start SnapshotReplication4. 重要：恢复synoinfo.conf中的机型修改
5. 此时套件虽然已经安装，但机型不匹配，会提示套件损坏，需要我们修改已安装软件包的信息，依次修改下面两个文件：
/var/packages/ReplicationService/INFO
/var/packages/SnapshotReplication/INFO找到类似model="synology_rtd1296_ds218"的行，修改为机器的真实型号，然后重启，即可正常使用SnapshotReplication进行快照。
如果你这样做后依然无法创建快照，请尝试以下命令（homes为共享文件夹名称，可修改），观察快照能否被创建，或是否有报错：
sudo sh -x synosnapschedtask.sh local share homes玩过黑群晖的都知道，除了SA6400机型用的Linux内核版本是5.10.55（2021年发布）外，其他机型都还在使用上古4.4.302内核（2016年发布），然而在4.4老内核下，btrfs的压缩功能并不支持zstd算法，因此99%的白群晖NAS的文件系统压缩功能都是快速但效果较差的lzo，包括那些同样上万的机型（不100%确定，群晖毕竟对btrfs进行了不少魔改，也有可能backport了zstd的功能，其他机型的朋友可以看下synoinfo.conf是否包含btrfs_default_compression="zstd"的配置）。
对于黑群晖而言，也有多了一个用SA6400机型的理由。
2024-06-24 15:29:51
2024/07/24 UPDATE: 最新版的群晖Photos APP似乎已经修复/缓解了此问题
这是由于iOS设备（比如iPhone）的空间不足，使App无法转存较大文件导致的。在iCloud中照片/视频大小较大时，尽管在设置中可能会看到还有大量的剩余空间，但实际上是一种“已占用但可被释放”的状态。卸载一些大App或删除一些照片/视频能够解决，但如果不想这样做的话，可以使用下方的方法强制iOS去释放一些空间（iPhone 13 Pro测试可用）：
手机打开 相机，切换到视频，开启“ProRes HDR”录制，此时会提示一个很短的“最长时间”和“正在释放资源”。等待一段时间后，当“最长时间”上升到5分钟左右时，群晖Photos即可正常工作。
2024-04-08 05:49:33
（更新Roofline图）在笔记本市场中，Intel Ultra系列和AMD 8000系列不约而同的加入了集成NPU作为卖点（甚至对于AMD而言，是其7000系到8000的几乎唯一变化），各路数码新闻中鼓吹最多的便是所谓“AIPC”概念，但却往往对其NPU的具体用法语焉不详，或者将一些实际使用核显进行的推理归功于NPU。
由于本人近日购入了Intel Core Ultra CPU的笔记本，外加科研需要，对其集成NPU进行了一些调研。
省流：通常跑AI推理的实用性不如核显，目前仅支持静态shape的模型，因此无法做LLM推理，通常只做AI抠图这类简单任务。目前最大的用途是Win11自带的“工作室”效果功能，包含摄像头背景虚化、眼神接触、自动缩放取景三个功能，虽然这些CPU/GPU也能跑，但或许用NPU功耗更低。
设备：华硕 ROG 幻16 air （GU605），CPU：Intel Core Ultra 9 185H
打开Intel官网中Ultra 9 185H的资料，其对NPU的描述如下：
注意最后一行，由于OpenVINO是Intel官方的推理框架，后续我们将用它来测试，OpenVINO显然是支持Ultra的NPU的，相关文档如下：https://docs.openvino.ai/2024/openvino-workflow/running-inference/inference-devices-and-modes/npu-device.html，可以看到Ultra中NPU的实际型号为NPU 3720
测试环境实用Win11，其自带NPU的驱动（Linux下则需要自行编译），OpenVINO使用pip方式安装，具体请参考官方文档，注意其并非所有安装方式都有NPU支持。
使用如下代码检测NPU，并打印其硬件属性：
import openvino as ov
import openvino.properties as ovp
print(f"{ov.__version__ = }")
core = ov.Core()
print(f"{core.available_devices = }")
DEVICE = "NPU"
if DEVICE in core.available_devices:
print(f"- {DEVICE} found")
supported_properties = core.get_property(DEVICE, ovp.supported_properties)
for p, w in supported_properties.items():
try:
print(f"{p:>40} ({w}) = {core.get_property(DEVICE, p)}")
except Exception as e:
print(f"{p:>40} ({w}):", e)
else:
print(f"- {DEVICE} not found")在我的设备上输出如下：
ov.__version__ = '2024.0.0-14509-34caeefd078-releases/2024/0'
core.available_devices = ['CPU', 'GPU.0', 'GPU.1', 'GPU.2', 'GPU.3', 'NPU']
- NPU found
AVAILABLE_DEVICES (RO) = ['3720']
CACHE_DIR (RO) =
CACHING_PROPERTIES (RO) = {'DEVICE_ARCHITECTURE': 'RW', 'NPU_COMPILATION_MODE_PARAMS': 'RW', 'NPU_DMA_ENGINES': 'RW', 'NPU_DPU_GROUPS': 'RW', 'NPU_COMPILATION_MODE': 'RW', 'NPU_DRIVER_VERSION': 'RW', 'NPU_COMPILER_TYPE': 'RW', 'NPU_USE_ELF_COMPILER_BACKEND': 'RW'}
DEVICE_ARCHITECTURE (RO) = 3720
DEVICE_ID (RW) =
DEVICE_UUID (RO) = <已打码>
ENABLE_CPU_PINNING (RW) = False
EXCLUSIVE_ASYNC_REQUESTS (RW) = False
FULL_DEVICE_NAME (RO) = Intel(R) AI Boost
INTERNAL_SUPPORTED_PROPERTIES (RO) = {'CACHING_PROPERTIES': 'RW'}
LOG_LEVEL (RW) = Level.NO
MODEL_PRIORITY (RW) = Priority.MEDIUM
NPU_BACKEND_NAME (RO) = LEVEL0
NPU_COMPILATION_MODE (RW) =
NPU_COMPILATION_MODE_PARAMS (RW) =
NPU_COMPILER_TYPE (RW) = DRIVER
NPU_DEVICE_ALLOC_MEM_SIZE (RO) = 0
NPU_DEVICE_TOTAL_MEM_SIZE (RO) = 33554432
NPU_DMA_ENGINES (RW) = -1
NPU_DPU_GROUPS (RW) = -1
NPU_DRIVER_VERSION (RO) = 1688
NPU_MAX_TILES (RW) = -1
NPU_PLATFORM (RW) = AUTO_DETECT
NPU_PRINT_PROFILING (RW) = NONE
NPU_PROFILING_OUTPUT_FILE (RW) =
NPU_PROFILING_TYPE (RW): Unable to convert function return value to a Python type! The signature was
(self: openvino._pyopenvino.Core, device_name: str, property: str) -> object
NPU_STEPPING (RW) = -1
NPU_USE_ELF_COMPILER_BACKEND (RW) = AUTO
NUM_STREAMS (RO) = 1
OPTIMAL_NUMBER_OF_INFER_REQUESTS (RO) = 1
OPTIMIZATION_CAPABILITIES (RO) = ['FP16', 'INT8', 'EXPORT_IMPORT']
PERFORMANCE_HINT (RW) = PerformanceMode.LATENCY
PERFORMANCE_HINT_NUM_REQUESTS (RW) = 1
PERF_COUNT (RW) = False
RANGE_FOR_ASYNC_INFER_REQUESTS (RO) = (1, 10, 1)
RANGE_FOR_STREAMS (RO) = (1, 4)
SUPPORTED_PROPERTIES (RO) = {'AVAILABLE_DEVICES': 'RO', 'CACHE_DIR': 'RO', 'CACHING_PROPERTIES': 'RO', 'DEVICE_ARCHITECTURE': 'RO', 'DEVICE_ID': 'RW', 'DEVICE_UUID': 'RO', 'ENABLE_CPU_PINNING': 'RW', 'EXCLUSIVE_ASYNC_REQUESTS': 'RW', 'FULL_DEVICE_NAME': 'RO', 'INTERNAL_SUPPORTED_PROPERTIES': 'RO', 'LOG_LEVEL': 'RW', 'MODEL_PRIORITY': 'RW', 'NPU_BACKEND_NAME': 'RO', 'NPU_COMPILATION_MODE': 'RW', 'NPU_COMPILATION_MODE_PARAMS': 'RW', 'NPU_COMPILER_TYPE': 'RW', 'NPU_DEVICE_ALLOC_MEM_SIZE': 'RO', 'NPU_DEVICE_TOTAL_MEM_SIZE': 'RO', 'NPU_DMA_ENGINES': 'RW', 'NPU_DPU_GROUPS': 'RW', 'NPU_DRIVER_VERSION': 'RO', 'NPU_MAX_TILES': 'RW', 'NPU_PLATFORM': 'RW', 'NPU_PRINT_PROFILING': 'RW', 'NPU_PROFILING_OUTPUT_FILE': 'RW', 'NPU_PROFILING_TYPE': 'RW', 'NPU_STEPPING': 'RW', 'NPU_USE_ELF_COMPILER_BACKEND': 'RW', 'NUM_STREAMS': 'RO', 'OPTIMAL_NUMBER_OF_INFER_REQUESTS': 'RO', 'OPTIMIZATION_CAPABILITIES': 'RO', 'PERFORMANCE_HINT': 'RW', 'PERFORMANCE_HINT_NUM_REQUESTS': 'RW', 'PERF_COUNT': 'RW', 'RANGE_FOR_ASYNC_INFER_REQUESTS': 'RO', 'RANGE_FOR_STREAMS': 'RO', 'SUPPORTED_PROPERTIES': 'RO'}使用fp16精度，batchsize = 1，重复2000次推理，单次耗时如下：
avg latency = 3.462ms
根据估计的ResNet-50的计算量，其达到的roofline性能大致如下（不准确，仅预估）：
RESNET50_M_FLOP = 8206.520 # approximate RESNET50_M_MEM_RW = 105.763 # approximate avg latency = 0.0034620463848114014 reached GFLOP/s: 2370.4246 reached GB/s: 30.5493
达到的fp16性能约为2.35 TFLOP/s，由于是bs=1的推理，离上限值应该还是有不小距离的
功耗的话，用HWInfo64可看到“System Agent Power”在推理时从4w左右增加到10w左右，即6w，不确定这其中是否都是NPU的功耗，否则这个能效表现其实一般。不过在打开全部的“Windows工作室效果”时，System Agent功耗仅上升了1~2w，此时任务管理器中NPU利用率约为46%
这是多个模型在其上的测试，达到的FLOP/s和内存带宽基于理论估计，模型列表如下，不存在则表示（在当时）尚无法成功运行。
可以看出，其优化程度较差，远远无法跑到理论性能fp16: 5.7 TFLOP/s, int8: 11.5TOP/s（计算方法：2048 fp16 MACs or 4096 int8 MACs per cycle @ 1.4GHz）。也有文章指出，其可能无法利用全部的内存带宽，具有远远更低的内存墙，但依然无法解释为何ResNet-34的性能也很低。
Intel Core Ultra 笔记本处理器集成NPU初探（Intel AI Boost）最先出现在WuSiYu Blog。