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?
