Liyue Zhang

同样的问题，参照issue #61 的方法做了，并没有什么作用，不知道他的.eeprom.bin和sku.dat到底是怎么弄的

1、查看factory分区 ``` root@OpenWrt:~# cat /proc/mtd dev: size erasesize name mtd0: 00030000 00010000 "u-boot" mtd1: 00010000 00010000 "u-boot-env" mtd2: 00010000 00010000 "factory" ``` 2、把factory信息dd到eeprom.bin ``` root@OpenWrt:~# dd if=/dev/mtd2 of=/lib/firmware/mt7615.eeprom.bin 128+0 records...

@Iy204 按照您说的方法做了，在`modprobe mt7615`之后用`ifconfig -a`查看mac还是00，接着运行`mtkwifi reload`直接系统崩溃重启。 我试过编译了两个内核版本(4.14.34和4.14.44)的openwrt，都不能正确显示mac地址，不知道您的系统和内核版本，我现在怀疑有可能是编译选项的问题。 如果可以的话，能提供您的编译配置`.config`文件或者固件吗？ 另外就是在modprobe加载驱动后，也没有看到rax0接口，只有ra0。感觉还是eeprom没有正确被驱动读取，但是已经按照上面的路径和命名导出了，就很迷。 内核崩溃信息记录 modprobe mt7615 ``` [ 58.670939] mt7615: module license 'Proprietary' taints kernel. [ 58.682757] Disabling lock debugging due to kernel taint [...

@Iy204 非常感谢您提供的信息。 使用您提供的配置后就能正确挂载mt7615驱动，mac也是对的，wifi也能用。 我这里wan-rax0测速只跑到120Mbps左右。在测试lan-rax0的时候，只要出现大流量（比如速度超过300Mbps），就会导致wifi与br-lan的桥接完全断开的情况（即设备还能连上wifi，但是无法ping通路由器）。然而此时并未触发内核错误。 之后，差不多20分钟后，再查看dmesg，就出现`-ash: can't fork: Out of memory`。在这之后的约5分钟，最终路由器完全卡死宕机，外网中断，但依然能ping通路由器。 看上去是内存泄漏了。详细测试见后文。我的系统内核版本是4.14.44，用openwrt最新master代码（r7093-4fdc6ca）编译。使用对应内核版本的mt7615驱动。多次测试发现，该现象多发生在空闲时突然发起高速率（大于300Mbps）wifi数据传输的时候。 此外，我尝试复现该错误，用连接lan口的设备从连接wifi的设备上下载数据，峰值速度超过了300Mbps，持续了十多秒，之后路由器瞬间卡死，ssh断开，跟wifi设备的连接断开，出现上面描述的最终路由器卡死宕机的情况。 再次尝试复现错误，此次使用两台连接wifi的设备传输文件，全程速度在60Mbps左右，此时没有出现因内存占满导致宕机，但是中途出现了内存占满的报错。使用free -h不断查看，会发现在开始连接之后内存一直上涨（此时速度在120Mbps左右），直到第一次内存用光报错出现后，传输速度降到60Mbps以内，之后内存占用率维持在80%以上（100MB/128MB），时不时出现内存占满的报错，但因为传输速度掉下去了，所以并没有整个宕机。 紧接着，跟前两次一样用lan口设备下载wifi设备的文件，此次高速度维持了很久，监控内存使用量从空闲时的40MB增加到了70MB左右并一直稳定在80MB/128MB左右。之后，突然又出现上面的连接断开的情况，不过这次直接导致路由崩溃重启了。 之后继续复现，基本跟上述一样，小流量可以使用wifi，大流量直接导致wifi断开，路由器宕机。在200Mbps左右的情况下，占用内存达到90MB/128Mb，一旦速度超过300M会导致内存占满，速度立刻降到200以内甚至100Mbps，如果此时没有降速，那么大概率路由器宕机。 wan-lan测速是正常，速度在900Mbps左右，同时不会导致内存占用增加，只有使用wifi的时候会导致大量内存占用，最终因长时间爆内存导致整个系统崩溃，路由宕机。 但是，最后一次测试中，反复大流量wifi传输（保持500Mbps传完10GB，测试多次），没有出现内存占用增加的情况。但在这几次传输之前的测试中，出现过短暂内存占满的情况，但因传输速度降低，内存占用马上就降下来，没有导致系统崩溃。也正是在此之后，即便大流量传输也没有出现过内存占满的情况。不过等路由器空闲半小时之后，进行同样的传输测试，但在几秒后路由直接崩溃重启。 总的来说，应该是驱动导致内存泄漏了，并且这个现象（内存占满导致wifi断开，路由卡死宕机）只会发生在瞬时流量激增的情况下。如果长时间进行低速率200Mbps以内的传输，则内存泄漏现象会自动消除（根据我的观察从之前90MB/128MB占用降到60MB/128MB并稳定下来），这是即便再进行大流量传输也不会导致内存占用过多。 @Nossiac 出错和测试记录如上，抱歉描述有点长，不知道是驱动和系统不兼容还是什么情况导致的。毕竟很玄学的地方是如果进行一段时间低速率“预热”，则不会出现上述错误。 我的K2P系统内核版本是4.14.44，用openwrt最新master代码（r7093-4fdc6ca）编译。使用mt7621对应内核版本4.14.44的mt7615驱动。 相关内核信息如下： 第一次崩溃前的信息： ``` [ 890.281945] Rcv Wcid(1) AddBAReq...

@Nossiac 十分感谢您抽空来分析这个问题。 如果是应用层导致的话，我这边先测试下不同配置选项编译的固件。有可能是编译的模块和额外组件导致的问题（issue #67 中有提到）。另外毕竟之前我自己勾选的配置编译出来的固件也是不能正确使用驱动加载出mac地址的。

现在长时间使用也会出现无线断开的问题，具体表现是搜得到SSID，但尝试连接被拒绝。 内核报错如下： ``` [71145.844853] RtmpPCIMgmtKickOut: Not available element in FastPathTxFreeQue [71145.958771] RtmpPCIMgmtKickOut: Not available element in FastPathTxFreeQue [71146.119559] RtmpPCIMgmtKickOut: Not available element in FastPathTxFreeQue ``` 搜索后发现潘多拉固件也是无线有问题并且也是该报错。。。 （看上去是跟fastpath软件加速冲突了。。。）

关于tracing和metrics，配置项collector_url只有一个，url填到tempo之后似乎查不到metrics信息了  在用tempo收集trace的时候，怎么才能同时拿到https://github.com/darkyzhou/seele/blob/main/docs/public/grafana.png 这样的metrics呢？

三个问题的示例，这里用plain提交了，原始代码为： ``` #include using namespace std; int main() { cout

另外根据tracing结果来看，耗时长的（已经去除本身死循环那些代码）,主要长在event: { "value": "Bound the runj container to cpu 338", "key": "message" }  不过不知道这里算上了等待时间吗？如果并发太大，等待时间被算进去的话倒是合理

非常感谢建议。 我在试用k8s先拉起多个kata容器，然后在kata容器里面跑seele。不过使用kata(或者虚拟机)，导致系统要开虚拟化，要弹性扩容得其他机器都开虚拟化，对我们现阶段架构不是很友好。但隔离kernel的方案目前除了虚拟机和kata container我想不到什么其他更好的了。 更进一步讨论：如果使用kata的话，是不是可以把底层runj改成用kata了，相对于设置namespace带来的问题，kata只有启动阶段固定的秒级别的开销，其他时候安全性也更高(攻击要同时击穿低权限限制和虚拟化限制），启动评测线程也变成调用k8s api启动kata container，这样seele自身要求的权限就变低了。不过问题是要求整个k8s支持kata架构，而云上大概率会面临嵌套虚拟化的问题，裸金属又会面临要不要开虚拟化的问题