Re: blktests scsi/007 failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Apr 14, 2023 / 08:09, Chaitanya Kulkarni wrote:
> On 4/14/2023 12:36 AM, Shin'ichiro Kawasaki wrote:
> > Hello Bart,
> > 
> > Recently, I built a new blktests trial environment on QEMU. With this
> > environment, I observe scsi/007 failure. FYI, let me share blktests output [1]
> > and kernel message [2].
> > 
> > I found the failure depends on kernel configs for debug such as KASAN. When I
> > enable KASAN, the test case fails. When I disable KASAN, the test case passes.
> > It looks that the failure depends on the slow kernel (and/or slow machine).
> > 
> > The test case sets 1 second to the block layer timeout to trigger the SCSI error
> > handler. It also sets 3 seconds to scsi_debug delay assuming the error handler
> > completes before the 3 seconds. From the kernel message, it looks that the error
> > handler takes longer than the 3 seconds delay, so I/O completes as success
> > before the error handler completion. This I/O success is not expected then the
> > test case fails. As a trial, I extended the scsi_debug delay time to 10 seconds,
> > then I observed the test case passes.
> > 
> > Do you expect the I/O success by slow SCSI error handler? If so, the test case
> > needs improvement by extending the scsi_debug delay time.
> > 
> > 
> 
> I faced the same problem, but increased timeout it is passing :-

Good to know that I'm not the only one seeing this issue :)

[snip]

> 
> echo "I/O timeout = $(<"/sys/class/block/$dev/queue/io_timeout")" 
>  >>"$FULL"                                                   # Change 
> the scsi_debug delay to 3 seconds. 
>                                    -       delay_s=3 
>  
>                 +       delay_s=10 

Yes, I did similar trial and observed the test case passes. While I tried it, I
observed that longer delay time is required when I add more kernel debug options
(KASAN, lock related options, etc). So, delay extension to 10 seconds may not be
enough to cover slower kernels or slower systems. I guess the test case will
need some time measurement to decide the delay time good for the system. But
before discussing such test case fix, I wanted to confirm that the delay time
extension is the right fix approach.




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux