捣鼓外贸电视盒子 h96 max x3

这周捣鼓了 H96max x3

从海鲜市场购入，到手后发现电源口有问题，特别不稳，稍微震一下就掉电了，有点被卖家坑的感觉，也不知道可不可以修。

因为打算作软路由用，（同一个房间内不需要信号有多强）所以就刷机测 WiFi 有线，经过一番折腾后，目前的状态是：
slimbox：ATV 的固件，32bit 的系统，驱动倒是完美了，但是额外的软件不好弄，WiFi 测速下来跟自带的系统一样，tx 速率：29MB/s rx 速率：24MB/s 基本上就是 ac 的单天线的正常速度。4.9 的 kernel ，无线驱动 dhd ，模块 ap6335
libreelec：5.x 的的 kernel ，用的是 brcmfmac 驱动，无线无法正常工作,tx 速率：3M/s rx 就 6M/s ，连接信息显示只有 n 的。
armbian 跟 openwrt：效果同上，kernel 来自恩山 f 大的 5.15 的 64bit
最后刷了 coreelec：4.9 的 64bit 的 vendor kernel 驱动是 dhd 。测试下来发送 9M/s ，收 6M/s
连接。最后把 slimbox 的 WiFi 固件（ nv_bcm4339a0_bg.bin ）跟 ap6335_nvram.txt 拷贝过去，然后速率就跑到发送 29M/s ，收 24M/s 了

然后重新刷回 armbian ，然后用刚才 coreelec 提到的固件跟 nvram ，使用 brcmfmac ，测试后发现 ac 已经正常使用了，只不过速率只有自带的一半。就是发 13M/s ，收 12M/s ，不过偶尔也能跑到 16M/s 。

为了装固件，还在京东买了个连托的 1080p usb 视频采集卡，价格 69 ，但是测试下来，它 edid 报告指出支持 4k 分辨率，而板子根据 edid 自动选了 4k ，但是一旦输入是 4k ，很快就黑屏了，还来不及到调整分辨率的界面。所以就直接退了。

另外，测试中发现，这话板子支持 USB 供电，所以那个电源口不稳的问题相当于间接用 USB 供电解决了。

刷机用的 Usb 公对公线不需要买，直接弄个 type-c 母口转 USB a 口就可以用了。同时也是 USB 供电线。

当时还考虑 x96 air 的，然后怕拿到不确定的 WiFi 芯片就先选 h96 max x3 了。不知道 x96 air 是啥情况。

#WiFi #固件 #kernel #USB #速率 #4k #测试 #驱动 #供电 #x3

硬盘盒认不到硬盘，有大佬给点思路吗？

### 硬件信息
- 硬盘盒 A
绿联 CM197 ，查了一下主控芯片是 ASM1153e 。
- 硬盘
西数 3.5HDD （就叫他硬盘 A ），WD30 EFRX-68EUZN0 ，NTFS 分区。
### 发生的事件是这样：
用硬盘盒外挂在华硕 AC68U 做 FTP ，大概已经稳定使用了 2 年。在什么都没有改动过的情况下，前段时间突然连不上 FTP ，发现在路由上已经识别不到外接硬盘了。把硬盘盒带硬盘接电脑（ win10 ），也同样认不到硬盘。
### 尝试排查问题：
1. 硬盘没坏
- 硬盘 A 放我另一个硬盘盒 B ，能识别，且完整看到过去保存的数据；
2. 硬盘盒也没坏
- 再随便拿个别的硬盘（就叫硬盘 B ，也是 HDD ），放到这个硬盘盒里，能识别，能正常拷贝数据；
3. 再把硬盘 A 放进硬盘盒 A
- win10 电脑也能识别了
4. 再把硬盘盒 A 接路由
- 又不能识别了
5. 还尝试了更新 ac68u 的固件，并恢复初始化
- 没有效果

### 路由 log
找了一下 log ，可能有关的信息贴在下面：
```Shell
> Jul 25 05:09:43 kernel: scsi 18:0:0:0: Direct-Access WDC WD30 EFRX-68EUZN0 0 PQ: 0 ANSI: 6
> Jul 25 05:09:43 kernel: sd 18:0:0:0: Attached scsi generic sg0 type 0
> Jul 25 05:09:43 kernel: sd 18:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
> Jul 25 05:09:43 kernel: sd 18:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
> Jul 25 05:09:43 kernel: sd 18:0:0:0: [sda] 4096-byte physical blocks
> Jul 25 05:09:43 kernel: sd 18:0:0:0: [sda] Write Protect is off
> Jul 25 05:09:43 kernel: sd 18:0:0:0: [sda] Assuming drive cache: write through
> Jul 25 05:09:43 kernel: sd 18:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
> Jul 25 05:09:43 kernel: sd 18:0:0:0: [sda] Assuming drive cache: write through
> Jul 25 05:09:43 kernel: GPT:Primary header thinks Alt. header is not at the end of the disk.
> Jul 25 05:09:43 kernel: GPT:1565565871 != 5860533167
> Jul 25 05:09:43 kernel: GPT:Alternate GPT header not at the end of the disk.
> Jul 25 05:09:43 kernel: GPT:1565565871 != 5860533167
> Jul 25 05:09:43 kernel: GPT: Use GNU Parted to correct GPT errors.
> Jul 25 05:09:43 kernel: sd 18:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
> Jul 25 05:09:43 kernel: sd 18:0:0:0: [sda] Assuming drive cache: write through
> Jul 25 05:09:43 kernel: sd 18:0:0:0: [sda] Attached SCSI disk
> Jul 25 05:09:45 usb: USB /dev/sda2(ntfs) failed to mount At the first try!
> Jul 25 05:09:48 usb: USB ntfs fs at /dev/sda2 mounted on /tmp/mnt/Data.
> Jul 25 05:09:50 rc_service: hotplug 12698:notify_rc restart_nasapps
> Jul 25 05:09:50 iTunes: daemon is stoped
> Jul 25 05:09:50 FTP Server: daemon is stoped

> Aug 15 09:36:44 kernel: sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
> Aug 15 09:36:44 kernel: sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
> Aug 15 09:36:44 kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
> Aug 15 09:36:44 kernel: sd 0:0:0:0: [sda] Write Protect is off
> Aug 15 09:36:44 kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through
> Aug 15 09:36:44 kernel: sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
> Aug 15 09:36:44 kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through
> Aug 15 09:36:45 kernel: GPT:Primary header thinks Alt. header is not at the end of the disk.
> Aug 15 09:36:45 kernel: GPT:1565565871 != 5860533167
> Aug 15 09:36:45 kernel: GPT:Alternate GPT header not at the end of the disk.
> Aug 15 09:36:45 kernel: GPT:1565565871 != 5860533167
> Aug 15 09:36:45 kernel: GPT: Use GNU Parted to correct GPT errors.
> Aug 15 09:36:45 kernel: sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
> Aug 15 09:36:45 kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through
> Aug 15 09:36:45 kernel: sd 0:0:0:0: [sda] Attached SCSI disk
> Aug 15 09:36:56 usb: USB ntfs fs at /dev/sda2 mounted on /tmp/mnt/Data.
> Aug 15 09:36:56 rc_service: hotplug 1491:notify_rc restart_nasapps
> Aug 15 09:36:56 iTunes: daemon is stoped
> Aug 15 09:36:56 FTP Server: daemon is stopped
> Aug 15 09:36:57 Samba Server: smb daemon is stoped
> Aug 15 09:36:57 kernel: gro disabled
```

### 咋办
- 因为完全不懂，只能贴上来向大佬求助了；
- 路由搭的 FTP 是为了共享数据，路由在局域网内有 IP 可访问，路由下的电脑原本是希望断网的，若实在不行，可以用什么办法（端口转发？），在电脑上搭 FTP 服务，外部还是访问路由 IP 登 FTP 吗？

#09 #kernel #Jul #25 #05 #sd #Aug #15 #36 #sda

Linux 内核版本到 6.0 了

https://www.kernel.org/

#https #www #kernel #org

「纯吐槽」升级 12.5.1 出现 userspace watchdog timeout

苹果的软件质量一年不如一年，网上搜到这个问题在 20 年左右就出现了，到现在都还在不同版本系统中被复现。

https://forums.macrumors.com/threads/constant-kernel-panics-userspace-watchdog-timeout-no-successful-checkins-from-com-apple-windowserver.2222878/

更过份是用户反馈问题，还被官方删号威胁

https://forums.macrumors.com/threads/constant-kernel-panics-userspace-watchdog-timeout-no-successful-checkins-from-com-apple-windowserver.2222878/post-28216058

AMD 之前被人骂了那么多年不稳定，现在自己组的台式机 7 * 24 小时运行也是稳稳的，草苹果丫的。

#com #https #forums #macrumors #threads #constant #kernel #panics #userspace #watchdog

MacBook Pro 14 使用 HDMI 外接显示器，合盖睡眠后可能出现因意外重启的 panic

在报错信息里面每次都出现了 AppleATCDPNativePort.cpp:264 ，有没有人遇到相似的情况呀。外接的显示器是 15.6 寸便携显示器，目前不清楚是不是显示器问题。

部分错误信息如下：
```
panic(cpu 4 caller 0xfffffe001be645b4): "AppleATCDPHDMIPort(atc3-dpphy)::enqueuePortMessage(0x1000002be): _messageQueue.enqueue(\"Unplug\") failed! Please file a radar under `AppleANXDPTX | all`.\n" @AppleATCDPNativePort.cpp:264
Debugger message: panic
Memory ID: 0x6
OS release type: User
OS version: 21G72
Kernel version: Darwin Kernel Version 21.6.0: Sat Jun 18 17:07:22 PDT 2022; root:xnu-8020.140.41~1/RELEASE_ARM64_T6000
Fileset Kernelcache UUID: 5CFF5B82BEB8FAE1094CE5733AD4234D
Kernel UUID: 43BBF43C-8008-3830-8A00-C8706889EEA1
iBoot version: iBoot-7459.141.1
secure boot?: YES
Paniclog version: 13
KernelCache slide: 0x0000000013648000
KernelCache base: 0xfffffe001a64c000
Kernel slide: 0x0000000013e0c000
Kernel text base: 0xfffffe001ae10000
Kernel text exec slide: 0x0000000013ef4000
Kernel text exec base: 0xfffffe001aef8000
mach_absolute_time: 0xf8bc828018
Epoch Time: sec usec
Boot : 0x62db7079 0x00050af5
Sleep : 0x62dd7b71 0x00040bd0
Wake : 0x62dd7c91 0x000e45c5
Calendar: 0x62dd7c94 0x00059241

Zone info:
Zone map: 0xfffffe10067f4000 - 0xfffffe30067f4000
. VM : 0xfffffe10067f4000 - 0xfffffe14d34c0000
. RO : 0xfffffe14d34c0000 - 0xfffffe166ce58000
. GEN0 : 0xfffffe166ce58000 - 0xfffffe1b39b24000
. GEN1 : 0xfffffe1b39b24000 - 0xfffffe20067f0000
. GEN2 : 0xfffffe20067f0000 - 0xfffffe24d34bc000
. GEN3 : 0xfffffe24d34bc000 - 0xfffffe29a0188000
. DATA : 0xfffffe29a0188000 - 0xfffffe30067f4000
Metadata: 0xfffffe3006804000 - 0xfffffe300e804000
Bitmaps : 0xfffffe300e804000 - 0xfffffe301439c000
```

#Kernel #&# #34 #version #slide #base #text #显示器 #AppleATCDPNativePort #cpp

clash tun 模式下自动插入的 ip rule 的作用

最近准备使用 clash permium 中的 tun 来实现透明代理，但在使用过程中碰到一些疑问，首先我很困惑的是 clash permium 自动插入的 ip rule 是什么意思？

```
> sudo ip rule ls
0: from all lookup local
1000: from all lookup [l3mdev-table]
9000: not from all ipproto tcp goto 9060
9000: from all dport 53 goto 9060
9000: from all iif lo sport 7777 goto 9060
9010: from all to 192.18.0.0/16 lookup 1919247465
9020: from all lookup main suppress_prefixlength 0
9030: not from all iif lo lookup 1919247465
9040: from 0.0.0.0 iif lo uidrange 0-4294967294 lookup 1919247465
9050: from 192.18.0.5 iif lo uidrange 0-4294967294 lookup 1919247465
9060: from all nop
9500: from all to 192.18.0.0/16 lookup 1970566510
9510: from all ipproto icmp goto 9560
9520: not from all dport 53 lookup main suppress_prefixlength 0
9530: not from all iif lo lookup 1970566510
9540: from 0.0.0.0 iif lo uidrange 0-4294967294 lookup 1970566510
9550: from 192.18.0.1 iif lo uidrange 0-4294967294 lookup 1970566510
9560: from all nop
32766: from all lookup main
32767: from all lookup default
```
除了 0 ，1000 ，32766 和 32767 是有明确的意思外，为何 clash 添加了这么多条记录，是啥意思？
接着，我有执行了 ip route show table all
```
> sudo ip route show table all | grep utun
default dev utun table 1970566510 proto unspec
192.18.0.0/16 dev utun proto kernel scope link src 192.18.0.1
broadcast 192.18.0.0 dev utun table local proto kernel scope link src 192.18.0.1
local 192.18.0.1 dev utun table local proto kernel scope host src 192.18.0.1
broadcast 192.18.255.255 dev utun table local proto kernel scope link src 192.18.0.1
fe80::/64 dev utun proto kernel metric 256 pref medium
local fe80::3b91:83c6:157c:91ad dev utun table local proto kernel metric 0 pref medium
multicast ff00::/8 dev utun table local proto kernel metric 256 pref medium
> sudo ip route show table all | grep redir
default via 192.18.0.6 dev redir table 1919247465 proto unspec
192.18.0.0/16 dev redir proto kernel scope link src 192.18.0.5
broadcast 192.18.0.0 dev redir table local proto kernel scope link src 192.18.0.5
local 192.18.0.5 dev redir table local proto kernel scope host src 192.18.0.5
broadcast 192.18.255.255 dev redir table local proto kernel scope link src 192.18.0.5
fe80::/64 dev redir proto kernel metric 256 pref medium
local fe80::872:3eff:fe29:d33f dev redir table local proto kernel metric 0 pref medium
multicast ff00::/8 dev redir table local proto kernel metric 256 pref medium
```

后面是我的 clash 配置：
```
log-level: info
allow-lan: true
mode: rule
ipv6: false
routing-mark: 6666

profile:
store-selected: true
store-fake-ip: true

tun: # 启用 tun 模式
enable: true
stack: system
auto-route: true
auto-detect-interface: true

dns:
enable: true
ipv6: false
listen: 0.0.0.0:53

default-nameserver:
- 233.5.5.5
- 119.29.29.29

enhanced-mode: fake-ip
nameserver:
- https://dns.alidns.com/dns-query

#后面未相关的配置省略
...
```

#192.18 #table #dev #proto #local #lookup #kernel #0.0 #utun #redir

上海哪里能给 mbp 清灰?

老生常谈的问题, Chrome 看视频 /直播, 没过一会就贼卡, 看了一下活动监视器, kernel_task 占用 cpu 好几百.
上次去七宝的天才吧说明问题, 他们做了检测后说硬件没问题, 不给清灰...

#Chrome #kernel #task #cpu #清灰 #... #问题 #好几百 #监视器 #老生常谈

[坑] 在 openwrt 上， Intel 网卡只支持 2.4GHz AP 模式，不支持 5GHz 和 6 GHz AP 模式，在 5、6G 上只能做客户端

https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi
https://bugzilla.kernel.org/show_bug.cgi?id=206469#c2

#https #kernel #org #wireless #wiki #en #users #drivers #iwlwifi #bugzilla

macOS13 好像已经解决了 M1 上频繁读写硬盘的问题

开机三天 launchd 、kernel_task 和 mds_stores 三个进程写入不到 30G ，之前一天好几十 G

#launchd #kernel #task #mds #stores #30G #好几十 #开机 #写入 #前一天

有人在 Apple Store 给过保 Mac 清灰么

两年半老型号了，最近刷个视频经常发热、kernel_task 占用百分之大几百上千、风扇狂转、系统卡得不行

过保了不知道清灰这种“设备维护”Apple Store 还会提供么以及收不收费，有去过的老哥么

#狂转 #半老 #刷个 #kernel #task #过保 #清灰 #Apple #Store #卡得

字节自研 Linux 操作系统 veLinux

内核： https://github.com/bytedance/kernel
操作系统试用： https://bytedance.github.io/kernel/
公众号说的是挺好的，不知道实际用起来咋样

#https #github #bytedance #kernel #com #io #内核 #操作系统 #咋样 #试用

AI 模型编译器 MegCC 开源，解决推理引擎体积问题

目前社区已经有多个移动端深度学习推理框架，如：NCNN 、MNN... 这些推理引擎都给社区的用户带来了在移动端上部署深度学习非常多的便利，但是他们也都有一个共性问题：随着不断地迭代以及性能优化，运行时库会逐渐的增大，特别是在不同算子 fuse 的时候，会导致非常多的长尾算子，这就会增大我们 App 或者 SDK 的体积。

为了解决这个问题，由 [MegEngine]( https://www.megengine.org.cn/) 团队开源的 MegCC 创新使用模型预编译的方案，生成模型推理必要的代码，去除掉了和模型推理无关的代码，因此极大程度上减少了推理引擎的体积。主要方法是：

将传统框架运行时的必要步骤：计算图优化、Kernel 选择、内存分配都移到编译时，从而最大程度上减少了 Runtime 时的二进制体积大小，并根据模型信息做进一步的性能优化。

该方案有以下优点：

* **随着框架的迭代将不会使得推理引擎的体积增大**
* **很多的算子融合可以在编译时根据模型信息生成对应的 code**
* **模型编译时可以获得整个计算图的信息，这样可以进一步进行极致的性能优化**
* **可以吸收社区在代码生成方面的经验用于为 MegCC 生成 code**

不同于传统推理框架，MegCC 是一个真真实实的深度学习模型编译器，具备极其轻量的 Runtime 二进制体积，高性能，方便移植，极低内存使用以及快启动等核心特点。用户可在 MLIR 上进行计算图优化，内存规划，最后通过预先写好的 code 模版进行代码生成。目前，MegCC 已支持 Arm64 ，Armv7 ，x86 ，risc-v 以及单片机平台。

GitHub 开源地址：[https://github.com/MegEngine/MegCCgithub.com/MegEngine/MegCC]( https://link.zhihu.com/?target=https%3A//github.com/MegEngine/MegCC)

## 使用方法及效果

使用 MegCC 完成模型部署只需要完成以下 3 步：

* **模型编译**：编译 MegEngine 模型，生成运行这个模型对应的 Kernel 以及优化之后的模型。
* **Runtime 编译**：这个阶段会将 Runtime 和上一步中生成的 Kernel 一起编译成一个静态库。
* **集成到应用中**：调用上一步编译的静态库的接口进行推理。

以 YOLOX 模型为例，运行效果如下图：



从图中可见，MegCC 生成的推理程序在保证推理性能良好（模型测速结果为 670ms ）的情况下，其大小可以达到 95KB 。

详细操作文档：[MegCC/how-to-use-chinese.md at main · MegEngine/MegCC]( https://link.zhihu.com/?target=https%3A//github.com/MegEngine/MegCC/blob/main/doc/how-to-use-chinese.md)

手把手操作教程：[挑战 100KB 可执行程序高性能推理 YOLOX 模型]( https://www.bilibili.com/video/BV1tg411B7dx/?vd_source=7bf60402180772b2217124f711769646) 


## 未来计划

目前 MegCC 仅支持 MegEngine 模型作为输入，其他模型格式可以考虑转换到 ONNX ，然后通过 [mgeconvert]( https://link.zhihu.com/?target=https%3A//github.com/MegEngine/mgeconvert) 进行模型格式转换。

预计在未来 2 个月内，MegCC 将支持更多的模型格式编译。同时实现以下进阶功能：

* 支持 ONNX 模型作为输入
* 做更多的 Kernel fusion
* 支持更多的后端设备

大家在使用 MegCC 过程中有任何问题，欢迎随时提 issue 告诉我们，也欢迎提 PR 帮助 MegCC 变得更好。

 

## 附

GitHub：[MegEngine 旷视天元]( https://github.com/MegEngine) （欢迎 star~

Gitee：[MegEngine/MegEngine]( https://gitee.com/MegEngine/MegEngine)

MegEngine 官网：[MegEngine-深度学习，简单开发]( https://www.megengine.org.cn/)

欢迎加入 MegEngine 技术交流 QQ 群：1029741705

#MegEngine #MegCC #模型 #com #https #推理 #编译 #github #Kernel #Runtime

kernel_task 离谱的磁盘读写

最近感觉运行有点卡，看了下监控，发现 kernel_task 的磁盘读写有点离谱啊，好几次都看到 800m+/s 写磁盘，还有几次 1G+/s

系统启动了 16 天未关机


#https #tva1 #sinaimg #cn #large #jpg #磁盘 #几次 #系统启动 #kernel

哪能下载现成的 Linux 内核 RPM 包？

大佬们，哪里可以下载 kernel rpm 包啊？ google 搜了没搜到

elrepo 只有最新的，centos7 的都 5.4 了，哪里能下载 4.19.2xx 的，4.14.2xx 也行啊。

#2xx #下载 #kernel #rpm #google #elrepo #centos7 #5.4 #4.19 #4.14

ubuntu22.04 下 chrome 硬件加速、休眠唤醒的问题以及解决方法

前段时间买了一张矿卡 1080 锁驱动的，使用 ubuntu22.04 的时候出现了以下几个问题:


1. 有时候休眠无法唤醒, 出现情况随机。表现是休眠后唤醒时屏幕无输出，无法 ssh 连接，只能强制关机重启。

2. chrome 卡顿，在桌面移动 chrome 和 vscode 的窗口都会出现掉帧的情况, 需要关闭 hardware acceleration 。 但关掉之后，看视频是用 cpu 解码的，很不爽.

3. 经过一些折腾之后，chrome 突然变得不跟手了，就是在选中一些网页文字的时候很不跟手。

对于 1 ，2 ， 最初我以为是锁驱动矿卡的 bug, 尝试了 nvidia 390 ，418 ，470 ，495 ，510 ，515 驱动都有出现睡眠卡死的问题，所以将就用了一段时间。

前几天搜索相关问题的时候，发现他们用 3060 在 ubuntu 下也有几率发生睡死的情况，看到解决方案是升级 kernel, 然后我就把原来的好像是 linux5.15 的内核升级到 linux6.09 ，卸载所有 nvidia 驱动并重装了 nvidia 520 的驱动，目前使用下来一切正常，chrome 不卡，暂时没出现休眠无法唤醒的问题了。


第三个问题发生是因为折腾过程中尝试重装 chrome, 卸载了 chrome-gnome-shell 这个软件，装回来就好了。

总结:
问题 1 ，2 是升级最新版本的 kernel 和 nvidia-driver 解决的，
第 3 个问题是通过安装 chrome-gnome-shell 这个软件解决的

#chrome #nvidia #驱动 #休眠 #问题 #唤醒 #矿卡 #kernel #gnome #shell

wps office ssd 写入怎么这么高。。。

就打开了个 400 多页的 pdf ，2 个小时里就写入了 10GB 。。。比 kernel_task 还高不少。。。
机器 m1pro 14 寸 macbook pro ，wps office 是海外版。。

#400 #pdf #10GB #kernel #task #m1pro #14 #macbook #pro #wps