On 14/07/17 15:44, Christoph Hellwig wrote:

can you please report what hardware this is one (e.g. libata or
real scsi, which driver), a kernel config and the actual command
used to suspend the system (to ram, to disk?) so that I an try to
reproduce it?

The hardware I used to bisect the problem is is Broxton: Asrock 
ITX-J3455 motherboard with Intel J3455 SoC (about Skylake Gen). Disk is 
Intel SATA SSD. Issue also happens with Samsung SSD on other testhost.

Note that there is half dozen other hosts indicating the same problem, 
and traces are available starting from ILK to Skylake. None of the Kaby 
Lakes triggers the issue (the KBL issue is probably NVMe-related 
instead). Usual setup is one SATA SSD disk on port 0 on motherboard.

Kernel config is available at:
https://intel-gfx-ci.01.org/CI/next-20170711/kernel.config.bz2

Kernel options:
BOOT_IMAGE=/boot/drm_intel root=/dev/sda2 console=ttyS0,115200n8 
console=tty0 intel_iommu=igfx_off drm.debug=0xe nmi_watchdog=panic,auto 
panic=1 softdog.soft_panic=1 rootwait ro 3

To reproduce the problem on Broxton, i-g-t was used:
https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

 From i-g-t, the binaries could be run with:

tests/gem_exec_gttfill --r basic
tests/gem_exec_suspend --r basic-s3

but, from my experience, this issue pops up much easier if there is 
piglit framework capturing logs to disk:

https://cgit.freedesktop.org/piglit

With IGT/piglit testlist file would be (ex. scsi-mq.testlist):
#
igt@gem_exec_gttfill@basic
igt@gem_exec_suspend@basic-s3
#
and command to run i-g-t through piglit is
/opt/igt/scripts/run-tests.sh -vT scsi-mq.testlist

I can try to reproduce the issue without i-g-t/piglit, but it might take 
some trying. Definitely suspend-to-ram and writes to disk are needed to 
trigger this, gem_exec_suspend/basic-s3 can loop quite well without 
panicing.

Tomi
-- 
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo