Date: Wed, 04 May 2022 03:23:44 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 263704] Panic because device went away with XPT_ATA_IO pending Message-ID: <bug-263704-227-22aQ9CGr7G@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-263704-227@https.bugs.freebsd.org/bugzilla/> References: <bug-263704-227@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=3D263704 Warner Losh <imp@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress Assignee|bugs@FreeBSD.org |imp@FreeBSD.org --- Comment #1 from Warner Losh <imp@FreeBSD.org> --- On further examination, it appears to be a bug in the dynamic I/O scheduler. We can call xpt_schedule(CAM_PRI_NORMAL) during recovery which causes all existing periphs that use it to schedule their recovery operation a second time, but at a bad priority. It has nothing to do with dropping references to the device, but rather causing extra I/O to be scheduled that can persist after the periph is invalidated (because the periph driver knows nothing of the extra CCBs) leading to accessing the path after it's been freed which leads to a number of different pathologies depending on where in the CCB lifecycle we wakeup. It only affects the dynamic scheduler (all the time, but that points out anoth= er bug, the timeout ticker shouldn't run all the time if there's nothing to be controlled like bandwidth or iops). --=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-263704-227-22aQ9CGr7G>