Forum Discussion
New ContributorArria 10 PCIe Gen 3 stuck at Equalization.Phase3
Hi ChenYang,
In my understanding of PCIe, contrary to MalfTLP, BadTLP is a much more underlayered concept with a only a few reasons to trigger: (1) Link CRC error (2) Sequence Number error. (Refer to PCIe 3.0 Spec, Figure 3-17, Page 185/860)
>> Okay
>> Another that that you could check will be- Do you check if your endpoint has received the 8 required consecutive TS2's ?
- But before it is able to complete sending 16 TS2s, the downstream port sends EIEOS and then starts sending TS1 ?
- Based on my experience, once it meet sending 16 TS2, it shall transition to Recovery.idle since the requirement for that transition are meet >>Recovery.equilization phase X >> L0.
Regards,
Wincent_Altera
New ContributorHi Wincent,
Nice to meet you again. Sorry for delay these days.
I realize that I misread the LTSSM signal. It stucks at 0x0D, which is Recovery.Rcvconfig. What we are trying to do is to implement an switch on Arria 10, with a NVMe device as a downstream EP. So we are loading the generic linux nvme driver. The Gen 3 link has established for some time. But soon it drops to Recovery.Rcvconfig during initialization of the driver. And for most of the time, I saw "BadTLP+" on the AER capability of the root port the FPGA is connected to, and sometimes the host even hangs with Machine Check. We tried to disable ECRC generation/forwarding and it didn't help.
In my understanding of PCIe, contrary to MalfTLP, BadTLP is a much more underlayered concept with a only a few reasons to trigger: (1) Link CRC error (2) Sequence Number error. (Refer to PCIe 3.0 Spec, Figure 3-17, Page 185/860)
My question is that, how can I move forward to debug this error?
One thing I just realize I may not handled well is the middle of TLP requirements on tx_st_valid signal, which generally requires a TLP to be transfered on TX AVST as a whole. I will look through it and come back with my findings.
Wincent_AlteraRegular Contributor
Hi ChenYang,
In my understanding of PCIe, contrary to MalfTLP, BadTLP is a much more underlayered concept with a only a few reasons to trigger: (1) Link CRC error (2) Sequence Number error. (Refer to PCIe 3.0 Spec, Figure 3-17, Page 185/860)
>> Okay
>> Another that that you could check will be- Do you check if your endpoint has received the 8 required consecutive TS2's ?
- But before it is able to complete sending 16 TS2s, the downstream port sends EIEOS and then starts sending TS1 ?
- Based on my experience, once it meet sending 16 TS2, it shall transition to Recovery.idle since the requirement for that transition are meet >>Recovery.equilization phase X >> L0.
Regards,
Wincent_Altera
