On Wed, Jun 05, 2019 at 09:25:37AM -0700, Guenter Roeck wrote:
> On Wed, Jun 05, 2019 at 09:06:20AM +0800, Ming Lei wrote:
> > Hi,
> >
> > Guenter reported scsi boot issue caused by commit c3288dd8c232
> > ("scsi: core: avoid pre-allocating big SGL for data").
> >
> > Turns out there are at least three issues.
> >
> > The 1st patch fixes sg_alloc_table_chained() which may try to use
> > the pre-allocation SGL even though user passes zero to 'nents_first_chunk'.
> >
> > The 2nd patch fixes issue in case that NO_SG_CHAIN on some ARCHs,
> > such as alpha, arm and parisc.
> >
> > The 3rd patch makes esp scsi working with SG_CHAIN.
> >
> > V2:
> > - add the patch1, which is verified by Guenter
> > - add .prv_sg to store the previous sg for esp_scsi
> >
> > Ming Lei (3):
> > scsi: lib/sg_pool.c: clear 'first_chunk' in case of no pre-allocation
> > scsi: core: don't pre-allocate small SGL in case of NO_SG_CHAIN
> > scsi: esp: make it working on SG_CHAIN
> >
>
> Running my tests on next-20190605, I get:
>
> Qemu test results:
> total: 349 pass: 296 fail: 53
>
> The same tests on next-20190605 plus this series results in:
>
> Qemu test results:
> total: 349 pass: 347 fail: 2
> Failed tests:
> sh:rts7751r2dplus_defconfig:usb:rootfs
> sh:rts7751r2dplus_defconfig:usb-hub:rootfs
>
> The remaining failures are consistent across re-runs. The failure is only
> seen when booting from usb using the sm501-usb controller (see below).
>
> usb 1-2.1: reset full-speed USB device number 4 using sm501-usb
> sd 1:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=0x00
> sd 1:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 08 7c 00 00 f0 00
> print_req_error: I/O error, dev sda, sector 2172 flags 80700
> usb 1-2.1: reset full-speed USB device number 4 using sm501-usb
> sd 1:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=0x00
> sd 1:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 01 da 00 00 f0 00
> print_req_error: I/O error, dev sda, sector 474 flags 84700
> usb 1-2.1: reset full-speed USB device number 4 using sm501-usb
> sd 1:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=0x00
> sd 1:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 02 da 00 00 f0 00
> print_req_error: I/O error, dev sda, sector 730 flags 84700
> usb 1-2.1: reset full-speed USB device number 4 using sm501-usb
> sd 1:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x03 driverbyte=0x00
> sd 1:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 0b 50 00 00 f0 00
> print_req_error: I/O error, dev sda, sector 2896 flags 84700
>
> Presumably that means that either the sm501-usb emulation has a subtle bug
> associated with SG, or something is wrong with the sm501-usb driver.
>
Turns out the above is caused by other (unrelated) patches in the sm501
USB driver. After reverting those, everything is fine. Sorry for the noise.
Please feel free to add
Tested-by: Guenter Roeck <linux@xxxxxxxxxxxx>
to all three patches.
Thanks,
Guenter
> The qemu command line in the failure case is:
>
> qemu-system-sh4 -M r2d \
> -kernel ./arch/sh/boot/zImage \
> -snapshot \
> -usb -device usb-storage,drive=d0 \
> -drive file=rootfs.ext2,if=none,id=d0,format=raw \
> -append 'panic=-1 slub_debug=FZPUA root=/dev/sda rootwait console=ttySC1,115200 earlycon=scif,mmio16,0xffe80000 noiotrap' \
> -serial null -serial stdio \
> -net nic,model=rtl8139 -net user -nographic -monitor null
>
> I'll be happy to provide kernel configuration and a pointer to the root file
> system if needed.
>
> Thanks,
> Guenter
