| Message ID | 134955874b401e6764077393c75ab2d4549b940a.camel@wdc.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote: > I applied your change, and rebuilt the Linux kernel. Unfortunately, it > looks like, it didn’t make a difference. In that case I don't know what is causing the failure. Can you run a bisect to determine which commit introduced this regression? Thanks, Bart.
Dear Bart, Am 24.04.2018 um 23:17 schrieb Bart Van Assche: > On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote: >> I applied your change, and rebuilt the Linux kernel. Unfortunately, it >> looks like, it didn’t make a difference. > > In that case I don't know what is causing the failure. Can you run a bisect > to determine which commit introduced this regression? With `scsi_mod.use_blk_mq=n` the system resumes fine, so for to me unknown reasons, that Kconfig option get selected in my Linux kernel configuration. I remember having similar issues when this was enabled by default in Linux 4.13-rc?, so it was just a configuration problem and not a regression. Unfortunately, the Linux configuration files are not under version control, so I cannot check, but it is probably my fault. Sorry for the noise, and please tell me, what I can do to get the option working on this old device. Kind regards, Paul
On Wed, 2018-04-25 at 07:37 +0200, Paul Menzel wrote: > Am 24.04.2018 um 23:17 schrieb Bart Van Assche: > > On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote: > > > I applied your change, and rebuilt the Linux kernel. Unfortunately, it > > > looks like, it didn’t make a difference. > > > > In that case I don't know what is causing the failure. Can you run a bisect > > to determine which commit introduced this regression? > > With `scsi_mod.use_blk_mq=n` the system resumes fine, so for to me > unknown reasons, that Kconfig option get selected in my Linux kernel > configuration. I remember having similar issues when this was enabled by > default in Linux 4.13-rc?, so it was just a configuration problem and > not a regression. Unfortunately, the Linux configuration files are not > under version control, so I cannot check, but it is probably my fault. > > Sorry for the noise, and please tell me, what I can do to get the option > working on this old device. Hello Paul, Did the same system boot fine with a previous kernel with scsi-mq enabled? Anyway, we would like to know what is the root cause such that this NULL pointer dereference can be fixed. There are namely plans to remove the legacy block layer in the not too distant future. Thanks, Bart.
Dear Bart, On 04/25/18 14:26, Bart Van Assche wrote: > On Wed, 2018-04-25 at 07:37 +0200, Paul Menzel wrote: >> Am 24.04.2018 um 23:17 schrieb Bart Van Assche: >>> On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote: >>>> I applied your change, and rebuilt the Linux kernel. Unfortunately, it >>>> looks like, it didn’t make a difference. >>> >>> In that case I don't know what is causing the failure. Can you run a bisect >>> to determine which commit introduced this regression? >> >> With `scsi_mod.use_blk_mq=n` the system resumes fine, so for to me >> unknown reasons, that Kconfig option get selected in my Linux kernel >> configuration. I remember having similar issues when this was enabled by >> default in Linux 4.13-rc?, so it was just a configuration problem and >> not a regression. Unfortunately, the Linux configuration files are not >> under version control, so I cannot check, but it is probably my fault. >> >> Sorry for the noise, and please tell me, what I can do to get the option >> working on this old device. > Did the same system boot fine with a previous kernel with scsi-mq enabled? No, as far as I know it never worked, see thread *[Regression 4.13-rc1] Resume does not work on Lenovo X60t* [1]. > Anyway, we would like to know what is the root cause such that this NULL > pointer dereference can be fixed. There are namely plans to remove the > legacy block layer in the not too distant future. I’ll be happy to test proposed changes. Kind regards, Paul PS: Your mailer also changed *doesn’t* to *doesn* in the subject line. [1] https://www.spinics.net/lists/linux-scsi/msg111457.html
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 57cae47ab1c2..b029a94a1e66 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -3272,7 +3272,6 @@ static void sd_probe_async(struct work_struct *work) gd->events |= DISK_EVENT_MEDIA_CHANGE; } - blk_pm_runtime_init(sdp->request_queue, dev); device_add_disk(dev, gd); if (sdkp->capacity) sd_dif_config_host(sdkp); @@ -3390,6 +3389,8 @@ static int sd_probe(struct device *dev) get_device(dev); dev_set_drvdata(dev, sdkp); + blk_pm_runtime_init(sdp->request_queue, dev); + get_device(&sdkp->dev); /* prevent release before sd_probe_async() */ WARN_ON_ONCE(!queue_work(system_unbound_wq, &sdkp->probe_work));