6678第二个网口不稳定问题

在光电切换过程中，请注意观察，是否有SGMII_STATUS的AN_ERROR bit 为1的情况发生？

您是说这个AN_ERROR如果被置起，过一会儿就会变低吗？

我之前观察过，出问题时，这个位并未变高。

另外，我又注意到，出问题时看cpsw的计数器：

每次dsp发包时，02090b00（即cpsw port0的收包计数器）能正常计数，

但02090c34（即cpsw port1的发包计数器）停止不动了。

这个应该理解为cpsw收到了dsp core发来的报文，但没有正常的从1口发出，

难道cpsw出问题了？

在出问题时，SGMII的寄存器看了一下，没有什么异常。

我说的是过程中观察，不是已经发生问题后观察，请注意，如果此bit出现为1，就算后来恢复为0，TI是不保证其正常运行的。换句话，只要此bit出现过为1的情况，发包是可能随机出现问题的，必须要在PHY端采取规避的配置。

刚写了个小程序，循环查询这个AN_ERROR是否被置起，
如有置起则打印提示。
当出现问题时，这个位始终没有被置起过。

1.我假设你查对了SGMII STATUS寄存器，因为两个口分别对应不同的状态寄存器，那么在光电转换中SGMII STATUS是否有变化？是如何变化的？MR_LP_ADV_ABILITY寄存器是否有变化，是如何变化的？

2. 在出问题后，MAC status寄存器的最高比特idle是否一直为0？

3.在往外发包的同时请再检查CPSW STATB统计，看是否有其他的值在增加？比如TXCARRIERSENSEERRORS? 如果确定没有任何异常计数器增加，能否增大发送的数据量（>68KB）,看看此时队列No.648是否有包拥塞？

感谢Marvin非常详细的指导！

Marvin Liang 说：

1.我假设你查对了SGMII STATUS寄存器，因为两个口分别对应不同的状态寄存器，那么在光电转换中SGMII STATUS是否有变化？是如何变化的？MR_LP_ADV_ABILITY寄存器是否有变化，是如何变化的？

我应该查对了寄存器，因为在监测AN_ERROR的同时，我也监测了相同寄存器的另外一位：link up，发现在切换时，表示link down的语句

不停打印出来。我的光口是1000兆，电口接100兆，表示link partner状态的寄存器MR_LP_ADV_ABILITY在每次切换后均能正常反应当前的速度。

2. 在出问题后，MAC status寄存器的最高比特idle是否一直为0？

这个没注意查看，有板子的时候我会核对一下。不过我想应该为0，因为从这个口还是能收到报文，只是发不出去。

3.在往外发包的同时请再检查CPSW STATB统计，看是否有其他的值在增加？比如TXCARRIERSENSEERRORS? 如果确定没有任何异常计数器增加，能否增大发送的数据量（>68KB）,看看此时队列No.648是否有包拥塞？

关于统计的其他寄存器我基本都看过（希望没有遗漏），表示错误的寄存器都为0。648队列应该没有问题，因为cpsw的port 0逻辑上是在648的后面，

接收648的输出，如果648出了问题，port 0的接收计数器在出错的时候就不会增加了，而我观察到这种情况下这个寄存器还在正常地递增。我也查看了

648里面有没有描述符，事实上没有。

首先对Marvin的耐心指导表示感谢！

Marvin Liang 说：

1.我假设你查对了SGMII STATUS寄存器，因为两个口分别对应不同的状态寄存器，那么在光电转换中SGMII STATUS是否有变化？是如何变化的？MR_LP_ADV_ABILITY寄存器是否有变化，是如何变���的？

STATUS寄存器应该查对了位置，因为我也查询了相同寄存器的另外一位：表示链接是否建立的bit0，

当进行切换时，表示这一位变化的打印语句执行了。

我的光口接的是1000兆，电口接的是100兆，在切换时，无论正常与否，MR_LP_ADV_ABILITY均能

反映当前链接的速度。

2. 在出问题后，MAC status寄存器的最高比特idle是否一直为0？

这个没看，不过应该是0，因为出问题时，dsp还能收到报文，只是报文发不出去了。

我会再查询一下这一位，看它有没有变高过。

3.在往外发包的同时请再检查CPSW STATB统计，看是否有其他的值在增加？比如TXCARRIERSENSEERRORS? 如果确定没有任何异常计数器增加，能否增大发送的数据量（>68KB）,看看此时队列No.648是否有包拥塞？

其他统计寄存器我基本都看过，均为0。

Q648应该没问题，dsp发包时，从报文数据的流向看，cpsw出在q648的后方，如果q648出现问题，

cpsw的port 0的接收计数器不会正常增长，比如dsp core发3个包，这个计数器就会增加3个。

   希望你再仔细的查询一下我列出的寄存器，确认其值到底是多少。

   “如果确定没有任何异常计数器增加，能否增大发送的数据量（>68KB）,看看此时队列No.648是否有包拥塞？”，请仔细看看，我的意思不是说648出了问题，我让你做这个测试是想确认 包确实没有发出去，还在CPSW Tx FIFO里，因为你发包少，所以只看到了计数器没有增长。如果你发包多，总数据量超过68KB, Tx FIFO应该满，同时反压到648,能看到648有包拥挤。这样才能证明是包挤压在Tx FIFO而没发出去，而不是其他原因如ALE交换问题等。

   因为你光电转化的时候有1000M->100M的切换和重协商过程，很多PHY会协商1000M半双工，在这样的情况下，EMAC可能会出现随机的发送问题。附件是一个规避办法供你参考。

  另，我们也曾遇到某些情况，MAC idle状态一直是0导致无法发送，问题在PHY一侧,你可以通过MIDO reset PHY试试。

hi, Marvin:

我在网口出问题之后（ping不通），又另外ping了一个负载为65k的大包，这时查看

02090b8c寄存器（RXDMAOVERRUNS），发现这个寄存器值非0，看了这个寄存器的

解释，似乎也没什么启发。

另外，还有一个现象：有时网口出问题时，接收方向似乎也有问题。我的接收free队列为q919，

收到包后放到q720，qdsp里的固件查看q720，并将q720的描述符pop出来，发中断core处理，

当出问题时，发现q720里面有描述符，但core却没有收到中断，很快q919队列里的描述符就

消耗尽了。这种现象也只在网口切换时发生。

1.在你的网口切换过程中，你是否有对以太网系统进行重新初始化呢？比如reset MAC, SGMII?
2.目前看来收发都可能出问题，那么请在切换后重新初始化以太网子系统，步骤如下（参考附件）：
A. close_emac
B.  ALE disable 如果你后面会设置ALE_bypass
C.   open_emac
D.  ALE bypass

网口出问题后，我软件上复位了整个系统，发现问题依旧，只有掉电才能恢复正常。

另外发现MACSTATUS寄存器的IDLE位在出问题后一直为0，应该表示MAC一直在忙。

怀疑是外接的phy有问题，在硬件上又单独复位了phy，问题依旧。

请教Marvin，什么情况下MAC一直在忙乎，能单独复位MAC吗？