Page Menu
Home
FreeBSD
Search
Configure Global Search
Log In
Files
F168890331
D20478.id58096.diff
No One
Temporary
Actions
View File
Edit File
Delete File
View Transforms
Subscribe
Mute Notifications
Flag For Later
Award Token
Size
980 B
Referenced Files
None
Subscribers
None
D20478.id58096.diff
View Options
Index: sys/dev/nvme/nvme_qpair.c
===================================================================
--- sys/dev/nvme/nvme_qpair.c
+++ sys/dev/nvme/nvme_qpair.c
@@ -513,7 +513,17 @@
"cpl does not map to outstanding cmd\n");
/* nvme_dump_completion expects device endianess */
nvme_dump_completion(&qpair->cpl[qpair->cq_head]);
- KASSERT(0, ("received completion for unknown cmd\n"));
+ /*
+ * If we're panicing, or we've stopped the sceudler just
+ * before we panic, don't assert consistency. We can
+ * arbitrarily interrupt other threads on panic, leading
+ * the qpair structure in an inconsistent state when we
+ * poll to complete the dumping I/O. This inconsistency is
+ * detected by the KASSERT bogusly, preventing a dump
+ * from completing while in this state.
+ */
+ if (!(dumping || SCHEDULER_STOPPED()))
+ KASSERT(0, ("received completion for unknown cmd\n"));
}
if (++qpair->cq_head == qpair->num_entries) {
File Metadata
Details
Attached
Mime Type
text/plain
Expires
Mon, Aug 31, 3:27 PM (2 h, 17 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
37697719
Default Alt Text
D20478.id58096.diff (980 B)
Attached To
Mode
D20478: Since a fatal trap can happen at aribtrary times, don't panic when the completions are not in a consistent state.
Attached
Detach File
Event Timeline
Log In to Comment