最近碰到棘手的问题: 以太网进行iperf测试时, 发生了SMMU (System Memory Management Unit)访问异常导致内核崩溃. 原本只是内部测试发现, 后面在试验车上也概率性的出现. 问题发生的概率还不小. 很严重. 只能先从头把一些基本概念与流程梳理清楚. 好在最后还是找到了原因并解决了. 松了口气, 才有时间把整个问题的来龙去脉细细的总结下, 算是一个SMMU相关问题的案例.
首先来看看问题的发生的背景.
问题发生在利用iperf做网络性能测试的时候, 测试系统(采用高通8155平台, 内置一个EMAC芯片, 最高支持1Gbps速率)作为客户端:
1 |
|
这里加-R参数表示客户端作为数据接收方(奇怪的是, 测试不加-R参数就不会有问题, 这也说明只有在接收数据的过程才会出现问题), 而服务端是发送方:
1 |
|
这么测试几十个小时就很快出现了, 抓取到的问题堆栈如下. 前面的日志是SMMU相关的寄存器状态打印, 后面是内核调用堆栈.
之前帮着解决了项目中WIFI相关的问题, 一直想梳理下WIFI的框架, 方便后续代码阅读以及问题的解决. 恰好年初修改了车机上WIFI热点相关的一些代码, 重新看了下Android 10(Q)的逻辑, 于是想通过WIFI热点相关的功能作为切入点, 完整的梳理下Android WIFI的整体框架.
先不多说, 看下Android WIFI的大致框架:
最近抽空学习下Linux网络协议栈, 读源码时总会前一天梳理完, 等两天再来看却发现又忘记的差不多, 只能再过一遍, 没有对协议栈构建一个系统性的框架. 于是想着要把看过的代码逻辑整理下来, 算是对这段时间学习的总结, 也方便后面的查阅.
在之前的一篇有关网络协议的文章从NAPI说一说Linux内核数据的接收流程简单的讲到了Linux的数据接收流程, 但主要是集中在数据链路层与设备驱动之间的交互, 并没有涉及到IP网络层以及TCP传输层的逻辑.对于Linux系统来说, TCP数据的传输大致要经历如下几个步骤:
socket并创建相应数据的buffer, 通过send函数发送给服务端DMA进行, 完成后网卡发送中断告知CPU, 此时内核会释放之前分配的buffer这篇文章, 我们着重来看下数据传输中内核部分的流程, 并梳理下Linux协议栈大致的结构与初始化步骤, 主要分为如下两个部分:
这两天隔壁部门的同事反馈说新项目上, 车机(Android系统)上挂载的USB外设(一个可以上网的TBOX设备)无法通过ADB(Android Debug Bridge)进行连接. 心里有点纳闷, USB不都识别到了吗, 上次也把ADB相关的客户端都移植过去了, 为啥还会识别不到设备了? 只得从头开始理下ADB相关的代码与逻辑.先来看看ADB的基本原理.
ADB(全称Android Debug Bridge)是Android上用途十分广泛的调试工具, 可用于与开发设备进行连接;ADB命令既可以用来主机与设备之间传输文件, 也可以通过SHELL命令对设备进行操作. 如下所示, 是ADB的一个工作原理图:
The major problems of our work are not so much technological as sociological in nature
《people-ware:productive projects/teams》
心灵是自己的地方，在那里可以把地狱变成天堂，也可以把天堂变成地狱
约翰-弥尔顿《失乐园》
这次新平台采用了与之前不同的以太网方案， MAC是内置在SoC(System On Chip)上，而PHY采用了Marvell的一款100Mps的车规级的芯片，MAC/PHY的驱动都要重新开发适配，工作难度比之前预想的要大了很多，完成时间比预想的慢了近一个星期。不过，往后看，这种直接与硬件打交道的经验很能锻炼人，在一定程度改善了我对系统的认知与理解。这篇文章重点在梳理总结下车在以太网MAC/PHY遇到的一些问题，以及Linux下MAC/PHY驱动的一些基本流程。
大致分为如下几个部分：
汽车电子的发展伴随着技术迭代而不断进化，汽车网络总线从最开的CAN，CAN-FD,到后来的Flexray, MOST再到LIN，到Ethernet，在市场需求与技术发展双重合力之下，经过了不断的发展积累，到如今已经有进40年的历史。近几年，随着各大汽车公司，尤其是新能源汽车公司如特斯拉/蔚来/小鹏等在自动驾驶领域的大力投入，汽车网络开始向高带宽/低延时的以太网方向发展。在这篇文章我们就来对比看看各种汽车网络总线的工作原理以及使用场景。
CAN最初是由博世(Bosch)于1985年开发出来的车内总线。在这之前，汽车厂商需要通过一条条线将各种汽车控制器连接起来，形成一个个点对点的连接网络。这也导致了增加了汽车本身的重量，增加了系统的复杂度与成本。
CAN作为一个串行总线，具有低成本，轻量化的优势，最高支持1Mb/s的速率，因此迅速被各大厂商采用，并于1993年被定为ISO国际化标准(ISO 11898).
在看Linux内核代码时，经常会遇到各种锁(lock)的使用。对于像spin_lock_irq/spin_lock_irqsave的区别感到困惑，每次都要重新查一下资料。遂决定写一篇文章记录下内核中使用到的锁，以及使用的场景。
与应用中的锁类似，内核中的锁也只是为了保护某个内核数据结构或者内存区域在多个并发执行路径时不被破坏，确保数据的一致性。Linux内核作为应用层服务的提供者，一方面要为应用提供系统调用接口(system call)，代表用户进程执行任务,即process context, 在进程上下文中可以休眠，执行调度;同时与硬件直接交互，要响应硬件中断的请求，处理诸如网卡数据/串口数据等请求，即Interrupt Context，在中断上下文内核不能休眠，无法重新调度. 内核就是在进程上下文/中断上下文直接来回切换，执行相应的任务请求。这就自然产生了数据的并发访问，产生了竞争条件(race condition)。另一方面，目前大多数的系统都是多核CPU、支持多进程，多个CPU、多个进程同时访问内核数据也同样会产生竞争条件。
前阵子在Android下调试一个只有IPv6地址的网络设备时，发现通过ping6来测试网络连通时提示错误：
1 |
|
stackoverflow上有人说这是一个link-local address本地链路地址，
