void285
commented
4 years ago 可能贝壳云用户比较少，也可能问题的出现与硬件体质有关，总之基本搜不到与此类似的中文问题描述。
以下两个链接描述的问题跟上述问题比较接近，但没有提供解决方案，也许有帮助。
'Re: NETDEV WATCHDOG: eth1 (r8169): transmit queue 0 timed out' - MARC
Closed void285 closed 3 years ago
void285
commented
4 years ago 可能贝壳云用户比较少，也可能问题的出现与硬件体质有关，总之基本搜不到与此类似的中文问题描述。
以下两个链接描述的问题跟上述问题比较接近，但没有提供解决方案，也许有帮助。
'Re: NETDEV WATCHDOG: eth1 (r8169): transmit queue 0 timed out' - MARC
xiaokaixuan
commented
3 years ago @qijianjun 我也遇到过一次断网的问题 后来再没有出现过...楼主可参考这篇帖子解决“NETDEV WATCHDOG: eth0: transmit timed out”
解决了的话记得回来说下方法。
xiaokaixuan
commented
3 years ago 可能贝壳云用户比较少，也可能问题的出现与硬件体质有关，总之基本搜不到与此类似的中文问题描述。
以下两个链接描述的问题跟上述问题比较接近，但没有提供解决方案，也许有帮助。
'Re: NETDEV WATCHDOG: eth1 (r8169): transmit queue 0 timed out' - MARC
你可以在/boot/armbianEnv.txt里面加一行extraargs=acpi=off noapic试试。
void285
commented
3 years ago 谢谢，我试试，不过可能比较难观察到效果，因为有这个问题，已经很久不用它干活了，只是有个脚本自动检测没法联网就重启，上次自动重启是17天以前了。 似乎负载重了就容易重启，我一度怀疑是我这个硬件有某种缺陷，因为之前用小钢炮，现在用armbian都有这个症状。 我给它上点负载看看效果再反馈吧。
void285
commented
3 years ago 1小时高负债，没断网，看后面长期观察吧：
System load: 14.17 14.17 13.99 Up time: 2:06 hours Local users: 4
Memory usage: 56 % of 985MB IP: 192.168.1.185
CPU temp: 68°C
Usage of /: 61% of 7.0G昨天断网重启了，继续观察。
xiaokaixuan
commented
3 years ago 昨天断网重启了，继续观察。
我的也出现了，但不是断网是死机，日志根本查不到，日志都停止记录了，死机前没任何异常日志。
mslovecc
commented
3 years ago 我有两台贝壳云，其中一台是矿机体质非常差刷的同样的系统和你们一样出现死机或断网的情况。但是刷降频版的小钢炮可以稳定运行一个多月都没有问题，可是不太喜欢小钢炮那样精简的系统，还是希望可以解决armbian断网死机的问题。
mslovecc
commented
3 years ago 谢谢，我试试，不过可能比较难观察到效果，因为有这个问题，已经很久不用它干活了，只是有个脚本自动检测没法联网就重启，上次自动重启是17天以前了。 似乎负载重了就容易重启，我一度怀疑是我这个硬件有某种缺陷，因为之前用小钢炮，现在用armbian都有这个症状。 我给它上点负载看看效果再反馈吧。
可以分享一下那个检测到无法联网就自动重启的脚本吗？
void285
commented
3 years ago 谢谢，我试试，不过可能比较难观察到效果，因为有这个问题，已经很久不用它干活了，只是有个脚本自动检测没法联网就重启，上次自动重启是17天以前了。 似乎负载重了就容易重启，我一度怀疑是我这个硬件有某种缺陷，因为之前用小钢炮，现在用armbian都有这个症状。 我给它上点负载看看效果再反馈吧。
可以分享一下那个检测到无法联网就自动重启的脚本吗？
root@beikeyun:~ # cat cping.sh
#!/bin/sh
# file to log ping result and debug
rfile=/root/ping.txt
# file to log ping result only (for find out continuous failure count)
rfile2=/root/ping2.txt
# the router ip
ip=192.168.1.1
# flag to show whether another work in process
pflag=/root/ping-flag
# flag to show whether transmission manually shutdown before
tflag=/root/transmission-flag
function doping()
{
# output eg: 10/10/0/ /0.945/0.980/1.059/
# nanodm
# r=`ping ${ip} -c 10 | grep "\(loss\|trip\)" | sed 's/\( packets transmitted, \| packets received, \|% packet loss\|round-trip min\/avg\/max = \| ms\)/\//g'`
# armbian
r=`ping ${ip} -c 10 | grep "\(loss\|rtt min\)" | sed 's/, time [0-9]\+ms//g' | sed 's/\( packets transmitted, \| received, \|+[0-9]\+ errors, \|% packet loss\|rtt min\/avg\/max\/mdev = \| ms\)/\//g'`
# output eg: 10/10/0/0.945/0.980/1.059/
r=${r/$'\n'\//}
r=${r/\/\//\/}
# output eg: 10
l=$(echo $r | cut -d'/' -f2)
d=`date "+%Y-%m-%d %H:%M:%S"`
if [[ $l -lt 10 ]]; then
# output eg: 2020-03-13 18:11:10 192.168.1.1 10/9/10/0.417/0.815/0.990/
echo "${d} ${ip} ${r}" >> ${rfile}
echo "${d} ${ip} ${r}" >> ${rfile2}
else
# prevent frequent reboot
fc2=`tail -n 1 ${rfile2} | grep 10/0/100 | wc -l`
if [[ $fc2 -eq 1 ]]; then
echo "${d} ${ip} ${r}" >> ${rfile2}
fi
fi
}
function checkping()
{
# network down
if [[ $l -eq 0 ]]; then
# output eg: 0
fc=`tail -n 3 ${rfile2} | grep 10/0/100 | wc -l`
# network still down after 3 tries
if [[ $fc -ge 3 ]]; then
# stop transmission
transmission-remote --torrent all --stop
sleep 60
# log the event with a flag file
touch ~/transmission-flag
transmission-remote --exit
# log timepoint and reboot
rmflag
d=`date "+%Y-%m-%d %H:%M:%S"`
echo "${d} reboot system from tail" >> ${rfile}
sudo reboot
# retry with down and up eth dev
else
# d=`date "+%Y-%m-%d %H:%M:%S"`
# echo "${d} down and up the eth0 dev" >> ${rfile}
# ip link set dev eth0 down
# sleep 15
# ip link set dev eth0 up
sleep 15
# redo the ping work
doping
# recursively call the checkping function, it will cause reboot or nothing
checkping
fi
# network not [totally] down
else
# start transmission if shutdown before
if [[ -e ${tflag} ]]; then
transmission-remote --torrent all --start
curl https://sc.ftqq.com/xxxxx.send?text=rebootBKY
rm ${tflag}
fi
fi
}
function rmflag()
{
if [[ -e ${pflag} ]]; then
rm ${pflag}
fi
}
if [[ -e ${pflag} ]];then
mt=`stat -c %Y ${pflag}`
now=`date +"%s"`
long=`expr $now - $mt`
d=`date "+%Y-%m-%d %H:%M:%S"`
if [[ $long -le 300 ]];then
echo "${d} in work after ${long}, skip" >> ${rfile}
# exit
exit 0
else
echo "${d} in work after ${long}, force to work" >> ${rfile}
fi
fi
touch ${pflag}
doping
checkping
rmflag
谢谢，我试试，不过可能比较难观察到效果，因为有这个问题，已经很久不用它干活了，只是有个脚本自动检测没法联网就重启，上次自动重启是17天以前了。 似乎负载重了就容易重启，我一度怀疑是我这个硬件有某种缺陷，因为之前用小钢炮，现在用armbian都有这个症状。 我给它上点负载看看效果再反馈吧。
可以分享一下那个检测到无法联网就自动重启的脚本吗？
root@beikeyun:~ # cat cping.sh #!/bin/sh # file to log ping result and debug rfile=/root/ping.txt # file to log ping result only (for find out continuous failure count) rfile2=/root/ping2.txt # the router ip ip=192.168.1.1 # flag to show whether another work in process pflag=/root/ping-flag # flag to show whether transmission manually shutdown before tflag=/root/transmission-flag function doping() { # output eg: 10/10/0/ /0.945/0.980/1.059/ # nanodm # r=`ping ${ip} -c 10 | grep "\(loss\|trip\)" | sed 's/\( packets transmitted, \| packets received, \|% packet loss\|round-trip min\/avg\/max = \| ms\)/\//g'` # armbian r=`ping ${ip} -c 10 | grep "\(loss\|rtt min\)" | sed 's/, time [0-9]\+ms//g' | sed 's/\( packets transmitted, \| received, \|+[0-9]\+ errors, \|% packet loss\|rtt min\/avg\/max\/mdev = \| ms\)/\//g'` # output eg: 10/10/0/0.945/0.980/1.059/ r=${r/$'\n'\//} r=${r/\/\//\/} # output eg: 10 l=$(echo $r | cut -d'/' -f2) d=`date "+%Y-%m-%d %H:%M:%S"` if [[ $l -lt 10 ]]; then # output eg: 2020-03-13 18:11:10 192.168.1.1 10/9/10/0.417/0.815/0.990/ echo "${d} ${ip} ${r}" >> ${rfile} echo "${d} ${ip} ${r}" >> ${rfile2} else # prevent frequent reboot fc2=`tail -n 1 ${rfile2} | grep 10/0/100 | wc -l` if [[ $fc2 -eq 1 ]]; then echo "${d} ${ip} ${r}" >> ${rfile2} fi fi } function checkping() { # network down if [[ $l -eq 0 ]]; then # output eg: 0 fc=`tail -n 3 ${rfile2} | grep 10/0/100 | wc -l` # network still down after 3 tries if [[ $fc -ge 3 ]]; then # stop transmission transmission-remote --torrent all --stop sleep 60 # log the event with a flag file touch ~/transmission-flag transmission-remote --exit # log timepoint and reboot rmflag d=`date "+%Y-%m-%d %H:%M:%S"` echo "${d} reboot system from tail" >> ${rfile} sudo reboot # retry with down and up eth dev else # d=`date "+%Y-%m-%d %H:%M:%S"` # echo "${d} down and up the eth0 dev" >> ${rfile} # ip link set dev eth0 down # sleep 15 # ip link set dev eth0 up sleep 15 # redo the ping work doping # recursively call the checkping function, it will cause reboot or nothing checkping fi # network not [totally] down else # start transmission if shutdown before if [[ -e ${tflag} ]]; then transmission-remote --torrent all --start curl https://sc.ftqq.com/xxxxx.send?text=rebootBKY rm ${tflag} fi fi } function rmflag() { if [[ -e ${pflag} ]]; then rm ${pflag} fi } if [[ -e ${pflag} ]];then mt=`stat -c %Y ${pflag}` now=`date +"%s"` long=`expr $now - $mt` d=`date "+%Y-%m-%d %H:%M:%S"` if [[ $long -le 300 ]];then echo "${d} in work after ${long}, skip" >> ${rfile} # exit exit 0 else echo "${d} in work after ${long}, force to work" >> ${rfile} fi fi touch ${pflag} doping checkping rmflag
谢谢分享，你的断网问题解决了吗？
void285
commented
3 years ago 没有解决，我不了解是固件的问题还是硬件的问题。 看到有个openwrt的固件，修订记录多次提到过针对贝壳云的优化，也许解决了此问题。欢迎有时间的人尝试并分享结果：[2021-02-17] 53+、53+O S905x3(含x2)、S922x、贝壳云、我家云、微加云等OP固件 - OPENWRT专版 - 恩山无线论坛 - Powered by Discuz!
xiaokaixuan
commented
3 years ago @qijianjun 可能就是内核或驱动的问题，这个帖子我看过了。我没有重刷，只把内核升级到了5.4.28。现在运行20天了，一直在下载东西，没再出现过，后续再观察下。
Linux beikeyun 5.4.28-rockchip-flippy-32+ #70 SMP PREEMPT Fri Mar 27 22:24:11 CST 2020 aarch64 GNU/Linux
void285
commented
3 years ago @qijianjun 可能就是内核或驱动的问题，这个帖子我看过了。我没有重刷，只把内核升级到了5.4.28。现在运行20天了，一直在下载东西，没再出现过，后续再观察下。
Linux beikeyun 5.4.28-rockchip-flippy-32+ #70 SMP PREEMPT Fri Mar 27 22:24:11 CST 2020 aarch64 GNU/Linux
请教怎么升级内核，没有查到有参考价值的信息来源。
xiaokaixuan
commented
3 years ago @qijianjun 可能就是内核或驱动的问题，这个帖子我看过了。我没有重刷，只把内核升级到了5.4.28。现在运行20天了，一直在下载东西，没再出现过，后续再观察下。
Linux beikeyun 5.4.28-rockchip-flippy-32+ #70 SMP PREEMPT Fri Mar 27 22:24:11 CST 2020 aarch64 GNU/Linux请教怎么升级内核，没有查到有参考价值的信息来源。
帖子里提供的网盘里有纯内核供下载，解压到对应目录，修改下/boot下config dtb Image System.map uInitrd的指向目标。
修改/boot/armbianEnv.txt中的fdtfile=dtb/rockchip/rk3328-beikeyun-1296mhz.dtb
改的时候最好谨慎一些不然有可能就启不来了。
kaixuan@beikeyun:~$ ll kernel_5.4.28/
total 56M
drwxr-xr-x 2 kaixuan kaixuan 4.0K 2021-02-04 16:13:30 ./
drwxr-xr-x 6 kaixuan kaixuan 4.0K 2021-02-23 12:11:28 ../
-rw------- 1 kaixuan kaixuan 28M 2021-02-04 11:40:15 boot-5.4.28-rockchip-flippy-32+.tar.gz
-rw-r--r-- 1 kaixuan kaixuan 383K 2021-02-04 11:40:26 dtb-5.4.28-rockchip-flippy-32+.tar.gz
-rw-r--r-- 1 kaixuan kaixuan 27M 2021-02-04 11:40:32 modules-5.4.28-rockchip-flippy-32+.tar.gz
kaixuan@beikeyun:~$ ll /lib/modules/
total 16K
drwxr-xr-x 4 root root 4.0K 2021-02-04 11:44:46 ./
drwxr-xr-x 17 root root 4.0K 2019-07-16 21:29:41 ../
drwxr-xr-x 3 root root 4.0K 2019-07-16 21:29:44 4.4.184-rockchip64/
drwxr-xr-x 3 root root 4.0K 2020-03-27 22:26:52 5.4.28-rockchip-flippy-32+/
kaixuan@beikeyun:~$ ll /boot/
total 42M
drwxr-xr-x 4 root root 4.0K 2021-02-06 09:54:40 ./
drwxr-xr-x 22 root root 4.0K 2019-07-16 21:29:41 ../
-rw-r--r-- 1 root root 216 2021-02-06 09:54:40 armbianEnv.txt
-rw-r--r-- 1 root root 0 2021-02-04 12:03:00 armbianEnv.txt.out
-rw-r--r-- 1 root root 1.5K 2019-07-16 21:31:31 armbian_first_run.txt.template
-rw-r--r-- 1 root root 38K 2019-07-16 21:31:31 boot.bmp
-rw-r--r-- 1 root root 2.9K 2019-09-16 19:29:11 boot.cmd
-rw-r--r-- 1 root root 4.8K 2019-07-16 21:31:31 boot-desktop.png
-rw-rw-r-- 1 root root 2.9K 2019-09-16 19:29:11 boot.scr
lrwxrwxrwx 1 root root 33 2021-02-04 16:34:26 config -> config-5.4.28-rockchip-flippy-32+*
-rwxr-xr-x 1 root root 185K 2020-03-27 22:26:52 config-5.4.28-rockchip-flippy-32+*
lrwxrwxrwx 1 root root 30 2021-02-04 11:52:34 dtb -> dtb-5.4.28-rockchip-flippy-32+/
drwxr-xr-x 3 root root 4.0K 2021-02-04 16:36:05 dtb-5.4.28-rockchip-flippy-32+/
lrwxrwxrwx 1 root root 34 2021-02-04 11:53:23 Image -> vmlinuz-5.4.28-rockchip-flippy-32+*
-rwxr-xr-x 1 root root 9.2M 2020-03-27 22:27:00 initrd.img-5.4.28-rockchip-flippy-32+*
drwxr-xr-x 2 root root 4.0K 2021-02-04 16:46:24 kernel.old/
-rw-r--r-- 1 root root 0 2019-07-16 21:30:37 .next
lrwxrwxrwx 1 root root 37 2021-02-04 16:33:16 System.map -> System.map-5.4.28-rockchip-flippy-32+*
-rwxr-xr-x 1 root root 4.0M 2020-03-27 22:26:52 System.map-5.4.28-rockchip-flippy-32+*
lrwxrwxrwx 1 root root 34 2021-02-04 11:53:54 uInitrd -> uInitrd-5.4.28-rockchip-flippy-32+*
-rwxr-xr-x 1 root root 9.2M 2020-03-27 22:27:00 uInitrd-5.4.28-rockchip-flippy-32+*
-rwxr-xr-x 1 root root 19M 2020-03-27 22:26:52 vmlinuz-5.4.28-rockchip-flippy-32+*
kaixuan@beikeyun:~$ ll /boot/dtb-5.4.28-rockchip-flippy-32+/
total 12K
drwxr-xr-x 3 root root 4.0K 2021-02-04 16:36:05 ./
drwxr-xr-x 4 root root 4.0K 2021-02-06 09:54:40 ../
drwxr-xr-x 2 root root 4.0K 2021-02-04 16:36:05 rockchip/
kaixuan@beikeyun:~$
谢谢，正在下载。
to others: 下载地址在：N1_Openwrt_免费高速下载|百度网盘-分享无限制，提取码：02im，需要的三个文件：
-rw------- 1 kaixuan kaixuan 28M 2021-02-04 11:40:15 boot-5.4.28-rockchip-flippy-32+.tar.gz
-rw-r--r-- 1 kaixuan kaixuan 383K 2021-02-04 11:40:26 dtb-5.4.28-rockchip-flippy-32+.tar.gz
-rw-r--r-- 1 kaixuan kaixuan 27M 2021-02-04 11:40:32 modules-5.4.28-rockchip-flippy-32+.tar.gz更新内核的命令记录，供参考：
# 查看当前版本
cat /etc/os-release
cat /etc/armbian-release
cat /etc/armbian-image-release
# 查看当前内核相关目录
ll /lib/modules
ll /lib/modules/4.4.192-rockchip64
ll /boot
# 准备工作目录，将下载的文件拷贝到工作目录
mkdir kernel_5.4.28
scp boot-5.4.28-rockchip-flippy-32+.tar.gz modules-5.4.28-rockchip-flippy-32+.tar.gz dtb-5.4.28-rockchip-flippy-32+.tar.gz root@bky:~/kernel_5.4.28
cd kernel_5.4.28
ls
# 解压
mkdir boot-5.4.28-rockchip-flippy-32+
tar xvzf boot-5.4.28-rockchip-flippy-32+.tar.gz -C boot-5.4.28-rockchip-flippy-32+
mkdir modules-5.4.28-rockchip-flippy-32+
tar xvzf modules-5.4.28-rockchip-flippy-32+.tar.gz -C modules-5.4.28-rockchip-flippy-32+
mkdir dtb-5.4.28-rockchip-flippy-32+
tar xvzf dtb-5.4.28-rockchip-flippy-32+.tar.gz -C dtb-5.4.28-rockchip-flippy-32+
# 将新版本的initrd、内核、dtb放置到正确位置
mv boot-5.4.28-rockchip-flippy-32+/* /boot
mv 5.4.28-rockchip-flippy-32+ /lib/modules
mv dtb-5.4.28-rockchip-flippy-32+ /boot
# 归档旧版本文件
mkdir kernel.old
mv *192* kernel.old
# 链接新版本文件
ln -s config-5.4.28-rockchip-flippy-32+ config
ln -s System.map-5.4.28-rockchip-flippy-32+ System.map
rm uInitrd
ln -s uInitrd-5.4.28-rockchip-flippy-32+ uInitrd
rm Image
ln -s vmlinuz-5.4.28-rockchip-flippy-32+ Image
rm dtb
ln -s dtb-5.4.28-rockchip-flippy-32+ dtb
rm dtb.old
# 更新dtb文件路径，据实修改
vim armbianEnv.txt
# 重启
reboot学习阅读了本repo的源码，了解到固件是对rock64的固件稍加定制形成的，于是尝试发布新版本。
因为armbian的新包发布格式略有更改，本人fork后做了一点针对性的修改，然后用travis-ci发布了5.10内核的新版本固件，需要的请尝试下并反馈： Releases · void285/build-beikeyun
Armbian_21.02.1_beikeyun_buster_current_5.10.12.img.xz | 379 MB | 基于debian
Armbian_21.02.1_beikeyun_focal_current_5.10.12.img.xz | 275 MB | 基于ubuntu
Armbian_21.02.1_beikeyun_focal_legacy_4.4.213.img.xz | 238 MB | 基于ubuntu，旧版内核@qijianjun 新repo的Issues功能没开放
void285
commented
3 years ago 更新内核后问题已解决，提供两个值得参考的信息。
1、使用旧内核时，每分钟运行ping -n 10到路由器的脚本，一天会出现上百次不同程度的丢包，即10个检测包只有9个或者更少返回的情况；使用新内核后，不再有ping到路由器时丢包的问题了。
2、一份内核日志分别记录了旧内核、新内核启动过程中的两次日志，有参考研究的价值。
root@beikeyun:/var/log # cat kern.log.1 | grep error
Feb 21 11:17:02 localhost kernel: [ 6.972181] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro
Feb 22 01:17:01 localhost kernel: [ 6.025738] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro
Feb 23 15:43:06 localhost kernel: [ 8.334920] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro
Feb 25 05:17:01 localhost kernel: [ 8.554624] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro
root@beikeyun:/var/log # cat kern.log.1 | grep warn
Feb 23 15:43:08 localhost kernel: [ 12.051229] random: 7 urandom warning(s) missed due to ratelimiting
Feb 25 05:17:04 localhost kernel: [ 11.690688] random: 7 urandom warning(s) missed due to ratelimiting
root@beikeyun:/var/log # cat kern.log.1 | grep fail
Feb 21 11:17:02 localhost kernel: [ 0.368002] genirq: Setting trigger mode 8 for irq 162 failed (gic_set_type+0x0/0x64)
Feb 21 11:17:02 localhost kernel: [ 2.618519] phy phy-ff470000.usb3-phy.0: Looking up phy-supply property in node /usb3-phy@ff470000/utmi@ff470000 failed
Feb 21 11:17:02 localhost kernel: [ 2.618949] phy phy-ff470000.usb3-phy.1: Looking up phy-supply property in node /usb3-phy@ff470000/pipe@ff478000 failed
Feb 21 11:17:02 localhost kernel: [ 2.622185] phy phy-ff430000.hdmiphy.2: Looking up phy-supply property in node /hdmiphy@ff430000 failed
Feb 21 11:17:02 localhost kernel: [ 2.634288] pwm-regulator vdd-center: lookup for GPIO enable failed
Feb 21 11:17:02 localhost kernel: [ 2.634346] pwm-regulator vdd-center: Looking up pwm-supply property in node /vdd-center failed
Feb 21 11:17:02 localhost kernel: [ 2.634706] pwm-regulator vdd-center: Looking up pwm-supply property in node /vdd-center failed
Feb 21 11:17:02 localhost kernel: [ 2.634807] pwm-regulator vdd-center: Looking up pwm-supply property in node /vdd-center failed
Feb 21 11:17:02 localhost kernel: [ 2.645056] i2c i2c-4: of_i2c: modalias failure on /hdmi@ff3c0000/ports
Feb 21 11:17:02 localhost kernel: [ 2.650748] rockchip-drm display-subsystem: failed to parse display resources
Feb 21 11:17:02 localhost kernel: [ 3.343423] pwm-regulator vdd-center: Looking up pwm-supply property in node /vdd-center failed
Feb 21 11:17:02 localhost kernel: [ 3.351793] pwm-regulator vdd-center: Looking up pwm-supply property in node /vdd-center failed
Feb 21 11:17:02 localhost kernel: [ 3.352071] pwm-regulator vdd-center: Looking up pwm-supply property in node /vdd-center failed
Feb 21 11:17:02 localhost kernel: [ 3.386264] dwmmc_rockchip ff520000.dwmmc: Looking up vmmc-supply property in node /dwmmc@ff520000 failed
Feb 21 11:17:02 localhost kernel: [ 3.386289] dwmmc_rockchip ff520000.dwmmc: Looking up vqmmc-supply property in node /dwmmc@ff520000 failed
Feb 21 11:17:02 localhost kernel: [ 3.394309] dwmmc_rockchip ff520000.dwmmc: lookup for GPIO wp failed
Feb 21 11:17:06 localhost kernel: [ 11.718129] [drm:dw_hdmi_rockchip_set_property] *ERROR* failed to set rockchip hdmi connector property
Feb 21 11:17:06 localhost kernel: [ 11.718180] [drm:dw_hdmi_rockchip_set_property] *ERROR* failed to set rockchip hdmi connector property
Feb 21 11:17:06 localhost kernel: [ 11.718196] [drm:dw_hdmi_rockchip_set_property] *ERROR* failed to set rockchip hdmi connector property
Feb 21 11:17:06 localhost kernel: [ 11.718210] [drm:dw_hdmi_rockchip_set_property] *ERROR* failed to set rockchip hdmi connector property
Feb 21 11:17:06 localhost kernel: [ 11.718225] [drm:dw_hdmi_rockchip_set_property] *ERROR* failed to set rockchip hdmi connector property
Feb 21 11:17:06 localhost kernel: [ 11.718239] [drm:dw_hdmi_rockchip_set_property] *ERROR* failed to set rockchip hdmi connector property
Feb 22 01:17:01 localhost kernel: [ 0.363937] genirq: Setting trigger mode 8 for irq 162 failed (gic_set_type+0x0/0x64)
Feb 22 01:17:01 localhost kernel: [ 2.614010] phy phy-ff470000.usb3-phy.0: Looking up phy-supply property in node /usb3-phy@ff470000/utmi@ff470000 failed
Feb 22 01:17:01 localhost kernel: [ 2.614447] phy phy-ff470000.usb3-phy.1: Looking up phy-supply property in node /usb3-phy@ff470000/pipe@ff478000 failed
Feb 22 01:17:01 localhost kernel: [ 2.617621] phy phy-ff430000.hdmiphy.2: Looking up phy-supply property in node /hdmiphy@ff430000 failed
Feb 22 01:17:01 localhost kernel: [ 2.629739] pwm-regulator vdd-center: lookup for GPIO enable failed
Feb 22 01:17:01 localhost kernel: [ 2.629797] pwm-regulator vdd-center: Looking up pwm-supply property in node /vdd-center failed
Feb 22 01:17:01 localhost kernel: [ 2.630151] pwm-regulator vdd-center: Looking up pwm-supply property in node /vdd-center failed
Feb 22 01:17:01 localhost kernel: [ 2.630279] pwm-regulator vdd-center: Looking up pwm-supply property in node /vdd-center failed
Feb 22 01:17:01 localhost kernel: [ 2.640619] i2c i2c-4: of_i2c: modalias failure on /hdmi@ff3c0000/ports
Feb 22 01:17:01 localhost kernel: [ 2.646223] rockchip-drm display-subsystem: failed to parse display resources
Feb 22 01:17:01 localhost kernel: [ 3.335928] pwm-regulator vdd-center: Looking up pwm-supply property in node /vdd-center failed
Feb 22 01:17:01 localhost kernel: [ 3.344260] pwm-regulator vdd-center: Looking up pwm-supply property in node /vdd-center failed
Feb 22 01:17:01 localhost kernel: [ 3.344523] pwm-regulator vdd-center: Looking up pwm-supply property in node /vdd-center failed
Feb 22 01:17:01 localhost kernel: [ 3.378583] dwmmc_rockchip ff520000.dwmmc: Looking up vmmc-supply property in node /dwmmc@ff520000 failed
Feb 22 01:17:01 localhost kernel: [ 3.378606] dwmmc_rockchip ff520000.dwmmc: Looking up vqmmc-supply property in node /dwmmc@ff520000 failed
Feb 22 01:17:01 localhost kernel: [ 3.386615] dwmmc_rockchip ff520000.dwmmc: lookup for GPIO wp failed
Feb 22 01:17:05 localhost kernel: [ 10.497107] [drm:dw_hdmi_rockchip_set_property] *ERROR* failed to set rockchip hdmi connector property
Feb 22 01:17:05 localhost kernel: [ 10.497157] [drm:dw_hdmi_rockchip_set_property] *ERROR* failed to set rockchip hdmi connector property
Feb 22 01:17:05 localhost kernel: [ 10.497175] [drm:dw_hdmi_rockchip_set_property] *ERROR* failed to set rockchip hdmi connector property
Feb 22 01:17:05 localhost kernel: [ 10.497189] [drm:dw_hdmi_rockchip_set_property] *ERROR* failed to set rockchip hdmi connector property
Feb 22 01:17:05 localhost kernel: [ 10.497204] [drm:dw_hdmi_rockchip_set_property] *ERROR* failed to set rockchip hdmi connector property
Feb 22 01:17:05 localhost kernel: [ 10.497220] [drm:dw_hdmi_rockchip_set_property] *ERROR* failed to set rockchip hdmi connector property
Feb 23 15:43:06 localhost kernel: [ 4.987298] rockchip-drm display-subsystem: failed to bind ff3c0000.hdmi (ops dw_hdmi_rockchip_ops): -517
Feb 23 15:43:06 localhost kernel: [ 4.988426] rockchip-drm display-subsystem: master bind failed: -517
Feb 25 05:17:01 localhost kernel: [ 4.986126] rockchip-drm display-subsystem: failed to bind ff3c0000.hdmi (ops dw_hdmi_rockchip_ops): -517
Feb 25 05:17:01 localhost kernel: [ 4.987164] rockchip-drm display-subsystem: master bind failed: -517
MiltonLai
commented
2 years ago 学习阅读了本repo的源码，了解到固件是对rock64的固件稍加定制形成的，于是尝试发布新版本。
因为armbian的新包发布格式略有更改，本人fork后做了一点针对性的修改，然后用travis-ci发布了5.10内核的新版本固件，需要的请尝试下并反馈： Releases · qijianjun/build-beikeyun
Armbian_21.02.1_beikeyun_buster_current_5.10.12.img.xz | 379 MB | 基于debian Armbian_21.02.1_beikeyun_focal_current_5.10.12.img.xz | 275 MB | 基于ubuntu Armbian_21.02.1_beikeyun_focal_legacy_4.4.213.img.xz | 238 MB | 基于ubuntu，旧版内核
请问这几个镜像怎么安装?
用AndroidTool2.58, 刷这个项目下发布的 Armbian_5.90_beikeyun_Ubuntu_bionic_default_4.4.182.img.xz 这些可以正常启动, 但是同样的方法刷上面的那几个5.10.12的无法启动.
void285
commented
2 years ago 抱歉，上面发布的版本打包时出错了，晚些我重新发布下
MiltonLai
commented
2 years ago 抱歉，上面发布的版本打包时出错了，晚些我重新发布下
哈哈感谢感谢!
robinZhao
commented
2 years ago 这个方法更新内核后无法启动啊
现象是双向都无法ping通，显示目标地址无法到达。
之前安装了小钢炮系统，不久就发现了这个现象，开始时大致三两天出一次问题，后来写了定时脚本，网络中断时记录日志并重启，最近基本几十分钟到几小时就出问题，一直怀疑是内核或以太网驱动有问题，所以安装了armbian。但发现问题依旧，目前装armbian4天了，好的时候大半天才出问题，坏的时候重启了几十分钟就出问题。
尝试过用
ip link set dev eht0 down/up重启端口，但无果，只会导致很长的错误输出，并且系统假死，只能多次ctrl+alt+del重启。 尝试过插拔网线，换上级路由，也无果。 贝壳云接了硬盘插座带了两块硬盘，没有改造过硬件，没有盖盖子，CPU基本稳定在45-52度，应该不是过热的问题。用小钢炮时通过定时脚本记录了一段时间日志，现在armbian出问题后直接在tty查看日志并重启。发现断网时都有
NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 timed out的记录，而此记录前没有明显异常的其它日志。现在对此问题的原因和解决完全没有头绪，希望获得帮助，谢谢。
以下是安装armbian这几天来系统发生错误时间点前后的日志，希望有帮助。