Binding to CPU1 during an iperf test on the C3338 causes a kernel crash

[shijun]

Here's the translation:

---

I conducted a series of iperf experiments using the C3338 CPU as follows:

**iperf server:**
```
iperf -s
```

**iperf client:**
```
iperf -c 10.17.131.188 -t 99999999 -i 10
```

In these experiments, the C3338 was used as the iperf server. Two different tests were performed:

1. **iperf -s bound to CPU1** resulted in a kernel crash.
2. **iperf -s bound to CPU0** did not result in a kernel crash.

In experiment 2, the crash occurred 100% of the time, with the crash occurring within a few minutes to several hours.

The Linux kernel version used is: 4.4.116.

The error logs are as follows:

---
[ 1482.032999] ixgbe 0000:07:00.0: registered PHC device on eth3
[ 1482.123830] IPv6: ADDRCONF(NETDEV_UP): eth3: link is not ready
[ 1485.934067] ixgbe 0000:07:00.0 eth3: NIC Link is Up 1 Gbps, Flow Control: RX/TX
[ 1485.934638] IPv6: ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready
[ 2578.648691] perf interrupt took too long (2514 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[ 4544.227828] perf interrupt took too long (5001 > 5000), lowering kernel.perf_event_max_sample_rate to 25000
[ 6145.075937] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[ 6145.098771] BUG: unable to handle kernel paging request at ffff88017558fb00
[ 6145.120900] IP: [<ffff88017558fb00>] 0xffff88017558fb00
[ 6145.137386] PGD 2204067 PUD 179e0a063 PMD 1754e0063 PTE 800000017558f063
[ 6145.159584] Oops: 0011 [#1] SMP
[ 6145.170509] Modules linked in: x86_pkg_temp_thermal coretemp kvm_intel kvm irqbypass shpchp ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 overlay isofs jfs xfs libcrc32c reiserfs hid_cp2112 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ixgbe aesni_intel vxlan aes_x86_64 lrw gf128mul glue_helper ablk_helper igb dca cryptd ip6_udp_tunnel sdhci_pci udp_tunnel usbhid ptp sdhci hid pps_core i2c_algo_bit fjes
[ 6145.319678] CPU: 1 PID: 1779 Comm: iperf Not tainted 4.4.116 #1
[ 6145.337815] Hardware name: EmbedWay_Technology_Inc COMe_C3000/CMC2100A1, BIOS LEK6.18.12.26.100 07/25/2017
[ 6145.367154] task: ffff8800758c6900 ti: ffff88017558c000 task.ti: ffff88017558c000
[ 6145.389979] RIP: 0010:[<ffff88017558fb00>] [<ffff88017558fb00>] 0xffff88017558fb00
[ 6145.413753] RSP: 0018:ffff88017558fa98 EFLAGS: 00010002
[ 6145.430070] RAX: 0000000000000002 RBX: ffffffff810b5864 RCX: 0000000000005b9d
[ 6145.451858] RDX: 0000013a94b465bb RSI: ffff88017793f800 RDI: ffff880179760800
[ 6145.473655] RBP: ffff880000060000 R08: 0000000000000081 R09: 0000000000000000
[ 6145.495450] R10: ffff880000060000 R11: 0000000000005800 R12: ffff880075846800
[ 6145.517234] R13: ffff880075846800 R14: 0000000000000001 R15: 00000596c31106e9
[ 6145.539032] FS: 00007f55c78eb700(0000) GS:ffff88017b240000(0000) knlGS:0000000000000000
[ 6145.563698] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6145.581322] CR2: ffff88017558fb00 CR3: 000000017566c000 CR4: 0000000000340670
[ 6145.603108] Stack:
[ 6145.609538] ffffffff810b771b 0000000000000000 ffff88017558fae8 ffffffff81741707
[ 6145.633820] 0000000000000001 ffffffff81ef2c80 ffff880177a28780 ffff880177a28780
[ 6145.658103] ffff880075846800 0000000000000001 0000000000000001 ffff880000060000
[ 6145.682388] Call Trace:
[ 6145.690118] [<ffffffff810b771b>] ? dequeue_entity+0x41b/0xa80
[ 6145.708007] [<ffffffff81741707>] ? ip_finish_output+0x137/0x1f0
[ 6145.726418] [<ffffffff810b7ddd>] ? dequeue_task_fair+0x5d/0x8b0
[ 6145.744830] [<ffffffff81021079>] ? sched_clock+0x9/0x10
[ 6145.761156] [<ffffffff810b202f>] ? sched_clock_cpu+0x8f/0xa0
[ 6145.778786] [<ffffffff810ab767>] ? deactivate_task+0x87/0xb0
[ 6145.796418] [<ffffffff818041ff>] ? __schedule+0xef/0x7f0
[ 6145.813004] [<ffffffff81804935>] ? schedule+0x35/0x80
[ 6145.828812] [<ffffffff81807ac6>] ? schedule_timeout+0x1b6/0x270
[ 6145.847224] [<ffffffff816e975b>] ? skb_release_data+0xcb/0xe0
[ 6145.865114] [<ffffffff816e8a59>] ? kfree_skbmem+0x59/0x60
[ 6145.881964] [<ffffffff818085de>] ? _raw_spin_unlock_bh+0x1e/0x20
[ 6145.900636] [<ffffffff816e5ac7>] ? sk_wait_data+0x107/0x120
[ 6145.918005] [<ffffffff810c4740>] ? wake_atomic_t_function+0x60/0x60
[ 6145.937459] [<ffffffff8174a939>] ? tcp_recvmsg+0x2e9/0xbe0
[ 6145.954569] [<ffffffff81779464>] ? inet_recvmsg+0x84/0xb0
[ 6145.971417] [<ffffffff816e11a1>] ? sock_recvmsg+0x41/0x50
[ 6145.988265] [<ffffffff816e13fb>] ? SYSC_recvfrom+0xeb/0x170

[Diego_INTEL · Accepted solution]

Hello @shijun,

Thank you for contacting Intel Embedded Community.

The recommended kernel version for Denverton processors is at least 4.14. 

I think it may be best to test with a newer kernel version.

Best regards,

@Diego_INTEL 

[shijun]

hello @Diego_INTEL

Thank you very much for your support.

If it's convenient, could you please explain why the minimum required kernel version is 4.14? Are there any critical features introduced in 4.14?

Our company has many C3338 CPUs running on the 4.4.116 kernel, but only very a few of them have experienced the issues mentioned earlier.

[Diego_INTEL]

Hello @shijun,

We use for reference the document #350329. There it is mentioned, the minimum kernel version is 4.14 for Denverton, could it be that there is better compatibility with Intel drivers, but I don't have any details that I can share.

Best regards,

@Diego_INTEL