On Wed, Aug 01, 2018 at 11:33:03AM +0100, Mark Brown wrote: > On Wed, Aug 01, 2018 at 11:05:36AM +0100, Guillaume Tucker wrote: > > On 31/07/18 16:14, kernelci.org bot wrote: > > > > Boot Regressions Detected: > > [...] > > > x86: > > > > > > x86_64_defconfig: > > > qemu: > > > lab-baylibre: failing since 1 day (last pass: next-20180727 - first fail: next-20180730) > > > lab-mhart: failing since 1 day (last pass: next-20180727 - first fail: next-20180730) > > > lab-linaro-lkft: failing since 1 day (last pass: next-20180727 - first fail: next-20180730) > > > I've run a few automated bisection on kernelci.org, it initially > > landed on this merge commit: > > > ff719be3476a Merge remote-tracking branch 'scsi/for-next' > > > The 2 parent commits boot fine, but not the resulting merge. So I > > did another bisection based on the first branch while merging the > > incoming one in each iteration, and that landed on this commit: > > > commit d5038a13eca72fb216c07eb717169092e92284f1 > > Author: Johannes Thumshirn <jthumshirn@xxxxxxx> > > Date: Wed Jul 4 10:53:56 2018 +0200 > > > > scsi: core: switch to scsi-mq by default > > > > > > I then tried to revert it on top of next-20180731 and it did make it > > boot again. Now, I haven't looked much further in the code, it's > > entirely possible that the problem is on another incoming branch, in > > the code that this config enables. At least it seems to be narrowing > > down the scope for where to look for a problem. > > Copying in everyone else who signed off/acked/reviewed that commit. You may have to provide some clue, such as dmesg log, boot disk, ... I guess you don't use virtio-scsi/virtio-blk since both run at blk-mq mode at default, even though without d5038a13eca72fb. Thanks, Ming
