Bug #9249
closedSystem crash dump to NVME not working
100%
Description
dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel dumping: 0:00 1% done 1% done: 6146 pages dumped, dump failed: error 11
The problem was introduced in #8628, which works correctly under normal conditions, but when the system is panicking, semaphores behavior becomes inconsistent:
- sema_p() would allow the count to go down to 0, and NOT block
- sema_tryp() used in io submission queue would then never succeeded
- and sema_v() would NOT increase the count at all
So the operation seem to go normal, with one cmd at time during panic -- we get cmd to the queue, do a sema_tryp() (count goes down), cmd completed, we take it out of the queue, do a sema_v() (count does NOT go up), so we return EAGAIN after 'count' cmds have been processed.
The fix here is to make semaphores complete no-op during panic.
Related issues
Updated by Yuri Pankov over 4 years ago
- Subject changed from kernel dump fails on emulated nvme in VMware ESXi VM to System crash dump to NVME not working
- Category set to kernel
- Status changed from New to In Progress
- Assignee set to Yuri Pankov
- % Done changed from 0 to 50
- Difficulty changed from Medium to Bite-size
- Tags deleted (
needs-triage)
Updated by Electric Monk over 4 years ago
- Status changed from In Progress to Closed
- % Done changed from 50 to 100
git commit 64216313af8955ed170cf25df29a04c18b3e0296
commit 64216313af8955ed170cf25df29a04c18b3e0296 Author: Joyce McIntosh <joyce.mcintosh@nexenta.com> Date: 2018-08-07T17:37:45.000Z 9249 System crash dump to NVME not working Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com> Reviewed by: Evan Layton <evan.layton@nexenta.com> Reviewed by: Rick McNeal <rick.mcneal@nexenta.com> Reviewed by: Ryan Zezeski <rpz@joyent.com> Approved by: Dan McDonald <danmcd@joyent.com>
Updated by Marcel Telka over 4 years ago
- Related to Bug #8628: nvme: use a semaphore to guard submission queue added