Date: Mon, 16 Oct 2017 10:45:45 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-scsi@FreeBSD.org Subject: [Bug 222898] [iscsi]: panic: page fault - system crashes while working as iSCSI target Message-ID: <bug-222898-5312-ZCWkzv642Y@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-222898-5312@https.bugs.freebsd.org/bugzilla/> References: <bug-222898-5312@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222898 --- Comment #8 from emz@norma.perm.ru --- Well, I took a risk and installed a stock r315520. Unfortunately, the behav= ior is identical: crash within dozens of seconds after starting ctld, same panic message on a debug kernel: =3D=3D=3DCut=3D=3D=3D WARNING: 213.152.134.114 (iqn.1991-05.com.microsoft:worker85): no ping reply (NOP-Out) after 5 seconds; dropping connect ion WARNING: 213.152.138.158 (iqn.1991-05.com.microsoft:worker265): no ping rep= ly (NOP-Out) after 5 seconds; dropping connec tion WARNING: 213.152.134.62 (iqn.1991-05.com.microsoft:worker33): no ping reply (NOP-Out) after 5 seconds; dropping connecti on WARNING: 213.152.134.114 (iqn.1991-05.com.microsoft:worker85): no ping reply (NOP-Out) after 5 seconds; dropping connect ion panic: destroying session with 4 outstanding PDUs cpuid =3D 24 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe105789a= 8f0 vpanic() at vpanic+0x186/frame 0xfffffe105789a970 kassert_panic() at kassert_panic+0x126/frame 0xfffffe105789a9e0 icl_soft_conn_close() at icl_soft_conn_close+0x20a/frame 0xfffffe105789aa10 cfiscsi_maintenance_thread() at cfiscsi_maintenance_thread+0x100/frame 0xfffffe105789aa70 fork_exit() at fork_exit+0x84/frame 0xfffffe105789aab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe105789aab0 --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- Uptime: 1m55s =3D=3D=3DCut=3D=3D=3D I am running a non-debug version of r315520 right now (so there's no either explicit regression or improvement over the r310734), it's still tending to crash in random moments of time when loaded by 299 initiators. As a workaround I will try to diminish the load by transferring some initia= tors to a spare SAN. Crashdumps, binaries and infos: http://files2.enaza.ru/ctld-stuck/r315520/ In the same time I'm still willing to help in any way in resolving this, including the access on a production system, over ssh/IPMI/whatever. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-222898-5312-ZCWkzv642Y>