Device: Dell Powerswitch w/ BMC OS10
help:
enter config mode:
enter certain port group:
change port mode:
port 1/1/21 mode Eth 100g-1x
port 1/1/21 mode Eth 25g-4x
show current config:
change MTU of multiple ports
interface range ethernet 1/1/1-1/1/32
mtu 9216
save config:
Large languange model translated English version available below.
0. 引言
SNAP (Smart Network ADC Processor) 是 CASPER 开发的低成本采样装置, 更多信息可见 https://github.com/casper-astro/casper-hardware/blob/master/FPGA_Hosts/SNAP/README.md. 通常情况下需要使用树莓派来驱动 SNAP, 但一些已有的镜像可能无法在新版树莓派上使用, 或可考虑其他单板计算机来控制 SNAP, 本文可为构建过程提供参考.
1. 下载系统
对于树莓派, 可从 https://www.raspberrypi.com/software/ 下载其系统; 类似地其他单板计算机可从制造商处获取.
特别地, 如果已有可在旧版本树莓派中可启动的镜像但该镜像无法在新版树莓派上启动, 可以考虑仅替换引导/固件与内核, 此时请注意原先镜像中的系统是 32 位还是 64 位, 否则可能无法启动.
下载系统后, 按照其教程烧录系统到 SD 卡上.
新版内核可能缩小了 SPI 缓冲区的默认大小, 需要手动扩大.
在 bootfs 分区的 cmdline.txt (即 Linux 内核参数) 中添加
(参考 https://raspberrypi.stackexchange.com/questions/65595)
然后卸载 SD 卡, 装入树莓派并启动.
2. 安装 CASPER 相关软件
2.1 casperfpga
• • • >>
Manual English translation available below.
安装 Vivado 2021.1
- 安装
ncurses-devel, ncurses-compat-libs (RHEL 8 或衍生版本) 或 libncurses5-dev libtinfo-dev libtinfo5 (Ubuntu 20.04) 以安装 libncurses.so & libtinfo.so.5 两个库; 否则安装后的 “list system devices” 卡死无法结束, 可在安装器输出中看到类似 “cannot load libncurses.so.5: no such file or directory”
- 安装 Vivado 2021.1 & Vitis 2021.1
- 注意 2021.1 对应的 Model Composer 可能不支持 RHEL 8.x (检测系统后拒绝启动)
- 获取 Vivado license 放到
~/.Xilinx/Xilinx.lic
安装 Matlab 2021a
- 不要安装 “Matlab Compiler” and “Matlab Compiler SDK” 否则调用 Vivado 时会卡死
解决运行库依赖冲突
- 大部分情况是 Matlab 或 Vivado 的组件 A 依赖运行库 B, 运行库 B 依赖运行库 C, B 由系统提供, Matlab 或 Vivado 试图提供 C 但太老使得 B 无法加载, 故必须使用系统提供的 C’
• • • >>
The most recent version of Wine is named wine-development in Ubuntu 22.04
repository, while in WineHQ repository it is named wine-devel .
This causes problem when installing packages depending on Wine and want the
most recent version, e.g. carla-bridge-wine32.
One workaround is to use a dummy package using “equivs”:
- install equivs
- run
equivs-control wine-devel-fixes
- edit control file, related lines:
Package: wine-devel-fixes
Depends: wine-devel
Provides: wine-development
Description: Fixes the Wine package rename on Ubuntu 22.04
- run
equivs-build wine-devel-fixes
- install the generated
wine-devel-fixes_1.0_all.deb
Reference: workaround ROCm installation on Ubuntu 22.04 (when it didn’t support): https://github.com/ROCm/ROCm/issues/1730#issuecomment-1205109513
It is known that there’s make rpm-pkg -j${nproc} / make deb-pkg -j${nproc} that helps build and package Linux kernel,
but on RHEL-like distros the default package name is still kernel and kernel-devel, causing conflict with existing kernels from repository.
So renaming the output package seems required, and here is one kind of patch:
• • • >>
情况: Git 远程服务器 (例如 GitLab 实例) 位于内网, 需要能从外部访问.
Situation: Git remote server (e.g. GitLab instance) is in private network but need to access from outside.
一种解决方案: 用 ssh 打开隧道, 例如
One solution: open tunnel using ssh, like
Host jumper-machine
# ...
LocalForward 3002 10.1.2.233:80
LocalForward 3003 10.1.2.233:33322
在用 ssh jumper-machine 开启隧道后,
即可使用 http://localhost:3002 访问 Git 远程服务器的网页,
ssh://git@127.0.0.1:3003/<user>/<repo> 可作为 Git 仓库的远程地址.
After opening tunnel using ssh jumper-machine,
use http://localhost:3002 to visit webpage of Git remote server,
use ssh://git@127.0.0.1:3003/<user>/<repo> as Git remote url.
When processing continuous observation of more than 1 day,
an error occurred from DSPSR:
Error::message
epoch 60230.28412758417979894210 not spanned by ChebyModelSet
The error is related to TEMPO2 wrapper T2Predictor, where TEMPO2 complains ChebyModelSet_OutOfRange.
This points to the command line of DSPSR calling TEMPO2, which does have a span of one day:
tempo2 -npsr 1 -f pulsar.par -pred "fast 60229.283869345 60230.283869345 200.006942749023438 350.006942749023438 12 2 3599.9999999999998" > stdout.txt 2> stderr.txt
Further searching shows the time span comes from dspsr/Signal/Pulsar/Fold.C, line 243.
Changed this magic number
diff --git a/Signal/Pulsar/Fold.C b/Signal/Pulsar/Fold.C
index 009c1615..0c5c42f9 100644
--- a/Signal/Pulsar/Fold.C
+++ b/Signal/Pulsar/Fold.C
@@ -262,7 +262,7 @@ dsp::Fold::get_folding_predictor (const Pulsar::Parameters* params,
/*
* Tempo2 predictor code:
*
* Here we make a predictor valid for the next 24 hours
* I consider this to be a bit of a hack, since theoreticaly
* observations could be longer, and it's a bit silly to make
* such a polyco for a 10 min obs.
*
*/
- MJD endtime = time + 86400;
+ MJD endtime = time + 10*86400;
generator->set_site( observation->get_telescope() );
generator->set_parameters( params );
generator->set_time_span( time, endtime );
so folding can be done further.
• • • >>
Translation below.
问题描述
某 2021 年还安装 CentOS 7 的服务器近期时常出现无响应、远程无法连接, 键鼠输入有延迟, 且有内核出错记录:
Aug 11 12:45:31 <machine name> kernel: warn alloc falled: 1380491 callbacks suppressed
Aug 11 12:45:31 <machine name> kernel: swapper/27: page allocation failure: order 0, mode: 0x20
Aug 11 12:45:31 <machine name> kernel: CPU: 27 PID: 0 Comm: swapper/27 Kdump: loaded Tainted: P OE ------------ 3.10.0-1160 62.1.el7.x86 64 #1
Aug 11 12:45:31 <machine name> kernel: Hardware name: <name>
Aug 11 12:45:31 <machine name> kernel: Call Trace:
Aug 11 12:45:31 <machine name> kernel: <IRQ> [<ffffffffbcb865a9>] dump_stack+0x19/0x1b
Aug 11 12:45:31 <machine name> kernel: [<ffffffffbc5c4bd0>] warn alloc failed+0x110/0x180
Aug 11 12:45:31 <machine name> kernel: [<ffffffffbc4d3383>] ? __wake up+0x13/0x20
Aug 11 12:45:31 <machine name> kernel: [<ffffffffbc5c976f>] __alloc_pages_nodemask+0x9df/oxbe0
Aug 11 12:45:31 <machine name> kernel: [<ffffffffbc5c9b78>] page_frag_alloc+0x158/0x170
Aug 11 12:45:31 <machine name> kernel: [<ffffffffbca4808d>] __napi_alloc_skb+0x8d/0xe0
Aug 11 12:45:31 <machine name> kernel: [<ffffffffc03df895>] mlx5e_skb_from_cqe_mpwrq_nonlinear+0x65/0x2f0 [mlx5_core]
Aug 11 12:45:31 <machine name> kernel: [<ffffffffc03dfdbf>] mlx5e_handle_rx_cqe_mpwrq+0xbf/0x8c0 [mlx5_core]
Aug 11 12:45:31 <machine name> kernel: swapper/57: page allocation failure: order 0, mode: 0x20
Aug 11 12:45:31 <machine name> kernel: CPU: 57 PID: 0 Comm: swapper/57 Kdump: loaded Tainted: P OE ------------ 3.10.0-1160 62.1.el7.x86 64 #1
Aug 11 12:45:31 <machine name> kernel: Hardware name: <name>
Aug 11 12:45:31 <machine name> kernel: Call Trace:
Aug 11 12:45:31 <machine name> kernel: <IRQ> [<ffffffffbcb865a9>] dump_stack+0x19/0x1b
Aug 11 12:45:31 <machine name> kernel: [<ffffffffc03e14be>] mlx5e_napi_poll+0xbe/0xd10 [mlx5_core]
Aug 11 12:45:31 <machine name> kernel: [<ffffffffbc78da24>] ? __radix_tree_lookup+0x84/0xf0
......
重启后可恢复一段时间, 但数小时到数天后仍会卡死.
问题排查
• • • >>
When testing SYCL programs on some backend based on Clang 14, it is noticed that the gdb-9 bundled with Ubuntu 20.04 cannot correctly read debug info of binary produced by clang-14, then stack info is not available at all.
Although haven’t figured out why, compiling & installing a gdb-13 simply fixes this problem.
NOTE: tested with vendor-specific compiler based on clang-14, not sure if applicable to vanilla Clang.