On 24/09/2024 11:06, Francesco Lavra wrote:
On Mon, 2024-09-23 at 01:47 +0300, Max Gurtovoy wrote:
On 17/09/2024 17:09, Marek Szyprowski wrote:
Hi Max,
On 17.09.2024 00:06, Max Gurtovoy wrote:
On 12/09/2024 9:46, Marek Szyprowski wrote:
Dear All,
On 08.08.2024 00:41, Max Gurtovoy wrote:
Set the driver data of the hardware context (hctx) to point
directly to
the virtio block queue. This cleanup improves code
readability and
reduces the number of dereferences in the fast path.
Reviewed-by: Stefan Hajnoczi <stefanha@xxxxxxxxxx>
Signed-off-by: Max Gurtovoy <mgurtovoy@xxxxxxxxxx>
---
drivers/block/virtio_blk.c | 42
++++++++++++++++++++------------------
1 file changed, 22 insertions(+), 20 deletions(-)
This patch landed in recent linux-next as commit 8d04556131c1
("virtio_blk: implement init_hctx MQ operation"). In my tests I
found
that it introduces a regression in system suspend/resume
operation. From
time to time system crashes during suspend/resume cycle.
Reverting this
patch on top of next-20240911 fixes this problem.
Could you please provide a detailed explanation of the system
suspend/resume operation and the specific testing methodology
employed?
In my tests I just call the 'rtcwake -s10 -mmem' command many times
in a
loop. I use standard Debian image under QEMU/ARM64. Nothing really
special.
I run this test on my bare metal x86 server in a loop with fio in the
background.
The test passed.
If your kernel is running on bare metal, it's not using the virtio_blk
driver, is it?
It is using virtio_blk driver.
I'm using NVIDIA BlueField-3 Virtio-blk device.
