Closed Smithx10 closed 1 year ago
Took a look to see what kind of issues may have been reported in the Linux 5.17 changelogs in regards to nvme_tcp.
Saw a few mentions, and am going to attempt building 5.17.15.
arch@9d46dd2d-1178-ce83-cbc4-d396e4a24060 /v/t/issues ❯❯❯ ls -1
ChangeLog-5.17.1
ChangeLog-5.17.10
ChangeLog-5.17.11
ChangeLog-5.17.12
ChangeLog-5.17.13
ChangeLog-5.17.14
ChangeLog-5.17.15
ChangeLog-5.17.2
ChangeLog-5.17.3
ChangeLog-5.17.4
ChangeLog-5.17.5
ChangeLog-5.17.6
ChangeLog-5.17.7
ChangeLog-5.17.8
ChangeLog-5.17.9
arch@9d46dd2d-1178-ce83-cbc4-d396e4a24060 /v/t/issues ❯❯❯ rg nvme_tcp
ChangeLog-5.17.14
17719: nvme_tcp_setup_ctrl
17721: nvme_tcp_configure_io_queues
ChangeLog-5.17.10
3798: Workqueue: nvme-wq nvme_tcp_reconnect_ctrl_work [nvme_tcp]
3823: nvme_tcp_setup_ctrl+0x337/0x390 [nvme_tcp]
3824: nvme_tcp_reconnect_ctrl_work+0x24/0x40 [nvme_tcp]
ChangeLog-5.17.2
7330: #5: (&queue->send_mutex){+.+.}-{3:3}, at: nvme_tcp_queue_rq+0x33e/0x380 [nvme_tcp]
Had another Panic:
[348899.956155] drbd pvc-e92632a9-b649-4520-878b-b3fe4bbfbd66 ac-1f-6b-a4-df-ee: meta connection shut down by peer.
[348899.967030] drbd pvc-e92632a9-b649-4520-878b-b3fe4bbfbd66 ac-1f-6b-a4-df-ee: Terminating sender thread
[348899.979412] drbd pvc-2ab282a6-a09a-4ebe-9a9a-51a805cd4f7b: Terminating worker thread
[348899.987901] drbd pvc-e92632a9-b649-4520-878b-b3fe4bbfbd66 ac-1f-6b-a4-df-ee: Starting sender thread (from drbd_r_pvc-e926 [1436411])
[348900.032428] BUG: unable to handle page fault for address: 0000000064627274
[348900.040001] #PF: supervisor read access in kernel mode
[348900.045819] #PF: error_code(0x0000) - not-present page
[348900.051624] PGD 1ce44b067 P4D 1ce44b067 PUD 0
[348900.056723] Oops: 0000 [#1] PREEMPT SMP NOPTI
[348900.061719] CPU: 3 PID: 1436411 Comm: drbd_r_pvc-e926 Tainted: P S OE 5.17.9-1.el8.elrepo.x86_64 #1
[348900.072456] Hardware name: Supermicro SYS-1029U-TN10RT/X11DPU, BIOS 3.2 10/16/2019
[348900.080683] RIP: 0010:drbd_free_pages+0x34/0x1f0 [drbd]
[348900.086586] Code: bc fa ff ff 41 56 41 55 4c 8d af b8 fa ff ff 41 54 55 53 48 83 ec 10 85 d2 49 0f 44 c5 48 89 04 24 48 85 f6 0f 84 55 01 00 00 <4c> 8b a7 58 f6 ff ff 49 89 fe 48 89 f3 41 89 d7 48 8b 6e 08 41 81
[348900.106613] RSP: 0018:ffffb03ef9527c88 EFLAGS: 00010286
[348900.112517] RAX: 00000000646276d8 RBX: ffff902d0f5f64b0 RCX: 0000000000000000
[348900.120322] RDX: 0000000000000001 RSI: fffff845c6900ac0 RDI: 0000000064627c1c
[348900.128130] RBP: ffff908eeff73800 R08: ffff902e0366b3e0 R09: ffff902e0366b3e0
[348900.135940] R10: ffff902e0366b3e0 R11: ffff902e0366b3e0 R12: 0000000000000001
[348900.143752] R13: 00000000646276d4 R14: ffff902e0366b35c R15: dead000000000122
[348900.151560] FS: 0000000000000000(0000) GS:ffff908a808c0000(0000) knlGS:0000000000000000
[348900.160326] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[348900.166742] CR2: 0000000064627274 CR3: 00000002624fe001 CR4: 00000000007706e0
[348900.168175] drbd pvc-cc0b63e9-4d96-4f6f-a033-bbcb301a763e ac-1f-6b-a4-df-ee: sock was shut down by peer
[348900.174158] drbd pvc-cc0b63e9-4d96-4f6f-a033-bbcb301a763e ac-1f-6b-a4-df-ee: meta connection shut down by peer.
[348900.174166] drbd pvc-cc0b63e9-4d96-4f6f-a033-bbcb301a763e ac-1f-6b-a4-df-ee: conn( Connected -> NetworkFailure ) peer( Secondary -> Unknown )
[348900.174547] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[348900.174548] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[348900.174549] PKRU: 55555554
[348900.174550] Call Trace:
[348900.174553] <TASK>
[348900.184658] drbd pvc-cc0b63e9-4d96-4f6f-a033-bbcb301a763e ac-1f-6b-a4-df-ee: Terminating sender thread
[348900.195397] __drbd_free_peer_req+0x48/0x120 [drbd]
[348900.209338] drbd pvc-cc0b63e9-4d96-4f6f-a033-bbcb301a763e ac-1f-6b-a4-df-ee: Starting sender thread (from drbd_r_pvc-cc0b [1436388])
[348900.217143] drbd_finish_peer_reqs+0xbc/0x170 [drbd]
[348900.268423] drain_resync_activity+0x7b/0x860 [drbd]
[348900.274052] ? _get_ldev_if_state.part.56+0x100/0x100 [drbd]
[348900.280376] ? wake_up_q+0x49/0x90
[348900.284441] ? __mutex_unlock_slowpath.isra.24+0x91/0x100
[348900.290489] ? _get_ldev_if_state.part.56+0x100/0x100 [drbd]
[348900.296796] conn_disconnect+0x192/0xb20 [drbd]
[348900.301981] ? _get_ldev_if_state.part.56+0x100/0x100 [drbd]
[348900.308295] ? _get_ldev_if_state.part.56+0x100/0x100 [drbd]
[348900.314592] drbd_receiver+0x3b5/0x880 [drbd]
[348900.319583] ? __drbd_next_peer_device_ref+0x1a0/0x1a0 [drbd]
[348900.325951] drbd_thread_setup+0x76/0x1c0 [drbd]
[348900.331197] ? __drbd_next_peer_device_ref+0x1a0/0x1a0 [drbd]
[348900.337571] kthread+0xd7/0x100
[348900.341312] ? kthread_complete_and_exit+0x20/0x20
[348900.346692] ret_from_fork+0x1f/0x30
[348900.350843] </TASK>
[348900.353601] Modules linked in: bcache(E) crc64(E) dm_cache(E) dm_persistent_data(E) dm_bio_prison(E) dm_bufio(E) dm_writecache(E) nvme_rdma(E) nvmet_rdma(E) rdma_cm(E) iw_cm(E) ib_cm(E) ib_core(E) tcp_diag(E) inet_diag(E) ext4(E) mbcache(E) jbd2(E) xt_multiport(E) nft_compat(E) nf_tables(E) nfnetlink(E) 8021q(E) garp(E) mrp(E) stp(E) llc(E) rfkill(E) sunrpc(E) intel_rapl_msr(E) intel_rapl_common(E) skx_edac(E) nfit(E) libnvdimm(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) iTCO_wdt(E) intel_pmc_bxt(E) iTCO_vendor_support(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) rapl(E) intel_cstate(E) ipmi_ssif(E) mei_me(E) intel_uncore(E) pcspkr(E) i2c_i801(E) acpi_ipmi(E) joydev(E) lpc_ich(E) mei(E) i2c_smbus(E) intel_pch_thermal(E) ioatdma(E) ipmi_si(E) acpi_pad(E) acpi_power_meter(E) vfat(E) fat(E) binfmt_misc(E) dm_mod(E) sr_mod(E) cdrom(E) sd_mod(E) sg(E) ast(E) i2c_algo_bit(E) drm_vram_helper(E) drm_kms_helper(E) syscopyarea(E)
[348900.353645] xfs(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) drm_ttm_helper(E) ttm(E) ahci(E) libahci(E) uas(E) drm(E) ixgbe(E) libata(E) mdio(E) usb_storage(E) dca(E) wmi(E) zfs(POE) zunicode(POE) zzstd(OE) zlua(OE) zavl(POE) icp(POE) zcommon(POE) znvpair(POE) spl(OE) nvmet_tcp(E) nvmet(E) nvme_tcp(E) nvme_fabrics(E) nvme(E) nvme_core(E) t10_pi(E) ipmi_devintf(E) ipmi_msghandler(E) drbd_transport_tcp(OE) drbd(OE) libcrc32c(E) crc32c_intel(E)
[348900.486652] CR2: 0000000064627274
[348900.490644] ---[ end trace 0000000000000000 ]---
[348900.527685] RIP: 0010:drbd_free_pages+0x34/0x1f0 [drbd]
[348900.533597] Code: bc fa ff ff 41 56 41 55 4c 8d af b8 fa ff ff 41 54 55 53 48 83 ec 10 85 d2 49 0f 44 c5 48 89 04 24 48 85 f6 0f 84 55 01 00 00 <4c> 8b a7 58 f6 ff ff 49 89 fe 48 89 f3 41 89 d7 48 8b 6e 08 41 81
[348900.553631] RSP: 0018:ffffb03ef9527c88 EFLAGS: 00010286
[348900.559532] RAX: 00000000646276d8 RBX: ffff902d0f5f64b0 RCX: 0000000000000000
[348900.567349] RDX: 0000000000000001 RSI: fffff845c6900ac0 RDI: 0000000064627c1c
[348900.575164] RBP: ffff908eeff73800 R08: ffff902e0366b3e0 R09: ffff902e0366b3e0
[348900.582972] R10: ffff902e0366b3e0 R11: ffff902e0366b3e0 R12: 0000000000000001
[348900.590773] R13: 00000000646276d4 R14: ffff902e0366b35c R15: dead000000000122
[348900.598581] FS: 0000000000000000(0000) GS:ffff908a808c0000(0000) knlGS:0000000000000000
[348900.607347] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[348900.613771] CR2: 0000000064627274 CR3: 00000002624fe001 CR4: 00000000007706e0
[348900.621597] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[348900.629411] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[348900.637211] PKRU: 55555554
[348900.640578] Kernel panic - not syncing: Fatal exception
[348900.646488] Kernel Offset: 0x1ce00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[348900.677714] ---[ end Kernel panic - not syncing: Fatal exception ]---
Thanks for posting these logs. I will look into them in due course.
Hi @Smithx10, I've looked at these logs. The first panic seems to be unrelated to DRBD, but the second looks related. I'm guessing it is caused by some race condition between the connection loss code and the resync request completing. Unfortunately there isn't enough information to work out how this might be happening.
Do you still have the preceding kernel logs?
Are you able to reproduce the problem?
Good Morning @JoelColledge ,
Sorry at the moment I don't have that build running.
Is there a better way to capture more information for you or settings I can add to these storage nodes?
@Smithx10
Is there a better way to capture more information for you or settings I can add to these storage nodes?
In this case simply collecting a longer section of the kernel logs might help. A packet trace would be very helpful, but I know that collecting this is often not feasible.
This may have been fixed by https://github.com/LINBIT/drbd/commit/f6a70dc080ed5db90496b695d099c69885c529ca. Please test with the latest master @Smithx10.
If you are not able to test at the moment, I will close this issue assuming it has been fixed.
Closing due to the lack of a response. Assumed to be fixed in drbd-9.2.2
.
While Testing performance with nvme-tcp with DRBD I received a panic:
Client workload was the following FIO:
Client Side:
ServerSide:
Panic Output: