10G ethernet for jetson tx1 using pci-e x4

Hi

we have tegra tx1 cluster and like to update its network connectivity using PEX10000SFP networks card, link:

We got the latest jetpack (2.2.1) installed on our boards and compiled the driver and make them to work; however, they fail under heavy load. We benchmark them using iperf and after couple of minutes the bandwidth goes to zero, its like the bus panics and data movement stops.
I don’t get any stack error otherwise I shared it with you. I am happy to share our logs in case needed but the summary is after couple of minutes network cards fail under load, the bandwidth goes to zero and a reboot make them work again (again failing happens under load though).
I contacted the support for the network cards and they told us they’ve seen this issue only if something is wrong with the motherboards and suggested to test the cards with other motherboards. I’ve tested them with other 64 bit ARM machines we have and they work fine.
I know more information needed to debug the problem but I don’t know what is needed or how to get them.

Before and after failure, check the output of ifconfig and “lspci -vvv” for that card. See if any error information changes from before to after.

Can you please share the logs when ‘iperf is run and bandwidth goes to zereo’ case?
Also, what is the release version here? (like 24.1 / 24.2 etc…)

Also, Can you please share ‘lspci -vvvv’ output before starting iperf?
Does it crash only when iperf client is run on the target or does it crash even with running iperf server also?

Dear Vidas: Im not sure you want release version of what?

here are our server information
lsb_release -a:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04 LTS
Release: 14.04
Codename: trusty

iperf and kernel:
iperf 3.0.7
Linux tegra-node5 3.10.96-tegra #1 SMP PREEMPT Tue May 17 16:29:05 PDT 2016 aarch64 aarch64 aarch64 GNU/Linux

About lspci: I got the lspci -vvv output and there is no difference between before and after.

01:00.0 Ethernet controller: Tehuti Networks Ltd. TN9210 10GBase-T Ethernet Adapter
Subsystem: Tehuti Networks Ltd. Device 3015
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 549
Region 0: Memory at 20000000 (64-bit, prefetchable)
Capabilities:
Kernel driver in use: tn40xx

it only crashes on the client side and here some of the iperf logs:


[ 4] 17.00-18.00 sec 86.9 MBytes 729 Mbits/sec 0 390 KBytes
[ 6] 17.00-18.00 sec 80.3 MBytes 674 Mbits/sec 0 359 KBytes
[ 8] 17.00-18.00 sec 86.9 MBytes 729 Mbits/sec 0 383 KBytes
[ 10] 17.00-18.00 sec 86.5 MBytes 725 Mbits/sec 0 372 KBytes
[ 12] 17.00-18.00 sec 80.7 MBytes 677 Mbits/sec 0 361 KBytes
[ 14] 17.00-18.00 sec 85.0 MBytes 713 Mbits/sec 0 337 KBytes
[ 16] 17.00-18.00 sec 80.7 MBytes 677 Mbits/sec 0 345 KBytes
[ 18] 17.00-18.00 sec 80.6 MBytes 676 Mbits/sec 0 369 KBytes
[ 20] 17.00-18.00 sec 85.1 MBytes 714 Mbits/sec 0 339 KBytes
[ 22] 17.00-18.00 sec 77.7 MBytes 651 Mbits/sec 0 314 KBytes
[SUM] 17.00-18.00 sec 830 MBytes 6.96 Gbits/sec 0


[ 4] 18.00-19.00 sec 86.1 MBytes 722 Mbits/sec 0 390 KBytes
[ 6] 18.00-19.00 sec 79.9 MBytes 670 Mbits/sec 0 359 KBytes
[ 8] 18.00-19.00 sec 86.5 MBytes 725 Mbits/sec 0 383 KBytes
[ 10] 18.00-19.00 sec 86.5 MBytes 725 Mbits/sec 0 372 KBytes
[ 12] 18.00-19.00 sec 80.3 MBytes 674 Mbits/sec 0 361 KBytes
[ 14] 18.00-19.00 sec 84.7 MBytes 711 Mbits/sec 0 337 KBytes
[ 16] 18.00-19.00 sec 80.3 MBytes 674 Mbits/sec 0 345 KBytes
[ 18] 18.00-19.00 sec 80.6 MBytes 676 Mbits/sec 0 369 KBytes
[ 20] 18.00-19.00 sec 84.7 MBytes 711 Mbits/sec 0 339 KBytes
[ 22] 18.00-19.00 sec 77.7 MBytes 651 Mbits/sec 0 314 KBytes
[SUM] 18.00-19.00 sec 827 MBytes 6.94 Gbits/sec 0


[ 4] 19.00-20.00 sec 87.7 MBytes 736 Mbits/sec 0 390 KBytes
[ 6] 19.00-20.00 sec 81.4 MBytes 683 Mbits/sec 0 359 KBytes
[ 8] 19.00-20.00 sec 87.3 MBytes 732 Mbits/sec 0 383 KBytes
[ 10] 19.00-20.00 sec 87.3 MBytes 732 Mbits/sec 0 372 KBytes
[ 12] 19.00-20.00 sec 81.1 MBytes 680 Mbits/sec 0 361 KBytes
[ 14] 19.00-20.00 sec 85.5 MBytes 717 Mbits/sec 0 337 KBytes
[ 16] 19.00-20.00 sec 81.1 MBytes 680 Mbits/sec 0 345 KBytes
[ 18] 19.00-20.00 sec 81.2 MBytes 681 Mbits/sec 0 369 KBytes
[ 20] 19.00-20.00 sec 85.5 MBytes 717 Mbits/sec 0 339 KBytes
[ 22] 19.00-20.00 sec 78.4 MBytes 657 Mbits/sec 0 314 KBytes
[SUM] 19.00-20.00 sec 836 MBytes 7.01 Gbits/sec 0


[ 4] 20.00-21.00 sec 79.6 MBytes 667 Mbits/sec 0 395 KBytes
[ 6] 20.00-21.00 sec 73.6 MBytes 617 Mbits/sec 0 359 KBytes
[ 8] 20.00-21.00 sec 80.0 MBytes 671 Mbits/sec 0 383 KBytes
[ 10] 20.00-21.00 sec 79.6 MBytes 667 Mbits/sec 0 372 KBytes
[ 12] 20.00-21.00 sec 73.9 MBytes 620 Mbits/sec 0 361 KBytes
[ 14] 20.00-21.00 sec 78.2 MBytes 656 Mbits/sec 0 337 KBytes
[ 16] 20.00-21.00 sec 74.4 MBytes 624 Mbits/sec 0 356 KBytes
[ 18] 20.00-21.00 sec 74.0 MBytes 621 Mbits/sec 0 369 KBytes
[ 20] 20.00-21.00 sec 78.1 MBytes 655 Mbits/sec 0 339 KBytes
[ 22] 20.00-21.00 sec 72.0 MBytes 604 Mbits/sec 0 314 KBytes
[SUM] 20.00-21.00 sec 763 MBytes 6.40 Gbits/sec 0


[ 4] 21.00-22.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes
[ 6] 21.00-22.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes
[ 8] 21.00-22.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes
[ 10] 21.00-22.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes
[ 12] 21.00-22.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes
[ 14] 21.00-22.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes
[ 16] 21.00-22.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes
[ 18] 21.00-22.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes
[ 20] 21.00-22.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes
[ 22] 21.00-22.00 sec 0.00 Bytes 0.00 bits/sec 2 1.41 KBytes
[SUM] 21.00-22.00 sec 0.00 Bytes 0.00 bits/sec 20


[ 4] 22.00-23.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 6] 22.00-23.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 8] 22.00-23.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 10] 22.00-23.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 12] 22.00-23.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 14] 22.00-23.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 16] 22.00-23.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 18] 22.00-23.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 20] 22.00-23.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 22] 22.00-23.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[SUM] 22.00-23.00 sec 0.00 Bytes 0.00 bits/sec 10


[ 4] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 6] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 8] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 10] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 12] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 14] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 16] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 18] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 20] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 22] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[SUM] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 0


[ 4] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 6] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 8] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 10] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 12] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 14] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 16] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 18] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 20] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 22] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[SUM] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 10


The odd issue I can see in the resource utilization is the memory:

the memory utilization is high when it crashes and although the iperf process is killed, the memory is not freed by the OS unless after reboot, here is the top results for memory after iperf client crashes:

KiB Mem: 3945328 total, 3553848 used, 391480 free, 31832 buffers

I checked for any zombie process but can’t find one:

#ps aux | grep “defunct”
ubuntu 2464 0.0 0.0 5136 828 pts/6 S+ 22:36 0:00 grep --color=auto defunct

I see this correlation between memory utilization and iperf client, since reboot first it works fine, after some threshold the memory utilization start going up and then when there is no memory left, iperf client fail.
At the beginning I thought it is memory leakage from iperf but after killing the iperf the memory doesn’t get freed unless reboot.

Any idea what’s happening?

Regards
Reza

Release version is the L4T version. Found via:

head -n 1 /etc/nv_tegra_release

Note that lspci will not give full information if you do not use “sudo”. Once you use sudo error and more advanced information can be seen.

The “ifconfig” output would be good to know because it gives error counts from the network stack’s perspective…seeing just TX errors or just RX errors would be a clue…particular error types would also be a clue. No error at all would indicate the issue is outside of the networking (such as applications using the network or drivers only indirectly related to the network card).

here is the release version, I think we are using 24.1

~$ head -n 1 /etc/nv_tegra_release

R24 (release), REVISION: 1.0, GCID: 7164062, BOARD: t210ref, EABI: aarch64, DATE: Tue May 17 23:37:30 UTC 2016

I checked with the root and there is no difference in lspci and in ifconfig I only some dropped packets.

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1578931 errors:0 dropped:491 overruns:0 frame:0
TX packets:924946 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3000
RX bytes:104209580 (104.2 MB) TX bytes:17054679543 (17.0 GB)
Interrupt:37 Memory:20000000-20010000

That’s a big dropped count, but RX has no issue. I guess the next question is figuring out why packets were received but not used prior to buffer requiring drop. You may still want to post the lspci -vvv from after a failure so the error features can be viewed…it would be nice to confirm that packets were received but not consumed, and that the cause is not in the PCIe or that it is in the PCIe. AER listings on lspci -vvv can help with that.

Aside from this what is the nature of anything on the Jetson which is receiving data (versus sending data)?

Here is the lspci with the root after the failure:

00:01.0 PCI bridge: NVIDIA Corporation Device 0fae (rev a1) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: 0000000020000000-00000000200fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity+ SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Subsystem: NVIDIA Corporation Device 0000
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/2 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [60] HyperTransport: MSI Mapping Enable- Fixed-
Mapping Address Base: 00000000fee00000
Capabilities: [80] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag+ RBE+
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <512ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
Slot #0, PowerLimit 0.000W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Off, PwrInd On, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet+ LinkState+
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR+, OBFF Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=30us PortTPowerOnTime=70us
Kernel driver in use: pcieport

01:00.0 Ethernet controller: Tehuti Networks Ltd. TN9210 10GBase-T Ethernet Adapter
Subsystem: Tehuti Networks Ltd. Device 3015
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 549
Region 0: Memory at 20000000 (64-bit, prefetchable)
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 000000017e4d1000 Data: 0000
Capabilities: [78] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 <2us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <512ns, L1 <2us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range A, TimeoutDis+, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Kernel driver in use: tn40xx

Sorry I don’t get what do you mean by this question “Aside from this what is the nature of anything on the Jetson which is receiving data (versus sending data)?”

Can you please try with this patch?

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index b4e5e8d..bbf7e6b 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -2567,7 +2567,8 @@ static dma_addr_t arm_coherent_iommu_map_page(struct device *dev, struct page *p
     * compound page then there's probably a bug somewhere.
     */
    if (page_offset > 0)
-       BUG_ON(page_count(page) == 1);
+       BUG_ON(page_offset > (1 << compound_order(compound_head(page)))
+           - ((page - compound_head(page)) << PAGE_SHIFT));

    dma_addr = __alloc_iova(mapping, len, attrs);
    if (dma_addr == DMA_ERROR_CODE)

I copied the text to a file (“nvidia.patch”) and ran $patch < nvidia.patch here is what I got:

"$patch < nvidia.patch
can’t find file to patch at input line 5
Perhaps you should have used the -p or --strip option?
The text leading up to this was:

|diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
|index b4e5e8d…bbf7e6b 100644
|— a/arch/arm64/mm/dma-mapping.c

+++ b/arch/arm64/mm/dma-mapping.c

File to patch:" (stuck here)

I tried with p (p1 p0) options too, sorry I’m not good with patches, how should I apply this patch? should I be in a specific directory?
also after applying the patch should I repeat the iperf or lspci? what should I expect?

thanks
Reza

Try “patch -p1”…without that it is looking for subdirectories “a” and “b”.
Oops…missed your comment on p1. Depending on where you run the patch from, perhaps p2.

By nature of anything receiving data, I mean what kind of programs are using the data received by the network card? For example, if video, then I’d expect the result of behavior from dropped RX to differ from a program using TCP.

If you are not familiar with patching,
just open the file arch/arm64/mm/dma-mapping.c and go to function arm_coherent_iommu_map_page()
find

BUG_ON(page_count(page) == 1);

and replace with

BUG_ON(page_offset > (1 << compound_order(compound_head(page))) - ((page - compound_head(page)) << PAGE_SHIFT));

Ironically there is no dma-mapping.c on our tegras.

It has to be there. Are you sure you are checking in the correct path?

Never mind. Patch mentioned for dma-mapping.c file is only applicable if SMMU is enabled for PCIe, but it is not enabled in 24.1 release version. So, that patch may not really help.
BTW, Can you please run ‘dmesg -n 7’ (as sudo) before running iperf and post the logs?

it showed nothing either before and after

you mean, even after enabling higher log level using ‘dmesg -n 7’ ?

I ran the sudo dmesg -n 7 and ran iperf nothing changed and the dmesg doesn’t print any information and logs of iperf ifconfig lspci remained the same.